Our book club is growing! We’ve added Jamie Phillips and Ryan Cox to our current group (Jameson McGhee, Dennis Stepp, and Houston Miller).
Dennis chose An Elegant Puzzle: Systems of Engineering Management by Will Larson as our next read. Here’s a snippet of the book’s description:
There’s a saying that people don’t leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to the good solutions of complex management challenges can make the difference between fulfillment and frustration for teams, and, ultimately, the success or failure of companies.
This week we discussed the introduction (chapter 1) through section 2.3.3.
Book format
- Each section of the book seems compartmentalized, perhaps because it’s from a collection of blog posts by the author. Sometimes the flow is disruptive, as one topic doesn’t seamlessly weave into the next.
- The physical book has blank pages for taking notes, which is handy given this will likely be a book you’ll refer back to as situations change.
- The references (footnotes) are QR codes, meaning you don’t have to type out long URLs.
- The book is designed to be skimmed, meaning you can read just the sections that apply to you rather than cover-to-cover.
- We found it odd that many sections — physical and Kindle edition — begin with an image, which later supports a paragraph. Why not have the image follow the paragraph?
Chapter 1: Introduction
- Houston liked the notion of tending the garden as you scale.
- Geoff commented that an executive at a previous job literally said that much of Geoff’s training would be from the “school of hard knocks.” Jamie said that learning on the fly is inevitable. There are plenty of management books which are beneficial to read, but reading alone is insufficient. After all, there’s no shortage of leadership books that get published every year.
Chapter 2.1: Sizing Teams
- We agreed that engineering teams with 6-8 people seems right.
- Each of us shared our experiences working with Technical Lead Managers (TLMs) in previous and current companies. This role involves coding and management. Geoff found it relevant that the book calls out how this role has limited career growth, as you can’t grow in both areas simultaneously.
- The author recommends an on-call team be 8 engineers. However, they need to understand what it is they’re supporting.
- If your team is too small, you have issues because a team “abstracts the complexity of the individuals.” Small teams are also fragile, meaning that a loss of a member has more of an impact.
- The book did a decent job of explaining that as a manager of managers, you’re likely to feel like you’re underutilized. Resist the temptation to meddle and micromanage.
- Avoid separating the innovators and the maintainers, as the latter are lower on the caste system that inherently forms. Let a team own both the innovation and maintenance for a given area.
- At our current job, Ryan and I almost witnessed the creation of an empty team, which the book discourages. Form the new team when you have critical mass.
Chapter 2.2: High-performing teams
- Jamie pointed out that the four states (falling behind, treading water, repaying debt, and innovating) almost line up with Tuckman’s stages of team development (forming, storming, norming, performing).
- What to do for each state…
- Falling behind: add people
- Treading water: reduce work in process
- Repaying debt: add time
- Innovating: add slack
- A team wants to climb toward the innovating stage, but entropy naturally slides the team back. You need to manage the teams intentionally, and each stage requires it’s own tact.
- Your job is to identify the transition and support the team, rather than to jump in and help them with their work.
- People are not fungible (swap one out for the other), so avoid reassigning them to different teams to drive optimality. This could work in some cases for senior devs that are used to moving in and out of different products.
- In the treading water stage, focus on team productivity rather than personal productivity.
- We discussed the use of productivity charts (e.g., burndown) for the team and for management. I think we settled on them being a tool to either help the team keep one another accountable and to build trust with management that work is getting done.
- Dennis asked how you could know whether your effort as a manager to transition a team was actually working. Geoff posed that you’d be able to tell which of the states your team is in, which seems measurable:
- Falling behind: percentage of tasks/stories completed by some deadline (would be less than 100%)
- Treading water: 100% completed, but none of those items are tech debt stories
- Repaying debt: 100% completed, more than zero items are tech debt-related
- Innovating: 100% completed, working on stories that are flagged as innovation-related
- Innovation is different than building stuff just to build stuff. It’s still a form of experimentation. Dennis said the book should have said “science fair projects” instead of “science projects.”
- These transitions take time; things do eventually come together with a good team.
- Prioritize and swarm around one problem at a time to reduce work in process. Here’s an example of making paper airplanes using single piece flow.
- We liked the phrase “peanut buttering,” meaning to spread people across teams or projects so thin that they’re not very effective.
Chapter 2.3: Against top-down global optimization
- Move the problems (tech debt, bugs) to the team instead of breaking up a team to have them focus on the problems.
- Geoff pointed out the paradox the author posed: 1) never break up a performing team, 2) never let a team stagnate. Jamie pointed out how Valve Software did this by having everyone’s desk be mobile, so they can feel free to move to different teams. (Source: Valve New Employee Handbook) Dennis said to avoid letting the team be T-shaped, otherwise they can only ever work on one thing. Keep things fluid as the work ebbs.
- You can’t run systems (or teams) at 100% capacity. CFOs often have issues with this because they equate slack as waste. You need slack to handle the inevitable unexpected work.
- Dennis added that slack time can also empower the team to go the extra mile to deliver something that delights users.
- Jamie described a situation where he had completed features stored up, yet not enabled, so that he always had work his team could deliver consistently every release. This gave him the flexibility to focus on innovation or tech debt without failing to release features every time. Geoff pointed out this is effectively drum-buffer-rope from the theory of constraints. The drum is the release cadence, the rope is the request of features from product management, and the buffer is the set of features ready for delivery.