Stephan Schmidt
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.
