Back in the early 00s I spent some time doing technical due diligence for a couple of VC firms, and I’ve dabbled at it over the years since. A useful assessment covers a ton of ground in not very much time, so it’s pretty important to get to the good stuff quickly. When it comes to evaluating technical leaders / co-founders / CTOs, I’ve found that one question performs better than any other: “How much code do you write these days?”
Giving away the punch line up front, I believe that every great CTO regularly writes production code. By phrasing the question as “how much” — I telegraph the assumption that of course they write at least some. A totally reasonable answer may be a lot or a little, depending on the stage of the company and makeup of the overall team — but it’s never zero.
You talking to me?
I understand that this is not a commonly-held expectation. For some reason, people seem to equate technical growth with getting farther away from code. They say things like “I set direction and need to avoid getting bogged down by details,” or “I’m just too busy managing the team to write code.” I find this incomprehensible. Details make or break success in our business — you simply cannot lead smart people living those details if you don’t honestly understand and share their experiences.
I ask the same question when interviewing and mentoring folks at every level of technical leadership. And look, I’m not saying that all that other stuff isn’t really important — of course it is. A CTO that hides in their office coding all day is not doing their job either. I just don’t see that very often.
Wait you say, I used to write code, I do understand. No you don’t, for two reasons. First, technology moves incredibly fast — core skills like encapsulation and abstraction are evergreen, but everyday patterns and rhythms evolve constantly. Containers, microservices, CD/CI, serverless computing, ML as a service, etc. etc. … you cannot judge their fitness for your purpose unless you really grok how they work, and that depth only comes from hands-on experience. Sales pitches and YouTube videos don’t count. Second, we quickly forget the realities of delivering code for much the same reason that the moms among us forget the painful realities of delivering babies — our brains soften the hard edges of memory over time. (Note this dynamic isn’t all bad; it explains why there are little brothers and sisters in the world.)
Code is Life!
Keeping your head in the details is reason enough to dedicate a few hours a week, but code is the gift that keeps on giving:
1. You’ll ship a bug. It’s more humbling than you may remember, will help make you more empathetic, and it’s a powerful message to your team. Everybody makes mistakes. Suck it up, take personal responsibility, and work hard until the bug is squished and fixed. Also, very little brings a technical team together like making fun of the boss — show them you can take it with grace.
2. You’ll be better at assessing difficulty and challenging estimates. Everything sounds easy when you ignore the details. Everything looks hard when it’s your job to get it done. A CTO is always trying to strike a balance between trusting their team and challenging them. When you can converse about the details of a feature, you’re in a better position to do that.
3. You’ll establish better 1:1 relationships with your team. Your code can’t exist in a vacuum; it will interact with other features and components. Working out those interfaces, debugging cross-system problems — those are opportunities to work in real time with folks across the team, especially those at “lower” levels you might not run into in daily leads meetings and such. Sure you can fabricate interaction with skip level meetings, team events, etc. — fine stuff, but not nearly as sticky as time in the trenches. These are also priceless teaching moments for young engineers.
4. You’ll feel a richer sense of self. Wow does that sound pompous. But how many of us in managerial roles drive home on Friday night wondering what the hell we actually DID all week? We went to meetings, “fought fires” (ugh I hate that phrase), sent email, looked at budgets, had lunch. All of it is important, but it’s impossible to explain to our kids and grandkids, and often even to ourselves. This old guy has come to believe that we are creative beings that need to create things to be happy. Code may be virtual, but it’s most definitely a creative work product. It does stuff. You can re-read it and relive all the tradeoffs, mistakes and dead ends that led to the final result. I don’t think it’s just me — this matters.
Fired Up? Ready to Go!
One last thought before you sudo apt install emacs (of course) and start writing — a word of caution. It’s important that you code; it’s just as important that you pick the right code for your company and team. If you’re really just starting up, go hard and lay as much track as you can — but that’s obvious. If your team is ten or fifteen or so, you probably can still own a key component and do a good job. But much beyond that, stay out of the critical path. Pick something a little out of the way, that isn’t time-critical or going to grind the business to a halt if you don’t get it done when you thought. There are a couple of reasons for this, pretty basic but I’ll call them out anyways:
- You are going to be distracted by the other parts of your job. That’s just reality — you can’t deliver with the consistency of a dedicated engineer.
- You are no longer the primary owner of the codebase overall — your leads and senior devs are. Don’t be walking on their lawn uninvited.
One great way for a midsize CTO to spend their coding time starts with log trolling. Pull out production logs and see what is going on — for 100% sure you’re going to find some weird errors in there that happen regularly, but don’t seem to be obviously tied to outages or other error conditions. Track those logs down in source and figure out what they really mean and what must be happening. Sometimes it really will be nothing, in which case you can do everyone a favor and fix the log spam. But many times you’ll find that something truly bad is happening, just not quite above the radar. Maybe it’s a canary for a slowly-growing problem, or is evidence that your end users are having a terrible experience and just assume you suck rather than report it.
Another option is to scan the backlog for feature asks that would really help, but always get postponed. Maybe your configuration system doesn’t hot-reload, or a download format isn’t escaping fields correctly, or users really want SMS alerts rather than just email. Look for things that are relatively self-contained and easily tested, so that you don’t over-burden other team members who are already busy doing their own jobs.
Or whatever — you know your codebase better than I do. Just make sure you dig into the details AND find a way to do it without driving your team (too) crazy. I’m pretty sure you’ll have fun, and I know for absolute sure that you’ll be a better CTO. Woot!