Taking the last hurdle to become a CTO
Mastering the Box Metaphor to grow consciousness and avoid regression into operational work
I’m known for my persistent emphasis on the strategic aspects of the Chief Technology Officer role.
In articles like 5 Things Founders, Investors and Recruiters Should Know about the CTO role, I’ve tried to help create a better understanding of the CTO role, and introduced my concept of the more operationally focused “Startup CTO”, warning of the dangers that could accrue should this role remain operationally focused beyond seed stage.
Startup CTOs are Chief Coding Officers (it’s a shame the CCO acronym is already taken 😏).
They focus on getting the software done. They are either, still in the trenches as developers, or they lead a team and are responsible for delivery, thus being Engineering- or Delivery Managers (both operational roles).
Of course, this is not intended as a harsh judgement call about Startup CTOs. They are of course doing what needs to be done, based on the stage of the startup or scaleup.
My point is that they’re certainly not performing much of what a CTO is responsible for; they’re far too operational for that.
Most Startup CTOs are responsible for operational excellence.
If you have operational responsibilities as a CTO, you’re in big trouble.
Being responsible for operational stuff is in direct conflict with having strategic responsibilities. More about this later.
What is Strategic?
The CTO role is a business focused strategic function. Look up Eric Ries’ description in my 5 things article, which I won’t repeat here.
But what the heck is strategic, anyway?
Enter the Box Metaphor
Picture a box. Let’s say that the box stands for everything operational: the rules of the game, the policies, the agile and ALM processes, the software delivery itself, the cultural setup, the reporting lines, the onboarding process, etc.
As a CTO, you’re continuously inspecting ‘the box’, trying to see where you could improve it, to align better with the business objectives, or to adjust based on these changing objectives.
Because Strategy means thinking about where you want to be in the medium/long term, and adjusting the system to increase the chances of getting there.
So, this potentially means changing the box, but changing the box will potentially create friction, and might even cause conflict.
If, for instance, with a looming deadline, and everyone ‘in the box’ is aligned on delivering, you will need to have a strong story in order to justify changing any current elements of the box…
Note that I don’t need to portray any extreme situation here. Anyone running any operation, regardless of it running smoothly, hates change. That’s simply a fact of life, and it plays into any aspect of it, as we all know. Change is hard, because we all tend to hold on to the structure we have — even if it doesn’t serve us well.
This is why I frequently repeat that being responsible for operational stuff is in direct conflict with having strategic responsibilities: if responsible for both, my experience suggests, our choices will be biased toward comfort — avoiding change: operation always wins.
Theory & Practice
Enough theory already! A theoretical understanding turns out to not be enough for people who want to make the step-up to really become strategic.
Having been a Lead Developer, Architect or Engineering Manager, you’ve been invaluable as an individual contributor, ‘in the box’.
This automatically means that deciding where to draw the line as a CTO will be excruciatingly hard, not only from an absolute, theoretical, thought-through perspective, but also from a gratification perspective.
Let’s think this through.
- you’ve probably been good at what you did. The reflex to do it yourself instead of having more inexperienced team members take care of stuff is imminent and can kick in at any time.
- your dopamine levels have been activated by achieving stuff, as an individual contributor. You will never get this immediate gratification from making strategic decisions, so you’ll need to ‘get clean’ first. As long as you’re addicted to the gratifications of being important in the trenches, you’re not really ready.
It’s clear that the psychological aspects add difficulty.
Here are a few important things to consider stopping altogether, with some reflection on what a Strategic CTO should be doing instead:
1. You cannot be a Member of the Team that codes the next feature
But you can assist in architectural brainstorming, coach team members, onboard them in a new technology by showcasing a PoC you built, or help them make a build-or-buy decision, looking at IP and TCO.
2. You cannot be directly responsible for Delivering the next Product/Feature on time
But you can be responsible for empowering the teams, removing blockers, and making the process more efficient, making better build-or-buy decisions, all to have future delivery done faster.
3. You should stop doing People Management
Leave that operational task to an engineering manager.
But you should work on improving the team culture, psychological safety, diversity, and general human skills like empathy, the prioritization of async communication and room for deep work, the prioritization of junior coaching, and documentation quality.
Also, you should have ongoing communication with the engineering manager(s), architects and other team members to prevent losing touch with the operational side.
4. You shouldn’t be the Architect of the SaaS solution
But you could coach and mentor architects, challenge ideas, and could even work on PoCs that show how they could to innovate and implement certain technological ideas.
5. You shouldn’t have Developers directly reporting to you
That would pull you into the operational side of things too much.
But you could have the R&D people report to you, because they are working on longer-term innovation.
Conclusion
Overall, the last step to become a Strategic CTO involves a radical change of mindset, and can certainly be daunting.
And you will see regression.
In your own behavior.
But now that you’ve mastered the Box Metaphor, you’ll never again relapse into operational, individual contributor style behavior without having that little devil on your shoulder warning you.
This newly gained consciousness will not stop regression altogether, but over time, you’ll see that you’ll be able to internalize the desired behavior.
If, after some time, you feel unhappy with this big shift to your new role, and really do still get more gratification from what you did before, the CTO role might not be for you.
But give it some time. It took me more than a year. You don’t lose an addiction overnight.
