The Codeless CTO
A recent conversation among a group of CTOs:
“I was a software engineer for 15 years before I became a CTO, and I still make sure that I code at least 20% of the time, even if I have to do it outside of work. Don’t you think that a CTO has to be able to actively code?”
“Of course! How can you lead engineers if you don’t understand the technology at least as well as they do? You’d never get their respect!”
“I had a CTO who wasn’t an engineer once. All that guy did was create PowerPoints and ‘manage up.’ He had no idea what we did every day.”
I’ve had this debate for decades now: “How can you possibly lead technical people if you couldn’t do their jobs for them, only better?”
I’m sorry, I meant to say, “Can you lead engineers if you don’t code?”
“How can you possibly lead technical people if you couldn’t do their jobs for them, only better?”
My definitive answer is yes, you can be a successful technology leader without ever writing a line of code. It’s definitely the harder path in the beginning, but long-term success as a CTO requires a balanced view of people, product, and technology. Overweighting technical experience eventually becomes a handicap.
Saying that you have to code to be a CTO is like saying that, in order to design a skyscraper, you have start as a cement mixer, then work your way up to girder riveting before finally hanging drywall and installing windows before they let you design the building. It assumes that the details are more important than the concepts, that hands-on knowledge of rivets is more important than understanding structural load and material stiffness. This sort of bottom-up thinking is a failing in many senior technical leaders, leaving them unable to participate in some of the “gravity-free” thinking that is so critical in setting a company’s direction. Understanding the details certainly helps, but being able to think at a conceptual level is far more important for a leader.
Long-term success as a CTO requires a balanced view of people, product, and technology. Overweighting technical experience eventually becomes a handicap.
This will surprise some people who know me or have worked for me in the past 20 years, but I don’t code. The last full-blown program I wrote was a text adventure game written in BASIC (and it was awesome, by the way), but 30 years ago I chose the business route instead. Comp Sci engineers weren’t making ridiculous sums coming out of college back then: they were going to work in basements for Digital or Bell Labs, which held little appeal. So I majored in marketing.
But I loved technology and I understood it at both a conceptual and a detailed level, so after dabbling around in business roles for a few years I found myself working for a software startup in Harvard Square.
wait for it…
… project manager.
Yes, the guy who makes sure people are checking off their tasks! The most hated and useless person in an engineering organization, right? The very definition of OVERHEAD.
Except I wasn’t. Instead, I was the person standing between the engineers and the business people, translating in both directions. When I wasn’t there, the engineers came across as surly, obstructionist, and condescending because all they did was repeat variations on “It doesn’t work that way, and if you understood all the details of what I have to do you wouldn’t even ask me to do that.” And to the engineers, the business people sounded like unreasonable, fluffy-headed fools who never stopped wanting new things before the other things they asked for were even started.
But when I stood in the middle and simply translated the conversations, both sides realized that:
- They were closer than they thought: they wanted the same things but they didn’t understand the other person’s way of thinking enough to communicate effectively.
- Most of the time, it was a question of priority and timing, not feasibility. Software can do just about anything you want it to if you‘re willing to wait for it.
- It was unreasonable to expect people in either role to invest the necessary time to understand the details of the other person’s job, but they could agree on the concepts: “Here’s the problem we need to solve. How do we do it?” In most cases, that meant someone needed to translate.
The rest of my career, up to and including this past week, has been variations on this theme. Whether I was building the first MVP for an early startup or a 300-person software division with 4 enterprise SaaS products, I’ve always stood at the intersection of business and technology, figuring out how to turn technical capability into competitive advantage.
And I think that’s the role of the CTO. As the leader of the technology organization, your job is to leverage technology to help your company beat the competition. If you work for a five-person startup and you’re the only engineer, then yes, that means that you have to do a lot of coding. But once you have a team, any kind of team, then your job is to make sure that they’re working on the right things, building the highest-value features first, and doing so as efficiently as possible. Yes, this requires some fundamental technology decisions, and yes, you must have your team’s respect if you’re going to lead them well, but if you aren’t constantly looking ahead and paving the way for your team then I don’t think you’re doing your job as CTO. And if you, as the leader, aren’t making your team successful, if you make their jobs harder instead of easier, then no amount of technical prowess is going to make them respect you.
As the leader of the technology organization, your job is to leverage technology to help your company beat the competition.
If you don’t pay attention to the people side of the equation as your team grows, then you and your company are going to fail. Here’s the thing that’s often missing in these conversations: with a few extremely rare exceptions, companies don’t succeed or fail because of fundamental technology decisions. You don’t have to look far in the unicorn stable to see that you can build a wildly successful business on absolutely terrible tech, and I’ve seen beautifully crafted products that could scale to hundreds of millions of users but never had the chance because those users never came. The basic ability to implement technology is an entry requirement for a tech company, but it isn’t a primary success factor. Instead, success is determined by a company’s ability to:
- Apply technology to the business need. This requires that the company understand its business space, its customers, and where technology will actually provide leverage (and just as importantly, where it won’t).
- Assemble and motivate a team of people to deliver that technology quickly and efficiently and respond to changes in the environment. This requires the knowledge of where and how to find the right people, the ability to motivate them to work on the right things at the right times, and the dedication to continuously improve their environment as the company grows so that they can remain nimble and effective in their delivery.
The basic ability to implement technology is an entry requirement for a tech company, but it isn’t a primary success factor.
In a tech company, the CTO should be the one person on the executive team who looks at those two factors and says, “Yes, that’s my job.” You don’t have to identify the business need — that can come from the CEO, marketing, or sales— but you have to understand it well enough to deliver the right leverage. If you really want to fulfill your role, you can’t just say, “tell me what to build.”
You also have to understand people well enough to lead them, which includes dealing with all of their human messiness. Simply leading by example isn’t enough: if you really want to build a high-performing team you have to dig into what makes each person tick individually, which is rarely the same thing that makes you tick.
Does the ability to code help in these areas? Sure, it gives you a head start. It makes it easier (though rarely faster) to assess new technology platforms, and you can sometimes dig in and help solve specific technical problems. It allows you to personally assess an individual’s ability to code before you hire them, which is valuable for the first few hires. But if you’re relying on your hands-on coding skills as you scale, then you’ll quickly become a bottleneck, especially if being the best engineer in the company remains your primary measure for success as a leader.
- Coding is, by its very nature, a very tactical exercise. It’s about solving a specific problem (or set of problems) with a huge number of details. Logic, variables, interfaces, data structures all pile up in your head and you have to hold them there while you create a structured solution. It requires great concentration and attention to detail, and it’s all about “the how.” This is the exact opposite of strategic thinking, which is all about what, why, and when, and can feel very fuzzy to a focused problem-solver. If you spend even a significant portion of your time in the code, you’re going to struggle to shift your mindset to tackle big, non-technical questions.
- As your team grows, more and more of your time will be spent on people issues, and this starts early. I’ve talked to CTOs who have fewer than five people on their team and already feel like they barely have time to code. If your company is successful at all, then you’re going to quickly grow to the point where, if you want your team to perform at a high level, then you’ll have to put energy into making them successful. If you think that writing code is your “real job,” then you’ll spend your whole day frustrated with the interruptions.
- As the business grows, so do the demands on the technology. Someone has to mediate those conversations and chart a course that balances business needs with technical capabilities. Unfortunately, that means meetings, which take time away from coding. If your value to the company is based on your personal code output, then you’ll have to make a choice: have a voice in the decisions or just implement the outcomes. You can’t do both, and if you abdicate that responsibility then you relegate your organization to becoming a bunch of order-takers.
- If your self-worth as a leader is based on being the best engineer in the room, then you will quickly become, at best, a limiting factor on what your team can accomplish and, at worst, a destructive influence on the team. I’ve seen this happen more than once, where great engineers become terrible leaders because they feel the need to constantly prove themselves. To stay on top of the heap, they either hire people who are worse engineers than they are or they insist on being in the code long after they should have released control to their team, frustrating the team and driving the best engineers away.
It comes down to this: based on time demands alone, being an effective technology leader means that you’ll have to get out of the code eventually. Those who hang onto coding either hand off those leadership responsibilities to others or try to cover the gap by putting in more hours, which burns them out over time. And engineering leaders who think that their primary value to the company is based on their coding ability often feel like failures as their teams grow because no one told them that they need to shift their focus from their individual output to the team’s output.
If you’re relying on your hands-on coding skills as you scale, then you’ll quickly become a bottleneck, especially if being the best engineer in the company remains your primary measure for success as a leader.
So, do you have to be a coder to be a CTO? My answers:
- It’s a great entry point but it’s not the only way in. Being a hands-on coder can help with a small team, but at that point you aren’t acting as CTO: you’re acting as an individual contributor. Personally screening candidates and reviewing code is fine at the beginning, but it doesn’t scale.
- Fulfilling the primary strategic function of the CTO — applying technology to achieve competitive advantage for your company — requires the ability to understand and apply technology, but not the ability to implement it. Detailed coding knowledge can lead to understanding what technology can do for your company, but it isn’t the only way and the details often get in the way.
- An effective CTO must sit at the intersection of business and technology and have a fundamental understanding of both domains. You can get there from either direction, as long as you’re willing and able to invest the necessary time to understand and function well on both sides of the conversation.
- As the CTO’s responsibilities grow, detailed coding ability becomes less and less relevant, and the insistence on keeping up or being the best engineer in the room quickly becomes a limiting factor on the CTO’s effectiveness as well as the team’s. Instead, the CTO must shift their focus to making their team as effective as possible, trading technical problems for people problems. Many pure technologists struggle with this transition.
This debate is a great example of the human desire to prototype things (and people) after our own experiences. We look at a challenging problem — like building a successful company or career — and we say, “This worked well for me. Therefore, the best solution looks like mine.” It’s easy, it’s natural, and it feels like it’s supported by evidence. I mean, just look at my experience! It’s also, pardon the phrase, lazy thinking. Since it’s based on anecdotal evidence, it’s akin to saying, “It’s freezing cold here in Minneapolis, so global warming isn’t real!”
This debate is a great example of the human desire to prototype things (and people) after our own experiences.
As technologists, we pride ourselves on logical, evidence-based thinking, so we should move beyond anecdotal evidence and personal experience when defining a template for success. In fact, we need to expand our understanding of what makes a successful technology leader, because it’s a fallacy that can cripple a company and its leaders. I’ve seen it happen and I work with people every week who are hurting because of it.
The idea that “all successful people in my field should look like me” is at the root of many problems in our industry. Let’s challenge ourselves to go beyond it.