We’ve all faced resource limited situations that just didn’t seem possible. Here’s a story of grace under fire, and how sound technical leadership can make all the difference…
This is a true story, but I’m withholding names and dates to protect the innocent (and not so innocent) parties. It happened in a venture capital-backed startup not long ago.
The Self Inflicted Wound
There are some wounds you just can’t avoid. Then there are the wounds you inflict upon yourself. Sometimes you just don’t realize they’re avoidable at the time. So the next best thing is to clean, fix, and dress these wounds as quickly as you can. But first you must accept what you’ve done, and deal with the consequences.
Our self-inflicted wound was to threaten to miss a delivery date that we committed to for a product that a large, strategic partner was going to take to market under their own brand. By large I mean the kind of company that coordinates events far in advance, and has serious issues changing schedules once things are in motion – not to mention it’s fanatical about protecting its reputation. I say “threaten to” because at least we had the sense to warn them in advance – not far in advance, mind you. Our product management felt there were higher priorities months before this (after it committed), but did not adequately discuss the possibility of missing the date with the partner until there were about 3 weeks left. In fact the topic only came up when the partner called for “11th hour” status. As you can see, this was a .50 caliber shot to our own proverbial foot.
The Horse’s Mouth
One afternoon about 3 weeks before delivery, I was busy working on technology strategy and vision. I had begun to transition more into a traditional CTO role than the technical leadership one I had in earlier stages of the company, and had thus not been working closely with the engineering team for a while. I still advised them regularly given that I had written most of the code, but my role was evolving along with the company as it grew.
I received a call from the CEO to meet him in his office, and walked over right away. When I entered, I saw that things were not pretty. This large partner of ours sent an entire product team delegation. Our VP’s of Product Management and Engineering looked bewildered. I sat down in an empty chair directly in front of the CEO’s desk, and asked how I could help. He explained to me that our partners were “in a world of hurt” now that they’d realized we were going to miss our date. They would have no choice but to pull the product, fire some of their staff for dealing with us, revoke most of our business agreements, and likely even pursue legal action to recover damages. If you read between the lines, it was obvious that our company would not survive such consequences. He then asked me directly, “can we do this?” He wanted our partners to hear from the “horse’s mouth”, from the “father” of the product and the spiritual leader of technology in our company, be it strategy or execution, that we could do this as promised. The horse said yes, without hesitation. Self-inflicted wound? Perhaps – the type where you cut off your arm in order to free yourself from the boulder you’ve been trapped under for the last few days, after exhausting all other options.
Entrepreneurial chutzpa aside, I immediately (politely) started negotiating deliverables with our partners. It turns out that we had committed to a handful of very specific things, and I knew that if we focused on solution rather than implementation, we could deliver. In other words, we didn’t need to build iPod-like user experience for each promised function. I knew right away that we could get away with delivering functionality with lots of known issues. I also realized that the delivery date was awfully close to the holiday season, and that we would probably have time for a “service pack” before the product really penetrated the market a few weeks later. This was as much about saving face for our partner as it was about selling product. For me it was about one thing alone – doing the right thing – that thing that we had promised to do.
Technical Leadership in its Finest Hour
It began in the CEO’s office as soon as our partners left the building, cautiously optimistic that we would deliver the goods as promised. The product manager just about had a stroke and could not believe that we would commit to such a thing. Even when we pointed out there was no real alternative here, it was still not possible for him to grasp. The engineering lead, who had only been with the company for a few weeks, simply trusted that we would get it done. In his case, ignorance was bliss, so to speak – especially since I took personal responsibility for the commitment. I just told him to try to keep up, and that I would get it done. This arrangement worked well from that point forward.
The very next thing to do was of course to get to work. This began with me addressing the team directly. In situations like these, I can’t help but think of Ed Harris in the movie Apollo 13 (obviously a dramatic reenactment of real events) stating with conviction that “this will be our finest hour” in response to naysaying about the challenge ahead:
I’m in no way trying to compare situations, because what those men did (in real life) was truly impossible, but it worked well in this context. I told the team very clearly what the situation was, what was at stake (in slightly more abstract terms than what the CEO told me), and that I believed this would be our finest hour. The key was for them to believe that I believed, and they did. “Grace under fire” is what I kept repeating in my head. I then outlined a very simple process (in place of the Waterfall-like system the team had been using at that time) – basically a 3 week sprint with daily standups and real-time triage in a “fail fast” approach. I explained what functionality was mandatory, and that everything else did not matter. I gave them a very good sense of technical leadership by example, as I next rolled up my sleeves and hit the code, with them.
I will never forget the effort the team put in over the next 3 weeks. Everyone believed this could be done. We hid any non-critical functionality that wasn’t working reliably. We made tough tradeoffs (but with open eyes) in terms of short term delivery and long term viability. We opened refactoring tasks in the backlog for technical debt we knew we had to incur. I personally logged dozens of known issues, sending our technical writer large amounts of data each day to note. My office resembled a forward battlefield hospital tent, except we were operating on the product rather than soldiers. We amputated. We cleaned. We dressed. But most importantly, we delivered.
It’s easy to argue that my efforts went beyond technical leadership itself. But when working with highly experienced developers, I don’t think there is any more effective range of leadership than being able to both get your hands dirty and stay focused on the highest level business objectives at the same time. It helped my credibility tremendously that I was already so close to the code – I did not have to sell the belief to the team, they just knew it. I’m not a fan of anything but hands on leadership in technical teams, especially in startups, but even if you’re not hands-on, I think there are some important lessons to take away and implement in situations like these:
- Believe. If you don’t believe, neither will your team. There is always a way to achieve the seemingly impossible. Identify the hard constraints early, and negotiate everything else. Find the right balance and compromise between short term delivery and long term sustainability. This is your job as a leader. The first and most important part of winning is to believe you are going to win. Everything else depends on that. Visualize winning. Then do it.
- Lead by example. This is always mandatory, but never more than when you are asking a team for extraordinary effort. If you don’t code, figure out some way to get into the product itself. Maybe it’s documentation (reviewing manuals, reporting known issues, etc.), maybe it’s testing, maybe something else – but find *something*. It doesn’t matter if your title is CTO, VP of Engineering, Supervisor, or Software Engineer. If you are in charge of a development effort, be it full time or temporary, you are practicing technical leadership in this day and age, especially in startup environments.
- Avoid administrative overhead of any sort. Don’t even think about mandatory overtime. Do not micromanage, even though you will be very close to the action. If your team cannot be accountable to deliver in whatever time they need, you have the wrong team. Remember, you already chose to believe.
- Stay cool under pressure. Pressure will be there whether you accept it calmly or not. I believe this quality is key to startup “DNA”, but it can apply in any size company. Grace under fire is one of the most important traits you can have as a manager – and it’s infectious.
I must add one more thing. If you are not empowered to tackle a situation like this and make the necessary adjustments and sacrifices, do not accept the challenge. I was empowered to do anything and everything except fail – and not because it was presented that way, but because I demanded it. Don’t confuse this as a promotion or change in responsibilities long term (it may or may not be), but part of accepting a seemingly impossible task is to make clear that you are empowered to fully execute it. During this effort, none of the engineers reported directly to on the organizational chart. But they took direction solely from me, and if I had had to make personnel changes, I would have.
One Response to Technical Leadership for Impossible Situations