Why I Code as a CTO

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.

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.

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".

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.

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?

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 liked your take and curious to know what you think a CTO should be doing here

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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).

This bit got me. It's a direct quote from the linked post for those who haven't read it

If you’re working on insurance SaaS, I agree.

If you’re building hard tech, I’d disagree entirely.