> Lots of travel<p>> 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.<p>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.<p>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'm in year 3 of being a CTO.<p>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 <i>little</i> less of that thankfully.<p>However, what I struggle with <i>a lot</i> is that there's absolutely no manual for this role. Everything is my problem, yet nothing is my problem.<p>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).<p>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 <i>really</i> 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.<p>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.<p>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).<p>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.<p>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.
I'm in year.. let's see.. 24 of being a CTO. I always enjoy reading what other people see as important enough to write about. The conversation about shipping code is something most technical CTOs feel, and my solution to that 'need' has been to continue to explore my deeper technical 'must be building' in other parts of my life.<p>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.<p>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.<p>Food for thought, at least for me.
>Ship code more consistently.<p>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.<p>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.<p>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.<p>And really whose job is it to prevent that from happening? The CTO ... oh noes.<p>That's not everyone of course, but that level of CTO with his hand in the bits just seems constantly dangerous.