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.
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.
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.
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’m not a CTO. I am a tech/implementation lead).
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.
Reviews? Sure. Design meetings? Sure. But taking critical work will end up causing issues.
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.
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.
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 a large company the size of Google? Yes. For a startup? No.
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.
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.
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.
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.
You didn’t have to be mean :)
But the other half of my job is leading the project once the contract is signed
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?
You probably won't have bandwidth for both roles.
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.
https://www.linkedin.com/advice/3/how-do-you-conduct-consult...
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).
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.