One of the recurring debates about senior engineering leadership roles is whether Chief Technology Officers should actively write code. There are a lot of strongly held positions, from “Real CTOs code.” at one end of the spectrum, to “Low ego managers know they contribute more by focusing on leadership work rather than coding.” There are, of course, adherents at every point between those two extremes. It’s hard to take these arguments too seriously, because these values correlate so strongly with holders’ identities: folks who believe they are strong programmers argue that CTOs must code, and people who don’t feel comfortable writing software take the opposite view.
There’s another question that I find more applicable in my own career: If I have five spare hours each week, how should I invest that time? It’s hard to answer that without specifying your investment goal, so a more complete version of the question is “If I have five spare hours each week, how should I invest that time to maximize my impact and long-term engagement?”
In most CTO roles, you have roughly four options:
- Build deep context – Write code, or otherwise engage in the detailed work within the Engineering organization you lead
- Build broad context – Expand your context outside of Engineering, better understanding your peer function’s work, goals and obstacles. This might be talking with customers, discussing product tradeoffs, understanding how marketing is driving interesting, etc
- Improve current systems and process – Work on your engineering strategy, planning process, or pretty much any existing element of how your Engineering organization operates
- Build relationships – Expand your internal or industry networks
These are all valid ways to invest your time, and picking among them for your last five hours depends on what your role needs from you, and what you need from your role. You should be wary – and honestly somewhat weary – of anyone who tells you, context-free, what’s important for you and your role. You should likely be capable of doing all of those, but there are many ways to do them, and what’s optimal in your circumstances is deeply context-specific.
There are some general rules. Smaller and pre-market fit companies are more likely to need their executives to build deep context. Larger and multi-business unit companies are more likely to benefit from broad context or improvements to existing systems and processes. They’re just generalized rules though, make the decisions for yourself.