I admit this is the second time I’m reading through this book. I first read Will’s book back in 2019 or 2020. I remember really enjoying it at that moment. Things were different then. It was a pre-covid world for one. I worked primary in the office. I worked for a much smaller company than I do now. I’ve learned so many things in the years since. So why revisit this book again? Well, because I’m at a new stage in my career and this sounds like fun. Heck, this was probably the last technical book I’ve read. This also isn’t the kind of book you read once and your problems are solved. These are skills you have to practice and situation change meaning your approach may have to change to meet the new challenges along the way.

One of the statements in the summary of the book says “There’s a saying that people don’t leave companies, they leave managers.” I believe there’s more truth to this than not, but every once in a while it isn’t the manager that is the problem. I can imagine having worked for companies such as Yahoo!, Digg, Uber, and Stripe that Will’s point of view is influenced by the sheer size of these companies. However, that doesn’t make his experience any less valid if you find yourself at a smaller shop. Managers do have a lot of power in what you work on, how you work on it, and how you’re compensated for your work.

We start off by looking at organizational structures. It’s suggested that Technical Lead Managers should have teams of around 6 people. It’s been a long time since I’ve worked with a team that large, usually it’s been half that size. When teams are that smaller it is very easy for people to fall into their niche. I for instance love working on maintenance type of task and occasionally would sprinkle in some design work. This means that when I do start working on implementation, I’m not as fast or inherently knowledgeable as I could be. On the other hand I can rip out dead code and refactor things without breaking a sweat. I can see patterns really well, but I do have a harder time knowing the pattern I’d like to use. But if I were to have worked on larger teams in the past few years, I expect this would all be different. It’s important to not shoehorn people into just what they are good at even if that means taking a longer time to deliver solutions.

I do enjoy the explanation of the different states of a team:

• Falling Behind | The Backlog is longer that it was last week | –> Add People
• Treading Water | Critical Work is getting done but debt is not | –> Reduce Work In Progress
• Repaying Debt | Benefits from debt payoff are beginning to snowball | –> Add Time
• Innovating | Debt is low, you can deliver features and maintain | –> Add Slack

“Time to complete a task approaches infinity as utilization reaches 100%.” I don’t know why, but it seems that most project managers know this to be true and don’t seem to understand what it really means. Picture an interstate highway. It’s a 6 lane super-highway which means that you should be able to shuttle a lot of traffic through it and you can. Now picture there’s a few hundred cars on a few hundred feet of this highway. It’s not a highway now. It is a parking lot. If you fill up all your teams’ time you’re going to bring productivity to a standstill. Worse than that you’re going to cause the team unnecessary stress which will only lead to worse problems. Cut back on the number of things your team is working on. You’ll see improvements in productivity and morale. Over time, you’ll actually become faster.