You are a CTO, not an expensive Copilot

How I use a silly accounting exercise to help first-time CTOs overcome the dilemma of not being able to code any longer as part of their job.

Many first-time CTOs struggle with the idea of not coding anymore. They feel they're losing what made them successful, to begin with. They are often among the people who have been around the organization for the longest time. Their familiarity with the product and the platform made them effective in solving complicated problems or handling arcane corner cases in the past.

Some are even afraid of losing the respect of their team, as the team feels they're becoming increasingly disconnected from the technical reality of what they're working with.

Will I lose their respect if I am not an expert any longer?

This question comes up often in conversations with some of my clients.

When faced with this type of question, I usually smile.

I smile because I have been there and faced the same struggle long ago.

I smile because it signals the person is out of their comfort zone, the first step of any personal growth journey.

In today's article, I want to share a funny and purposefully silly accounting exercise I have them go through to gain a different perspective on the subject.

A simple accounting exercise

The exercise goes as follows. Let's assume you're a CTO of a team of about ten engineers. It is a relatively small number, but not too far from what a first-time CTO will often face. Replace that number with whatever is closer to your situation. The higher the number, the more evident the result.

Assuming they can all get five days of coding time in a week, that will add up to 5 x 10 = 50 coding days per week.

The reality is different, though. That number will be lower between meetings, incidents, and administrative work. Let's say your team has 30 coding days per week available.

Now, assume you, the CTO, decide to spend one day per week coding.

Add in your dose of distraction, the cost of context switching, and the fact that you're not as effective at coding as you used to be, and adjust that to something more realistic. Let's say 0.8 net coding days, which is still quite optimistic.

In that scenario, you're constantly investing 20% of your time to gain a staggering 2,6% increase in coding days in your team.

That increase is not compounding: the day you have a rough week and can't spend your day contributing to the cause, the benefit is lost.

And I'm not even factoring in that with such a setup, you will usually work on simple tasks, as you don't want to block the team for one week if you cannot finish your work in time. So, your actual contribution will be even smaller than that.

Once we get to that point, I ask a question.

Would you be comfortable going to your CEO with these numbers and selling them on the idea that you absolutely have to spend 20% of your time, week after week, with your hands in the mud?

According to available data¹, investing $19 per month per user in GitHub Copilot will yield a much better ROI with virtually zero opportunity cost.

If you're afraid that AI might take your job, coding one day a week as a CTO might be the perfect way to make that happen.

At this point, I often share a story to add more perspective to the conversation. I learned this from the host of a management training course over a decade ago.

As part of that training, he told us a story about a client he was working with, a hotel chain. One day, he was talking with the director of one of the establishments in the chain, who was proud of what he did every morning. He would spend one hour every morning wiping the access staircase to the hotel because nobody did it as well as he did.

He didn't like what he got as a reaction.

The teacher told him to lower his voice and said something like, "Shhh, if your boss knew that they are paying you such a high salary to wipe the staircase, you'd be in serious trouble.”

I love that story, as it exemplifies how often we let our ego and a distorted perception of what doing a good job means get in our way.

The accounting exercise is meant to provoke thought and trigger a conversation about the role of a CTO. It's illustrative; don't put it in a research paper.

The point is simple.

Coding is a low-leverage activity if you are the CTO of a team with more than a handful of engineers. It doesn't scale and has a high opportunity cost.

You might still like doing it, but that's a different conversation.

Here are some of the common objections that arise from that conversation.

I'm the only one who knows X.

This is another instance where you might have a bus factor of 1, as discussed in last week's post².

It is your responsibility to solve this problem, not indulge in it.

If you are the only person who knows about certain parts of the platform, their history, and quirks, you just found a great candidate for getting value out of that 20% of the time you seem to have available in your schedule.

Use that time to devise a plan to de-risk this situation. Your goal should be to remove yourself from the critical path on these parts of the code. Identify which team or part of your team should own it, make sure it's well documented, and then work with the team to ensure they ramp up their knowledge as quickly as possible.

The good news is that you can even throw in some pair programming sessions with team members in the mix.

Be deliberate on the goal. You could take inspiration from the See one, Do one, Teach One approach commonly employed in healthcare³.

Pair programming should be a temporary means to an end, not a routine activity you'll engage in indefinitely.

I'm really good at software engineering!

