Will Larson - An Elegant Puzzle (Highlights)

# Will Larson - An Elegant Puzzle (Highlights) ![rw-book-cover|256](https://images-na.ssl-images-amazon.com/images/I/51aTO3pGp9L._SL200_.jpg) ## Metadata **Cover**:: https://images-na.ssl-images-amazon.com/images/I/51aTO3pGp9L._SL200_.jpg **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Will Larson]] **Full Title**:: An Elegant Puzzle **Category**:: #books #readwise/books **Category Icon**:: 📚 **Highlighted**:: [[2022-03-18]] **Created**:: [[2022-09-26]] ## Highlights ### Introduction - Organizational design gets the right people in the right places, empowers them to make decisions, and then holds them accountable for their results. ([Location 178](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=178)) ### Organizations - When I have a problem that I want to solve quickly and cheaply, I start thinking about process design. A problem I want to solve permanently and we have time to go slow? That’s a good time to evolve your culture. However, if process is too weak a force, and culture too slow, then organizational design lives between those two. ([Location 204](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=204)) #### 2.1 Sizing teams - the fundamental challenge of organizational design is sizing teams. ([Location 213](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=213)) - Managers should support six to eight engineers ([Location 219](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=219)) - Tech Lead Managers (TLMs). Managers supporting fewer than four engineers tend to function as TLMs, taking on a share of design and implementation work. ... it’s a role with limited career opportunities. ([Location 223](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=223)) - Coaches. Managers supporting more than eight or nine engineers typically act as coaches and safety nets for problems. They are too busy to actively invest in their team or their team’s area of responsibility. ([Location 227](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=227)) - Managers-of-managers should support four to six managers ([Location 230](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=230)) - On-call rotations want eight engineers ([Location 240](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=240)) - Small teams (fewer than four members) are not teams ([Location 247](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=247)) - Keep innovation and maintenance together. ([Location 253](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=253)) - Teams should be six to eight during steady state. ([Location 258](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=258)) - To create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five. ([Location 258](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=258)) - Never leave managers supporting more than eight individuals. ([Location 259](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=259)) #### 2.2 Staying on the path to high-performing teams ##### 2.2.1 Four states of a team - A team is falling behind if each week their backlog is longer than it was the week before. ([Location 279](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=279)) - A team is treading water if they’re able to get their critical work done, but are not able to start paying down technical debt or begin major new projects. ([Location 281](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=281)) - A team is repaying debt when they’re able to start paying down technical debt, and are beginning to benefit from the debt repayment snowball: ([Location 283](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=283)) - A team is innovating when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs. ([Location 285](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=285)) ##### 2.2.2 System fixes and tactical support - When the team is falling behind, the system fix is to hire more people until the team moves into treading water. ([Location 297](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=297)) - When the team is treading water, the system fix is to consolidate the team’s efforts to finish more things, and to reduce concurrent work until they’re able to begin repaying debt (e.g., limit work in progress). ([Location 303](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=303)) - When the team is repaying debt, the system fix is to add time. ([Location 306](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=306)) - Especially for a team that started out falling behind and is now repaying debt, your stakeholders are probably antsy waiting for the team to start delivering new stuff, and your obligation is to prevent that impatience from causing a backslide! ([Location 309](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=309)) - Innovating is a bit different, ([Location 311](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=311)) #c1 - In this case, it’s to maintain enough slack in your team’s schedule that the team can build quality into their work, ([Location 312](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=312)) There is not much work or activity. ##### 2.2.3 Consolidate your efforts - For each constraint, prioritize one team at a time. ([Location 327](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=327)) - Adding new individuals to a team disrupts that team’s gelling process, so I’ve found it much easier to have rapid growth periods for any given team, followed by consolidation/gelling periods during which the team gels. The organization will never stop growing, but each team will. ([Location 329](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=329)) ##### 2.2.4 Durable excellence #### 2.3 A case against top-down global optimization ##### 2.3.1 Team first - Fundamentally, I believe that sustained productivity comes from high-performing teams, and that disassembling a high-performing team leads to a significant loss of productivity, ([Location 344](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=344)) - The lesson is that you have to account for re-gelling costs after periods of change, ([Location 351](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=351)) ##### 2.3.2 Fixed costs - most teams have high fixed costs and relatively small variable costs: ([Location 356](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=356)) Spliting a team into two doubles the fixed cost. ##### 2.3.3 Slack - you can often slow a team down by shifting resources to it, ([Location 367](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=367)) - The Goal by Eliyahu M. Goldratt10 and Thinking in Systems: A Primer by Donella H. Meadows11 are both phenomenal books on this topic. ([Location 373](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=373)) #rl ##### 2.3.4 Shift scope; rotate - If a team has significant slack, then incrementally move responsibility to them, at which point they’ll start locally optimizing their expanded workload. ([Location 380](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=380)) - do this slowly to maintain slack in the team, ([Location 381](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=381)) - Shifting scope works better than moving people because it avoids re-gelling costs, and it preserves system behavior. ([Location 383](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=383)) - The other approach that I’ve seen work well is to rotate individuals for a fixed period into an area that needs help. ([Location 385](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=385)) #### 2.4 Productivity in the age of hypergrowth ##### 2.4.1 More engineers, more problems ##### 2.4.2 Systems survive one magnitude of growth - If your company is designing systems to last one order of magnitude and is doubling every six months, then you’ll have to re-implement every system twice every three years. ([Location 453](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=453)) - 2.4.3 Ways to manage entropy ([Location 465](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=465)) - Finally, the one thing that I’ve found at companies with very few interruptions and have observed almost nowhere else: really great, consistently available documentation. ([Location 496](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=496)) - When at all possible, build systems with sufficient isolation that you can allow most actions to go forward. And when they do occasionally fail, make sure that they fail with a limited blast radius. ([Location 511](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=511)) ##### 2.4.4 Closing thoughts #### 2.5 Where to stash your organizational risk? - What I’ve found most 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. ([Location 536](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=536)) #### 2.6 Succession planning - consider your work from several different angles: ([Location 558](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=558)) - Take a look at your calendar and write down your role in meetings. ([Location 560](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=560)) - For each of the individuals you support, in which areas are your skills and actions most complementary to theirs? How do you help them? What do they rely on you for? ([Location 566](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=566)) - Filter the gaps down to two lists: ... The first should cover the easiest gaps to close. ... The latter will be the riskiest gaps. These are the areas where you’re uniquely valuable to the company, ([Location 582](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=582)) ### Chapter 3 Tools #### 3.1 Introduction to systems thinking - If you really want a solid grasp on systems thinking fundamentals, you should read Thinking in Systems: A Primer3 by Donella H. Meadows, ([Location 609](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=609)) #rl ##### 3.1.1 Stocks and flows - Big changes appear to happen in a moment, but if you look closely underneath the big change, there is usually a slow accumulation of small changes. ([Location 618](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=618)) - Changes to stocks are called flows. These can be either inflows or outflows. ([Location 621](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=621)) - an information link. This indicates that the value of a stock is a factor in the size of a flow. ([Location 624](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=624)) - keep in mind that every flow is a rate, whereas every stock is a quantity. ([Location 627](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=627)) ##### 3.1.2 Developer velocity - Accelerate: The Science of Lean Software and DevOp, by Nicole Forsgren, Gene Kim, and Jez Humble,4 I’ve spent a lot of time pondering the authors’ definition of velocity. ([Location 630](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=630)) #rl - Delivery lead time is the time from the creation of code to its use in production. ([Location 633](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=633)) - Deployment frequency is how often you deploy code. ([Location 634](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=634)) - Change fail rate is how frequently changes fail. ([Location 635](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=635)) - Time to restore service is the time spent recovering from defects. ([Location 636](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=636)) - Pull requests are converted into ready commits based on our code review rate. ([Location 640](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=640)) ##### 3.1.3 Model away - Stella5 is the gold standard, but the price is quite steep, ... The best cheap alternative that I’ve found is Insight Maker, ([Location 658](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=658)) #### 3.2 Product management: exploration, selection, validation  - Product management is an iterative elimination tournament, with each round consisting of problem discovery, problem selection, and solution validation. ([Location 676](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=676)) ^393179759 - Write a customer letter. Write the launch announcement that you would send after finishing the solution. Are you able to write something exciting, useful, and real? ([Location 733](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=733)) ^393179760  - A mild caveat: it’s better to rely on people you have some connection to instead of on conference talks and such, since there is a surprisingly large amount of misinformation out there. ([Location 737](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=737)) ^394178942 - A strategy recommends specific actions that address a given challenge’s constraints. ([Location 777](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=777)) ^394178943 - A structure that I’ve found extremely effective13 is described in Good Strategy/Bad Strategy by Richard Rumelt,14 and has three sections: diagnosis, policies, and actions. ([Location 778](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=778)) ^394178944 - Before you’ve even finished reading a great diagnosis, you’ll often have identified several good candidate approaches. That’s the power of a well-defined problem statement, and why it’s an important foundational element for your strategy. ([Location 786](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=786)) ^394178945 - If strategies describe the harsh trade-offs necessary to overcome a particular challenge, then visions describe a future in which those trade-offs are no longer mutually exclusive. ([Location 810](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=810)) ^394178946 - Visions should be detailed, but the details are used to illustrate the dream vividly, not to prescriptively constrain its possibilities. ([Location 814](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=814)) ^394178947 - Bad goals are indistinguishable from numbers. “Our p50 build time will be below two seconds,” or “We’ll finish eight large projects.” You’ll know a goal is just a number when you read it and aren’t sure if it’s ambitious or whether it matters. ([Location 860](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=860)) ^394178948 - Good goals are a composition of four specific kinds of numbers: A target states where you want to reach. A baseline identifies where you are today. A trend describes the current velocity. A time frame sets bounds for the change. ([Location 862](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=862)) ^394178949 - Baseline metrics are useful for narrowing the solution space that you explore in order to accomplish your investment goals. They are also useful for identifying when you should pause pursuing your goals and instead invest in platform quality. ([Location 881](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=881)) ^394178950 #spark - Although your baselines will often be about preserving a current property, you can also decide to accept some degradation before you want to trigger reprioritization. ([Location 884](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=884)) ^394178951 - After you’ve evolved the design, the next step is to embed into the most challenging one or two teams, and work side by side with those teams to build, evolve, and migrate to the new system. Don’t start with the easiest migrations, which can lead to a false sense of security. ([Location 994](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=994)) ^394178952 - Many folks start migrations by generating tracking tickets for teams to implement, but it’s better to slow down and build tooling to programmatically migrate the easy 90 percent. ([Location 1001](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1001)) ^394178953 - The best migration tools are incremental and reversible: ([Location 1006](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1006)) ^394178954  - Answer the question you want to be asked. If someone asks a very difficult or challenging question, reframe it into one that you’re comfortable answering. Don’t accept a question’s implicit framing, but instead take the opportunity to frame it yourself. ([Location 1228](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1228)) ^399617770 - Speak in threes. Narrow your message down to three concise points, make them your refrain, and continue to refer back to your three speaking points. ([Location 1235](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1235)) ^399617771 Rule or Three, also in: - [[Johanna Rothman - Free Your Inner Nonfiction Writer (Highlights)]] - One of the trickiest, and most common, leadership scenarios is leading without authority, and I’ve written about one of the styles that I’ve found surprisingly effective in those conditions. I call it Model, Document, Share. ([Location 1240](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1240)) ^399617772 - Then just start running kanban. Don’t publicize it, don’t make a big deal about it, just start doing it with your team. Frame it as a short experiment with the team, and start trying it. Keep iterating on it until you’re confident it works. ([Location 1255](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1255)) ^399617773 - Mandates assume: It’s better to adopt a good-enough approach quickly. ... Model, Document, Share assumes: It’s better to adopt a great approach slowly. ([Location 1268](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1268)) ^399617778  - Start with the conclusion. Particularly in written communication, folks skim until they get bored and then stop reading. Accommodate this behavior by starting with what’s important, instead of building toward it gradually. ([Location 1373](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1373)) ^406764010 - Frame why the topic matters. Typically, you’ll be presenting on an area that you’re intimately familiar with, and it’s probably very obvious to you why the work matters. This will be much less obvious to folks who don’t think about the area as often. Start by explaining why your work matters to the company. ([Location 1375](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1375)) ^406764011 - Everyone loves a narrative. Another aspect of framing the topic is providing a narrative of where things are, how you got here, and where you’re going now. This should be a sentence or two along the lines of, “Last year, we had trouble closing several important customers due to concerns about our scalability. We identified our databases as our constraints to scaling, and since then our focus has been moving to a new sharding model that enables horizontal scaling. That’s going well, and we expect to finish in Q3.” ([Location 1377](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1377)) ^406764012 - Tie topic to business value. One or two sentences to answer the question “Why should anyone care?” ([Location 1407](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1407)) ^406764013 - Establish historical narrative. Two to four sentences to help folks understand how things are going, how we got here, and what the next planned step is. ([Location 1409](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1409)) ^406764014 - Explicit ask. What are you looking for from the audience? One or two sentences. ([Location 1410](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1410)) ^406764015 - Data-driven diagnosis. Along the lines of a strategy’s diagnosis phase,39 explain the current constraints and context, primarily through data. Try to provide enough raw data to allow people to follow your analysis. ([Location 1412](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1412)) ^406764016 - Return to explicit ask. The final step is to return to your explicit ask and ensure that you get the information or guidance you need. ([Location 1420](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1420)) ^406764017  - This last bit is essential: it’s fine to drop things, but it’s quite bad to silently drop them. ([Location 1449](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1449)) ^477267284 - Technical disagreements become learning opportunities for everyone. ([Location 1687](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1687)) ^477267285 - “With the right people, any process works, and with the wrong people, no process works.” ([Location 1694](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=1694)) ^477267286