281–290 of 304 posts
I don't want to come across as judgemental or anything, nor I did deep research on your background. 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.
There are a few serious issues with this kind of "passion" in a work area outside of yours. * 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.
In your opinion, what are the actual responsibilities of a CTO?
Earlier quoted context omitted.
On my resume, I usually list it as “Lead Engineer” since it fits the roles I’m applying to better.
I think a founder/early gets away with "CTO" on their resume, esp. if they're the only person in the org with the role (ie: it's a PM-style CTO, and there isn't a VP/PM; or: it's a VP/E-style CTO, and there isn't a VP/E). But outside that circumstance, given the choice, I'd rather have the VP/PM or VP/E role than "CTO". (As we get deeper into these threads I am further out on a limb.)
Articles like these are kind of hard to parse because there's no well-defined meaning to the title of "CTO". Our "CTO" codes, probably more than anybody in the company, but that's because he's got a founder-inherited CTO title that mostly just means "he can do whatever he wants" --- we're happy with that, what he wants is practically always great. That's one definition of a CTO. Another CTO type is the opposite: "the…
Title inflation everywhere. "Founder" instead of small business owner of a company with no customers.
Earlier quoted context omitted.
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 a…
You're not describing a CTO, then
Earlier quoted context omitted.
How can the Chief Technical Officer not be the one chiefly responsible for technology decisions?
I thought it's typically Chief Technology Officer 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…
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.
I have a hard time taking someone with the title of “CTO” seriously if they have no reports and have time to code instead of being concerned with strategy. 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
How do you concern about strategy all day? Just sit down and think about it?
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.
My journey has been quite similar (just a few more years of "unhappy John") and this approach is now very close to what I practice. I do have a few reports and run the R&D leadership team, I delegate as much as I can to my directors. (Besides being hands on where the organization needs it, I still regard the other part of my job to keep our org accountable, engineers inspired, and keeping the big picture in.) For peo…
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.
It was hard to tell if he means he doesn’t do meetings at all, though it’s kind of implied. There are lots of high leverage activities around advocating for engineering’s perspectives among the other executives and bringing the business context to engineering, both of which don’t involve directly managing reports. But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in fav…
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 appreciated the sentiment but I do wonder how on earth a CTO has enough time to write one line of code, let along several thousands. Even before reaching the C-suite roles, higher ups tend to be in meetings all day, back to back. In the short amount of non-meeting time they find, they typically have to do other admin related things or information sharing. I guess that CTO uses weekends or works super long hours whi…
While I think CTOs should take steps back from pushing to production systems because there's a lot of I dotting and T crossing that needs to happen with production systems that CTOs don't reasonably have time for, if a CTO wasn't writing experiments and building test systems to determine technical direction, or at least getting their hands dirty with said systems produced by their top principles, I wouldn't trust the…
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.