These are my notes on An Elegant Puzzle: Systems of Engineering Management by Will Larson.

Key Insights

• Managers should support 6-8 engineers.
• Managers of mangers should support 4-6 managers.
• Tech lead is a role with limited career opportunities: too little management and too little technical.
• Teams smaller than 4 are not teams.
• On hiring, fix one team at a time, not a bit on each.
• Move work, not people.
• States of a team:
  1. Falling behind:
     • Backlog growing, low morale, hard work but little progress.
     • Solution: hire more people.
     • Tactical support:
       • Setting user expectations.
       • Quick wins (for morale).
  2. Threading water:
     • Critical work gets done but no innovation or paying technical debt.
     • Solution: reduce WIP.
     • Tactical support: from personal to team view on productivity.
  3. Repaying debt:
     • Compounding effect.
     • Solution: find time to continue.
     • Tactical support: ensure enough delivery to keep users happy.
  4. Innovating:
     • Solution: Enough slack.
     • High performing teams are sacred.
     • Tactical support: ensure work is valued.
• Key tools for leading change:
  1. Systems thinking.
  2. Metrics.
  3. Vision.
• Folks universally want to be responsible.

• The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over-designed.
• Most poor working relationships are the by-product of information gaps.
• Prioritize long-term success over short-term quality.
• Bad policy is one that does little constraint.
• Policies are hard to enforce because:
  • Reduce opportunities.
  • Are a local suboptimal.
• With the right people, any process works, and with the wrong people, no process works.
• Typical errors as a manager.
• Growth only comes from change, and that is something you can influence.

TOC

• Chapter 2 - Organizations
• Chapter 3 - Tools
• Chapter 4 - Approaches
• Chapter 5 - Culture
• Chapter 6 - Careers
• Chapter 7 - Appendix

Chapter 2 - Organizations

• Sizing teams:
  • The fundamental challenge of organizational design.
  • Managers should support 6-8 engineers:
    • Less == tech lead.
      • It is a role with limited career opportunities:
        • Too little management and too little technical.
    • More == coach.
  • Managers of mangers should support 4-6 managers:
    • Less == underutilized, tempted to create their own work.
    • More == coach.
  • On-call requires 8 engineers.
  • Teams smaller than 4 are not teams.
• Staying on the path to high-performing teams.
  • States of a team:
    1. Falling behind:
       • Backlog growing, low morale, hard work but little progress.
       • Solution: hire more people.
       • Tactical support:
         • Setting user expectations.
         • Quick wins (for morale).
    2. Threading water:
       • Critical work gets done but no innovation or paying technical debt.
       • Solution: reduce WIP.
       • Tactical support: from personal to team view on productivity.
    3. Repaying debt:
       • Compounding effect.
       • Solution: find time to continue.
       • Tactical support: ensure enough delivery to keep users happy.
    4. Innovating:
       • Solution: Enough slack.
       • High performing teams are sacred.
       • Tactical support: ensure work is valued.
  • Slow process to move between stages.
  • On hiring, fix one team at a time, not a bit on each.
  • Move work, not people.
  • Gatekeeper antipattern:
    • Having humans who perform gatekeeping activities creates very odd social dynamics, and is rarely a great use of a human’s time.
  • If you are overwhelmed with possible areas of improvements, agree with your manager on an explicit plan, and give yourself permission to do the rest poorly.
  • Plan your succession: Page 53.

Chapter 3 - Tools

• Key tools for leading change:
  1. Systems thinking.
  2. Metrics.
  3. Vision.
• Basic product management:
  1. Explore problems to solve:
     • User’s pain.
     • User’s purpose.
     • Competition.
     • User cohorts.
     • Further competitive advantages.
  2. Problem selection:
     • Consider different time frames.
     • Industry trends.
     • ROI.
  3. Solution validation:
     • Write an announcement letter.
     • Prior art.
     • User switching costs.
     • Find an early adopter.
     • It is far more reliable to get good at cheap validation than it is to get great at picking the right solution.

• Goals decouple the “what” from the “how”.
• Good goals have 4 numbers:
  1. Target.
  2. Baseline.
  3. Trend.
  4. Time frame.
  • Answer:
    1. How ambitious the goal is.
    2. When it is achieved.
  • Set constraints: investment, baselines that should not change.
• Metrics are an effective way to lead change with little or no organizational authority:
  • The most general and self-managing tool is bench marking (against other teams).
  • Nudge teams into action by pushing notifications.
  • Folks universally want to be responsible.
• The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over-designed.
• Migrations are the only mechanism to effectively manage technical debt.
• Reorgs:
  • Is it going to solve an already existing and not temporal structural problem?
  • Use a years out head count, to avoid yearly reorgs.
  • Put teams that work together (especially poorly) as close together as possible. This minimizes distance from escalation during disagreements, allowing arbiters to have sufficient context.
