Book notes & reflections: An Elegant Puzzle

In this article, I share my notes and reflections from the book “An Elegant Puzzle: Systems of Engineering Management” by Will Larson. This includes an overview of the book itself and then some of my key takeaways, how they relate to my own experiences, and what I am trying to implement as a result.

This is another long one, and while I didn’t enjoy the book as much as the previous engineering management books I have read (The Art of Leadership and The Making of a Manager), I still found a lot of use in the author’s structured approaches to different problems. While there is no way I would use them step-by-step, they did trigger some reflection and ideas of my own.

Overview

An Elegant Puzzle by Will Larson focuses on the challenges of engineering management and how the author proposes you solve them. From what I can tell, the book is largely blog posts adapted into a book, broken down into the following chapters:

Unfortunately, I didn’t feel like the content has been adapted into a book format as well as The Art of Leadership had. The content felt very loosely coupled, and I struggled with the changes in tone and how much the chapters overlapped on content.

While linking off to external websites for required reading is good practice in blog posts, I expect a book to be mostly self-contained. Unfortunately, an Elegant Puzzle isn’t like this. As a result, almost 20% of the book is a list of recommended reading and QR codes linking off to articles that didn’t make the book. This meant that the book felt like it was missing content, which often turned out to be the “what” of a key concept the author was trying to convince you to use.

The systems thinking section is a good example of missing content. For something referenced throughout the book as a fundamental approach that the author recommends you apply to all aspects of your life, the book barely scratches the surface of what systems thinking actually is. Also, what the hell is a “growth plate”?

That being said, my biggest gripe is that the content often missed the “why” or left it to the end to justify sweeping statements. Not my preferred style of writing.

The top review on Goodreads says some of this best. For an alternative review and book notes, check out the notes by Gergely Orosz, who enjoyed the book more than I did.

Book notes

For this article, I’ll share my key takeaways from each chapter. Despite the content overlap, I’ve kept my notes based on chapters, as that is how I took my notes. In hindsight, writing them based on the topic would have been better, but I wouldn’t have known that going in.

Despite my complaints, I still took plenty of notes. While I disagreed with some of the content (the Author and I have very different approaches), seeing alternatives to tackling common problems with practical steps were useful.

Introduction

One of my favorite things in these leadership books is the author’s definition and introduction of what a manager/leader does and what happens when you become one.

“Some people go into management out of a desire to be of service. Others become managers in a cynical pact, exchanging excitement in their current role for the prospect of continued salary bumps and promotions. There are even folks who initially go into management because they’re entirely fed up with their own managers and are convinced that they could do better. [...] For many such people, the entry into engineering management begins with a crisis, and their training is a series of hard knocks.”

It’s a similar sentiment to The Making of a Manager: great managers are made, not born, and we often choose to become managers for different (often wrong) reasons.

Organizations

The first chapter talks about organizational structure and approaches to team design. It’s a random topic to start with, and the content often switches between the perspective of a manager, manager of managers, and CTO. There are some useful titbits, though.

Sizing teams

The author suggests that engineering managers should support six to eight engineers to have enough time to balance coaching, coordinating, and getting the best from their team. With fewer engineers, the manager becomes more of a tech lead, and with too many, they become a full-time coach.

Tech leads

Tech leads (or tech lead managers, as the author calls them) support around four engineers and spend their time focussing on design and implementation. They are still an individual contributor, another engineer on the team whose opinion has slightly more weight than the others. They don’t have time to develop the team or many opportunities to build their managerial skills. They’re too busy trying to maintain velocity, working on the product.

The role of tech leads suits some people, and sometimes, it’s all the team needs. But as the author suggests, the role comes with limited career opportunities as there is just no time to develop your management skills or the technical skills required of a staff or principal engineer. As a temporary role, it can give you a good insight into the life of an engineering manager and what is important to them, but it isn’t the most sustainable role in the long term.

Small teams are not teams

“Small teams (fewer than four members) are not teams.”

It sounds a little harsh, but in the author’s experience, it never works out. A team should “abstract the complexity individuals that compose them”. Small teams are a leaky abstraction where the team is indistinguishable from the individuals. For example, to do anything with a small team, you must know the personal schedule of each individual (e.g. on-call or vacation). Small teams are also fragile; one resignation can significantly derail them.

Coaches

Coaches support more than eight engineers and spend most of their time mentoring/coaching and acting as a safety net for the team. As a result, they are too busy to actively invest in the team or get involved with the team’s day-to-day. The author suggests this can be useful during a transition period but not long-term.

Goldilocks team sizing

The author proposes the following high-level guidance for sizing teams:

• The perfect size for a 24/7 on-call rota is eight engineers.
• Teams should consist of 6 to 8 engineers.
• Never create empty teams. Instead, grow an existing team to 8 to 10 engineers and then split it into two teams of 4 or 5 engineers.
• Never leave managers supporting more than eight engineers in the long term.

The four states of a team

The author proposes four states that a team can shift between: falling behind, treading water, repaying debt, or innovating. Your aim should be to get the team to the innovating state.

Falling behind is the worst state, where the team is unable to reduce their backlog, everyone is working hard, morale is low, and customers are unhappy. To fix this, adding more engineers is the solution. As a manager, you can help by setting realistic expectations with stakeholders and customers, prioritizing easy wins, and improving morale.

The author suggests you focus on hiring new engineers rather than reassigning them. They reason that people usually end up in useful places, and reassigning can too often become political.

Treading water is when you can complete critical work but cannot address any tech debt or start any major projects. In this state, morale may be higher, but everyone is still overworked, and customers are unhappy. To fix this, focus on completing projects one at a time without leaving things unfinished and reducing concurrent work (e.g. limit work in progress) until the team can start addressing technical debt. As a manager, you can help by shifting the team to view their performance as a whole rather than their individual performance.

