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 bit got me. It's a direct quote from the linked post for those who haven't read it
My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.
I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.
In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).
This scenario is far more common outside of the tech industry, where you usually have a CIO running the IT cost center, and a CTO making decisions about technology adoption strategy.
I’m the chief legal officer but at the end of the day I’m just like bruh, chill, who gives a shit
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
Show everyone that system (that you’ve created) is shit and when some lowly SE thinks he’s above them all, you publicly flay him and make example for all that you’re the god emperor.
Business value? The ego trip is a business value!
I mean yeah, but hes the fucking CTO. If hes the CTO, _he_ is responsible for that process. Its his job to evolve it to make it fit for purpose.
What he's done is basically created a whole bunch of process debt, which is much harder to correct than tech debt.
Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.
And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.
If I were an engineer working under a CTO doing this, I’d find it extremely demotivating.
Why, as a CTO, are you not setting things up so that I can do it instead?
I personally don't think there's anything wrong with doing it (i.e. shipping a feature quickly that a customer needs), but writing a blog post about it is questionable.
The job profile of founder-CTO has not a lot of overlap with that of an individual contributor to be leading by example, the overlap is quite narrow even for senior engineering leadership.
Until recently[3] leaders with prior coding skills were always discouraged from code contributions and focus on management exclusively, for all the reasons some of them you describe.
--
I usually say that I am a part-time coder, not a professional one, and caution not to look at what I do as a benchmark or signal.
Vast majority of the code I write are DevEx or QoL for internal teams[4], or refactor tech debt that no one has time to deal with. Even mid-stage startups may not be large enough to invest in dedicated teams for this type of work.
Occasionally I have written such integrations like OP[1]. It is typically a PoC for a demo, never a production one to actual customers. It would be unfair (and failure prone) to expect anyone else to start supporting a production integration without the full tooling or documentation.
--
I agree it is a fine-line and you can err on the wrong side of it. It is easy and tempting to start focusing on production code and lose focus of the core job, but so many decisions as a founder are like that. I am hardly the best or optimal founder-CTO. However the value of being close to the metal is important and worth some risk in early to mid stage startups.
Perhaps there is also value in a CTO who understands what individual contributors are doing and is able to be more realistic about outcomes instead of being purely few layers above and not clued in.
--
[1] Not skipping legal that seems ridiculous, even if I wanted to, I can't imagine any partner would agree to it.
[3] Now I do encourage to try the new tools, it is not they contribute to production or be an IC, it is to get a sense of what is possible and what is not today. A lot of pipe-dreams are being sold in the industry, without hands on experience using the new tools ( which are rapidly evolving) managers can tend to overestimate or misunderstand what is doable.
[4]This is the core of the CTO job, writing code is rarely the bottleneck for productivity that was true even before generative coding tools, it is everything around that which creates friction. If you can reduce it, even writing some code to do so, it shouldn't be a problem or a flag.
- Edited for brevity(some).
I don’t want to set the expectation that people should work outside of business hours or that I’m willing to.
If you’re working on insurance SaaS, I agree.
If you’re building hard tech, I’d disagree entirely.
Prediction: this is the part of the AI boom that goes bust.
If you wanted to work yourself into a CTO position, his shop might not be a terrible choice, although I would imagine it would be a bit rough at first.
For the later, what you said makes some sense, and it definitely seems like you're more familiar with this archetype.
For the former, the article appears correct. If you've not worked at an early stage startup before, the culture is _very_ different.
As a side note: This article is doing it's job. People that are a good fit for the company will agree, and want to work with them. People that are not a good fit for the company will not agree, and naturally run the other way. Makes filtering out candidates easier.
Maybe the CTO’s company uses GPLv3 or AGPL software and the customer’s legal department vomits all over AGPL and demands extensive review for GPLv3 for their developers. Or maybe they’re worried about later finger-pointing and support issues. Or ensuring the company is running on unmodified, mainline sources.
Those would all be reasons why the CTO’s company could ship without involving customer legal teams without it being a red flag to me.
Once I sent an email at 5:45pm as I forgot to say something earlier about the project. I didn't get a response and in the morning got told off that I should never send an email outside of working hours, unless it is a personal matter that cannot wait.
Couple of years later the owners exited and new management replaced everyone with workers from consultancy of theirs. Company no longer exists.
Your job is to delegate, yes, the first delegation is hard, but the engineer either grows, or doesn't (then you need to move or yeet).
Yes I understand that you want to code all the time, then you're not a CTO. A CTO leads from the front, leads with process, and context. Your job is to provide context so that your team can execute.
depending on the legal requirement it may not have been foregoed but instead became legal because an executive did it
Slightly more details here: https://news.ycombinator.com/item?id=39174707
Goodness gracious corporate america. Can we PLEASE stop with hustle and bs?
You ever heard buffet or munger say everyday they do some bill keeping in a double entry accounting system and AI makes them better? Never. Why? Because when you and your org are competent you're not constantly on the hussle. My guess if they need to, they do and as they have things on their mind they don't have time to blog about.
People know what management at Berkshire Hathaway stands for. Case closed.
Competent upper management can be a boon for orgs esp on cross functional management which builds the org and keeps ia from infighting and running in 10x different directions. This guy isn't that. Moreover that means other people on the board don't know that either.
You don’t want a boss that works on Thanksgiving and thus probably expects you to as well ?
I’d actually be ok with this if bro offered half a million total comp. I’ll deal with it for 5 years and then retire.
It only doesn’t make sense when this jackass thinks the salaried engineer needs this “grit”.
C-levels aren’t supposed to be “model employees”. The incentive structure is wildly weighted in their favor. Instead you should ask them to understand the difference, which is asking a lot of these sociopaths, but I digress.
Complete nonsense. The free market will tell him if he can do this or not. If he can get valid candidates pushing this culture and it’s legal, why shouldn’t he? You, anyone interviewing there or anyone working at their company presumably doesn’t have to work there. Most countries don’t have slavery for tech jobs!
No doubt he will lose many candidates with this culture (you and I included) but maybe that’s a strategy? Maybe he still gets plenty of candidates that are good and the culture he wants.
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.
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.
and probably a lumbering ghost ship by one or more KPI.
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?
Amen.
I am a CTO, but spend most of my day coding. I was brought onto a smallish/medium sized company to get their base tech into the modern age, build LOB apps to improve some workflows, and ultimate build a new EMR in that space to replace the one the company is using.
I don't have anybody that reports to me. I'm one of 2 tech people in a company of clinicians and doctors. There is no budgeting or reports I have to generate.
But, it was the only title that made sense given my role in that specific company.
Anytime someone asks me I always have to add "but I don't really do CTO things".
In small startups, people wear multiple hats due to resource constraints. Executive roles and responsibilities change when the company grows.
> I am a CTO
> "but I don't really do CTO things"
so you’re not a CTO according to your own definition of what a CTO does then.
my previous employment i was “lead engineer”. i got to pick that title. had a 1 day per week part timer reporting to me. similar company description. making technical decisions. strategy meetings with CEO and founder etc.
i was not a lead engineer and ive since changed my linkedin page/cv to just say “engineer”. who or what was i leading? a contractor in ukraine who did work for us one day a week? nah, need a team (ie more than 1) to be able to lead.
do the brave thing and call bullshit on yourself. this is something good leaders do.
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!
I don’t know that I understand what you mean by toxic or why, but I’ve only ever seen the architecture overseer kind of thing in pretty small companies. In big companies, where there are multiple VPs of engineering and product management, that feels like the only time CTO even makes sense, and I expect they need to be setting vision and deciding where to invest (i.e. setting budgets) sometimes handling legal issues. In such large companies I’ve never seen a CTO providing architecture oversight, let alone coding. They might mandate the use or avoidance of some tech for reasons of corporate politics, but they are never in the trenches.
Having been a founding engineer in a startup where I was called CTO and mostly wrote code, I feel like this is a ‘cute’ thing we do, using C-level role names for everyone in a 3 person company. I didn’t feel like a real CTO, or VP, and I feel like using C-level names for roles in startups and small companies is a little goofy and awkward. A lot of people seem to like inflated role titles, and VCs seem to like having someone in key roles who can both lead well and take all responsibility and blame. I feel like ideally the name CTO shouldn’t be used until it’s needed, which isn’t until there are enough devs to need managers, and enough managers to need VPs and enough VPs to need a CTO. If that were the case, then the possible things on the list of CTO responsibilities is a lot smaller and more definable than if we say CTO can be anything including the 2nd founder who’s more interested in coding than pitching or marketing.
Look at this CEO who codes: https://github.com/lattner :-) (He was fund raising in July, August)
In any company, only a small number of developers can ship a difficult feature within a reasonable time frame, and that will almost always include the CTO if they were a founder and probably wrote half of the code. Only many years of experience working on a particular code base will give you that so no matter what you do, it may be years for someone else to get to the same level and that may never happen because the product just grew so large no one can do that anymore. If a CTO is still in the position to ship a large feature in a day , you are having an extremely hard time arguing they still should not do that. What could be more valuable use of a day in their schedule? Meeting with the CEO to discuss KPIs?? Fuck that.
This hits close to home as you might have realized. But yes I am all for letting the c-level go back to the trenches once in a while to feel what the salaried guys are facing. They can’t fix things just based on third party accounts anyway.
At the CTO level of a growing company it is one of the lower leverage things they can do. Setting technical direction, hiring the right people, and putting the right people in positions of power will all have much more impact than writing some code on the weekend.
It's not about them avoiding what they enjoy. It's about empowering and scaling a human organization to take on larger and larger scope over time. And at a technical company, the CTO is uniquely positioned to understand organizational scalability and technical scalability. So the risk I see with a CTO that focuses predominantly on coding is that they may be neglecting higher impact work that they could be doing that would set the organization up to empower more people to do the kind of work that they think is necessary.
The other risk I observed with a CTO that predominantly codes is that they become a bottleneck and are not actually able to ship the really experimental and product-altering features that they envision, and so they end up handing off essentially half-done ideas to teams who are then responsible for picking up the half-done mess and getting it to something that's suitable for production. I think this is probably avoidable in some way, but I do think it's an intrinsic risk of taking on large projects as a single coder while having other responsibilities to the company.
I liked your take and curious to know what you think a CTO should be doing here
If you have to build something because "Devs are too busy working on other things", then you're just bad at prioritising tasks.
If your team "can't do what I can" then you're bad at hiring.
I don't mind if a CTO works on a bug ticket, but make it part of the usual process, not hero driven development. Otherwise, what's even the point of having a process in the first place?!
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
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
I'm not OP, but whenever your product is implemented by more than one team you will also have the need to coordinate and set strategic goals as well as accompany and steer each team towards where it's infrastructure/tech stack/systems architecture need to be.
If you do not offer guidance and determine technical directions, each engineer working in each team will happily fill the void and do their best to scratch their itch at the expense of the whole company becoming an unmaintainable big ball of mud.
Let's put things differently: what do you expect will be the output of a company if no one is responsible for things like directing the company's R&D effort, coordinate and specify the company's tech roadmap, even oversee product development.
How do I do it?
(1) It is my job to be familiar with a wide range of technologies, which might include tech stacks, but us mostly tech offerings. The tech offerings means lots of meetings with companies that build tech that we might use. Some of those are useful, most are painful.
(2) Actually using technology - IMHO - This is one of the most important aspects of the CTO job. I code all the time, but not for any of our products or operations. I code to learn so I can help make better decisions. We use Kafka for instance, and when we first started using it I built a cluster in my homelab so I had a better idea how it worked. The same with Hadoop, Cassendra, and a few different flavors of Kubernetes. The T in CTO is for 'technology', but it really should be for 'technical'.
(3) Perhaps the single most important thing - I try to hire people that are much smarter than I am, always. The amount I learn from people that are smarter/faster/better is many orders or magnitude greater and more valuable than the reverse.
(4) All the rest of the CTO job needs to support this - so budgeting, head count plans, spending strategy, patents and IP, roadmaps, decisions, etc. All of these details have to roll up and hopefully support a strategy.
At least that is how it looks from the engineers perspective.
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.
As a leader, especially a CxO, the most important job they have is the allocation of resources. It was clearly NOT valuable if they couldn't apply any developer time towards it.
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.
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.
> I can.
It's weird to hear a company executive say essentially "this work is important, but our company has too much bureaucracy and risk aversion for a regular IC to spend time working on this, so I just do it myself." Like, maybe that means you should actually be spending your time removing those roadblocks, instead?
It's no wonder why small companies innovate more than large companies. What is a wonder is, why many small companies intentionally make themselves more like large companies and lose their innovative spark as a result.
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.
I'm also a CTO, and the comment about 'delegation' is something I think is important. The decision of what and how to delegate is IMHO something that is easy to get wrong. It is hard to do right all the time.
It is easier the better your team is, so hiring people that are better/smarter than you is the first step. I like the concept that I can do the job of most of the people that work for me, but all of them can do it better. There are times where direct involvement is important - sometimes for big decisions but also sometimes for small ones that need something extra to make it across the line. I like what you said about "org accountable, engineers inspired, and keeping the big picture in". That is a good summary.
* PR reviews for your commits may not be honest, as people may hesitate to reject your code changes.
* You may not have time for your actual responsibilities.
* It may confuse people about your role.
* May be you are not letting some folks do their job.
* You are probably a coder at heart, not a CTO.
True. That's already something I struggle being the most senior in my team. It is hard to find reviewer for my commits who dare to actually reject my code.
If people on the team don't dare to reject code from other members on the team, then it sounds like your team has some serious issues.
In your opinion, what are the actual responsibilities of a CTO?
I am a "CTO" and I always put that in air quotes because I have one direct report and I spend the lion's share of my time doing IC work. I know what I do is not what people picture when they hear the title and I feel weird saying it. I use it because I do have to make the strategic technical decisions, there is no one else. When people are marketing technical B2B SaaS I am the one they are looking for.
From my perspective there just isn't nearly enough for me to do as a CTO to justify me not coding. If I were to hire someone just to manage them that would be an unjustifiable expense at this point. But I also get that as soon as we get to a reasonable size this would be totally unsustainable.
It appears like you became a CTO, because you co-founded the company, not because you rose to the rank.
If you were to join a different company with this approach you are taking, I doubt if you would even reach Staff level.
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.
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.
Any good engineer will be grateful you find issues in their work, especially if you help track down solutions.
Of course, the CTO depending on AI to solve things may be less like that, IDK. Or even before AI I knew the type. I once gave a new CTO a whitepaper to read in private to understand some of the direction I was taking a project, and he basically flipped out. So YMMV.
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.)
> When I was figuring out my role as CTO, I read Greg Brockman’s blog post about defining the CTO role at Stripe. He talked to a bunch of other CTOs and realized there’s enormous variance in what the role looks like. Some CTOs are technical visionaries, some are org builders, some are infrastructure-focused. The commonality is that great CTOs figure out where they can create the most value given their particular skills, interests, and company context.
> For me, that’s meant writing a lot of code. It works because of my particular context: I enjoy building software more than org design, I have deep customer and codebase knowledge that makes me particularly effective, and we’ve hired strong engineering managers.
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.
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.
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...
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.
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).
When the company found product market fit, they hired the CTO to bring the technology leadership in house. Early on he would do experimental POC work that he passed on to me to make it a working system as I was swamped doing my own architectural herding cats work as the company was growing.
But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team.
I’ve been working full time for consulting departments/companies since mid 2020. My goal on any project I’m on with more junior people is to development them. I purposefully give them ambiguous technical requirements with broad guardrails so they have the autonomy to learn and grow and then help them when needed and I put them in front of the customer early on to I present their “workstream”.
From a hands on keyboard side, I let them pick what they want to work on first and I take the left overs.
I like to say that my job as a CTO is to be able to do the job of most the people that work for me, but most of the people that work for me are much much better at it.
Mike McCarthy hasn't played a down of American football in 40 years, and never played at a very high level. But we don't question his ability to get others to perform complex motions.
I am not saying you should sit down and write code. But in IT you know the difference between a tech lead who knows technology, who knows what works, for what reason. And the one that just demands results but knows nothing about the details of the technology. Has never gotten his hands on it.
But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones.
It seems like this sentiment relates closely to the ideas around dual track career progression, and having technical leadership tied to hiring and managing people. Hiring engineering talent is certainly important to the company, but is quite orthogonal to technical decision making and it seems like a natural place to split the role.
The distinction might be something more subtle - I think s good CTO should maintain a deep technical skill, but should do so without putting the technology of the company in jeopardy. I write code, and am a CTO, but I don't write code for our products. I write code in order to continue to develop and maintain deep technical skill. I also manage our technical operations, so I make an effort to a good understanding of the technical areas that are needed to operate - networking, device configuration, IP, etc. In a pinch I am fully capable of making a configuration change to a Cisco switch or a Palo Alto firewall, but in practice I have a team of people that are much better at those tasks. That allows delegation and understanding.
I agree with the author that CTO positions are incredibly varied, so I appreciate them sharing what works for them personally and in their organization, even if it doesn't match what has worked for me.
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.
Every hour they spend coding is time not spent doing the things only the CTO can do.
They really need to hire a programmer or two and focus on their job.
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"?
Also the "C" in CTO means Chief, as in main manager (of managers); if you have no direct report you are not a manager, let alone a "chief" one; call yourself Founder/Distinguished Engineer
CTO-titled people who self admittedly aren’t interested in leading groups of people set a terrible example for smaller outfits, and a confusing and tempting example for eng leadership at larger ones.
In very small startups, CTOs need to code. You need as many people who can code checking in as possible, but you are trying to extend runway and so you don't have too many people on the team yet.
Critically, at this stage of the company your attention is not needed elsewhere as much as it will be one day: governance is light, the team size is small and everyone in the business is talking about product market fit all the time.
In more established businesses, CTOs can't code. I don't mean they don't have the ability, I mean they don't have time at first, and eventually they lose touch with the code base and tools to the point where getting involved slows everyone down, so please, on behalf of your staff, don't.
These CTOs are not "stuck in meetings" - the meetings are the work. Meetings are work. If a meeting isn't work for you, the questions is why are you there. Every meeting a CTO is asked to attend should (and probably does), need strategic technical/engineering input.
The CTO is going (or at least should be), because they have the experience, skills and ability to synthesise decisions and move everyone forward without having to drag all the rest of the senior engineering staff in. They are doing that work so that others don't have to.
They may also sit at the top of the org chart for a section of the company that means HR, Finance or other senior stakeholders want to engage them in order to drive strategic changes.
For a long time, I joked I was in the middle: I worked for startups that were small enough I had to code, but I didn't have the time because of everything else. So I coded, but I was exhausted.
And now you know why it's "former" CTO. This stage is painful. The temptation is to do both. Perhaps start working long days or weekends, but that sends a poor signal to your team.
Complaining or boasting about being very busy or working long days is not the badge of honour you might think it is: it's a signal to your team that you can't manage your time, and you don't value work/life balance. They will vote with their feet if that carries on for more than a month or two.
The better solution is, in my view, find the work/life balance, prioritise and say no to things that don't fit. It's often easier to say no to coding tasks, which you can hire other people to do, than it is to say no to the CEO about something they need doing, which you can't hire other people to do (at least, not without replacing you). Make clear - and signal to others - that you're going to choose how you spend your time carefully, but not because you are a precious resource but because that's the culture you want to instil and for them to do the same. Lead by example, always.
As an aside, even in small startups, when you are coding as a CTO, you should not choose the things that excite you the most, but the things that get in the way of your team the most.
Your engineering staff don't want you to take the meaty things that customers value - they want to do that, it's why they took a crap salary and the promise of untold options-based riches, because at least they get to work on meaningful things customers get excited by.
What they'll value is that horrid piece of refactoring that nobody wants to go near just going away, or that nasty new feature that needs integrating with that third party API everyone hates working with.
Your job as CTO is not to be "the best guy in engineering", it's to move all the obstacles out of the way of the engineering team to make them all the best they can possibly be.
Get rid of their reasons/excuses for failure, by doing whatever it is that needs to be done to help them succeed.
Sometimes, that means focusing on being in meetings to make sure that new policies or product directions aren't going to chop their feet out from underneath them. That means you need to realise that meetings are the work. Get over it.
And if you don't want to do that, and instead throw PRs over the wall that you & AI put together on a Saturday morning and expect a round of applause and hearty thanks... again, expect people to vote with their feet eventually.
Edit: relatedly - at what size do you need a cto?
Very loose definition of a CTO.
(Actually, I did read more, but with contempt stuck in my eyes...)
AI coding tools are great, and the biggest problem they create is that inexperienced people think they can now make technical contributions AND management. Totally untrue. Coding is a tiny part of the technical contribution, and AI tools right now mostly do ONLY that. Troubleshooting and debugging, and communication, and gathering customer requirements are much harder to delegate to AI tools. And, maintenance of code is the real cost center, and AI tools have yet to be proven on that front, and my experiences so far make me think this will be marginal improvements, not 10x improvements.
I'm going to paraphrase his comment about "shipping a vital customer feature by myself because I'm a big boy coder" (maybe I added something there, not sure) because I don't want to deal with the pain of reading it again. I see this all the time where CTOs brag about vibe coding something, and it is always to prove to the team how fast they can go as if that's the main problem. Focusing on that work means you are not writing down coding standards, managing team dynamics, and dealing with the hard problems. Those problems don't go away on their own, they are the real problems, and the downstream effects are what experienced CTOs and technical managers know all too well.
Posts like these show why the founding engineer is the most underpaid person in Silicon Valley. This CTO probably has 30% of the company. There’s probably a founding engineer doing 90% of the same work for years (and likely doing the technical bits better) for 1-1.5% of the company max.
I will say it over and over. Do not code as a CTO.
Coding IC work takes a lot of focus and context that someone who is operating at the company-level should not really be in sole possession of.
To me, the whole point of these positions is to take the hit on random bullshit, planning, people management, etc and give your ICs space to do the kind of work he is taking on.
That doesn't mean you have no technical context or involvement in the development process, but it does mean you should probably be at least one step removed from it.
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.
Because that’s how ridiculous this person is.
