> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie.
This bit got me. It's a direct quote from the linked post for those who haven't read it
(Author here) I stand by this comment and I think it’s really important for engineers to recognize that everyone has different places where they gain and lose energy.
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).
I'm glad you are comfortable coming forward and for sharing your thoughts. Not to pile on with the others here but you may go fast alone but you go far together when you build the right team. Being an individual contributor CTO is not being a CTO for a business that succeeds at scale. Don't stop doing what you love if you feel that's more important but it's probably best to step back from being a CTO and hire someone to manage that role so you can code if you don't want to do the job.
This can work, imho, IFF the organization has both a CTO and CIO (or someone else tasked with managing the org). I've seen lots of places where the CTO is purely the technical visionary/advisor/final decision maker, and doesn't directly manage the technical organization.
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.
The technical capacity of a CTO matters less then the CTOs ability to stay in their lane (for a lack of a better term).
I once worked for a company with a self taught CTO (and not the good kind). They had a number of star players, and this CTO would frequently lash out at them. All because he was getting in the way of them doing their jobs, doing work he wasn't qualified to do, trying forcing them to clean up after him, and then yelling at them for it. It was insanely toxic. I only lasted a few months. It was so bad I back channelled patches and project briefs to people he liked to get them approved.
Had this CTO remained people, project and product focused everything would have been fine.
> this CTO would frequently lash out at them [...] doing work he wasn't qualified to do, trying forcing them to clean up after him [...] and then yelling at them for it
Was that a Fintech in Germany, by any chance? :)
I once witnessed a meeting between a CTO and a Tech Lead. The CTO was attending from his laptop in an open office, and he was yelling in Russian for one hour straight at another Tech Lead because he wanted the tech lead to finish his work. It was a pathetic display, with the whole company watching and wondering what was going on.
Eventually he was "phased out" by having a few people promoted to VP of engineering who would deal directly with the CEO instead of him.
Last I heard he tried to rewrite the financial core in Golang by himself, but he failed since nobody wanted to work together with him and he doesn't really knew the language.
Self taught in the programming sense, or the people management sense? Because I feel like the letter is much more common than not in software. Just curious in case there's an expected background you're thinking of when you say that. I have no point of reference for CTO backgrounds beyond generic MBAs or senior devs that either gave themselves the titles as founders or failed upwards.
CTO, CIO, and the head of engineering (the latter of which can often be split among different groups) are often very distinct things, especially at larger companies. And, yes, while the CTO probably has a seat at the table for technology direction is often primarily a public technology face of the company as opposed to someone involved in a lot of hands-on day to day technology implementation.
“Probably has a seat at the table for technology direction” is a wild take to me. So much so that I can’t even formulate a response other than “what…?!”
I'm not sure what you find confusing. Someone can have an advisory and essentially technology evangelist role without necessarily being the ultimate decision maker. (And, at a larger company, a variety of folks--including the board--will ultimately make final consequential decisions.)
In most companies I've been a part off, including multiple >$1B tech companies, the CTO's focus is not on the engineering. That's the job of a VP Engineering or some similar position.
CTO (which will sometimes have a "CTO office") is to work besides the engineering on investigating new technologies and ideas that are beyond what the engineering organization would have otherwise done on the day to day. They are also an authority on all technology in the company but are not in the engineering "chain of command".
That said this is not universal, there are organizations where the CTO does lead the engineering organization. I think that's sub-optimal because there is always going to be tension between the day to day and the broader scope and those should be different roles.
In a startup, it is more common for a CTO to lead engineering because there is not yet enough to justify having both a VP Eng and a CTO and perhaps most of the work is around figuring out technologies. But as the company grows it makes sense to separate those functions.
I've seen both. A CTO office that also leads engineering--typically via a direct report to the CTO--and an organization where the CTO is largely an external evangelist (typically with a small staff) while engineering is a separate organization--though hopefully aligned. The view here where CTO is also the head of day-to-day engineering operations and technical vision is more of a small company/startup thing. The two are often separated to at least some degree at larger operations.
This description is accurate to what I have seen and what I do. I'm a CTO of a >$1B tech company, and my roles is focused around the technology innovation, and that includes evaluating and prototyping new tech. In my particular case that role also includes the operation of our technology because that is very central to our business - and also extremely focused on high reliability.
When I was CTO of my startup I had far more direct engineering development work, but that is typical in the building stage.
As for the core of this post, the one thing I do agree with is the ability of the CTO to actually be technical. I write code all of the time, but not for our products. The goal is to remain both technically proficient but also focus that proficiency on leadership.
There is a big leap between them not being the sole person responsible for technical decisions and them not even necessarily having a seat at the table for technology direction. The former is understandable. Later - quite surprising.
I'm not sure what I wrote that's contrary to any of that? Maybe I shouldn't have used the word "probably"? There are a lot of people responsible for the technical direction of a large company of which the CTO is important but hardly the only one.
I worked at company where the VP of engineering regularly stated that he "hated managing people". This is also the same guy who literally deleted the main production database because he was testing something out.
He mentions he has nobody reporting to him. That sounds like he’s really a staff engineer with a vanity CTO title, plus a lot of sway in strategic decision making.
It’s not a guaranteed recipe for disaster, but it depends critically on his relationship with whoever actually manages the engineering org. If they don’t pull in the same direction, things go south very quickly and you end up with a little civil war.
Either way it’s a red flag and I wouldn’t work there. Another red flag is that he wrote this blog post at all. Given how clearly negative the reaction to it was going to be, it’s a strong signal he doesn’t really think things through and has a ego wrapped up in his “coding” prowess and ability to circumvent process. People mention Woz as an example of a technical co-founder in a non-management role, but he is a humble guy and wouldn’t brag like this.
LinkedIn suggests "50-200". 54 work in San Francisco, and 154 people are associated with it. So probably closer to 150, but that includes a lot of Sales and Marketing related roles. Maybe the "engineering" org is ~100 or just under that.
FWIW Carmack did this as CTO of Oculus [0]. Another configuration I've seen is for the CTO to have like 1 direct (VP Eng) who does actual eng managing. You could argue it's a staff engineer role but I've never seen staff engineers actually get much say over org direction/structure or be empowered to break gridlock like this.
It's not that uncommon to keep the "CTO" title and not be the primary manager of the engineering organization. There are all kinds of things you can do with the org chart. If I recall correctly, Clickhouse works this way.
The company's cofounders comprise three people [1]:
* Aaron, a sales-oriented CEO from Elastic and Salesforce
* Alexey, the original Clickhouse developer, as CTO
* Yury, an experienced engineering executive from Google/Netflix as "President"
An excerpt from the launch announcement [2]:
> While negotiations were still ongoing, Katz decided they needed a third co-founder. “I kept thinking, if I could get a third co-founder to run product and engineering, and if I could find someone with the same level of experience building distributed systems on open-source that I have on go-to-market, it could be a really compelling combination,” Katz says.
I'm not that familiar with his employment history; you could be right. Either way, he'd still be an example. If you have longer term ones, I'm sure it would add to the discussion
I recall James Goodnight of SAS coding while being a CEO. As per https://www.forbes.com/sites/peterhigh/2014/05/12/an-intervi..., he still programs from time to time but doesn't have a specific part in development. In looking at the articles to refresh my memory, it is clear he is one of the good CEO's
This bit got me. It's a direct quote from the linked post for those who haven't read it