Repaying debt is when you are addressing tech debt and starting to see the benefits. This is when the benefits start to build up; each debt repaid leads to even more time to repay further debt. As a manager, you need to keep stakeholders and customers involved so that your improvements are visible and viewed as positive. You need to prevent them from becoming impatient for new features and causing you to fall back a stage or two.

Innovating is when tech debt is low and sustainable. Morale is high, and most of the team’s work is on new features, making your stakeholders and customers very happy. As a manager, you need to maintain enough slack in the team’s schedule so they can focus on producing quality work rather than being forced to create technical debt. You also need to make sure that the team is working on something important to the wider organization rather than something unnecessary or low priority that can be defunded. Don’t suffer from success.

The author warns that the process of changing states is slow but recommends that you stick with it as it offers a better learning experience than jumping ship.

Consolidate your efforts

The author recommends that you should not spread your efforts too thinly. Rather than spreading yourself too thin, accept that you have limited resources and prioritize one thing at a time to see your work pay off sooner. They argue that by spreading your resources thinly and trying to keep everyone happy by doing everything at once, what really happens is that no one gets anything. The author terms this as “indecision-framed-as-fairness”.

I really liked the figure for this one, where you can see the visible payoff of concentrated investment vs. the slow returns of spread investment. I imagine there’s a balance to this, but I like the idea.

Team First

The author discusses the cost of “jelling” a few times in this chapter. This is where a team builds working relationships and its culture. After a while, the team forms its own identity. Established teams like this can produce amazing results. Take that into account during periods of change and organizational restructuring, and avoid unnecessary changes to the team that might disrupt their identity.

“The organization will never stop growing, but each team will.”

One interesting point from the organizational perspective in the “Consolidate your effort” section is that the author recommends you improve an organization team by team, using the example of recruitment. New starters will always disrupt a team, so by completing recruitment for one team at a time, you allow them to start “jelling” sooner and see returns faster.

Organizational risk

Again, the author’s thoughts on “Where to stash your organizational risk?” apply to a range of scopes: organization, team, and personal.

“What I’ve found successful is to identify a few areas to improve, ensure you’re making progress on those, and give yourself permission to do the rest poorly.

Typically, my organizational philosophy is to stabilize team by team and organization by organization, ensuring any given area is well on the path to health before moving my focus. [...] As an organizational leader, you’ll always have a portfolio of risk, and you’ll always be doing very badly at some things that are important to you. That’s not only okay, but it’s also unavoidable.”

Succession Planning

“Two or three years into a role, you may find that your personal rate of learning has trailed off. You know your team well, the industry particulars are no longer quite as intimidating, and you have solved the mystery of getting things done at your company. This can be a sign to start looking for your next role, but it’s also a great opportunity to build experience with succession planning.”

Figure out what you do, document the gaps if you’d leave, and start to fill them in. Some useful things to ask yourself:

• What do you bring to meetings? What is your role?
• Reviewing existing TODO lists, calendar invites, and email/IM chains.
• What recurring processes do you handle?
• What external relationships do you manage? Who are your partners?

Tools

This chapter is all about tools for managing change. When change impacts teams, it is up to the manager to create stability. To step in as product managers, program managers, recruiters, or salespeople to hold things together until an expert relieves us. It also has some interesting takes on creating your own career opportunities when open roles become scarce and presenting to leadership. “Tools” is maybe an unusual name for this chapter.

Product management - problem discovery

Surprisingly, this engineering management book has a few interesting sections on product management. I’m a big fan of engineers being involved with sales, customer support, and product. In my experience, a product-focused engineer can identify gaps in the market, customer improvements, and other product initiatives that a dedicated product team could only dream of.

Out of these product management sections, I found the author’s process for problem discovery the most useful:

• User’s pain: what problems do your users face? Go broad with surveys and deep dive with individual conversations.
• User purpose: what motivates their use of your system? How can you better help them achieve their goals?
• Benchmark: how do you compare to your competitors? Perform a gap analysis and see where you are weak vs. where you are strong.
• Cohorts: find the types of users in your system. There may be new kinds of users you hadn’t previously considered.
• Competitive advantages: understand your strengths and where you are better positioned to take advantage of a new opportunity.
• Compounding leverage: what things could you start building today that would compound into a major product or technical leverage? This could be tech debt or a design update for a component that would make working on a new feature easier or even possible.

Maybe it’s time to read a product management book.

Metrics and baselines

The author talks about organizational growth causing top-level planning to shift from discussing specific projects to discussing goals. As the organization grows, this happens across all leadership levels, as their accountability areas become too broad or complex for leaders to understand every project in detail. This can be empowering, as goals decouple the “what” from the “how”.

Defining goals

The author gives some decent guidance for creating goals that someone without context can understand and have a rough idea about the difficulty of the goal and whether or not it has succeeded. They recommend the following structure:

1. Set a target you want to reach
2. Create a baseline that identifies its current state
3. Find a trend that describes the current velocity
4. Set a timeframe that sets boundaries for the change.

“Example: In Q3, we will reduce [the] time to render our frontpage from 600ms (p95) to 300ms (p95). In Q2, render time increased from 500ms to 600ms.”

It can also be useful to combine investments and baselines. While you could achieve a goal by just throwing money at the problem, it probably doesn’t lead to a desirable outcome. Instead, you could create a baseline metric, for example:

• “[the] efficiency of running core batch jobs should not exceed the current price of $0.05 per GB.”
• “core batch jobs should not increase the alert load on the team operating or using the pipeline, which is currently alerting twice per week.”

You can tweak these baselines when you need to reach a compromise and rebalance them based on priorities. Infrastructure and team costs are good examples of baseline metrics.

Migrations

“[Migrations] occupy the awkward territory of reduced immediate contribution today in exchange for more capacity tomorrow. This makes migrations controversial to schedule, and, as your systems become larger, they become more expensive.”

