I'm a VP eng/research at a startup and also feel like one of the few people apart from the founders who can push major technical initiatives by just doing it themselves, due to: business context, technical chops, architectural judgment, grit, and seniority to pull in cross-functional stakeholders to help out.
However, I have often questioned if it is correct that so few people in the org can do this and if I shouldn't be enabling others to do it themselves instead.
How have you been able to navigate not having any direct reports? Who does your engineering org report to and how are you able to manage conflict between org builders and your technical vision?
That for me, is the core of the issue. I have been in a few places where senior management (up to c level) still code and are critical parts of the project team.
The problem is who keeps them to schedules and co-ordination with the other people on the project. Hard to complain about team level issues if the failing person is also the boss of the technical staff.
Build a demo perhaps to illustrate the idea/vision but don’t code, focus on the high level management and direct the ICs to build out the production version.
Both roles (management and coding) are difficult, demanding positions to do well, deserving of respect and commitment.
Just my opinion after bad experiences.
This is not the same as an SDM or Director or people with lots of reports. It’s mostly the “having reports” part that causes devs to reduce or stop coding, since managing and project leadership are whole jobs.
That's one definition of a CTO. Another CTO type is the opposite: "the thing you call an engineering founder when they've done so much customer-facing work that you have to take their commit bit away from them". This is, I think, an even more common archetype than the other one.
Then you have the toxic CTO definitions --- CTO as "ultimate decision maker for engineering", or, God help you, CTO as "executive manager of all of engineering".
You'd have to be specific about what kind of CTO you are to really make the question of why you code interesting.
I do wonder if it is possible to agree on a general definition of the CTO from the perspective of the job to be done, rather than how they do it.
For example, we could say the job of the CTO is to ensure the company remains technically competitive. If they do it by means of building an organization then so be it. If they rather do it by writing code themselves, then why not?
He calls himself a CTO, and that's fine, but he's really just a technical cofounder, and that's what he's acting like (and it sounds like it's a very positive thing for the company).
The CTO title and the whole point of the article are not really relevant, this entire situation would not be possible if he weren't a co-founder.
I think it is a good lesson that founders shouldn't necessarily be pigeon holed into roles they don't want, but the CTO title really has nothing to do with it.
You could event extend it farther by highlighting that many firms have a VP of Engineering AND a CTO.
In that scenario, the CTO tends to do more "strategic" and "big picture" work and the VPE is who runs the day to day work of managing SWEs, setting standards etc.
But even then, there are many different flavors of that too.
Very loose definition of a CTO.
The question is: what are you not doing that is in the list of CTO responsibilities because you're coding? One of the reasons stated why you do this is "because you enjoy it", and on the list of reasons you need to do it is there are only a handful of people in the org that can ship new product surface area. That's...concerning. That seems like the kind of thing the CTO would want to fix, but I don't think having the CTO be the one to ship that surface area is highest-leverage use of time. If I'm reading this right, it's essentially that "because of the virtue of my position and autonomy, I can work on experimental projects for months at a time, but I don't empower my teams to do the same."
I have direct experience with this sort of attitude at companies between 200-400 people, and the messaging from top brass was framed as "innovation cannot be democratized". After seeing it in action for several years, I think it's a poor model. CTOs are technical visionaries, but coding is not a high-leverage activity. Good startup CTOs need to change their role multiple times over the course of the life of a company, and failing to understand the profound impact you can have as a leader is a common pitfall, because it doesn't fit with what you enjoy, or often what you have experience with. In the case of Assembled, Crunchbase says between 100-250 employees. If you get more towards 500-1000, I would seriously recommend you re-evaluate your thinking on coding as CTO, at least to the degree you are today.
One technical question: do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? What happens when you don't have time to land the long-term experiment before you need to turn to the next concern? I ask these questions because they are the points where I've seen this system fail, and I'm curious if that has every been an issue for you.
In orgs where the CTO does a bunch of stuff, I think it usually makes more sense to think of them as a VP/E with a different-shaped hat (or a VP/PM).
There's definitely an interesting article to write about the VP/E who still codes!
Look at this CEO who codes: https://github.com/lattner :-) (He was fund raising in July, August)
I liked your take and curious to know what you think a CTO should be doing here
This is a wildly different status than almost all other people with this title.
I’m glad this person still likes coding, and they seem to be great at it, but this role doesn’t match up to the title. This doesn’t really matter until he wants to switch jobs and realizes near zero CTO positions outside of this one company will require few meetings and zero management. He’d have to change title to principal engineer or something but an article titled “Why I code as a Principal Engineer” doesn’t quite grab attention the same way.
My own anecdote is that the level of work I was doing as an “architect” at a 60 person startup where I was the second technical hire when the new CTO was hired to bring tech leadership in house from a third party consulting company mapped to a mid level L5 consultant at AWS ProServe (to be fair I only had two and a half years of AWS experience at the time I was hired by AWS) and now while I’m a “Staff consultant” at a third party AWS consulting firm with around 1000 people, looking at the leveling guidelines and expectations at my current company, AWS and GCP, it maps to a “senior”
But the article framing is still odd. If the CTO has no reports who is going to do the coding other than the CTO? The reason the CTO is coding is because, being CTO, they want technical things to happen. He can't farm it off to his reports because they don't exist. Case closed. The real question is why doesn't he feel hiring some people to code is a good idea. 1 highly capable report could probably +30%, 40% his productivity.
For people who doubt this, I recommend "How to Build a Car" by Adrian Newey (CTO of Redbull Racing).
But to be clear - if you do coding as CTO only because "only you can run certain projects," part of your job should be to fix that first. You will still have the easiest time doing it, but you should always have (many) others in position to run innovation projects, work with customers etc.
That’s all fine when you have no employees - C titles are bullshit when it’s just two bros in a dorm - but it invariably hurts the company prospects as the team grows.
The common hack is hiring a “VP of Eng” to take care of the actual C-level work.
Mind you, there’s absolutely nothing wrong in wanting to be the guy who sits in a corner and codes. Just don’t call it “leadership” or “chief” anything, since you’re sitting in a role and not acting the part.
Edit: relatedly - at what size do you need a cto?
I’ve had a few “opportunities” to be a “CTO” that were really no more than a glorified, underpaid senior developer with the promise of “equity” that would probably be meaningless
One place I was a senior dev running two teams of 8-9 devs (as both a line manager and a day to day manager plus mentoring), another I was a “Head of Software Engineering”, there where only 9 devs in the business, did get a nice pay bump with the ridiculous title though so that was nice.
The senior managing two teams thing came about because there was one senior per team and when the pandemic hit the manufacturing dev teams senior just upped and quit, I took over temporarily and then the pandemic lasted longer than anyone expected, it was a lead role even with one team and frankly at least a couple on each team should have been seniors on ability and experience but it was a weird org that way.
If he came in and call himself a “CTO” and then he described his day to day work, that would be a red flag for me.
We also have zero employees and relatively little revenue :-)
I think my role would indeed have to shift if we were to employ people and I don't like it, but I think you're not wrong.
But yes, I've been a CTO with a zero reports and doing everything while working in a company with > 200 employs. And while revenue was fine %he payment was shit.
I try to minimize meetings to the minimum necessary to get everyone on the same page with what our next goal is. From there, I'm right there in the trenches with my team working to get these sprints done. sure, it sounds like a senior lead developer and if you're in a small startup, it kind of is. The CTO part comes in twofold, if the project is falling behind, its on me to figure out whats keeping us from hitting the dealing and resolving it. I've let people go who underperformed. Its also my job to see who's getting burned out and making sure they get some time off so that they can come back refreshed and ready to push again.
Ss far as promise of "equity," Im currnetly pretty happy that I maxed out equity at the beginning.
CTOs come in all shapes and forms
And the “two parts” of your responsibility were those of senior/lead devs at the last 60 person company I worked for in 2020.
Equity in private companies is statistically meaningless and will be worthless. I’m at a point in my career where I only care about cash and RSUs in public companies that I can easily sell when they vest
It feels it bit disingenuous though to act like he’s breaking the mold and continuing to code when his day to day is higher level management stuff. It’s not quite the same as like Tobias Lutke still working on Ruby or something.
However a few things stood out in this to me.
> So pushing new ideas is quite important because they require intentional, sustained effort. Between org structure, roadmap incentives, and limited risk budget, few engineers can take months to pursue ambiguous bets.
That's exactly the kind of thing a CTO should be fixing.
> A recent example: we kept talking about building an AI chat product for our customers. It was clearly valuable, but it felt like a daunting task, and no one on the team had the time and headspace to take it on given their existing commitments.
Why? It's one of the hottest tech trends. If you've got nobody who would jump on this given you're an AI company, did they have valid technical reservations?
If nobody had the space, why? You're a C-suite exec, saying something is clearly valuable, why can't you get someone to work on it for a few days?
This post is a job ad, but it screams of a disfunctional company to me. Why can't your other devs do this? Why do they not have the time or headspace? Why do they not have the safety of taking on ambiguous bets that the company itself thinks are sensible?
> Last month, we had a million dollar per year customer that came to us with a burning need: they needed full data redaction on one of our integrations for compliance reasons. Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day
There are two possible explanations (outside of "it's a lie"):
1. Your team has valid reasons that data redaction for compliance reasons isn't the sort of thing you should slap together in a day
2. You have massive customer need for features that take a day to ship and your company is so fucked it'll turn them into multi-departmental nightmare meetings for absolutely no reason
> We’re building AI-powered tools to transform customer support, and we need technical folks who aren’t afraid to get their hands dirty. If this sounds like your kind of environment, check out our open roles.
No thanks. Sounds like being CTO could be fun, coding-wise, and being a grunt elsewhere without the headspace or time to take on valuable tasks sounds pretty awful.
Broadly it sounds like someone else is the CTO and John gets the title because he's a cofounder and coding. But he's a software engineer. That's cool, enjoy that, you don't need to want to do larger scale strategy or anything else. But someone should do that job.
Example: we talked about upgrading our scraper because it was getting blocked quite frequently. The CTO wrote a brand new one that was supposed to be much smarter than what we had in place. The only problem was, he wrote a python script. This was a php application. Yeah, it was merged, it never ran because, well it was python. We fixed some of the flaws in our scraper and reduced the block rate. The CTO saved the day...
As Brockman says, you need a very strong VP Eng to make this possible.
It’s an important milestone for the technical founder(s) to decide if they are going to hang up their spurs and become a manager/leader, or keep doing the technical work. (A common failure mode is trying to do both.)
people don't think that. people think CTOs who code may not be doing the leadership, managerial, or biz dev aspects of their job, or something like, why is he called CTO and not "engineer" or "architect" or "lead"?
Your job at the top is, more than anything else, pushing down a healthy culture. That includes things like setting an example of not working through the weekend. If you're doing it, your reports and their reports will feel the need to do it, too. Don't. And if you do anyway, certainly don't brag about it!
And then listen to this insanity:
> Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day. It wasn’t perfect, but it solved their immediate problem and preserved goodwill with the customer.
That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute, but, being above that process, you personally choose to circumvent it, foregoing required legal or engineering reviews, and shipping it immediately to your critically important customer? If one of the engineers who worked under you did that, you'd probably have fired him.
This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well
If you’re working on insurance SaaS, I agree.
If you’re building hard tech, I’d disagree entirely.
I guess that CTO uses weekends or works super long hours which I is fine if they don't push that expectation onto others.
I'd only really expect a CTO in an early stage startup to be pushing code like this (and eventually stepping back when they grow).
So you're not an officer
> Because it’s what I love and what I’m good at. I don’t particularly enjoy building orgs and figuring out people stuff.
Was my first guess as well.
29athrowaway•10h ago
CTO has a different meaning at different levels of scale.
With a headcount of around 250 employees, you can still work directly on implementation. But with a headcount of 100,000, it doesn't make sense.