• Most poor working relationships are the by-product of information gaps.
• Career progression:
  1. Identify your 3-5 years goal.
  2. Identify gaps in your skills to achieve that goal.
  3. Pick a few to focus for the next 3-6 months.
  4. Agree on action plan with manager.
• Model, document, share:
  • Approach to leadership without authority.
  • Model:
    1. Baseline.
    2. Try it long enough as an experiment.
  • Document:
    • The problem solved.
    • Learning.
    • Detailed approach.
  • Share:
    • Don’t lobby for changes, just present.
• Designing centralized decision-making groups:
  • Aim to increase positive freedom, while not reducing negative freedom.
  • Decide:
    1. Influence: advisory <–> authoritarian.
    2. Interface: ticket, email, weekly review sessions.
    3. Size.
    4. Time commitment.
    5. Identity: small teams and high time commitment are required for shifting identity to this group. If you want this.
    6. Selection process.
    7. Length of term.
    8. How representative will this group be?
  • Failure modes:
    • Domineering.
    • Bottlenecked.
    • Status oriented.
    • Inert.
• Presenting to senior leadership: Page 104.
• Time management:
  • Reflect on how you spend your time.
  • Prioritize long-term success over short-term quality.
  • Stop doing things, and then alert your team and management.
• Communities of learnings:
  1. Few minutes of content, then move to discussion.
  2. Discuss in groups of 4-5.
  3. Regroup and share learnings per group.
  • Pick topics people already know about.

Chapter 4 - Approaches

• Policies:
  • To bring consistency == fairness.
  1. Define goals.
  2. Defines constraints that support those goals.
  • Bad policy is one that does little constraint.
  • Policies are hard to enforce because:
    • Reduce opportunities.
    • Are a local suboptimal.
  • Avoid exceptions:
    1. Collect escalations and exception requests.
    2. Periodically, review policy with (1) in mind.
• How to say no to more work:
  1. Explain current velocity and its constraint. Outcome, either:
     1. You get more resources.
     2. Move to prioritization vs current work.
  2. Prioritization vs current work:
     1. Document all incoming tasks.
     2. Develop guiding principles on how work is selected.
     3. Show selected list.
     4. Compare new work against principles and selected list.
• Almost every internal problem can be traced back to a missing or poor relationship:
  • Start debugging problems from the relationship angle.
• With the right people, any process works, and with the wrong people, no process works.
• When:
  • Rapid growing: execution is more important than new ideas.
  • Stabilized: ideas > execution.

• Typical errors as a manager:
  • Junior:
    • Only manage down.
    • Only manage up.
    • Never manage up.
    • Optimize locally.
    • Assume hiring never solves any problem.
    • Not spending time building relationships.
    • Define their role too narrowly
    • Forget your manager is a human being.
  • More experienced:
    • Do what worked in previous company.
    • Spend too much time building relationships.
    • Assume hiring can solve any problem.
    • Abscond rather than delegate.
    • Become disconnected from ground truth.
  • Both:
    • Mistake team size for impact.
    • Mistake title for impact.
    • Confuse authority with truth.
    • Dont trust the team enough to delegate.
    • Let other people manage your time.
    • Only see problems and not celebrate successes.
• To grow as a manager, purse growth in scope rather than # people you manage.

Chapter 5 - Culture

• To make your peers your team:
  1. Must be aware of each others work.
  2. Know at a personal level.
  3. Somebody must act as a referee.
  4. Avoid zero-sum culture.
  5. Make it explicit.

Chapter 6 - Careers

• Growth only comes from change, and that is something you can influence.
• Interview process:
  1. Be kind.
     • Budget enough time.
  2. Agree with interviews on role’s requirements.
  3. Understand the signal your interview is checking for.
  4. Come prepared.
  5. Deliberately express interest:
     • Get every interviewer to send a note saying that they enjoyed the interview (with an explanation).
  6. Feedback loops:
     • Training new interviews.
     • Candidate to interview designer.
     • Interviewers to interview designer.
• Performance management systems are the most valuable entry point to shape company’s culture, inclusion and performance.
• Moving away from generalized roles and towards specialists, creates a more brittle organization.

Chapter 7 - Appendix

• Teams and orgs have very limited appetite for new process: roll out one change at a time.
• Sprints work well if:
  • Team knows:
    • What they should be working on.
    • Can determine if the work is complete.
    • Knows how to figure out what to work on next.
  • Stakeholders:
    • Can learn what the team is working on.
    • Can learn what the team plans to work on next.
    • Know how to influence the team’s plans.
  • Middle management: focus on roadmaps.