This is a good one where you can feel the author’s experience, considering their background with platform teams.

The author proposes the following playbook for working with migrations:

• De-risk: Write a design document and share it with teams with the hardest migration path and the teams with the bizarre edge cases. Iterate on this document until you have a solid plan and understand how it fits with your 6-12 month roadmaps. The author even recommends embedding yourself with the teams who will have the most challenges and working with them on the migration. Starting with the hardest migrations helps you avoid creating a false sense of security.
• Enable: Once you’ve validated your solution, the author recommends slowing down and building tooling that will automatically migrate the common use case (the 90% of use cases) and creating self-service tooling and documentation to enable teams to handle the final 10%. These migration tools should be incremental and reversible. Treat these tools and your migration documentation as products and build upon them over time. This means rather than simply creating tickets for each team and setting an organizational goal, you are instead enabling teams and reducing the cost of the migration to the wider organization.
• Finish: Once you’re ready, deprecate the old approach and ensure that all new code uses the new one. Stop the bleeding. This allows you to progress by default rather than fight an uphill battle. This is where you start creating tickets and tracking migration status. Ensure managers understand the context for the migration, as they are the ones who will prioritize the work. To get to 100% completion, you & your team may need to get involved to help push the final edge cases over the line.

Degree of alignment

Defining the degree of alignment with the team or manager can be useful no matter how you manage a project as a manager. By being explicit, you can remove any ambiguity.

The author defines some useful levels:

• I’ll do it: you will be personally involved and responsible for completing it. Use this level sparingly.
• Preview: you will get involved early and often. This is where you think there’ll be some disagreement and want to prevent the team from re-doing work.
• Review: you will review the work before it gets published. This is where you’re pretty aligned with the team.
• Notes: you’d like to follow the project but have much to add. This is useful for wide-reaching initiatives where you are aligned with the team and want to be able to represent their work correctly.
• No surprises: you have a mental model of the work and want your understanding to be up-to-date. When asked about the project, you want to be able to answer correctly.
• Let me know: you’re aligned with the team, and they have done this before and done it well. You just want them to let you know if something comes up that you can help with. Otherwise, you’re going to stay out of their way and not expect to talk about it much.

Career narratives: artificial competition

The author talks about how career ladders are great and being on the ladder creates more opportunities than being off the ladder; however, the author notes that they funnel people toward an increasingly small pool of opportunities.

A good approach early in your career is to expand your responsibilities and start operating at the role above yours; however, for scarce roles such as head of engineering, that won’t be possible for every engineering manager within the organization.

Instead, the author suggests that you identify the gaps in your skillset that would keep you from operating in that role and then use your current role to help fill those gaps. To find opportunities to practice this role within your current role. Your current role doesn’t need to hold you back.

You could even take this to the next level by changing your 1-5 year career plan to a list of 1-5 year goals for skill development. Write this up, prioritize it, pick some to focus on in the short term, and then share it with your manager in your next one-to-one. Use your manager as a partner to help you create goals that matter to the business and help you achieve your goals while staying aligned with your company’s priorities.

“Chasing the next promotion is at best a marker on a mass-produced treasure map, with every shovel and metal detector re-covering the same patch. Don’t go there. Go somewhere that’s disproportionately valuable to you because of who you are and what you want.”

Model, document, and share

“Model, document, and share” is the author’s approach to changing an organization process when you don’t have the authority to do so outright by convincing others with proof.

• Model: start by creating a baseline by monitoring team health or throughput. Quietly make your changes and keep iterating until you’re confident it works. Have the courage to keep at it, all the while monitoring your metrics.
• Document: once you have your approach, document the problem you set out to solve, the learning process you went through, and detail how other teams might use the same approach.
• Share: share the documented approach and your experience with the process with others in a short email. You’re not asking people to adopt the approach, only presenting your approach and experience. Surprisingly, in the author’s experience, this often leads to more adoption than a top-down mandate.

The author then compares the benefits of top-down mandates vs. their “model, document, and share” approach.

In summary, top-down mandates are useful when you need to adopt an approach quickly. They are helpful when:

• Teams have the bandwidth
• The organization has the resources to coordinate the rollout
• You want to centralize decision making
• Consistency is important, and you need all teams to approach the problem in the same way
• It’s important to make the change quickly,

On the other hand, “model, document, and share” is better when you have the time to iterate and find the best possible approach. They are helpful when:

• Some teams don’t have the bandwidth
• The organization may not have the resources to coordinate the rollout
• You want to decentralize decision making
• Teams can adopt the approach if it works for them
• It’s okay to make the change gradually.

The author warns that this approach isn’t foolproof and is not always appropriate, especially if you use it to circumvent organizational authority.

Presenting to senior leadership

The author calls presenting to senior leadership a “dark art” that takes time to master and often relies on hard-to-replicate advantages (charisma, subject matter expertise, and years of experience). It’s certainly something I’ve struggled with in the past, despite a past in training and speaking at conferences.

The author provides some tips:

• Communication is company specific: watch how others present to leadership and study their approach.
• Start with the conclusion: especially in written communication, to prevent skim reading and incorrect assumptions. Start with what’s important rather than slowly building toward it.
• Frame why the topic matters: start with why your work matters to the company. It’s obvious to you, who is familiar with the work, but less so to others.
• Everyone loves a narrative: create a narrative of where things are, how you got there, and where you’re going now.
• Prepare for detours: be prepared to lead the presentation yourself while also being ready for unexpected questions.
• Answer directly: senior leaders are used to indirectly managing while also deep diving into problems to help debug them. As a result, they are often keenly aware of evasive answers. Instead of hiding problems, take this opportunity to explain your plans to address them.
• Deep dive into the data: you should know your data well enough that you can use it to answer any unexpected questions.
• Discuss the details: some executives test presenters by diving into the details, trying to find an area the presenter is uncomfortable speaking on. You should be familiar with the details but also able to reframe the conversation using either data or principles.

  This reminds me of an interesting Joel Spolsky story about presenting to Bill Gates.

