A New CTO’s Reading List

Here’s a crazy thought: a lot of first-time CTOs are also first-time managers.

That means it’s your first time negotiating a salary from the other side of the table. It’s your first time hiring; your first time managing; your first time promoting someone; and your first time letting someone go.

Now startups are not known for being well managed. That is in part because of the (necessary) focus on achieving product-market fit above all else. But, if we’re honest, part of it is also a lack of experience.

Most start up CTOs are really competent, generalist software engineers who built the first few iterations of the product themselves. That works great when the team is small. It works less well when you raise your first major round of funding and need to start quickly building out and managing a team.

When you’re building the plane at take-off, it’s too late to go and get some management experience. But CTO is fundamentally a management role. While this feels like a hard problem, it’s really not. The answer is simple: go read some books.

Here are three books to get you started.

[Managing Humans: Biting and Humorous Tales of a Software Engineering

Manager](https://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1484221575)

Managing Humans is probably one of the best, wholistic management books out there, and it happens to be specifically focused on engineering management. This book is also, in many ways, your one-stop shop introduction to the most important parts of managing a team of people. While it should not be the last book you read on one-on-ones, performance reviews, or team structure, it can be your first. There is just a lot of general and cross-cutting wisdom in this one book.

Most new CTOs want (and even expect) people to behave the way that computers do: tell them what you want and they go off and do it, predictably and systematically. While that is how computers work, it is not how people work. You can’t profile and program a performance issue with a person the way you can with your system’s architecture.

You also probably haven’t ever really thought about the point of performance reviews. Big hint: they’re not really about reviewing performance. I mean, that is part of it. You do have to critically think about each of your team members’ performance and give them constructive feedback. But performance reviews are really a conversation starter for each employee.

High Output Management

This book was technically written by a CEO, not a CTO. However, Andy Grove was an engineer and his first role at Intel was Director of Engineering, so we’re going to count it. Most importantly, this book will help you understand the true meaning of your role better than any other.

A struggle many start up CTOs face early on is how to measure their output. When you are first building the product, it’s easy: how many features did you ship to production and how quickly did you ship them. One of the biggest insights people share from High Output Management is: “the output of a manager is the output of the organizational units under his or her supervision or influence.”

That means that you have to stop thinking of your output in terms of the lines of code you write or the features you push to prod and instead start to think about the output of the people you manage.

[Getting Real: The Smarter, Faster, Easier Way to Build a Web

Application](https://www.amazon.com/Getting-Real-Smarter-Successful-Application/dp/0578012812)

Getting Real is a quick and short classic. You could probably read it in an afternoon, but you shouldn’t. Each chapter is only a couple of pages long, but packed with wisdom you’ll want to think through and digest.

You should read this book because it’s fundamentally about managing a team that is building a product. The distinction is important. You are not building the product, your team is. It’s a subtle difference, but missing it can lead to a lot of headaches.

For example, as an engineer, it can be tempting to build things because they’re cool or technically challenging. But that’s not how you build a wholistic and cohesive product. You need to transition from a default answer of yes for new feature ideas, to a default answer of no. Most features shouldn’t be built. Instead, you have to focus on a couple of key features that solve your customers’ critical problem.

Conclusion

Three book recommendations for start up CTOs and not a single one of them is technical. What is that about?

If you’re a CTO who is actively contributing to the product (as in pushing lines of code to production) then you’ve achieved a local maxima. You and your company are destined to be stuck there until you can learn what your role is actually about: managing people who build the product.

These three books will get you started with all three parts of that job:

• “Managing…” - High Output Management
• “… people …” - Managing Humans
• “… who build the product” - Getting Real

Best of luck.