If you are an outstanding software engineer and love doing that more, be honest with yourself and your company. Ask to be moved to a Staff or Principal engineer role and find someone else to run the team and the whole engineering organization. You will likely need to put your ego aside and accept that someone else will run the show.

As I've discussed in an article about the five archetypes of CTOs⁴, this is not the most common transition. It's not easy to succeed at it, and it requires a lot of maturity from the old and the new CTOs.

But seriously, if you think you can be a great Staff or Principal software engineer, do that.

Accept the tradeoffs of the choice, and be happy with it.

What about the risk of losing the respect of my team?

This objection is a common consequence of conflating being technically savvy with coding. Coding is only one of many activities and disciplines involved in software engineering.

As a CTO, you will have to keep a broad technical profile, and there are many ways you can keep doing that beyond churning out pull requests.

You are responsible for the overall coherence of the systems your team is building, while each team and individual will tend to be concerned only with their parts.

As such, you are responsible for ensuring the overall architecture is coherent and solves the proper users' problems in the right ways. This means you must validate many architectural decisions until your team reaches a size that makes them retractable. You should be able to delegate a significant part of that responsibility at that point.

It doesn't mean you'll make all those decisions.

Even more so, it doesn't mean you'll have to come up with all the ideas or answers.

In fact, in your role, it will be more important to ask the right questions when people suggest a particular course of action. Your accumulated expertise and experience will be a unique asset to help you ask those critical questions.

You should not pretend to know the answer; you don't need to.

But if nobody else in the team knows them, more work is required before jumping to a decision.

Zooming out one more level, you'll be responsible for defining the tech strategy for your company. Such work requires you to do significant research and investigation in technical domains. It is one of the highest-leverage activities in your role for two reasons.

1. No one else can do it on your behalf. Other people can help, but you have the mandate and the accountability for the tech strategy.

2. If you do a good job setting a compelling strategy, your team can make many decisions without directly involving you, effectively speeding them up and multiplying your impact.

These are just examples, as a CTO's list of high-leverage activities is long, and its prioritization will be context-dependent. Many of these activities will require your accumulated technical experience and force you to update yourself on trends shaping the industry's future.

Coding will tend to be more of a distraction as it's highly tactical in nature. It will give you the illusion of progress, but its impact will be irrelevant on a bigger scale.

One More Thing…

I recommend one more thing, and I've written extensively about it⁵: the practice of Engineer-ication.

It's an idea that came out of Stripe. It basically consists of tech leaders taking a fake vacation from work. They'll pretend they're not there, skipping all the recurring meetings and obligations associated with their role. Instead of going to a beach, they will spend the week working as software engineers in one of their teams.

I recommend the activity as it provides many insights and context about teams, processes, and platforms. You experience the onboarding process, documentation, review, deployment processes, etc, first-hand. You'll observe how people interact with each other and how meetings are run.

It's a great way to stay connected to reality on the ground while clearly signaling that you only do this occasionally.

The goal isn't to contribute code per se but to gain insights into what works and what doesn't in your organization. Lack of familiarity with the codebase will be an advantage, as it'll give you a fresh and more objective perspective, free of any bias that comes with things you're used to.

You are not alone; don't do it alone.

Chances are that many of my readers will recognize some of their struggles in the challenges I shared with you in today's article. Knowing you are not alone will help make you feel better, but that's the beginning.

Making the transition to a first-time CTO is not easy. I've done it and helped other people who went through similar journeys.

I do personalized mentoring and coaching sessions with all kinds of tech leaders, from ICs to EMs and CTOs. Many of them are first-time CTOs who want more clarity on how to excel at their jobs.

If you're struggling with the transition, I can help you.

Just reply to this email with your main concerns and doubts, and I'll be happy to guide you through the details.

If you prefer a face-to-face conversation, feel free to book a discovery call to get to know each other, and I'll explain how I am helping my clients.

If you know someone else who is struggling with similar challenges, feel free to forward this article; it might help them.

See you all next week for another article!

1. An interesting study published on Hacker Noon on productivity or speed gains in a team using GitHub Copilot. They found the gains to be in the 10-15% range. The full article is available here.

2. For those who missed it, last week's article discussed a typical situation where Tech Strategies has a bus factor of 1, the CTO. You can read the full article here.

3. For more information about the practice, you can check out this article.

4. Read The 5 archetypes of CTOs to learn more about them.

5. I wrote two articles on the topic of Engineer-ication. The first one covers the practice and why I think it's relevant. The second one is a practical guide for people who want to implement it.