• Prepare a lot; practice a little: these presentations tend to detour quickly, so prepare by gaining a deep knowledge of the data and details rather than preparing the perfect presentation.
• Make a clear ask: start the meeting by explicitly stating your goal.

The author suggests the following format, tailoring it to your company-specific communication style:

• Tie the topic to business value: one or two sentences on why people should care.
• Establish a historical narrative: two to four sentences to help everyone understand how things are going, how we got there, and what the next steps are.
• State the explicit ask: one or two sentences on what you want from the audience.
• Data-driven diagnosis: a few paragraphs on the current constraints and context presented through data. The data should be raw enough for people to follow your analysis (just the analysis with no data can seem evasive or like you’re hiding something).
• Decision-making principles: explain the principles you’re applying against the diagnosis and the mental model you’ve used to make a decision.

  Skip the bullshit here, and just be honest about how you’ve come to your decision. There’s no need to try and look smart with systems thinking.

• What’s next and when it’ll be done: apply your principles to the diagnosis to generate the next steps. Make it clear why you have chosen certain actions and that they make sense compared to what you have presented.
• Return to the explicit ask: return to your ask and ensure you get the information and guidance you need.

Time management

Oh, man. Something we all struggle with. Unless you’re a LinkedIn influencer, maybe.

Time management is the enduring meta-problem of leadership. For most other aspects of leadership, you can look to more experienced line managers and be reassured that things will get better, but in this dimension, it appears that the most tenured folks are the ones most underwater.

The author details some of the most impactful changes they made to how they manage time:

• Quarterly time retrospective: once a quarter, spend some time categorizing your calendar to understand how you have used your time. This helps you understand where your time is being spent and also allows you to reflect on the projects you have completed. I’ve previously used my weekly brag sheet as a tool to do this (when I remember to do it).
• Prioritize long-term success over short-term quality: prioritize long-term success, even if it is personally unrewarding in the short term.

  This leans into the approach of concentrated investment vs. spread investment. Whole-assing one thing.

• Finish small, leveraged things: each thing you finish will create more bandwidth for future work. It’s rewarding to finish things.
• Stop doing things: if you’re swamped, identify critical work you won’t do, flag it as a risk, and alert your team and management chain.

  See my previous analogy to spinning many plates and giving yourself permission to let some fall – but it’s a good point, be honest and manage expectations.

• Size backward, not forward: specify the number of hours you can dedicate to an activity, not how many hours the activity needs (think of an ever-growing number of skip-level 1-to-1s). Identifying what is possible allows you to stay in control of your time and scale with the growing organization.
• Trust the system you build: Handling exceptions to processes can consume all of your energy. Delegate or solve the problem with the process.
• Decouple participation from productivity: attending meetings can make you feel powerful, but you need to be realistic about how much you’re accomplishing by attending. Don’t fall into the trap of thinking that attendance alone is valuable.
• Hire until you are slightly ahead of growth: hire just about more people than you need. Hire before you are overwhelmed and before an absence becomes disruptive.
• Calendar blocking: this is not especially effective, but it’s quick and easy to set up.
• Get administrative support: once you hit a certain level of complexity, this becomes necessary - have someone else handle the dozens of little interruptions.

Approaches

This chapter is mostly about approaches for managing teams and projects. It goes into a bit of philosophy, how to work with your manager, and becoming a manager of managers. I’m not sure how these topics differentiate from the “Tools” chapter (maybe it should be one big “Approaches” chapter?), but focussing too hard on the chapter names of this book won’t lead you to a happy place.

Saying “no”

“[...] I came to view management as, at its core, a moral profession. We have the opportunity to create an environment for those around us to be their best, in fair surroundings. For me, that’s both an opportunity and an obligation for managers[...]”

Saying no requires you to convincingly explain your team’s constraints and why the proposed request is either unattainable or undesirable.

Disagreements often come down to velocity (“why is this taking so long when it should take a couple of hours?”) and prioritization (“why can’t you work on this other, more important project?”).

Velocity

When folks want you to commit to more work than you believe you can deliver, your goal is to provide a compelling explanation of how your team finishes work. Finishes is particularly important, as opposed to does, because partial work has no value [...]”

Show them your process, the steps each piece of work must go through in order to be completed, and make sure you document these steps. This will enable you to narrow down your current constraints and ensure suggestions for improvement will actually help.

Explain how you decide the number of story points for each sprint and how that number is trending over time.

Once you convince them your velocity is accurate and cannot be improved or changed to fit in their work, you can discuss priorities.

Prioritization

Document all your incoming tasks and how you choose what you work on. Make sure you show clear value in current work versus future work - investment today that will pay off in the future but will limit value in the short term. Specify quotas for both immediate and long-term work.

If priorities need to shift, you can try to limit churn by waiting for the next planning session rather than making changes immediately.

You can avoid this by methodically framing their ask and your pushback using your existing velocity and prioritization decisions. I’ve found having a delivery manager and product team on hand extremely useful in these situations.

Philosophy of management

I’m sharing this one purely for the quote. It’s another perspective on the role of leadership and management, and I liked the sentiment.

“I believe that management, at its core, is an ethical profession. To see ourselves, we don’t look at the mirror, but rather at how we treat a member of the team who is not succeeding. Not at the mirror, but at our compensation policy. Not at the mirror, but how we pitch the roles to candidates. Whom we promote. How we assign raises. Provide growth opportunities. PTO requests. Working hours.

We have such a huge impact on the people we work with - and especially the people who work “for” us - and taking responsibility for that impact is fundamental to good management.

