> 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.
It's sad in America and ESPECIALLY in "startup culture" people base their entire identity and self-worth on their career. Literally even above their own children as seen here.
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.
Yeah as I’ve gotten into parent age territory I’ve been surprised by how basically all of my peers seem to value making money over spending time with their young children.
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.
For me, it's not clear what was most valuable here. I think that's an important thing to take away from a statement on traveling more. I don't think all of the items will have had equal value. Being physically present and checked out is possible. In any case, the other spouse carries more of the burden.
"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 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.
Yeah that line struck me as interesting as well. Very "start up / career hype" kinda line there. You can't replace time with your kids, even "quality time" doesn't make up for lacking in quantity.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
>> 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.
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.)
"That's not everyone of course, but that level of CTO with his hand in the bits just seems constantly dangerous."
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.
> Lots of travel
> 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.
It's sad in America and ESPECIALLY in "startup culture" people base their entire identity and self-worth on their career. Literally even above their own children as seen here.
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.
Yeah as I’ve gotten into parent age territory I’ve been surprised by how basically all of my peers seem to value making money over spending time with their young children.
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.
For me, it's not clear what was most valuable here. I think that's an important thing to take away from a statement on traveling more. I don't think all of the items will have had equal value. Being physically present and checked out is possible. In any case, the other spouse carries more of the burden.
"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 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.
Yeah that line struck me as interesting as well. Very "start up / career hype" kinda line there. You can't replace time with your kids, even "quality time" doesn't make up for lacking in quantity.
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.
I'm in year 3 of being a CTO.
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.
"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.
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.
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.
>Ship code more consistently.
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.
>> 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.
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.)
"That's not everyone of course, but that level of CTO with his hand in the bits just seems constantly dangerous."
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.
> Lots of travel...It’s hard being away from two little kids, but each trip turned out to be worth it.
Enough said.
That almost conflicts with his line that "life is what happens when you’re busy building your startup".