Hacker News Reader

"I have had several conflicts with founders because I act outside of my scope (I.E, I do things they think is a waste of my time: like budget forecasts, headcount plans, retrospectives of milestones and previously I was doing the product roadmap- which I definitely agree is out of scope)."

The founders hate it when you use numbers, facts and analysis to come up with very good reasons not to implement their latest Great Idea on demand. I presume you were the one that actually implemented a Product Roadmap to keep founders out of the weeds in the first place.

> I presume you were the one that actually implemented a Product Roadmap to keep founders out of the weeds in the first place.

Wow, spot on.

The issue was that the team was being pulled from pillar to post and could never focus on anything for more than 5 minutes before having a different highest priority task foisted onto them, requiring them to change focus immediately and abandon progress.

By forcing a roadmap I gave the dev teams a week or so to work on something a little more undisturbed before moving onto the next thing. This massively increased our throughput and the quality of the outcome, but it was not popular with the founders because it forced the founders to crystallise ideas and prioritise them properly for the resources we had.

Technical Cofounder here: I presume we're all living some parallel life. Forcing founders/investors/biz people to think it even 10% through was always really hard. It's like they have some kind of dopamine addiction that only NEW SHIT EVERY DAY can scratch. They live in a sort of dream world and simply cannot STAND being pulled back into reality.

One of the worst books ever published was that damn Steve Jobs biography by Walter Isaacson. The week after that was published literally everyone with a laptop was a demanding asshole with ridiculous ideas they now felt compelled to beat everyone else into because IT WORKED FOR STEVE AMIRITE!!!???

"However, what I struggle with a lot is that there's absolutely no manual for this role. Everything is my problem, yet nothing is my problem."

For me, that last sentence is the most empowering. The essence of the CTO role is the ultimate responsibility for 'technology', yet you are often not the actual leader that controls the technology. It is one of the hardest concepts to make work because it relies on your own deeper understanding of the technology AND the people that are trying to use it. You are constantly trying to predict what the outcome will be so you can decided what to influence, which is like pushing on slushy water.

"Failures are concentrated (blameless post-mortems mean that it's the culture or environment that's wrong, guess who is responsible for the environment!) and successes are amortised (credit should go to the team who are hands on, of course)."

That is a really good compact statement about the crossover between credit and responsibility - and it really pushes hard that post-mortems are important. I have said more than once at a post-mortem - "Just to start us out, all of the failures are my fault, so lets leave the arrows pointing at me and dig in". Sometimes that is the only way to get people to open up and focus on the truths and not worry about the arrow. Just remember that managing upward is a different task.

One thing I notice when reading CTO/CIOs' thoughts on their role, regardless of their experience level or how they attained the position, is that those who mention being "hands-on" – that is, coding or "being technical" – often lament that being good at their job prevents them from indulging in it. I find this sentiment telling, valuable, and a marker of a good technical leader.

Those who don't mention it might be good administrators, procurement officers, or even strategists, but they don't strike me as good technical leaders. Perhaps that's still being a good CTO, but I'm not so sure.

An HN user who is a CTO/CIO of some repute at a medical company (if I recall correctly) had a comment that has stuck with me (paraphrasing): the marker of a good CTO isn't necessarily someone who is in the technical minutiae, rather someone who wants to be in the technical minutiae; someone who is technically very curious.

"someone who is technically very curious."

By far the most useful quality in a CTO, but I'm a CTO and have said that exact thing so I'm biased.

I have met hundreds of CTOs in my career so far. It is surprising how quickly I can tell if the person is curious or not, and how often that one attribute ends up being a marker of someone who is extraordinary.

Funny enough it was you I was attempting to paraphrase :)

Ha! It is a funny thing.. one time I was trying to remember something specific about a calibration table in a Subaru ECU and I googled it and found a great answer.. and sure enough it was something I posted years before. Ah the beauty of forgetting!

Haha, I've actually had the exact opposite problem: I was looking for a specific answer I knew I had only to find an obviously wrong answer on Stack, think to myself "who is this moron with his bag of lies", only to find it was me. Ah the pain of remembering!

Maybe a bit of ruthless advice, but if you have very little/almost zero company ownership, it isn’t worth pushing yourself extra for the company’s benefit particularly if the CEO doesn’t appreciate it.

I appreciate the advice, and I don't think it's ruthless. So, thanks!

To answer though: I would prefer not to let down the team, no matter my own personal situation.

As a senior dev, team lead and sometimes acting principal, I wonder what is the definitive role for CTO. I've seen several companies try to have CTO only to have no role for them.