This doesn’t always mean being your team’s best friend. Sometimes it means asking them to make personal sacrifices, letting go of a popular member of the team, or canceling a project the team is excited about. It’s remembering that you leave a broad wake, and that your actions have a profound effect on those around you.”

Partnering with your manager

The author suggests some good ways of working effectively with your own manager. To partner effectively, your manager should know:

• What problems are you trying to solve & how are you trying to solve them
• That you’re making progress (and not stuck)
• What do you prefer to work on (so that they can give you work properly)
• How busy you are (so they know if they can send more things your way)
• What are your professional goals and growth areas, and where are you between bored & challenged
• How you believe you are being measured.

Likewise, you need to know how you can help your manager and ensure you are working towards similar goals. Some good things to know about your manager:

• What are their current priorities?
• How stressed/busy are they?
• Is there anything you can do to help?
• What is their manager’s priority for them?

Finding managerial scope

The author defines three types of engineering management roles:

1. Manager - you manage a team directly (e.g. Team Lead or Engineering Manager)
2. Director - you manage a team of managers (e.g. Senior Engineering Manager, Head of Engineering)
3. Vice President (VP) - you manage an organization (CTO)

The author warns that when you’re early in your career, it can be easy to see progress as increasing the number of people you manage, as that can be easier to focus on over titles, which are easy to create and can often not mean anything at all (see my favorite LinkedIn find: the Associate Software Engineer (VP)).

Instead, the author suggests that to grow, you should pursue scope, taking responsibility for leading increasingly important and complex parts of the organization and company. After all, there is typically less competition for more work. You can always find opportunities to increase your scope and opportunities for learning, even if the organization has no room for more directors or VPs.

Project-managing an initiative that allows you to work with 50 engineering managers is a far better learning opportunity than managing an organization of 50, and it often builds the same skills. It is also experience that will set you apart from the masses with inflated job titles. That experience of managing managers is better than being the Head of Engineering with a team of 3 engineers or the CEO of none.

You can also use this approach to change how you hire engineering managers. Rather than making the usual grand promises of a bigger team once the organization grows, provide meaningful promises of growing scope and learning through broad, complex, and highly visible projects.

Other notes

• Your company, your team, yourself: the author recommends framing decisions using the following order of prioritization: doing the right thing for the company, the right thing for your team, and only then doing the right thing for yourself.
• Think for yourself: learn from your peers but be honest with yourself about what is truly a best practice and what is just you and others being on autopilot. “The worst theory of management is to not have one at all, but the second worst is one that doesn’t change”. Question the status quo.
• Mining for direction: discover work and direction by asking the team and colleagues what their previous organizations did well. Get them to open up about ideas they have been toying with but have not yet proposed. Work with them to make it happen.
• “[...] transitioning to managing managers: it’s an unsettling period when you lose access to what used to make you happy - partnering directly with a team - and haven’t found new sources of self-worth in your work.”

Culture

This chapter mainly focuses on organizational culture, but most of the advice applies to all levels of management. It contains more approaches than the approaches chapter and yet more career narrative advice. There’s so much overlap in this book 😭.

Opportunity

There are workplaces where everyone around you is delightful, the customers are friendly, and you feel respected, but you still return home each night dissatisfied.

The author discusses how to create opportunities for your direct reports in order to stop them from feeling like this:

• Work to ensure that people go home feeling fulfilled by challenge and growth.
• Ensure that people have role models – someone senior to look up to and learn from or someone similar to them.
• Consider time at level to understand how long people have waited between promotions. How does it compare across teams? Is it influenced by the initial level/compensation at the time of hire?

Select project leads (growing the team)

It isn’t very fun when the same people get the most important projects to work on. It is frustrating for others in the team and limits the team’s throughput as the chosen few become a blocker. Having a wide range of capable individuals is a much better idea and de-risks the absence of one of the chosen few.

The author suggests the following process for structuring projects for delegation. While this process suggests the project is being advertised at an organization-wide level, I think there are some interesting parts you can pick out for team-level or area-level projects:

1. Define the project’s scope and goals. Identify time commitment, requirements (if there are none, say so), and selection criteria (how you will select the project leader if multiple steps forward).
2. Announce and ask for applicants via email, at an all-hands, on Slack, etc. Allow people to apply in private (some are uncomfortable in public), don’t allow applicants to know who else applied (some will disqualify themselves if they see someone senior applied), and give at least three working days for applications (they may need to get permission from their manager first).
3. Nudge good candidates who may otherwise not apply to get new people involved with the process.
4. Select a lead based on your criteria. Try to evaluate each candidate and write a paragraph or two about each one. Privately check with the chosen project lead that they can still commit.
5. Sponsor the lead by getting someone who completed a similar project to be an advisor. (sponsor). They will be accountable for coaching the project lead to successful completion. This is a good learning opportunity for the sponsor. They may be used to doing things themselves but not to teaching others how to lead large, ambiguous projects.
6. Notify applicants who weren’t selected, providing feedback on why you didn’t select them. Sometimes it’s because they’ve done something great already, and you need to give someone else a chance to learn (tell them this!).
7. Kick off the project by notifying the original audience who the leader is, who the sponsor is, and their plan for running the project.
8. Record the project, who was selected, the sponsor, and a project brief.

Make your peers your first team

Managers often feel membership with the team they manage, but there’s still an element of distance, especially when you have to exercise your authority on those unfortunate occasions. Membership with your peers can also be uncomfortable, as you may not know much about what they do or even find yourself competing against them for resources or promotion opportunities, no matter how high-growth the org is.

This can lead to teams whose camaraderie is at best a qualified nonaggression pact.

