# An Elegant Puzzle  ## Metadata - Author: [[Will Larson]] - Full Title: An Elegant Puzzle - Category: #books - Source: kindle - Last Highlighted: 2025-01-03 04:56:00+00:00 ## Highlights - 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)) - It also digs into a few particular culture topics on the conflict of “freedom to” and “freedom from,” and deals with hero culture. ([Location 187](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=187)) - 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)) - How many teams should we have? Should we create a new team for this initiative, or ask an existing team to take it on? What is the boundary between these two teams? ([Location 211](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=211)) - To progress as a manager, they’ll want more time to focus on developing their management skills. Alternatively, to progress toward staff engineering roles, they’ll find it difficult to spend enough time on the technical details. ([Location 225](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=225)) - Managers supporting more than eight or nine engineers typically act as coaches and safety nets for problems. ([Location 227](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=227)) - On the other hand, it will also keep them busy enough that they won’t be tempted to create work for their team. ([Location 231](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=231)) - Most folks find being on-call for components that they’re unfamiliar with to be disproportionately stressful. ([Location 245](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=245)) - An important property of teams is that they abstract the complexities of the individuals that compose them. Teams with fewer than four individuals are a sufficiently leaky abstraction that they function indistinguishably from individuals. ([Location 249](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=249)) - They are also fragile, with one departure easily moving them from innovation back into toiling to maintain technical debt. ([Location 251](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=251)) - Keep innovation and maintenance together. A frequent practice is to spin up a new team to innovate while existing teams are bogged down in maintenance. I’ve historically done this myself, but I’ve moved toward innovating within existing teams.5 This requires very deliberate decision-making and some bravery, but in exchange you’ll get higher morale and a culture of learning, and will avoid creating a two-tiered class system of innovators and maintainers. ([Location 253](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=253)) - 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)) - As a caveat, the system fix is to hire net new people, increasing the overall capacity of the company. Sometimes people instead attempt to capture more resources from the existing company, and I’m pretty negative on that. ([Location 299](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=299)) - 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 ([Location 303](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=303)) - The hard part is maintaining faith in your plan—both your faith and the broader organization’s faith. At some point, you may want to launder accountability through a reorg, or maybe skip out to a new job, but if you do that you’re also skipping the part where you get to learn. Stay the path. ([Location 317](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=317)) - 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)) - “Once a team has repaid its technical debt, shouldn’t the now surplus team members move to other teams?” ([Location 338](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=338)) - 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, even if the members are fully retained. In this worldview, high-performing teams are sacred, and I’m quite hesitant to disassemble them. ([Location 344](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=344)) - This is part of why my proposed model9 recommends rapidly hiring into teams loaded down by technical debt, not into innovating teams, which avoids incurring re-gelling costs on high-performing teams. ([Location 352](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=352)) - moving one person can shift an innovating team back into falling behind, and now neither team is doing particularly well. ([Location 356](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=356)) - Okay, so what does work? I’ve found it most fruitful to move scope between teams, preserving the teams themselves. If a team has significant slack, then incrementally move responsibility to them, at which point they’ll start locally optimizing their expanded workload. ([Location 379](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=379)) - The other approach that I’ve seen work well is to rotate individuals for a fixed period into an area that needs help. The fixed duration allows them to retain their identity and membership in their current team, giving their full focus to helping out, rather than splitting their focus between performing the work and finding membership in the new team. This is also a safe way to measure how much slack the team really has! ([Location 385](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=385)) - Although it’s rarely quite this extreme, this is where the oft-raised concern that “hiring is slowing us down” comes from: at high enough rates, the marginal added value of hiring gets very slow, especially if your training process is weak. ([Location 440](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=440)) - you only get value from projects when they finish: to make progress, above all else, you must ensure that some of your projects finish. ([Location 467](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=467)) - If your engineer is doing more than three interviews a week, it is a useful act of mercy to give them a month off every three or four months. ([Location 476](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=476)) - generally you start to see larger companies do major investments in both new-hire bootcamps and recurring education classes. I’m optimistically confident that we’re not entirely cargo-culting this idea from each other, so it probably works, but I hope to get an opportunity to spend more time understanding how effective those programs can be. ([Location 480](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=480)) - One specific tool that I’ve found extremely helpful here is an ownership registry, which allows you to look up who owns what, eliminating the frequent “Who owns X?” variety of question. You’ll need this sort of thing to automate paging the right on-call rotation, so you might as well get two useful tools out of it! ([Location 490](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=490)) - 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. It’s probably even harder to bootstrap documentation into a non-documenting company than it is to bootstrap unit tests into a non-testing company, but the best solution to frequent interruptions I’ve seen is a culture of documentation, documentation reading, and a documentation search that actually works. ([Location 496](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=496)) - Along these lines, if you can keep your interfaces generic, then you are able to skip the migration phase of system re-implementation, which tends to be the longest and trickiest phase, and you can iterate much more quickly and maintain fewer concurrent versions. ([Location 506](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=506)) - Finally, a related antipattern is the gatekeeper pattern. Having humans who perform gatekeeping activities creates very odd social dynamics, and is rarely a great use of a human’s time. ([Location 510](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=510)) - There are some cases in which gatekeepers are necessary for legal or compliance reasons, or because a system is deeply frail, but I think that we should generally treat gatekeeping as a significant implementation bug rather than as a stability feature to be emulated. ([Location 513](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=513)) - Something that is somewhat ignored a bit here is how to handle urgent project requests when you’re already underwater with your existing work and maintenance. The most valuable skill in this situation is learning to say no in a way that is appropriate to your company’s culture. ([Location 518](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=518)) - Lately, I’m increasingly hearing folks reference the idea of organizational debt. This is the organizational sibling of technical debt, and it represents things like biased interview processes and inequitable compensation mechanisms. ([Location 524](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=524)) - Some good examples might be a toxic team culture, a toilsome fire drill, or a struggling leader. These problems bubble up from your peers, skip-level one-on-ones,16 and organizational health surveys. ([Location 528](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=528)) - How you respond to this is, in my opinion, the core challenge of leading a large organization. How do you continue to remain emotionally engaged with the challenges faced by individuals you’re responsible to help, when their problem is low in your problems queue? In that moment, do you shrug off the responsibility, either by changing roles or picking powerlessness? Hide in indifference? Become so hard on yourself that you collapse inward? ([Location 532](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=532)) - 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)) - 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. ([Location 542](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=542)) - Succession planning is thinking through how the organization would function without you, documenting those gaps, and starting to fill them in. ([Location 552](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=552)) - This isn’t a one-time tool, but rather a great exercise to run once a year to identify things you could be delegating. ([Location 588](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=588)) - You can even get a sense of how well you’re doing by taking a two- or three-week vacation and seeing what slips through the cracks. ([Location 590](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=590)) - If you ask a manager about their proudest moments, they will probably tell you a story about helping someone grow. ([Location 596](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=596)) - If you ask that same manager about their most challenging experience, they will probably talk about a layoff, a reorganization, a shift in company direction, or the time they weathered an economic downturn. ([Location 597](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=597)) - The key tools for leading efficient change are systems thinking, metrics, and vision. ([Location 600](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=600)) - When the steps of change are too wide, teams get destabilized, and gaps open within them. In those moments, managers create stability by becoming glue. We step in as product managers, program managers, recruiters, or salespeople to hold the bits together until an expert relieves us. ([Location 601](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=601)) - 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)) - Linking these pieces together, we see a feedback loop, in which the system’s downstream behavior impacts its upstream behavior. With a sufficiently high defect rate or slow recovery rate, you could easily see a world where each deploy leaves you even further behind. ([Location 647](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=647)) - Creating an arena for quickly testing hypotheses about how things work, without having to do the underlying work beforehand, is the aspect of systems thinking that I appreciate most. ([Location 653](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=653)) - Most engineering organizations separate engineering and product leadership into distinct roles. This is usually ideal, not only because these roles benefit from distinct skills but also because they thrive on different perspectives and priorities. ([Location 662](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=662)) - 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)) - Taking the time to evaluate which problem to solve is one of the best predictors I’ve found of a team’s long-term performance. ([Location 684](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=684)) - What are the composable blocks you could start building today that would compound into major product or technical leverage10 over time? ([Location 701](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=701)) - There are a number of ways (many of them revolving around quality trade-offs) to reduce long-term throughput in favor of short-term velocity. ([Location 714](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=714)) - 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)) - 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)) - Prefer experimentation over analysis. It’s far more reliable to get good at cheap validation than it is to get great at consistently picking the right solution. ([Location 740](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=740)) - Justify switching costs. What will the costs of switching be for users who move to your solution? Even if folks want to use it, high switching costs may mean that they simply won’t be able to. ([Location 746](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=746)) - After experimenting with a handful of different approaches, agreeing on strategy and vision has been the most effective approach that I’ve found to alignment at scale. ([Location 764](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=764)) - Strategies are grounded documents which explain the trade-offs and actions that will be taken to address a specific challenge. ([Location 767](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=767)) - Visions are aspirational documents that enable individuals who don’t work closely together to make decisions that fit together cleanly. ([Location 768](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=768)) - strategy recommends specific actions that address a given challenge’s constraints. ([Location 777](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=777)) - 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)) - Folks are often comfortable with hard decisions in the abstract, but struggle to translate policies into the specific steps to implement them. This is typically the easiest part to write, but publishing it and following through with it can be a significant test of your commitment. ([Location 796](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=796)) - When you read good, coherent actions, you think, “This is going to be uncomfortable, but I think it can work.” When you read bad ones, you think, “Ah, we got afraid of the consequences, and we aren’t really changing anything.” ([Location 799](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=799)) - 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)) - This is your core speaking point, which you will repeat at each meeting, planning period, and strategy review. ([Location 817](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=817)) - You’ll know a vision is succeeding when people reference the document to make their own decisions, and you’ll know it’s struggling when decisions keep happening that don’t fit into its direction. ([Location 836](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=836)) - 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)) - “In Q3, we will reduce time to render our frontpage from 600ms (p95) to 300ms (p95). In Q2, render time increased from 500ms to 600ms.” ([Location 867](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=867)) - Investments describe a future state that you want to reach, and baselines describe aspects of the present that you want to preserve. ([Location 873](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=873)) - In particular, I’ve found metrics to be an extremely effective way to lead change with little or no organizational authority, and I wanted to write up how I’ve seen that work. ([Location 903](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=903)) - (Let me insert a plug for Ryan Lopopolo’s amazing blog post on “Effectively Using AWS Reserved Instances.”19 ([Location 905](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=905)) - Infrastructure cost is a great example of a baseline metric. ([Location 909](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=909)) - have found that tying it against net revenue is more useful than pinning it at a specific dollar amount.) ([Location 912](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=912)) - What’s so powerful about nudges is that simply letting folks know their behavior has changed will typically stir them to action, and it doesn’t require any sort of organizational authority to do so. (For more on this topic, take a look at Nudge by Richard H. Thaler and Cass R. Sunstein.)21 ([Location 939](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=939)) - Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt. ([Location 974](https://readwise.io/to_kindle?action=open&asin=B07QYCHJ7V&location=974))