Year 7 as a CTO
miguelcarranza.es
miguelcarranza.es
> This was the year I traveled the most in my life—and looking back, I probably should have traveled even more. I visited customers, helped with sales, conducted executive interviews, and spoke at a few conferences. It’s hard being away from two little kids, but each trip turned out to be worth it.
For me, no. Absolutely not worth it. I traveled during my kids early years and it was a waste of time. That job is long gone, do not even remember most names, it is just a vague memory. My children are here and I missed a too much time to be with them.
I count my remaining years in much shorter spans. I do not look back and say, I should have spent more time working and traveling.
I remember a blog on some start up's website and it described a founder who was in the office on Christmas Day and praising other people who came in on their own time too that day and how they're all working so hard to work on their startup that ... provided some rando non essential service with a web interface. Honestly that particular blog was kinda creepy / sad.
By saying that traveling for work (aka working, aka participating in their career) INSTEAD of spending time with their kids' early years was "worth it" they are saying that it was a worthy tradeoff--that the value of the career actions exceeded the value of formative early time with their own children. And they likely don't even realize that's what they're saying.
Like, you have decent money already, you can make money again in 5 years or whatever, I don’t understand the priorities.
It feels more like they are sleepwalking vs making conscious value judgements.
I specifically waited to have children until a bit later because of work/startup travel. Time goes in one direction and there is a giant locomotive at the end waiting to smash into you.
I was non-founding, so while the author mentions fleeting bouts of imposter syndrome (which he leans into by trusting his instincts) I have a little less of that thankfully.
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.
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).
I think it's an unfortunate case that since there's not a really solid role definition, it's not even possible to talk about what should and shouldn't be included. For example I was acting as IT for a really long time because justifying a person for such a role was really difficult, and we spent even more time dealing with our IT service provider than if I was doing it by myself- so I did.
As for being hands on, that's dead. I still get my little joy from shipping toy code (little bots that automate stuff for example) but I've hired people who are better programmers than me and do it daily, and I have to trust them.
Aside from what I mentioned about the role, the absolute hardest thing for me to come to terms with is that I no longer get a dopamine hit when I fix/build something. 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).
It's a very thankless, extremely stressful job, where there is little direct joy from accomplishing something. And worse: people will rarely give you critical feedback to improve should you be doing anything wrong, so you're constantly second-guessing yourself because you know the power dynamic stifles feedback loops. Nobody will ever thank you, and I find that people treat you like you're part of a system and not a human.
I'm not sure I'll make it to year 7, and I wonder if I'll change my tune by then; but I wonder more how the author feels about these points.
To answer though: I would prefer not to let down the team, no matter my own personal situation.
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.
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.
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!!!???
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.
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.
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.
I have a small Youtube channel that follows a few different technical paths, and I keep another array of deeper technical challenges in the development pipe always ready to go. I still write code, design hardware, build cars, and look at stars, but they are all self driven projects.
I find the result is a tighter focus at my core job of technology strategy and the bigger decisions but also not a loss in my core technical abilities. To me the T in CTO means technical, and I think it is my responsibility to deeply understand the technology that our teams use. That understanding however can come from personal learning just as much from being in the production loop. Be a nerd.
Food for thought, at least for me.
Speaking generally, for a CTO to personally ship more (non trivial code) code ... I think is such a double edged sword and even potentially dangerous.
His point 1 hits close to home, not for me personally, I'm not a CTO, but for the CTOs I worked with. CTOs shipping code that is important seems like constant pressure for the CTO to work outside the system or put off organization that the CTO should be doing. I see it time and again with heavily "involved" CTOs where they take that important task and now some other changes are held up or they just have to get it out the door so we'll try this ... oh and they're heads down this week because they took that important task so other important organizational things don't happen. Or they do the organizational thing, and the important task, AND miss the mark with the code / feature.
Personally I'm in a situation now where a great guy who was the CTO left abruptly and the rest of us are in a situation where we're picking up the pieces from all the exceptions he as CTO was empowered to allow. Things aren't documented, unexpected things show up like this code uses a weird auth pattern that seemed like a great idea and maybe was going to be used elsewhere if they just were around longer and so on. And at the time each event wasn't that bad maybe ... except it is now.
And really whose job is it to prevent that from happening? The CTO ... oh noes.
That's not everyone of course, but that level of CTO with his hand in the bits just seems constantly dangerous.
It is dangerous and is likely to cause a range of problems. The challenge is stepping away from that part of the work. It would seem the best way to do this is to progressively give up this direct work and mentor your replacement(s) possibly reviewing changes before quitting entirely.
It seems to be a personality thing with some people being unable to take those steps before being forced by circumstances. I love leaders to have curiosity about details and want to create the environment for great technical work, but that is a very different type of work that doesn't drive the same rewards (or dopamine hits.)
The biggest danger of a CTO being too deeply involved at a technical level is it does not scale. Knowledge and deep understanding helps you scale, but actually writing production code that has to be maintained puts a burden on scale.
Of course at a startup that might be different, especially in the beginning, but the faster you get someone working for you that is even better than you at the job the faster you will be better at your future job.
Enough said.