Collaboration suffers, and while we pride ourselves on building healthy, functional teams, we neglect to do the same with our peers or wider leadership team. The author recalls working with teams that looked out for one another and believed they’d all come out better together. Where managers were willing to disappoint the teams they managed in order to help their peers succeed. This team balanced outcomes from a broad perspective that included their peers and not just the teams they owned. They have shifted their “first team” from the engineers they support to their leadership peers:

The author proposes the following ingredients for such a team:

• Awareness of each other’s work: you cannot help if you don’t know what they do. This could involve sharing weekly progress and creating opportunities for deep dives into each other’s work.
• Evolution from character to person: “When we don’t know someone well, we tend to project intentions onto them, casting them as a character in a play they themselves are unaware exists”. If you know them personally, you’re less likely to fall into this trap. Ensure your leadership team socializes and has opportunities to turn strangers into people. You are a team, not competitors.

  I have been super guilty of this one.

• Refereeing defection: Hold team members accountable for their behavior. If someone acts in their self-interest and actively works against the team, others will start doing the same. Consider a highly respected senior leader to act as a referee and hold people accountable.
• Avoiding zero-sum culture: where success depends on gaining scarce resources such as headcount. Focus on a positive culture of support, development, and recognizing impact.
• Making it explicit: it doesn’t happen organically.

Treating your peers as your first team allows you to start practicing your manager’s job. As you understand and work toward their priorities, your own priorities will become the same as your (and their) managers. It will also allow you to get useful feedback from your manager as you will both be thinking about the same problems since you now share goals.

You can also get feedback from your peers when they understand your work and are thinking about it in a similar way to you (e.g. how they might approach something differently).

Consider the team you have for senior positions

Some observations from the author about recruiting manager of manager positions:

• many people can’t find upward mobility in their current role and are looking for a manager of manager opportunity
• most people managing managers are happy in their existing role
• people interested in the role outnumber the available roles
• you need to consider internal candidates.

This brings us to how to evaluate internal candidates:

• Partnership: have they been effective partners to their peers and the team they manage?
• Execution: do they support the team in operational excellence?
• Vision: can they present a vision of the future state of their team and its scope?
• Strategy: can they identify ways to turn their vision into reality?
• Spoken and written communication: can they communicate complex topics using both written and verbal communication? Can they do it while being engaging? Can they adapt it to their audience?
• Stakeholder management: do they make others feel heard? Do they make stakeholders feel confident that their concerns will be addressed?

Kill your heroes, stop doing it harder

A “work harder” approach creates hero programmers whose ways of working make it difficult for non-heroes to contribute meaningfully. Heroes eventually burn out, leaving you in a disastrous position (inevitable disaster).

I recommend giving this one a read: Kill Your Heroes, Stop Doing it Harder.

The author tells you to “kill the hero programmer”. Their presence limits the team’s effectiveness in exchange for short-term productivity. Save the hero programmer before they burn out, but remember, their creation suggests a larger problem.

Working “hard” for a few weeks or months may feel effective, but it’s near impossible to quickly undo issues created over months of poor execution and implementation or management choices. Projects fail slowly. Fixing them is slow too.

One option is to step back and let the project fail. If band-aids can’t save it, it will likely consume you. The author suggests you conserve your energy and avoid creating rifts as it collapses. Projects fail all the time, usually due to someone failing to acknowledge their mistakes and letting things get worse. Acknowledge errors quickly and cut your losses before burning yourself out or going into hero mode.

Other notes

• Speed up your rate of learning by joining a rapidly expanding org or by making your peers your first team.
• Follow the standard process every time but change exactly one thing for each new project.

Careers

This is the chapter that is officially about careers, but let’s try not to dwell on the overlap anymore.

I really liked how the author pointed out how much of your career comes down to dumb luck; however, managers have the power to reduce the role of luck in the careers of others. Managers must therefore hold themselves accountable for creating fair interviews, promotion cycles, and growth opportunities.

Roles over rocket ships, and why hyper growth is a weak indicator of personal growth

For some people, there is stigma around working at a single company for too long, where you somehow become too specialized to be hired elsewhere, or your skills become outdated.

There’s also stigma around working in one type of company for too long; for example, working at a big company for too long makes you unsuitable to work at a small one.

And then there’s the stigma around short tenure, with some employers seeing it as a red flag if you have worked at multiple places for under one year. Some people even get upset if you have a career of only short one to two-year stints.

The author suggests that these stigmas are reinforced by age bias, and in reality, few companies maintain excellence over time to warrant a long tenure. The author themselves had a career that changed jobs every two years, which they now admit wasn’t the best career plan; after all, working at a company isn’t a single experience you can complete within two years.

During your time at an organization, you’ll see stable periods and periods of rapid change. There is experience to be gained from both.

A different career narrative

The author recommends reviewing the last 12 months in your current role. Each time there was a change that impacted how you work, flag that as a transition. For example, a manager change, a re-org, or a shift in priorities. What skills did you rely on to get through that transition? What skills did it allow you to develop?

Then think about the periods after those transitions. How did values and expectations change? Did fixing operational toil become critical work? What skills did you depend on the most, and which fell out of use?

This tells a much better story than “just another year at the company”.

Opportunities for growth

Transitions require you to build completely new skills, while stable periods allow you to build upon existing skills. While the organization itself does affect opportunity, what matters most is the particular team you join.

“If you’re offered a seat on a rocket ship, don’t ask what seat! Just get on.” -Sheryl Sandberg.

The author challenges this. Not all startups are fast-paced rockets ships. Not all teams at large organizations are slow-moving. Even hyper-growth organizations have teams that are sheltered from change (e.g. too far away from the organization’s focus or too stuck in BAU to get attention or opportunity).

Track your transitions and growth to avoid lingering in any area to the point you are not developing new skills or mastering existing ones.

“Don’t treat growth as a foregone conclusion. Growth only comes from change, and that is something you can influence.”

Interview guidelines

