Engineering management books

2022-04-30 in book-review

If you’re like me (first time manager in a fast growing software company) you’re likely facing a vast number of organizational issues that you never faced before and they are coming at you faster than you can learn how to deal with them.

Thankfully there are smarter, more experienced people out there that figured out a lot of topics that you can copy, claim credit and become the leader that you always dreamed out to be and your company desperately needs!

My list of books I wish I knew about before scaling Gorgias

If it’s not immediately obvious, the book selection and the order below is opinionated. I’m starting with the leadership and culture books first, then going into management fundamentals, engineering manager career orientation, hiring engineers, operational best practices, writing strategy and finally scaling teams and productivity.

First fundamentals, then tactics.

Turn The Ship Around!

My #1 recommended professional book. Manager or not, if you want to figure out what is a great leader I recommended reading it!
My personal take on the whole leader-follower dichotomy is that it's abused in our industry. Being a follower: bad! Being a leader: good!
Great leaders figured out when to follow and empower people in your team and when to lead. The art of moving between these modes is what separates noobs from experienced and effective leaders. This is how trust is built and how you encourage growth, ownership and motivation in people.
IMO the best part about this book is that's it's **not boring**! If you read enough management and self-help books you know what I'm talking about.

No Rules Rules

It's about the (in)famous Netflix culture. The core idea is that an exceptional company increases talent density and establishes a culture of freedom and responsibility.
Allow me to put it less diplomatically in steps:

First you aggressively fire anyone that is not a "top performer".
Then you pay top of the market salaries to those who are left and recruit the "best" people.
Remove redundant bureaucracy because you hired the "best" and they hate stupid rules that don't bring any value.
Make sure that they know they own their shit, they are expected to take risks and will get fired if they don't get results on time.

The book is full of anecdotes of the CEO and interviews from the various employees that make the case for the above.
My recommendation is to take the ideas here with a giant grain of salt, it's likely not something that applies to your seed-stage B2B SaaS startup where cash is in limited supply and you have commission based roles.

Why do I recommend this book then?
Because I think it helps to think about how you should treat product, engineering and design roles. Why it's worth paying the top dollar to get the best possible engineers. Why your designers should not have to jump through ridiculous hoops to get their best work done and why your product people should be empowered to take risky but calculated decisions.
I think it applies to marketing and other "scalable" roles, but that's not my place to comment.

The Manager’s Path

This is a great "operating" manual for any engineering manager. Starts with coaching and managing ICs, managing teams, teams of teams and goes all the way to answering the question of what the hell is the difference between VPE and CTO? If you're looking for orientation about various roles and growth paths in the engineering management I couldn't think of a better book. It's easy to pick up from any point in the book. You'll also find a career path/ladder section. It's a great reference that I always have on my desk.

Smart and Gets Things Done

One could argue that it's somewhat dated now, but I think it's still great if you want to follow a simple rule when hiring:

Is the candidate smart and can they get things done?

Today I would add cultural fit: it’s important because you cannot change someone’s values or personality. The point the book is making is that you should not hire academics that are smart, but never get anything finished. Nor should you hire people who work a lot, but make dubious decisions and constant mistakes.

This book forced me to answer the same two questions after every interview: Are they smart? Can they get things done?
Not sure? Not a good idea to hire.

Accelerate

Data-driven approach to best practices in engineering. Can you measure good engineering? The main point the book is trying to make is that you can avoid sacrificing quality and focusing on the right things you can increase velocity of your organization. What are those metrics?
Introducing DORA metrics - read more [here](https://www.swarmia.com/blog/dora-metrics/).

**Deployment frequency**: How often a software team pushes changes to production
**Change lead time**: The time it takes to get committed code to run in production
**Change failure rate**: The share of incidents, rollbacks, and failures out of all deployments
**Time to restore service**: The time it takes to restore service in production after an incident

Should you use these metrics and draw immediate conclusion if you team is amazing or sucks? Metrics without the context are a huge danger, but can trigger valuable investigations and gaining more understanding.
I recommend supplementing this book with [Swarmia](https://www.swarmia.com/). I have no affiliation with them. Just a fan.

Team Topologies

For later stage scaling teams and how to think about it. The core concepts of the book are [cognitive load](https://en.wikipedia.org/wiki/Cognitive_load), [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) and the "Inverse Conway Maneuver" which translates to: if you need a system with **X** components then you should have **X** teams.
From Jacob Kaplan-Moss's [blog](https://jacobian.org/2021/jul/5/book-review-team-topologies/) which goes in more detail:

The main thesis of the book is to engage in “team-first thinking”:
We consider the team to be the smallest entity of delivery within the organization. Therefore, an organization should never assign work to individuals; only to teams. In all aspects of software design, delivery, and operation, we start with the team.

It covers four common patterns for teams:

Stream-aligned teams, that are aligned to a single delivery stream, such as a product or service (what others might call a “product team” or a “feature team”).
Enabling teams, specialists in a particular domain that guide stream-aligned teams
Complicated-subsystem teams that maintain a particularly complex subsystem, such as an ML model
Platform teams that provide internal services like deployment platforms or data services

Again, you can read more [here](https://jacobian.org/2021/jul/5/book-review-team-topologies/).

An Elegant Puzzle

This one is last because I think it's better for bigger orgs. It starts with organizations, how to size teams, the types of malfunctions and how to fix them.
Then it gets into processes and various rituals that are common in scaling orgs.
Finally gets into some work principles and culture ending in hiring and career growth.
I couldn't pinpoint a single thing about why I like this book. It addresses a lot of issues that I'm having right now at Gorgias.

That’s it for now! In the future I will update the above list by adding or removing. I’ll try to keep the list to less than 10.

Word of advice:

Supplement your book reading by meeting leaders in your space, getting an executive coach, listening carefully to your team and customers and mentoring people. There are many ways to learn, books, podcasts and blogs posts is just one way. Arguably not the best way.