Do I really want to be a CTO?
How to deal with the oh-so-common existential questions related to being a Manager or an Individual Contributor
Last week, in the Sudo Make Me a CTO Community, we explored a common struggle among engineering leaders: doubting their career choices.
Raise your hands if you've never been there.
More specifically, we explored the eternal dilemma of whether to stay and grow on the Managerial/Leadership track or return to the Individual Contributor (IC) track.
No such conversation would be complete without addressing the desire and difficulties of remaining technically relevant as a leader, which we did.
Today's article is a high-level recap of the main points we covered and the key ideas we surfaced to help us face the dilemma and be even more deliberate in our career choices.
If you want more details, you're welcome to join us in the community. Upon joining, you'll immediately gain access to all recordings and transcripts from past sessions. Follow this link to learn how.
The eternal dilemma
Let's face it: we've all been there a few times in our careers. I've been there more often than I'd like to admit.
Asking ourselves a variation of the following questions:
Should I stay on the manager's track or move back to the IC track?
What if I don't want to be a CTO any longer?
My life was simpler when I had to deal primarily with code. Why don't I go back to doing it?
Will I find another job if I were to lose the current one?
It is healthy and can be productive to reassess our career choices regularly.
What's not healthy nor productive is to constantly ruminate about our past decisions — a common symptom of depression — or continuously worry about the future — a common symptom of anxiety — without ever deciding which way to go.
I'm no therapist, and I can't help you deal with your case if you find yourself stuck in such situations, but I can offer an alternative approach to prevent your case from becoming one that requires professional help.
Let's start with what can be a very unproductive approach to the problem.
The dangers of the passion theory
Most of what follows is something I learned from reading So Good They Can't Ignore You by Cal Newport1, other articles on the subject, and my own experience.
In the late 1990s and early 2000s, what Newport calls the passion theory emerged. This theory states that you'll be successful and happy if you just follow your passion. Sounds familiar?
The main problem with such an approach is that it's simply not proven.
On the contrary, there are plenty of examples of people who fell into the trap of the grand gesture: leaving everything to do something completely different and follow their passion. More often than not, such approaches led to a sad discovery: their passion turned out not to be such a fun experience — hard work is hard — and they often had no clue how to succeed at making a living out of it.
The cliché example would be a software engineer who has practiced meditation on a somewhat regular basis and decides to leave their job to become a Buddhist monk… without trying to live like a monk even for a week, let alone days. Only to discover they were totally unprepared for such a life.
To put it another way, just because you're passionate about something, that doesn't give you a free card to improvise your way through it, making it your next profession. That approach has more to do with picking lottery tickets than career planning.
Besides, what is even your passion?
Do you have the same passion today as 20 years ago? Do you believe your passion in 20 years will still be the same? How can you be sure about that?
Leaving everything to follow what you believe might be your passion without preparation seems too risky, especially at a point in your career where your responsibilities involve other people beyond yourself.
Does that mean you're stuck with whatever decisions you've made in the past?
While it's hard to become a professional athlete in your forties if you've barely ever trained before, you shouldn't believe you're stuck in a rut for the rest of your life just because of the job you're in today.
Focus on building career capital
Instead of leaving your career as a CTO to open a flower shop on a whim, you should focus on building career capital to open up new opportunities for yourself.
The first recommendation I always give to people wondering how to get promoted is disarmingly simple: do your best at your current job. Or even better, be the best at your current job.
While you can find plenty of advice online about the 5 things you need to do to be promoted within 6 months, those tend to focus on skills that will teach you how to game the system, not necessarily how to learn rare and valuable skills that can be put to work in different contexts.
Granted, there is value in learning how to navigate an organization and understanding what it rewards, but in a context where promotion processes in tech companies are becoming more and more questionable, they could lead you astray from the fundamental skills of the job you can build an entire career around.
There is something I've observed plenty of times: countless opportunities are offered to those who distinguish themselves in their jobs.
Paradoxically, obsessing about the next steps might backfire as you lose focus on what matters today.
Does that mean you should not have a plan? Not at all. Being deliberate is key to progress.
But make sure your plan has a strong focus on how to get better at your job today, not the next job you might never even get.
Finally, the causality relationship between work and passion seems to contradict what we're often told.
It's not "follow your passion, and you'll be happy", but rather, the more you become good at something, the more you'll develop an interest and a passion for it.
Passion develops as a consequence of getting better at something.
That's powerful. That's agency. That's the opposite of fatalism.
Experiment and explore from a safe place
Let's assume you've reached a point in your current role where you feel stagnant. You always have the option of leaving for a new job, but I argue that's not the only option you are being offered.
You can, for instance, decide to leverage the safe place you are in — salary, known context, etc — to experiment in new areas with limited risks.
If you intend to keep growing as a leader, you can spend a ton of time educating yourself on new approaches or techniques and then use your current job to experiment with them. Transforming a stagnant or slowly drifting situation into a lab. Or, to use the words I shared with a friend lately: make this your university, where someone is paying you to learn.
If you're considering returning to the IC track, start by recognizing there is nothing to be ashamed of if that's your intention. Don't let external definitions of the right career path limit your ability to grow. Once you've internalized that aspect, you can take the same deliberate approach described above and make your current job a university with a salary. Find an area you'd like to improve — a language, framework, architectural patterns, etc. — that is compatible with your current job's environment, and start investing a few hours every week in educating yourself through experimentation.
For this to work, you'll first need to manage your time and priorities at a stellar level. I've written a popular article on the topic2, and I recommend you check it out if you're considering any of these approaches.
Beware of the comfort of the familiar place
A common anti-pattern I observe is first-time managers indulging in hands-on technical activities to escape leadership responsibilities. There is something comforting in the familiar place of the IDE and code challenges. Coding can give them a sense of efficacy because they're undeniably good at it. But focusing on that and ignoring fundamental aspects of your job that intimidate you is a perfect recipe for disaster.
Instead of (just) asking yourself: how do I stay technically relevant? Ask the more congruent question given your new role: how do I learn to become a better leader, day after day?
In your new role, getting 1% better as a leader has a bigger impact than becoming 5% or even 10% better as a software engineer. That's your lever now. Learn how to use it.
Facing that question might scare you, but ignoring it will not get you anywhere. If you're reading this article, you're already facing it in some way. Congrats.
Keep doing that, and then follow some of the recommendations I'm about to share to stay connected to the tech world.
Staying technically relevant as a leader
First, let's apply formal logic to dismiss inaccurate interpretations often discussed.
The responsibility of a leader is to lead.
Technical leaders, especially those who lead other managers or leaders, should not be required to spend a significant part of their time hands-on coding.
Now, here is the logically incorrect conclusion some people get to.
They read "should not" as "must not" and, therefore, wrongly assume that a CTO should almost be forbidden access to the codebase, lest they be fired ipso facto.
I'm still convinced that at a certain scale, if a CTO has to code as part of their daily tasks, it's usually a symptom of a larger problem. That said, there are plenty of situations where a CTO, a VP, an EM, or any other leader would get their hands dirty with the code.
What's important is to be clear about why that is happening.
For instance, getting a better understanding of the systems, platforms, and tools your team is working with daily is a perfectly valid example. I've been practicing the concept of Engineerication3 , and I find it a very effective way to reach that goal. There is a big difference, though, between that and making a PR per day, every day.
Assuming you have a solid answer to the question asked earlier about staying relevant as a leader, there are plenty of ways to keep your technical skills honed.
Read books and articles on topics that you find interesting and helpful. Leverage the most senior members of your team and have them teach you about the latest trends. Experiment with the code in your company or work on side projects with languages, frameworks, or architectural approaches you want to improve at.
But never ever forget to avoid putting yourself in the critical path of your team's delivery. These hands-on activities should be interruptible, as your role must prioritize leading the team. You would not want to block the next release because you're rightfully dealing with a situation concerning someone in the team that requires your attention.4
Would you like more on this topic?
Most of what I shared here emerged from the last Sudo Make Me a CTO Community discussion. However, due to an article's inherent limitations, I could only capture a fraction of the rich discussion.
Even more importantly, these are my takeaways, but I'm sure every person took home a slightly different perspective, one that's more relevant to their current situation.
So, if you're serious about staying relevant as a leader, I can guarantee that joining the Sudo Make Me a CTO Community is a very effective way to achieve that.
It's never too late to join, as you'll always have access to the recordings and transcripts from previous sessions.
You might just be a couple of clicks away from an inflection point in your leadership journey.
Follow this link to take advantage of the opportunity with zero risks. I offer a 30-day money-back guarantee.
I'm looking forward to seeing you inside!
See you all next Wednesday for another article!
This is one of the books I've been recommending or gifting more often and for a reason. Reading it opened my eyes to a completely different perspective from the dominant one. If you haven't read the book, I recommend getting your copy here. You'll have plenty of time to thank me later
One of the articles with the most views is a symptom that more people need and are willing to get more disciplined and structured about how they use their limited time. Read it here.
This is a concept I learned from the folks at Stripe and have been promoting ever since. I wrote a couple of articles on the topic. The first one is here
I have more considerations on this topic captured in another article that you might want to check out.