The author details some interview guidelines that should be obvious, but unfortunately, in my experience, are not to many people:

1. Be kind to the candidate
2. Ensure all interviewers agree on the role’s requirements
3. Understand the signals the interview is searching for and how to search for it
4. Come prepared
5. Deliberately express interest in the candidates
6. Create feedback loops for interviewers and the loops designer
7. Instrument and optimize as you would any conversion funnel.

Always allow the candidate time to ask questions; do not run to the next interview or meeting.

If you’re running lots of interviews, prevent interviewer burnout by factoring in rest time. Otherwise, interviewers can become jaded and struggle to create space for the candidate, often resulting in them turning away good candidates.

Before interviewing, ensure everyone agrees on the role you are interviewing for. Roles such as engineering managers, product managers, and architects/principal engineers often vary between companies and particularly suffer from interviewers being misaligned or looking for very different things.

The author reinforces a couple of interesting ways of getting the best from candidates that I have enjoyed in the past:

• Ask for a prepared presentation on a topic (around 30 mins) rather than spur of a moment architecture question.
• Pair program to debug or extend an existing codebase, mimicking the expected day-to-day role rather than whiteboarding an abstract algorithmic question that bears little resemblance to reality.

Sourcing

The author defines three major sources of candidates when hiring: referrals, inbound (via jobs page), or sourced (candidates you’ve searched out).

Referrals come from a tiny pool of candidates when compared to the total available across the industry.

It’s harder to find referrals early in your career, especially if you work at a small company. This can be a benefit of working at a big company early in your career: name recognition on your CV and a kick-started personal network.

However, referrals can also hinder diversity. After all, your small talent pool is often filled with people like you.

Beyond personal networks, the author recommends cold sourcing on LinkedIn. This can be unsettling at first. You’ll likely be worried about the candidate getting annoyed with you or wondering if you’re wasting their time. These are valid questions, but the author thinks a concise, thoughtful invitation is an opportunity, not an infringement, especially on LinkedIn (a career-networking site).

Most people will ignore you; others will politely decline. Some will respond, others will ignore you for six months and then say they’re now on the job market. The author has never had anyone respond unkindly.

Recruitment beyond contract signing

The author also recommends extending your hiring process to also cover onboarding, impact, promotion, and retention.

How long does it take for someone to be promoted after being hired? This is useful for understanding if employees can access opportunities within your org.

Are new hires staying at the organization? This is a laggy indicator but important to track.

This helps you reframe hiring from a transaction to your organization’s “lifeblood”. While these stats are sensitive, it is important that someone tracks them.

Career ladders

The author has found that there is an overhead to each career ladder you write and maintain, but there is also a downside in trying to group different roles & tracks with a shared career ladder.

Any ladder with more than ten people on it should be fleshed out. The author recommends creating a lightweight ladder before you hire the first person into a new role.

Template and establish themes across ladders.

The author calls out companies that use rating systems such as the nine-block performance vs. trajectory grid.

“They simply create the impression of rigor while remaining equally challenging to implement in a consistent, fair way.”

Preach!

More important than ratings are self-reviews (compare against the career level or create a brag document), peer reviews (to recognize mentorship and leadership that might otherwise be missed, to identify problems you might not be aware of), upwards reviews (for managers to get perspective from their team), and manager reviews.

Calibrations

Calibration sessions are when management gets together with HR to discuss the performance designation they’ve given their team. You’ve assigned designations in isolation using whatever framework HR has given you, and now you’re being asked to normalize it by comparing each person. You may even have a quota of how many people can get certain designations. Let the horse trading begin.

“Done poorly, they become bastions of bias and fierce politicization, but they’re pretty hard to do well even when everyone is well-meaning.”

My thoughts exactly.

The author’s advice for good calibration sessions:

1. Adopt a shared quest for consistency. Frame calibration as “a community of coworkers working together toward the correct designations”. Avoid letting people focus on the designations they enter with.
2. Read, don’t present. Don’t allow managers to pitch to the room; instead, have everyone read the manager’s review. While this still relies on the manager’s communication skills, it reduces the pressure for them to perform in order to get their team the designations they think their team deserves.
3. Compare against the ladder - not others. Comparing people against each other often leads to false equivalencies without adding much clarity.
4. Study the distribution, don’t enforce it. Stack ranking (fitting designations to a fixed curve) is a bad solution. It only leads to horse trading. Instead, consider if the organization has outgrown the designation. Look at designations in other organizations and discuss how you are deviating.

Feedback for weak performance should be delivered immediately. Waiting for a performance review “is typically a sign of managerial avoidance”. However, they do ensure that performance is being addressed.

Career levels, designation momentum, level splits, etc.

Designation momentum is the natural tendency of a performance process to consistently produce the same evaluations for the same people despite changes in performance. This is great if you are on the receiving end of good designations; however, it can demotivate high performers who want feedback on how to improve. Those receiving poor designations find it challenging to understand if the bad reviews are a lagging indicator of a previous issue or if they continue to perform poorly.

Many employees rely upon their manager for a step-by-step path to high performance. But if designation momentum is not working in your favor, you need to be an active participant in your success. The author recommends proposing a set of clear goals to your manager. Work with them to ensure they are ambitious enough to impress at calibration.

