If it's just a "planning my first startup" stage and not an existing enterprise of some non-zero size, I'd suggest starting from the book "The Lean Startup" by Eric Ries and other general "startup mentality" information sources. For a tech-minded CTO, it's especially important to have that correct "startup mentality" to avoid big mistakes from the start.
I’m reading the O’Reilly book on terraform. The end appendix has a great list of books to read for a CTO. Also planning to check the author other book, “Hello, startup” (see [1]).
Assumming you have worked as software engineer I recommend to talk with other CTOs, product people, and/or senior engineers (peer groups) and have concrete problems you would like to solve in mind.
What kind of startup you want to build and in what field? Knowing more details about the challenges you will face help to narrow the focus to specific knowledge and skills.
Does "CTO" mean you are the tech lead of a small (single team) engineering organization? Then everything written for staff engineers applies. E.g I've heard good things about "Staff engineer's path" by Tanya Reilly.
Does "CTO" mean you are leading an org that is too large to be hands-on with tech, and need to build an effective structure and culture? Then I second the recommendation for "an elegant puzzle" by Will Larson.
Or does "CTO" mean that you switched from being an engineer to managing a team of engineers? Then everything for new managers applies, for starters I'd recommend "Becoming an effective software engineering manager" by James Stanier, or "Engineering management for the rest of us" by Sarah Drasner.
For some good general material, I'd also recommend the resources that Gergely Orosz makes available for subscribers to his "pragmatic engineer" newsletter. Those are templates for the kind of documents and processes you will most likely need - if you're new to the role, you will not go too wrong by using them, and if you want to create your own they are excellent starting points.
I don't think the parent comment means only code, never learn. I think their intention was to not worry too much about the "CTO" title and instead focus on building the product at hand.
Yep. When building a startup you’ll find a lot of well-meaning people (in books or in person) who really do nothing but distract you. YC got it right, you should make something people want. Everything that’s not either making something or finding out what people want is just going to slow you down.
This takes many forms including adequate learning / training for self improvement as well as investment in your tooling that will pay dividends on delivering faster or with higher throughput.
These are second and third system effects that require intention to monitor or measure but the effect is real.
Of course nothing is black and white, but if you have limited time/money then you want to get to ramen profitability fast and you simply don’t have time for business model canvases, the perfect employee option scheme, a scalable k8s setup or a perfect CI/CD pipeline.
There’s so much stuff that feels important and valuable, but so little of it really cannot wait until after your wheels are off the ground.
When you read postmortems of startups that didn't get enough customers, often it’s this stuff that actually went wrong. Too much time spent on other stuff than “build something” and “that people want”.
To my experience, it’s difficult to resist all that good advice that’s all over the internet, books, accelerator programs and the like, and saving it all for later. People will tell you “you should get $PETPEEVE right from the start” for every imaginable pet peeve (all the way from legal stuff to unit tests to SEO) and they’ll be very convincing. Trying to resist this is not reductionist, it’s super hard.
It is survivorship bias.
Because the companies get to a point where unimportant things are important and you spend years in that second phase, the learnings are upside down.
„If only we would have solved technical problem X from day 1 we would have so much less hassle in the years to come.“
Except that solving problem X on day 1 instead of shipping what the company did might have killed the company.
I see this in a lot of second time founders, where startup 1 was successful - „this time I‘ll really avoid my mistake X.“
I'd say the time for sharpening the saw was before you started the company. The next opportunity to invest into best practices / long-term is when the company actually has some traction.
The entire point of sharpening the saw is that it is continual though. It doesn't have to be a major investment or long-term, in fact it explicitly references "Daily Self-Renewal". I believe the original comment branch just meant don't worry about "what's applicable to the CTO".
Sure. But the point was that if you're a team of 1 engineer, even if your title is CTO, time spent learning "how to be a CTO" when you don't have any team whatsoever is time not spent building the prototype that needs to demonstrate $XX value/growth by YYYY-MM-DD in order to survive.
Learning is always encouraged, but you should be learning to solve the problems you're about to face. Learning to solve problems which aren't going to be obstacles in the near or mid future isn't helping you in your immediate circumstances. Sometimes the immediate circumstances aren't much of a concern, but when they are, you need to be sure you're learning with that in mind.
Any advice is going to be reductive when measured against the reality of building a startup. While learning and continuous improvement are table stakes, I think the GPs advice is much better to get first-time founders overall. "Sharpening the saw" is likely to feed perfectionist tendencies, or send them into dopamine learning loops online. There's a reason that "bias for action" is treated as a highly valuable trait in founders.
And honestly, pre product-market fit my advice would be not even coding, but iterating in an extremely scrappy way (read: Google Sheets, Jupyter Notebooks, no-/low code, handwritten invoices) until you have people paying for your product and not churning after the first month. Everything else comes secondary. For every company that didn‘t manage to scale their tech and teams fast enough, there‘s 100 that die by „building and they will come“ a polished app with great UX through 4 ecosystems that get launched to deafening silence.
this is perfect advice which i can't agree with enough. that is unless the founders insist on a flawless UI... then you are in for a world of pain
never understood why teams of literally 1 or 2 devs are always forced to try attempt to acheive the visual quality of apps like instagram, whatsapp, etc
> never understood why teams of literally 1 or 2 devs are always forced to try attempt to acheive the visual quality of apps like instagram, whatsapp, etc
For the same reason those kinds of places have more managers than workers… it’s a vanity project.
Obviously some ideas can’t be tested without writing some code, but it’s more of a mindset than a strict playbook–many programmers (myself included) tend to bias towards wanting to write code and avoid sales conversations until the thing feels “done”. Tech message boards are littered with programmers trying to justify why their app has to have a full polished build that will take a year before they can begin selling it.
When you get in the habit of asking yourself, before building, how you can learn the most about what people want with the least amount of code, clever ideas often come to mind.
> For some good general material, I'd also recommend the resources that Gergely Orosz makes available for subscribers to his "pragmatic engineer" newsletter. Those are templates for the kind of documents and processes you will most likely need - if you're new to the role, you will not go too wrong by using them
One word of caution: Engineers and EMs read these newsletters and even management books, too.
It’s not hard to see when your leadership is just parroting things they read from a book or newsletter and trying to pass it off as if they had deep leadership experience. Engineers are good at seeing through cargo cult leadership.
I suggest that if you embrace a practice found in a book or a newsletter, be transparent about the source. Encourage people to read more about it in the book or newsletter where you found it. Don’t try to pass it off as a management technique you invented or pulled from deep background experience, because it feels disappointing to the team when someone realizes their CTO is just parroting things from a newsletter or blog and trying to hide the source.
Also, don’t get into the mindset that having read a lot of books or blogs or podcasts or newsletters is a substitute for experience. Some of the worst leaders I’ve had were those who would lord their book knowledge over everyone as though it made them the confident expert on everything, while we could all clearly see that the extents of their knowledge started and stopped with what was contained in the books they read. Books contribute bits and pieces and give suggestions to add to your corpus of knowledge, but if you treat them like definitive, all-encompassing sources of wisdom then it’s going to be clear to people that you don’t really know what you’re doing. Be honest and stay humble.
That's a very good point. A "CTO" can mean any mix of managerial, leadership and technical responsibilities.
It is my assumption that a CTO is usually coming with technical background already except when he/she is a cofounder and they got technical domain as a result of division of responsibilities. But I am suspicious of startups where none of the cofounders come from technical background.
That leaves managerial and leadership. IMO, if you are a CTO, managerial is something you can hire other people to do for you as your technical organisation grows and leadership is something you should really be focusing on.
You can have flourishing technical organisations with the CTO being a poor manager but a good leader but very unlikely with a CTO with good management but poor leadership skills.
Even if you're effectively 'just' a tech lead of a small team, like I am, it's still a very different job than being a tech lead of a small team in a larger company. You are at the top level of the small group, so you end up being involved in a lot more non-tech things than you think you would be.
Your peers are not other engineers and engineering managers like you would be in most situations, but marketers, product people, designers, PMs and so on. Who is the founder and ultimate authority (CEO) and if you are a co-founder or not also really changes things. A founder CTO is also very different from a non-founder CTO. Co-founder conflicts is a huge thing to manage, (see https://flocrivello.com/co-founding-considered-harmful/ ) because at a small size even as a non founder, you're pretty close to it. You should decide upfront if you're going to approach the job as another effective founder or employee and communicate that to founder at the start as part of a conversation.
I made the transition from staff eng to eng manager to CTO at a small startup, and each one is still a very different job even though the skill sets transfer greatly. I code way more at the startup than I did as an eng manager too. Several things I would suggest:
2. Don't be shy about getting exec coaching, and having the company pay for it. We did that and it was very helpful.
3. Read Radical Candor (updated edition!!!), but also read it with a bit of a grain of salt, realizing the title and advice was chosen because the writer wanted to balance their general high agreeableness with a counterweight that goes too far for the typical person IMO, which the writer writes about that exact dynamic in the second edition.
2a. Learning to be properly direct is super essential, especially at small sizes where its more make or break based on how emotionally deluded you are. The people you are working with need be able to handle you being real with them too. If they cannot, move on, it's that important.
4. Expand your skill set, do everything technical. If you're a backend engineering manager, expand your stack to all parts of the business. That means the back end, the front end, data, analytics, observability, devops, AI models, performance tracing, etc. I started as a mobile eng with previous backend experience, and I wish I expanded sooner so the company had those things on lock sooner, especially in the data analytics side. Engineers hate analytics, embrace it fast to counteract that tendency.
5. Gergely, Will Larson, etc are good resources, but also note they come from what I call the "Uber strain", and thus structure a lot of their experience and advice based on formative years working at Uber. I also worked at Uber when they were there and I recognize a bunch of Uber-isms in their writing.
A good chunk of what they talk about is how to be successful at a place like Uber. Something I've realized later with them is that other companies can be pretty different, and what they espouse sometimes might not match. But on the other hand, Uber's work culture came from previous strains of silicon valley tech culture, especially google's due to the top engineers being from google and setting up their...
As a CTO you'll work a lot with people, the best resource you can get is related to people.
Get a mentor, read books about dealing with people in the most optimal way for you and the business (closing deals, negotiation, psychology etc).
Also learn how to develop people. There are a few books on this, but nothing beats experience and being reflective about it. Every situation is specific and it's up to you to strategize how to develop people in your team, finding out what are the right buttons to push.
Given that you have provided no information about your industry, the size of your company or team, your background, or any relevant information that could be used to help, literally any book could be a good fit for you.
Your best bet is to see if your company is willing to pay for you to take some Dale Carnegie classes (Specifically the ones on Effective Communication). It will help you more than anything technical.
If this is the first time you'd to be responsible for budgets, working with the board, finance teams, HR, etc, then I'd recommend a general business management book like "The Personal MBA" to give you an introduction to the concepts and language that those teams will use.
A couple of hours of listening in here, it feels a lot like "The Five Dysfunctions of a Team" - a made-up story about a made-up company with made-up problems that are simple and self-contained enough to have solutions, and where colleagues are able to work together, despite turbulence.
It's hard to relate to, honestly. It's likely that the target audience is just not "me", but I think somebody with very limited experience dealing with operations would enjoy it. Questions like "why is IT Change Management important" and "how do we prevent people from making mindless changes in production on a Friday afternoon". If you know this already, so far this book is nothing but a "good story about work" - if anybody ever miss this part of life.
I would suggest reading 2-3 books from your tech domain, I mean the tech stack your startup will be using, and maybe 2-3 more about your niche (for example if you are in online advertising, read books about advertising in general and online in particular)
Whichever books you read - some great suggestions in the comments so far - please treat them as advice, and not religious texts.
So many managers and higher fail terribly at being effective because they believe all they need to do is encourage/enforce the practices in the books on the engineering teams, and that is the path to failure and the death of morale.
Take the books as guidance, but listen and engage with your reports (and their reports) to find the problems that need to be solved. Don't dictate or drive people, let them use their expertise in the direction you lead.
I’d imagine mostly because, at least with some jobs, a dead parrot could be successful because the success was tied to other things (luck, founder connections, a few great sales/devs, etc).
On a side note, when I had my startup and was the CTO, a lot of advice I got and also what I ended up realising was that my priority and goal was to build an amazing `Tech Team`.
Technical founders are not CTOs. At least, not for a long time. A CTO role defines the strategic vision for the org. You'll have a vague idea of that as a founder but until you nail the product and where it fits in a market it won't really matter too much. Focus on executing and getting traction instead.
IMHO they ought to have a developer background. That doesn't mean they need to be an expert in DBMS design or whatever, but they should know enough to know when one of their reports is talking BS.
I once worked for a CTO who threw out all our Linux systems and replaced them with Solaris (early 2000s) because "Linux couldn't scale", at the behest of our database architect who was basically just trying to increase his own empire and budget. One of the stupidest and most costly decisions, that also demoralised the rest of the team.
My expectation as a lead-role in DevOps is that my CTO understands what I am saying, if I were to present a business case to him for evaluation or raise a concern with the company tool stack. Shortly put I want somebody with decision making powers to also have the knowledge to make those decisions. I don't need them to be able to implement any of the changes, but I need them to be able to know why the change needs to happen and what business value it does or does not give.
At a startup phase, I'm not sure there is anything that is strictly speaking a "CTO" task, except the paperwork. And once you get big enough for it to matter, the same rule applies as for a CEO: the CxO you need for your first million is a different one you need for your 100 million and different yet again for your first billion.
There is of course a GitHub list for this: https://github.com/kuchin/awesome-cto and perhaps the best way to find out what you need is to check things off of that list that don't actually have anything to do with what you're actually working on. Role names generally have very little meaning on their own, it's all about context.
You need to book communication and/or good sales course. As CTO you’re into politics, not into tech. Ability to communicate clearly and steer the conversation is your skill number one. Tech background is nice to have, but not really useful. You will hire people for that.
147 comments
[ 4.9 ms ] story [ 56.4 ms ] threadhttps://www.amazon.com/Tom-Demarco/dp/0932633439/?nodl=1&dpl...
https://news.ycombinator.com/item?id=37971795
1: https://www.ybrikman.com
What kind of startup you want to build and in what field? Knowing more details about the challenges you will face help to narrow the focus to specific knowledge and skills.
Does "CTO" mean you are the tech lead of a small (single team) engineering organization? Then everything written for staff engineers applies. E.g I've heard good things about "Staff engineer's path" by Tanya Reilly.
Does "CTO" mean you are leading an org that is too large to be hands-on with tech, and need to build an effective structure and culture? Then I second the recommendation for "an elegant puzzle" by Will Larson.
Or does "CTO" mean that you switched from being an engineer to managing a team of engineers? Then everything for new managers applies, for starters I'd recommend "Becoming an effective software engineering manager" by James Stanier, or "Engineering management for the rest of us" by Sarah Drasner.
For some good general material, I'd also recommend the resources that Gergely Orosz makes available for subscribers to his "pragmatic engineer" newsletter. Those are templates for the kind of documents and processes you will most likely need - if you're new to the role, you will not go too wrong by using them, and if you want to create your own they are excellent starting points.
You must "sharpen the saw".
This takes many forms including adequate learning / training for self improvement as well as investment in your tooling that will pay dividends on delivering faster or with higher throughput.
These are second and third system effects that require intention to monitor or measure but the effect is real.
There’s so much stuff that feels important and valuable, but so little of it really cannot wait until after your wheels are off the ground.
When you read postmortems of startups that didn't get enough customers, often it’s this stuff that actually went wrong. Too much time spent on other stuff than “build something” and “that people want”.
To my experience, it’s difficult to resist all that good advice that’s all over the internet, books, accelerator programs and the like, and saving it all for later. People will tell you “you should get $PETPEEVE right from the start” for every imaginable pet peeve (all the way from legal stuff to unit tests to SEO) and they’ll be very convincing. Trying to resist this is not reductionist, it’s super hard.
Learning is always encouraged, but you should be learning to solve the problems you're about to face. Learning to solve problems which aren't going to be obstacles in the near or mid future isn't helping you in your immediate circumstances. Sometimes the immediate circumstances aren't much of a concern, but when they are, you need to be sure you're learning with that in mind.
never understood why teams of literally 1 or 2 devs are always forced to try attempt to acheive the visual quality of apps like instagram, whatsapp, etc
For the same reason those kinds of places have more managers than workers… it’s a vanity project.
When you get in the habit of asking yourself, before building, how you can learn the most about what people want with the least amount of code, clever ideas often come to mind.
One word of caution: Engineers and EMs read these newsletters and even management books, too.
It’s not hard to see when your leadership is just parroting things they read from a book or newsletter and trying to pass it off as if they had deep leadership experience. Engineers are good at seeing through cargo cult leadership.
I suggest that if you embrace a practice found in a book or a newsletter, be transparent about the source. Encourage people to read more about it in the book or newsletter where you found it. Don’t try to pass it off as a management technique you invented or pulled from deep background experience, because it feels disappointing to the team when someone realizes their CTO is just parroting things from a newsletter or blog and trying to hide the source.
Also, don’t get into the mindset that having read a lot of books or blogs or podcasts or newsletters is a substitute for experience. Some of the worst leaders I’ve had were those who would lord their book knowledge over everyone as though it made them the confident expert on everything, while we could all clearly see that the extents of their knowledge started and stopped with what was contained in the books they read. Books contribute bits and pieces and give suggestions to add to your corpus of knowledge, but if you treat them like definitive, all-encompassing sources of wisdom then it’s going to be clear to people that you don’t really know what you’re doing. Be honest and stay humble.
It is my assumption that a CTO is usually coming with technical background already except when he/she is a cofounder and they got technical domain as a result of division of responsibilities. But I am suspicious of startups where none of the cofounders come from technical background.
That leaves managerial and leadership. IMO, if you are a CTO, managerial is something you can hire other people to do for you as your technical organisation grows and leadership is something you should really be focusing on.
You can have flourishing technical organisations with the CTO being a poor manager but a good leader but very unlikely with a CTO with good management but poor leadership skills.
Your peers are not other engineers and engineering managers like you would be in most situations, but marketers, product people, designers, PMs and so on. Who is the founder and ultimate authority (CEO) and if you are a co-founder or not also really changes things. A founder CTO is also very different from a non-founder CTO. Co-founder conflicts is a huge thing to manage, (see https://flocrivello.com/co-founding-considered-harmful/ ) because at a small size even as a non founder, you're pretty close to it. You should decide upfront if you're going to approach the job as another effective founder or employee and communicate that to founder at the start as part of a conversation.
I made the transition from staff eng to eng manager to CTO at a small startup, and each one is still a very different job even though the skill sets transfer greatly. I code way more at the startup than I did as an eng manager too. Several things I would suggest:
1. You're an exec, even if your company is tiny, and how it works is different than being a manager. Concepts like the 'first team' https://www.michaelvizdos.com/resources/first-team and 'getting on the balcony' matter way more than when you're in a purely product & eng organization: https://www.bettermanager.co/post/move-away-from-the-dance-f...
2. Don't be shy about getting exec coaching, and having the company pay for it. We did that and it was very helpful.
3. Read Radical Candor (updated edition!!!), but also read it with a bit of a grain of salt, realizing the title and advice was chosen because the writer wanted to balance their general high agreeableness with a counterweight that goes too far for the typical person IMO, which the writer writes about that exact dynamic in the second edition.
2a. Learning to be properly direct is super essential, especially at small sizes where its more make or break based on how emotionally deluded you are. The people you are working with need be able to handle you being real with them too. If they cannot, move on, it's that important.
4. Expand your skill set, do everything technical. If you're a backend engineering manager, expand your stack to all parts of the business. That means the back end, the front end, data, analytics, observability, devops, AI models, performance tracing, etc. I started as a mobile eng with previous backend experience, and I wish I expanded sooner so the company had those things on lock sooner, especially in the data analytics side. Engineers hate analytics, embrace it fast to counteract that tendency.
5. Gergely, Will Larson, etc are good resources, but also note they come from what I call the "Uber strain", and thus structure a lot of their experience and advice based on formative years working at Uber. I also worked at Uber when they were there and I recognize a bunch of Uber-isms in their writing.
A good chunk of what they talk about is how to be successful at a place like Uber. Something I've realized later with them is that other companies can be pretty different, and what they espouse sometimes might not match. But on the other hand, Uber's work culture came from previous strains of silicon valley tech culture, especially google's due to the top engineers being from google and setting up their...
Get a mentor, read books about dealing with people in the most optimal way for you and the business (closing deals, negotiation, psychology etc).
Also learn how to develop people. There are a few books on this, but nothing beats experience and being reflective about it. Every situation is specific and it's up to you to strategize how to develop people in your team, finding out what are the right buttons to push.
Your best bet is to see if your company is willing to pay for you to take some Dale Carnegie classes (Specifically the ones on Effective Communication). It will help you more than anything technical.
The Personal MBA: A World-Class Business Education in a Single Volume https://amzn.eu/d/dTAp1GF
It's hard to relate to, honestly. It's likely that the target audience is just not "me", but I think somebody with very limited experience dealing with operations would enjoy it. Questions like "why is IT Change Management important" and "how do we prevent people from making mindless changes in production on a Friday afternoon". If you know this already, so far this book is nothing but a "good story about work" - if anybody ever miss this part of life.
So many managers and higher fail terribly at being effective because they believe all they need to do is encourage/enforce the practices in the books on the engineering teams, and that is the path to failure and the death of morale.
Take the books as guidance, but listen and engage with your reports (and their reports) to find the problems that need to be solved. Don't dictate or drive people, let them use their expertise in the direction you lead.
- Dev/ML/X Ops
- System Architecture
- DB design? etc?
I once worked for a CTO who threw out all our Linux systems and replaced them with Solaris (early 2000s) because "Linux couldn't scale", at the behest of our database architect who was basically just trying to increase his own empire and budget. One of the stupidest and most costly decisions, that also demoralised the rest of the team.
There is of course a GitHub list for this: https://github.com/kuchin/awesome-cto and perhaps the best way to find out what you need is to check things off of that list that don't actually have anything to do with what you're actually working on. Role names generally have very little meaning on their own, it's all about context.