Startup CEOs learned Engineering Management from Captain Kirk
How to make estimates work
One type of startup CEO I met through my CTO coachees is one who learned how to manage engineers from Captain Kirk of Star Trek fame. I don’t know if this is the natural way to do it, if this is taught in management schools, or whether the CEO has no other role models than James T. Kirk.
I was reminded of this when re-watching Star Trek DS9. Yesterday there was an episode, where not Kirk but Captain Sisko had to manage an engineer. And in DS9 it goes like this:
Captain Sisko: When are you repairing the gravity net? Last time I was on the bridge I felt ten kilos heavier.
Chief O’Brien: It’s going to take some time.
Captain Sisko: How much time?
Chief O’Brien: Three weeks. We have to replace the graviton stabiliser.
Captain Sisko: You have three days.
Do they learn this at Starfleet Academy? There was an engineer who made a guess on how long things take to make a repair. And the CEO cuts him short by ordering a repair a magnitude - days instead of weeks - lower. Was he thinking the engineer was just slacking off? Or the engineer was too stupid to make estimations? But if so, how could a stupid engineer meet an aggressive deadline?
And the engineer made the classic mistake of saying “Yes” instead of sticking to the estimate. I see this repeatedly with the CTOs I coach. They accept the forced deadlines, then of course they can’t make it. They don’t stand their ground and say “I stand with my professional estimate of three weeks. It can’t be done in three days.” And then are attacked because they couldn’t make the estimate they didn’t make, but the CEO made it without engineering knowledge.
The DS9 episode ends as you’d expect, the engineer does it in three days. This is insidious and where the startup CEOs take their learning from. The engineer is quoting three weeks as an estimate but can make it happen in three days if pressured enough. So, Sisko was right? Always drum with the galley drum. Boom boom boom. Otherwise, my staff doesn’t move. And a whiplash from time to time can’t hurt either.
Never trust an engineer it seems.
There is a grain of truth in this. Often engineers are bad with estimations. Especially if pressured all the time to lower their estimates, they will increase the buffer in their estimates. Which in the end only makes them look bad and reinforces the CEO’s belief that the engineer can’t be trusted.
This disrupts all planning. If you think something is done in three days, and plan accordingly as CEO, and then it takes three weeks, your plan is disrupted. And if this happens repeatedly, there is pure chaos.
The pressure it creates on engineering also disrupts engineering. Everyone shows actionism, runs around, takes shortcuts, and fails with the deadline only to have to live with the shortcuts and improper architecture, to make things take even longer in the future and make the three weeks, five weeks.
Trust is one of the most important things to have in a startup. Trust works like lubrication; everything goes smoother and with less friction and discussion. People trusting each other go outside their comfort zone. The Captain Kirk method of engineering management destroys trust. The CTO does not trust the CEO, the CEO does not trust the CTO.
What can you do as an engineer to solve this?
There are several things you can do. First, have an efficient development process based on fix-bug-first, no-shortcuts, and clean code to have proper and consistent development times. Second, make proper estimates and stick with them. Even under pressure, your estimate is the best that is possible, not the one from the CEO. Third, do everything to increase trust with the CEO. Do the things you promise. Last explain, explain, explain. Explaining things to the CEO in the language of the CEO and the models she has in her head will increase trust in you. If you spout techno-lingo like “graviton stabiliser”, not so. Let’s no longer follow the Starfleet school of engineering management.
As a CTO, Interim CTO, CTO Coach - and developer - Stephan has seen many technology departments in fast-growing startups. As a kid he taught himself coding in a department store around 1981 because he wanted to write video games. Stephan studied computer science with distributed systems and artificial intelligence at the University of Ulm. He also studied Philosophy. When the internet came to Germany in the 90 he worked as the first coder in several startups. He has founded a VC funded startup, worked in VC funded, fast growing startups with architecture, processes and growth challenges, worked as a manager for ImmoScout and as a CTO of an eBay Inc. company. After his wife successfully sold her startup they moved to the sea and Stephan took up CTO coaching. You can find him on LinkedIn or on Twitter @KingOfCoders