• Tit-for-tat: calibration systems without a strong process or fairness can degrade into tit-for-tat trading. Collusion is uncommon; however, people will be silent rather than raise concerns.
• Level expansion: As an organization ages, it will add levels to support career progression. If this is a frequent occurrence, then it is a sign that progression, compensation, or recognition is too tightly-coupled to your level system.
• Level drift: level expansion can cause new levels to create downward pressure on existing levels. However, it’s uncommon for companies to adjust compensation in response to level drift. Therefore, the organization should manage this so that levels are expanded consistently.
• Opening the gate: level expansion combined with level drift can lead to a group crossing level boundaries together. As a manager, you need to coordinate with your peers and ensure you open the gate together in a consistent way, making sure that the cohort stays together and no one gets missed.
• Career level: eventually, a career level will present itself, where most people will not be expected to progress beyond that level. I’ve seen this called a terminal level in the past. This leads to level clustering, where most people are at the career level rather than a distribution centering at the mid-level.
• Time at level limits: employees who have not reached the career level (terminal level) are expected to progress towards it at a consistent rate. This is typically used to ensure performance management is taking place.
• Level split: to create new rules and upward mobility, some organizations split a level in two (SB: CB engineer L2 and L3, senior L4 and L5). This extends the runway for most people but can be seen as a way of preventing people from reaching ‘post-career’ levels (levels beyond the career level).
• Crisis designations (for retention-driven designations): special temporary roles created to address someone’s elevated status. Often, these temporary levels become permanent, but it can be a useful tool.

Another approach is to create specialized roles with new career ladders (e.g. SRES or technical product managers).

Appendix

Okay, the final chapter and one last “wtf”. I have no idea what this chapter is meant to be. It goes into organizational structure again (a throwback to the first chapter) and then goes into a list of recommended books and papers. I get chapters aren’t a big deal, but they seem like an afterthought and make it obvious this is not a book but a loosely coupled collection of blog posts.

That being said, this chapter has some good guidance about management concerns as you rise through an organization.

Tools for operating a growing organization

One tension in management is staying hands-off enough to let people innovate yet staying close enough to keep the work aligned with your organization’s “value structures”. Let’s look at each role and what they care about.

Line management

Once you have three or more engineers, the author recommends that you adopt a sprint process and use the following criteria to evaluate if a team’s sprint process is working well:

1. The team knows what they should be working on
2. The team knows why their work is valuable
3. The team can determine if their work is complete
4. The team knows how to figure out what to work on next
5. Stakeholders can learn what the team is working on
6. Stakeholders can learn what the team plans to work on next
7. Stakeholders know how to influence the team’s plans.

Your backlog is important. “It’s the context-rich interface that you’ll use to negotiate changes in direction and priority with your stakeholders. It’s always more interesting to discuss which of the two things we should do next, rather than whether something is worth doing.”

As the team gets bigger and stakeholders increase, you’ll want to create a roadmap describing high-level plans for the next 3 to 12 months. Keep it short to allow teams to coordinate.

The backlog is for your team. The roadmap is for your stakeholders.

Most teams will monitor operational metrics focusing on day-to-day user and system behavior. These metrics allow the team to detect outages, regressions, and other such interruptions.

Middle management

Once you’re responsible for 2-5 line managers, your attention shifts away from day-to-day execution, allowing your line managers to have an impact and for you to be free to make an impact too.

As a manager of managers, you are more concerned with roadmaps than backlogs. You move from receiving asks from stakeholders to deeply understanding the motivation behind the asks, and you invest effort in learning what others are working on in order to evaluate if the team’s work is valuable.

The author recommends holding a weekly staff meeting with your managers (stand-ups) for short updates from each manager and discussing shared topics. These can also be used as a learning forum to discuss effective sprints, career development, etc.

Consider creating a vision document: a concise statement of the team’s goals and the strategy for accomplishing those goals. Formally defining this can prevent misalignment. The author warns that some teams will struggle to write a vision document as it forces them to recognize and reconcile areas of distributed and unclear ownership.

Strategies are ground documents that explain the trade-offs and actions that will be taken to address a specific challenge. Visions are aspirational documents that enable individuals who don’t work closely together to make decisions that fit together cleanly.

Run skip-level one-to-ones to create open channels for feedback about your managers and teams. These meetings should be used as a backstop. You shouldn’t be learning new negatives from these meetings; if you do, it is a sign something is up.

Managing an organization

At this level, you are now managing managers of managers. Your staff meetings offer less value (hard to receive updates – too many loud managers), and they rely upon middle managers who themselves do not have all the context.

The author suggests that every team should have a set of clear directional metrics. These should cover long-term goals and operational baselines to show teams are functioning well. Staff meetings can therefore avoid schmoozing and give you a clear indicator of projects/teams that need help or require further deep dives.

Team snippets can also be useful, every sprint or two, with snapshots on what they’re doing, why they’re doing it, and what they’re doing next.

The book of required reading

The remainder of the book (49 pages – around one-fifth of the content) is a list of recommended books & papers that the author found useful and QR codes linking to more books and articles. Unfortunately, these are often required reading. Without it, there is missing content in this book.

Closing thoughts

There are some real gems in this book, but it was definitely a chore to get through.

The strange layout and lack of a coherent structure or story prevents me from giving the book a 4/5. I often found myself writing more notes about the author’s writing style and lack of evidence or self-awareness than the book’s content.

This is the first time I wished I had broken down my notes into subjects or themes rather than using the chapters and section titles. This book would really have benefited from a larger rewrite of the original content, normalizing the tone, ensuring all content was present, and creating a coherent story. You may get the most value by picking and choosing sections (let’s face it, articles) that sound like they may be useful to you. I wouldn’t recommend reading it cover-to-cover as I did.

I found the most insightful content to be the career advice, and while I found the practical approaches a bit hit-and-miss, I did appreciate the alternative perspective. Much of the content is aimed at life beyond entry-level line management, where job opportunities are scarce and where it is harder to start practicing the next role. As a result, the author’s recommendation to focus on finding this experience and growing your skills rather than job hopping is something I’ve truly taken to heart.

I recommend reading other engineering management books before this one. While it is worth picking up later in your leadership journey to hear from a different perspective and see some structured guidelines for running particular processes, I would wait until you’ve made some mistakes for yourself and started forming your own opinions on engineering management before reading this one.