Learnings from “An Elegant Puzzle: Systems of Engineering Management” by Will Larson

I recently became an engineering manager, and this book had a huge impact on my decision.

What I appreciated most is that Will Larson, the author, is highly opinionated about various management topics. He clarifies a nebulous role through an actionable set of systems.

There are parts of the book that are not super relevant for me yet (like being a manager of managers), but I know I can come back to those parts if/when they become relevant.

#1 — Team Size

Will has a clear formula for what kind of manager you will likely be based on your team size.

• “Balanced” manager— team of 6–8
• “Tech lead” manager — less than 4 reports
• “Coach” manager — greater than 8 reports

With 5 reports, I am not quite in the sweet spot but I find myself closer to the “tech lead” manager role. I prefer that anyways, so I can spend more time coding and be closer to implementation.

The “coach” manager, with more than 8 reports, is at the opposite end of the spectrum. Will believes this team size is unsustainable and spreads the manager too thin.

As I progress in my career, I’ll keep in mind how team size will affect my efficacy as a manager and where I can make the greatest impact.

#2 — Teams Should Both Innovate and Maintain

I love this principle.

Will advocates for a team to own both innovation (creation of net new features) and maintenance (making sure existing systems don’t break).

I have worked at companies that have done the opposite and quickly develop two factions with opposing goals.

With my team, I advocate for extreme ownership of all features we build including maintenance.

#3 — Four States of a Team

Every manager should have this diagram embedded in their brain:

Will provides an opinionated formula for how to handle each state:

1. Falling behind

• State: Team is working hard but backlog keeps growing. Morale is low.
• Solution: hire more people.

2. Treading water

• State: Critical work is getting done, but tech debt isn’t being paid down. Morale is ok.
• Solution: Reduce concurrent or new work until the team can pay down tech debt.

3. Repaying debt

• State: Able to spend time on technical debt. Each piece of technical debt solved unlocks more time to focus on tech debt (debt-repayment snowball) and innovation. Morale is good.

4. Innovating

• State: The team has low tech debt and there is bandwidth to work on net-new features. Morale is high.

#4 — “You Only Get Value From Projects When They Finish”

This is a simple but powerful concept.

Every engineer on your team may be working hard on individual projects, but there is no value for the business until some of them are finished. Sometimes, the individuals on your team can benefit from partnering up to accelerate completion of projects.

From my experience, it is also possible to get incremental value even when a project is not “finished.” This is done by incrementally releasing your feature to users in phases. The downside is that this requires more planning.

#5 — Developer Productivity System Diagram

This is my favorite diagram in the entire book.

It provides a way to debug/optimize constraints in your teams development velocity.

For example, I noticed that the deploy rate was every 2 weeks for our mobile application team. This made it so that 2 weeks worth of “Ready Commits” would pile up before getting deployed. The sheer volume of code made it difficult for us to QA and led to bugs or further delays to deployment.

The bottleneck was our slow deploy rate. As a solution, I proposed investing time in a tool called CodePush that would allow us to have “web-like” instant deployment for some of our Javascript app features. It is now being integrated in our deployment process and should unlock increased velocity.

#6 — Become the Product Manager When You Don’t Have One

This is a critical concept for engineering managers to learn.

You will not always have a full team of designers, product managers, data analysts, etc. Hopefully, that is a temporary situation. But when one or more of these functions are missing, it is up to the engineering manager to put on the relevant hats in order to unblock and ensure the team’s success.

You must blur the lines of your role when necessary.

#7 — Strategies and Visions

The point of strategies and visions is to create alignment at scale.

This is more for managers of managers who do not have the time to meet with every team or understand every roadmap but want to make sure their approach is understood across teams.

Will outlines the simplest formula for creating a strategy or vision that I have ever read.

But first, what are they for?

“Strategies confirm you have a shared understanding of the current constraints and how to address them.”

“Visions ensure that you agree on long-term direction while preserving short-term flexibility.”

— Will Larson

The Simplest Formula

1. Strategy — write 5 Design Docs (aka RFCs), and synthesize those docs into a strategy. This allows your strategy to be rooted in examples and not too abstract.
2. Vision — Write 5 strategies, and extrapolate them into a vision. Write a prediction of what will happen 2–3 years out as these 5 strategies play out.

It’s so simply brilliant!

Strategies and visions always felt like vague concepts to me. It was unclear to me why leaders wrote them while I was an individual contributor. Probably because they were too abstract or complex for me to understand.

Will emphasizes that good strategies and vision should be boring and not to be confused with innovation_._ They are tools to create alignment, and unnecessarily complex or abstract ones will do just the opposite.

Example Strategy

While I don’t have experience writing a vision doc, I have encountered several RFCs that made it clear a strategy was needed and how we needed to write it.

I’ll break the strategy down using Will’s 3 steps for writing a strategy: diagnosis, policies, and actions.

• Diagnosis — Currently, our frontend is distributed over several codebases, and I do not know where to add a new frontend application or feature. There is also a desire to consolidate these fragmented codebases, but there is disagreement about which ones to remove. In addition, there is disagreement about where to add new frontend features. I believe part of this is because ownership is unclear for these frontend systems.
• Policies — Ownership and expertise will determine which codebase a feature will be migrated/added to. The two primary expertise categories are React developers and backend developers. The two broad categories of ownership are user-facing products vs. internal tooling/settings interfaces. React developers tend to own user-facing products, while backend developers tend to own internal tooling/settings interfaces. React developers will contribute to a single React codebase, while backend developers will contribute simpler static pages to a Ruby on Rails application.
• Actions — This is simply applying the above policies. Will says this is straightforward to outline, but making sure others follow through is the hard part. The more specific, the better:

1. Is the feature user-facing and owned by product engineering? Implement it in the React codebase.
2. Is the feature for user settings or internal tooling? Implement it in the Ruby on Rails codebase.
3. Apply the same rules above for existing features that need to be migrated from other fragmented systems.

#8 — Model, Document, and Share

This is a brilliant visualization of how to create change without (or with) authority.

Having worked as a growth engineer, a test/experiment-driven mindset is my bread and butter when building products.

What I love about this diagram is that Will applies that same experimental mindset to creating change within an organization.

The basic idea is to model the change that you want, aka run an experiment at a smaller scale, e.g. through leading by example or your team leading by example.

At my recent company, I modeled behavior that led to strong outcomes. One element of that was operating as a full-stack engineer and demonstrating increased velocity and a stronger product mindset.

I then spent time documenting what behaviors led to positive outcomes. This process involved deep reflection and reverse engineering what I was doing to create a repeatable framework.

As an engineering manager, I then spent time sharing and socializing the document I developed. In addition, my team further amplified this model by becoming full-stack, product-minded engineers.

Modeling, documenting, and sharing allowed me and my team to positively impact the organization without a top-level mandate.

#9 — Decouple Participation From Productivity

This is a brilliant reminder to relentlessly prioritize and learn to say NO as a manager.

There will be endless meetings, requests, emails, and messages that can suck up all your time.

Will’s cautionary advice here is that attendance is not inherently valuable. Being picky about where you are adding value or can gain value from meetings is critical.

Something I do every morning is trying to identify the 4 or 5 decisions I can make that will actually make a difference. This makes it easier to say no to everything else.

#10 — Internal Problems Can Be Traced Back to a Missing or Poor Relationship

The way I interpret this is that issues or conflicts are often due to missing data between people.

Finding or fixing the missing or poor relationship fixes that communication path to allow data to flow.

With repaired communication, two individuals or parts of the organization can build a more universal data set.

This universal data set allows groups to be aligned and solve problems agreeably.