Ask HN: What are good books/blogs to read for a first time CTO?
Planning my first startup as CTO, what resources should I go through for sure.
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.
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.
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.
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 promo system to match googles (vs lets say apple) and the knock on effects of that. Something about that place made people get really good at understanding what is needed to succeed in tech leadership and write about it, I guess it's kind of a paypal mafia effect.
The team wrote web / SaaS / analytics software in Python and JavaScript, deployed on Linux + AWS, using lightweight planning tools like GitHub and Notion. It was also a fully distributed team long before the pandemic. Over time, the company (Parse.ly) gained hundreds of enterprise customers and established itself via profitable growth in a straightforward SaaS business model. In 2021, less than a year after this blog post was published, the company was acquired by one of the largest open web internet companies (Automattic, creators of WordPress.com).
"Managing software teams: the definitive reading list"
https://amontalenti.com/2020/11/28/definitive-reading-list
The blog post is organized into a few sections, each featuring a few relevant books:
- Management as a high-leverage activity
- Product marketing and product management
- Debugging dysfunctional product cultures
- The psychology of deep work
- Fully distributed teams
- Programmer mindset and philosophy
It's easy to skip around to find a good starting point or make your own (smaller) reading list. Hope that helps. Good luck!
Thanks for sharing all the resources and giving me guidance a few years ago. Still very thankful for a few of your posts and pointing me to read Venture Deals, all made me a much better CTO and founder. Hope your current journey is going great!
You should instead TALK to long-time or former CTOs and ask them for advice. You won't find that advice in any book. It's invaluable.
I also helped many of them a lot during my years at AWS, and most of them were very eager to give me a hand / provide advice.
7 CTOs is another one that I have heard of but haven't participated in.
(Your comment is less appropriate because the analogy would be if you said: "Nice to meet you, Jim. Not all people in your position are men, though.")
https://en.wikipedia.org/wiki/Simone_(given_name)#Simone - Pick any of the Italians off the list and they're almost certainly men, most of the non-Italian Simone's are women.
Of course, it's still safer to look them up if you don't actually know the person in question and want to use he or she.
> Of course, it's still safer to look them up if you don't actually know the person in question and want to use he or she.
Physician, heal thyself.
I’ve been an exec, founder, CEO, and board member at various stages of successful (IPO) /unsuccessful companies (acqui-hire) companies. And the common thread at every stage is that the most successful companies had management teams that worked well together to optimize for the business.
So instead of spending your energy on reading / learning more about tech, I’d recommend you spend your energy learning more about business (I’d probably start by asking the CEO & the rest of the mgmt team for advice on what to learn.)
You should do this even if it leads to layoffs for your department, because, again, your goal should be a thriving business, not a thriving engineering department and a lackluster business.
Source: I did recommend and lead this course of action once (the outsourcing, not the layoffs). Company is still using an outsourced solution.
A warning, though: it's a "business fable", where he gets his point across by telling a fictional story. Business writers tend to be pretty terrible fiction writers so it's corny, but it also makes it a pretty light read.
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.
https://www.amazon.com/Tom-Demarco/dp/0932633439/?nodl=1&dpl...
1) Behavioural Psychology - https://en.wikipedia.org/wiki/Behaviorism
2) Organizational Behaviour - https://en.wikipedia.org/wiki/Organizational_behavior
3) Evidence-based Management - https://en.wikipedia.org/wiki/Evidence-based_management
An Elegant Puzzle: Systems of Eng Management (https://lethain.com/elegant-puzzle)
and
The Art of Leadership, small things done well (https://www.amazon.com/Art-Leadership-Small-Things-Done/dp/1...)
There are a lot more that were helpful to me, but those two encompass most of the important concepts and skills already in a usefully synthesized way, at least for me.
I can't stress just how good this podcast is, all of the guests are excellent. Here's a brief highlight of my favorites:
- Michael Nygard, SVP of Enterprise Architecture, Sabre - brilliant breakdowns of how to approach software problems conceptually
- Dr Steven Spear - tons of excellent stuff from years of studying Japanese management techniques
- Elisabeth Hendrickson - has been studying testing and QA for decades, tons of great insights
- Scott Havens - incredible breakdown of the inventory management system of jet.com, acquired by Wal-mart and now powering walmart.com
Eye-opener (worst take away / for me - you can't be friends with devs-under-you anymore. Or with anyone techie it seems. Probably depends on company-founders' culture - if small and new - or politics - if older and/or bigger)
some more of hers here: https://skamille.medium.com/an-incomplete-list-of-skills-sen...
Also.. you can't be everything. Choose your poison (or if it has been pre-chosen, find out what it is sooner than later), hire other people for other stuff:
https://www.allthingsdistributed.com/2007/07/the_different_c...
more on the topic:
https://news.ycombinator.com/item?id=20642423
And... think/assess very-very well - all-the-time - How much trust you have got.. and for what. YMMV. Sometimes "CTO" is only a parrotizing label for investors to flock on. Sometimes it's for real.
have fun
Contrast it with: https://www.folklore.org/MacBasic.html
and the early history of VisualBASIC (and wonder how things might have played out had the Mac had a nice development environment out the gate)
and for management interactions see: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
The Personal MBA: A World-Class Business Education in a Single Volume https://amzn.eu/d/dTAp1GF
Read about what not to do: _The Ultimate Question_ by Fred Reichheld. This book is about the notorious Net Promoter Score. (Would you recommend HN to a friend? Would you? Would you?) Reading it will give you insight into how bonehead MBAs with Cs in their marketing classes can convince leadership they've come up with a good way to measure customer satisfaction. (Net Promoter Score works fine for competitive businesses selling commodity products -- rental cars to individuals for example -- but not for many places where it is now used.)
- An Introduction to General Systems Thinking
- Becoming a Technical Leader: An Organic Problem-Solving Approach
So that you have a good answer to "when will it be ready"
- Software Estimation: Demystifying the Black Art
- Agile Estimating and Planning
People management
- The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
- High Output Management
Besides Mythical Man Month already mentioned in other comments.
As someone who went from engineering to product design, I observe that CTOs without a product vision are challenging to work with. For example, at a previous company, a CTO tried to implement the hard rule that every UI component should be in the shared UI library. But, even when I was leading the design system, that rule didn’t match how a product design process works. It caused delivery slowdowns and a degradation of the UX. I can bring up other examples, and the typical pattern is a leader looking at only one aspect or two without balance. Try to go beyond engineering and learn more about business and product design, which will help you prioritize engineering decisions. Some product-related books: Inspired by Cagan and Well-Designed by Kolko. Beyond engineering and product, as a C-level executive or director, people and hiring will be your primary concern. There are many management books, and I don’t have any particular to recommend (all of them will provide tools, but none is perfect: The Advantage and The Five Dysfunctions of a Team by Lencioni, The Phoenix Project by Gene Kim). I also enjoy taking ideas from biographical stories like Creativity Inc. by Ed Camull or Creative Selection by Ken Kocienda. Finally, a book I found funny and cynical but depicts big corps very well is “Management Stripped Bare” by Jo Owen.
One I find no trouble recommending regardless of these however is High Output Management by Andy Grove (of Intel). Not a new book, but chalk full of what I consider absolute truths when it comes to optimizing middle management (which is predominantly your role as a CTO, once the org reaches 50+ people and your direct reports all have direct reports). The fact it is still very relevant to organizational challenges today when it was written 40 years ago is a testament to this. It is a shame there are so few books that focus on this very-ignored (and honestly largest) segment of management and arguably where you get the most traction as a company.
I've yet to meet two CTOs that share the same skillset or strengths, or who work in the same org structure.
I would recommend doing some executive courses and trainings (with our other execs) to learn some common language and techniques/methodologies around team management and execution - this has been the thing which helped me most in embracing a CTO role (even one with other CTOs from separate business units reporting into). It is ironic but the best blend for a high level CTO is actually people and organizational skills moreso than pure technical aptitude. You need to be able to fact check your people and ask the right technical questions and understand the fundamentals of technical debt and TCO analysis, but honestly you'll be using your people/organizational skills and trying to hire people that know the technology better than you for the most part.
[0] https://press.stripe.com/an-elegant-puzzle [1] https://lethain.com/eng-execs-primer/
Coincidentally, a quote from Ycombinator CEO Garry Tan on their site: You’ve got to find your own window of opportunity. Game Thinking is your instruction manual.
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.
As an example, here's the chapter on estimates: https://superstruct.tech/blog/estimates
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.
https://www.amazon.com/Peopleware-Productive-Projects-Teams-...
It's a classic, and also a pretty easy read. If you're in technology and haven't read it yet, you should.
https://github.com/kuchin/awesome-cto - A curated and opinionated list of resources for Chief Technology Officers and VP R&D, with the emphasis on startups and hyper-growth companies.
Someone else beat me to the link.
From my exp CTO in small startup is marketing tool and it does not mean real "the CTO". In small org CTO is simply "do it all in no time" type of job, that includes hands on coding, infrastructure, but also hiring, overseeing and managing people. You also need to understand code lifetime and methodology of your choice, how to use it to provide good enough time estimates. And all of this will lead you to be probably replaced once organization grows.
If you don’t get to this point, the startup will die. So spending time optimizing the performance or arguing which code formatting standards to follow is just a waste of time and resources.
Sorry, not a helpful answer...
I would be equally worried if I was the director of engineering and had to work with this person. Ditto if I was a lower level engineer.
If I had to guess the poster is actually talking about engineering and confusing it with technology ... which is a whole different problem.
edit: the book was already mentioned by mattferderer [1].
https://github.com/kuchin/awesome-cto
Some hit-and-miss there but I discovered a lot of great advice.
Books and blogs have a limited anecdotal value (sometimes it is high but the effort is also high). I’ve learned more from individual HN comments and actual work experience and mistakes than any book.
Maybe it’s some reverse psychology thing. Ok I’ll do it, you evil genius…
PS CTOs aren’t always chosen, many are self-appointed as founders or co-founders (possibly in this case too).
Chosen implies you’ve been subject to external assessment, self-appointed is a different matter altogether (ie. you may be extremely aware of possible knowledge/experience gaps that you need to quickly fill).
To add my own suggestion, I think High Output Management by Andy Grove is an excellent resource (not just for CTOs)
It just seemed a shame not to mention hackernewsbooks since it is probably a good resource for the OP :)
It makes more sense though if you have sold it! Congrats on that.
CTOlunches.com, which is an in-person group that meets for lunches around the world. It also has an active mailing list, with hundreds of engineering leaders there.
The rands leadership slack (Google for it) is an invite only slack with thousands of engineering leaders across the world. Great for asynchronous conversations across a wide variety of topics; they even have an anonymous q and a channel.
https://github.com/kuchin/awesome-cto
Maybe I have few more useful links here:
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.
romance: i would suggest "Looking for Alaska" by John Green or "Pierre et Luce" by Romain Rolland
fantasy: The Way Of Kings by Brandon Sanderson or "Blackout" by Marc Elseberg
life advice ig?: "The Algebra of Happiness" by Scott Galloway
... never been a CTO xd
The students like a book called "Adventures of an IT leader". It's a fun read that students with work experience can relate to. And students without work experience can learn a lot from.
This is a great book for larger team sizes.
Often overlooked is dealing with power and politics (https://www.wittenburg.co.uk/Work/Politics.aspx)
Keeping up to date on tech also important, especially at the tech lead/architecture level (https://www.wittenburg.co.uk/Work/Mentoring.aspx).
If you’re building, I’ll echo other commenters…stop reading and go code.
For just about any advice I’d say go read Rework, in between coding sessions.
The mom test - how to discover product
The EOS (Traction and Co) - how to manage the company and give direction to the vision of the company
CTO skills needed for a 10-person company is radically different than a 10,000-person company.
Learn to do every technical job in your company.
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.
- 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.
I have the software written, and it appears to run as intended. Now, doing computer systems management, silly stuff; main problem, getting past bad documentation, e.g., was just up all night working with video adapters, device drivers, display resolution, font scaling, HDMI, display port, flickering cursors, etc. Since the documentation was so bad, I did take some notes on the more important things I learned, e.g., by the TIFO (try it and find out) Method. The results are not perfect but are good enough for now. I can delay more until the business is growing nicely (if it ever does). That is, for now concentrate on giving people "something they want" and put video issues way down on the TODO list.
But a concern: If such silly technical stuff does go well, then I could be going live on the Internet fairly soon. Then some of the issues might be:
(1) publicity and getting the first users
(2) getting advertisers
(3) billing and accounting
So, from this thread and a few hours at Google this week, I just concluded: For nearly all that stuff, nearly every business has to do it. So, there are well polished options for how to do it, and I can put it low on the TODO list for now.
For what to do if the business starts to grow, I saw some of that at FedEx and elsewhere. Right, as in this thread, focus on providing "what people want", the work, and the revenue. E.g., if I get a lot of users, then that should help getting some advertisers. Then will need billing and accounting, and, uh, there is no shortage of people who can provide such services for me -- getting the revenue is the hard part; given the revenue, it stands to be easy to work with an accounting service! Or, for a lot "I don't know how to do it, but there are plenty of people who do."
In particular, for management and in particular engineering management, I've seen, been in, and done some of it and conclude now that my business will be nicely successful before I will have to look into the theories of it. In particular, I saw several cases of guys really eager to work hard, occasionally all night, get good stuff done, with no credit from any management.
For the core technical stuff, my efforts have some of that, and it should be a business advantage, uses some of my experience and Ph.D. in applied math, I would say beats AI, and easy for me -- early on in the effort I wrote up the math in Knuth's math word processing TeX. Then used the write up when I wrote the code (Windows, IIS, .NET, ASP.NET, ADO.NET, platform invoke, etc.). So, the core technical stuff is done, not even on the TODO list! On with the rest with the balances as often in this thread.