Business Books for Technical Leaders

I get a lot of questions like, "You seem to know a lot about business for a technical CTO. How?" and "I'd like to be a CTO someday. Do you have any tips?" First and foremost, a CTO is a business-focused role. You must be able to do whatever the business requires most at any given moment, whether that's coding, technical architecture, hiring, raising money, selling, conducting a layoff, leading Product, being a stand-in COO, or otherwise. 

One of my common responses to these questions is, "Read and be curious!" But read what, exactly? Since I'm a fan of scalable communication, I'm documenting my recommended reading list here for public consumption. 

This list is current as of March 2024, and I plan on updating it ~yearly.

Top Ten Business Books (Must Read)

Ten might seem like a lot of books, but an executive should be reading 10-20 books a year, and when you multiply that by a 10-20 year career to become an executive, you'll have read hundreds of books before you land your first CTO job. 

Good Profiles of Successful Businesses and Leaders

Other Recommended Reads

  • High Output Management - A little dated and process-driven, but it has some good tactical tips on how to run a large team
  • Thinking in Systems - Most engineers are naturally good at this, but the book helps you apply this outside of engineering 
  • Amp It Up - How to operate with urgency 
Did I miss any of your favorites? Let me know in the comments!

Comments

Post a Comment

Popular posts from this blog

14 Day Challenge - Information Diet

Image
In the spirit of the 30-day challenges popularized by Matt Cutts (among others), I have spent the last 14 days on an "information diet".  This is not a new idea by any means, and in fact there was an entire  book written about the concept (and a more recent one from Cal Newport which I highly recommend).  I actually heard about it initially from Tim Ferris, and this post on the 4-Hour Life Blog.  Anyway, enough with the background - what the heck is this about?
Read more

Trust, but verify

I’ve always disliked this phrase, and it felt like a pure contradiction - you wouldn’t need to verify if you truly trust. It has come up recently in my life and work, so I decided to dig in and crystallize my thoughts. The phrase originated as a Russian proverb (doveryai, no proveryai) and is attributed to Vladimir Lenin and Joseph Stalin . Inauspicious beginnings, to say the least. Ronald Reagan then co-opted it in 1986 to refer to nuclear disarmament, and from there, it entered the American lexicon. People often consider it a leadership principle or some fundamental truth, which needs more nuance.  As a leader, one must decide how to operate in different contexts. A good initial posture is to distrust and verify often until you have built up the appropriate level of trust over a long enough period. I’ve had so many occasions in my career when I heard some variant of: The code is terrible The code we’re writing is excellent! That’s impossible That will take months We’re in a good stat
Read more

Cognitive Biases in Software Engineering

Image
Human logic, unlike that of the machines which we program and use every day, isn't perfect.  We make mistakes, we establish bad mental habits, and we have many cognitive biases that negatively impact our ability to be successful engineers.  I want to go over five of the most common biases that I see on a regular basis as a software engineer.
Read more