I read all the time about folks who become a VP/CTO and stop coding. Management skills are not coding skills. I know it. But I can't for the life of me figure out why folks hang up their keyboards and let their first super power go to waste. You can be a technical CTO from start to finish. Treat your team and the company like a service that needs active contribution, maintenance, and on-call support; and also, get your hands dirty building by yourself and with your team.
At VP/CTO level you don’t have time to contribute and maintain code. If you do, the VP or CTO title is probably symbolic, like when someone is a “CTO” in a team of 3 at a startup.
The real problem is when people take early career roles that leave no time to code: They take architect roles where they just draw boxes on whiteboards and hop from meeting to meeting, or they accept a role labeled “tech lead” that is actually management in disguise.
They get comfortable not writing code and years pass until one day they need a new job. Now they have to interview for coding roles while confronting the fact that they spent a good portion of their programming career not writing any code. It doesn’t come back fast for many.
IMO the architect-leader role is an attempt at scratching the itch of not being able to code. I've worked with leaders that would spend any extra time they had building projects in new frontier tech to understand the nuances behind the marketing, and I'm sure we've all worked with folks that blindly parrot the marketing speak in design meetings.
You don't have to always be building things to be a great leader, but I place more trust in a company with a technical CTO.
I can build POCs, or I can just come up with high level ideas and ask my most senior architects to do the research and build the POC to see if my ideas are feasible.
And I avoid “frontier tech” as often as possible. I want to base my implementation on proven technology with a healthy ecosystem. I don’t want to use “frontier tech” just to read a blog post six months later about “our amazing journey”.
I was an active developer from 1996 - 2018. Between 2016 - mid 2020 I started transitioning to team lead/architect roles with some coding until I did a
pivot to cloud consulting specializing in app dev. First it was 50/50 coding/strategy until now where it is 10/90 coding/strategy talking to customers and leading teams.
I can tell you it was a lot easier finding full time jobs both in 2023 and 2024 as a “staff architect” at both product companies and consulting companies than regular old “senior” [1] enterprise software development jobs. Especially working remotely.
Every job posted for generic developers gets hundreds of applications and most of the applicants are probably good enough to do the job. I applied for hundreds of jobs between both times I was looking and heard crickets. They were plan B jobs that actually paid less.
On the other hand, in 2023 I had three offers for team lead/architect jobs in three weeks and one offer in 2024 based on replying to one internal recruiter that reached out to me.
Besides, I keep between 9-12 months of expenses in a liquid savings account outside of retirement savings. That gives me plenty of runway to prep for coding interviews if I had to.
[1] “Senior” roles at most non tech companies mean “you codez real gud” not that you operate at any different level of “scope”, “impact” or “ambiguity” than a mid level developer.
In my own experience it's a matter of only having that much time in the day. For 7 years I had somewhere between 20-25 people I was directly or indirectly responsible for. There was just not enough time to get anything useful done in the code and my time was much better spent solving problems that others couldn't. A few times I was able to pick up some really simple change just to get the experience first hand to go through all our processes and see where we can do better.
I always kept coding nights and weekends but it's just not the same and over time you are gonna get a little rusty. That said I greatly enjoyed getting my hand dirty all day during a sabbatical I'm taking.
When you're not just an IC, you have other priorities. That means your IC work can be derailed at any moment. _That_ means you can't take on work anywhere near the critical path or you're just blocking others or handing things off.
Reviews? Sure. Design meetings? Sure. But taking critical work will end up causing issues.
I don't think there's a right answer here, but there's definitely a point where your code contributions are much lower leverage than for example trying to recruit the next set of critical engineers, working on the technical roadmap to keep ahead of the competition, or making sure the engineering org is aligned with the rest of the company.
Any lines of code the VP/CTO could write, could likely be written by someone else on their team (and their team's quality could be even better) - but all the other items I listed is likely only something the VP/CTO could do the best at in the company. It's quite a rational decision to largely give up hands-on technical work for what's more important for your team and company.
My last CTO role (team of 40) had me absolutely over capacity from day one, and I am _good_ at time management. I would rather have been programming 50% of the time, but there just was no time, and no support structure in place I could hand stuff off to; I had to painstakingly build that, which was yet another reason I had no time.
I like the idea of continuing to code, but usually that’s not what you’re being paid for, and while I consider myself a very strong developer, they can be purchased for less than the CTO’s salary, rather than the more expensive CTO doing the work. FWIW I went back to IC after a few years and plan to stay that way for the rest of my career.
If “that decision” you mean going back to IC, it’s going well I think? I work remotely from outside the US, get a decent salary, and have a lot less stress than I used to! I’m currently working on AI projects I find really interesting and I’m getting a decent US developer salary in a tax-free company. Plan to retire in 15 years.
Getting Things Done and Seven Habits set the foundation, and then just iterating on those principles until I found systems that worked for me. Big believer in not using the Inbox as a task list, and apps that make setting, repeating, and organising reminders very easy.
Also, many start-ups seem to do fine without formal management structure up to 50 or more employees. The CEO / CTO is still coding, talking to customers, hiring, and making the product better.
Getting "all managery" in early stages seems like a huge misstep to me. The skills needed to successfully create a start-up are far more rare than those needed to be a good manager.
I really dislike almost everything Oracle and Larry Ellison, but he had an early-days adage "There are 2 jobs at Oracle: you're either building software or selling it". At a early-stage startup most people should be doing both.
The job of a CTO is strategy. The last thing you want is a manager that codes. They always end up either being shitty managers who don’t do the things that I need from a manager - making sure the team gets the resources we need, prioritization, big picture, etc - or they end up being shitty developers because they can’t keep their commitments because of management responsibilities.
Development is not a “super power”. Developers are a dime a dozen and if you look at the leveling guidelines of every well known tech company, how well you code only makes a difference up to the mid level.
Knowing what to develop, knowing how to deal with business, how to lead an implementation, managing trade offs, “dealing with ambiguity”, etc is the differentiator.
For even a 20-30 person company. My CTO at the last startup I was working for was constantly flying to talk to customers - B2B with long sales cycles. He was the first technical person that the CxOs at the other companies spoke to.
I find it quite funny when startups reach out to me about a “CTO” position that is really just a glorified team lead where I would be doing more hands on work and less strategy (with lower pay) than I was doing as a mid level (L5) employee when I was working at AWS (Professional Services).
I’ve interviewed former “CTOs” at startups that never did handle the scope of work, budgets and strategy that we expect from our “staff” level employees (my level now) at the medium size company I work at.
> For even a 20-30 person company. My CTO at the last startup I was working for was constantly flying to talk to customers - B2B with long sales cycles. He was the first technical person that the CxOs at the other companies spoke to.
That's really not a job for the CTO. It's a job for a sales engineer (with whatever their CxO title is), and it requires a different skill set. You need to be able to extract the product requirements from the customer, and to distill them for other teams. You don't necessarily need to be able to guide their implementation.
> I find it quite funny when startups reach out to me about a “CTO” position that is really just a glorified team lead
But that's exactly what a CTO position is! Their job is to lead the technical teams, on the company level.
And a good CTO will know how to scale up. When you're working at a 10-people startup, you'll need to get into the details of the code on the actual "team lead" scale. Once you grow into a larger company, the job becomes a bit more abstract.
I worked at L6/L7 positions in AWS, and it indeed is a much more relaxed place if you want it to be. Being a CTO in a startup is way more stressful.
A CxO doesn’t want to talk to a sales engineer who is not technical. They want to speak to someone on their level. The sales engineer defines the problem space and the customer needs. But isn’t technical enough to design a solution or know the feasibility of a solution.
I’m not in sales. I am the first deep technical person that a customer talks to (consulting).
Even for projects at AWS ProServe, the SA’s were sales and unless they were a “specialist SA” weren’t technical. But they came to the consultants (full time employees) in ProServe to do the technical deep dives and lead the implementations.
> A CxO doesn’t want to talk to a sales engineer who is not technical. They want to speak to someone on their level
Well, yes. That's why you invent a CxO position (Chief Sales Officer?) or maybe "VP of Engineering" for it.
Or you can do the reverse, "CTO" can be a de-facto CSO, and you can have a separate CxO position for the technical stuff.
> I’m not in sales. I am the first deep technical person that a customer talks to (consulting).
This means that you're in sales :)
I think the distinction here matters. CTO is a more inwards-facing position, they are responsible for formulating and executing the technical plans and maintaining the quality of the product.
In other words:
CEO - "we need to get the city of San Francisco as our customer"
CSO - "San Francisco needs a bridge"
CTO - "we can build a cable-stayed bridge across the Golden Gate"
Tech Lead - "we can use 1 meter cross-section cable stays to construct a cable-stayed bridge across the Golden Gate"
In reality, especially in startups, there's always going to be some level of responsibility sharing.
There's nothing wrong with working in sales! No kink shaming here.
Startups usually require people to wear several hats at once. That's normal. But suppose that your company grows to be 20 times larger. Would you still be working with customers or directing the projects to implement their requirements?
I’m far from the only staff level consultant at the company. Doing requirement analysis is considered “leading a project”. It’s a billable project assigned to a staff level consultant once sales brings in a customer and usually last 3-5 weeks.
While I’m considered a specialist for “cloud native applications”, I can pinch hit for almost any of our specialties at this level except for migrations.
Once the customer accepts the proposal, then leading the implementation is considered another project that is assigned to a staff level consultant. The “architects” (non staff) are the specialists that lead their “work stream” and are hands on and leading their sub team depending on the size of the work.
An implementation is made up of multiple work streams (epics).
Mostly because of the Maker's Schedule vs. Manager's Schedule (https://www.paulgraham.com/makersschedule.html) issue. It's really hard to be in a role that deals with a lot of randomization and then sit and focus for 4 hours straight on something.
I've also had the experience where the CTO was activly coding, 80% of the code base were theirs, and the company was hiring software engineers who could and wanted to fix up their stuff - there was this true luxury problem for this start-up: bad bugs everywhere, but patient and resilient customers. They found 4 willing engineers with good chemistry at first, at least up until they were constantly vetoed by the CTO in their decisions, because the teams best practices conflicted with the CTO-way of "getting things done" - it's a rigid hierachy after all, and not a democracy.
I'm a first-time Director at a SW company with a total org under me of ~30 people in 5 different subject areas. I struggle with what you highlight, but it's impossible for me to go deep in all these areas. MY boss is the CTO and he talks about "T-shaped" or broadly across and narrowly deep. I really don't like this, but the reality is I view myself as senior-dev level in one area, int in another, junior in 2, and barely familiar with the third - and I'm by far the most technical of all the Director/VPs
For me, the hacker super power — the one worth carrying forward as you progress in leadership — is being able to prototype something that works and proves a concept.
Realistically, a proof of concept is also only 20% of the work an engineer needs to do in order for a change to become production worthy and I respect that my sketched ideas need a lot more care and craftsmanship than I have time to give them. Where I can help other ICs is having that initial 20% idea around which they can then build a working idea, and do so autonomously.
It feels very cringey to write — oh brave new world that has such people as me in it! — but I can easily reassure myself by remembering all the times earlier in my career where I was very grateful to be initially pointed, with quite a lot of prompting, in a particular direction and then being given the chance to deliver on it.
I’m just a lead, but I can imagine part of being a CTO takes the same form as what I’ve described.
Every junior has mentors and leaders that help them and that they can follow. As you grow you might become one of them. That's the reason why you then let others do all of the coding. It's not like you unlearn everything, but you let your team grow and become you in the end. It can be really satisfying. If you can't stop getting your hands dirty then maybe it's not for you (yet).
