An Elegant Puzzle

The book is fine, with a set of tools meant to help decision makers in a fast-evolving environment (he was at Uber), but I read it in bits between breaks at work, paying little attention. I did not get as much out of it; it felt a bit too abstract and conceptual. By comparison The Phoenix Project is much more pragmatic. The Pragmatic Engineer took excellent notes: https://blog.pragmaticengineer.com/an-elegant-puzzle-book-review/

Chapters

Organizations: topics on organization and team design

Interesting that in a system evolving this quickly, like Uber, scaling and changing systems every few months is the norm. The migration process is fundamental. Be flexible, with the awareness that as you grow you will need to retire systems.

Tools: systems thinking and tools to manage change at the org, team and individual level

Nothing stood out to me except presenting to executives, which is very important to be heard:

There absolutely is not a single right way to present to senior leaders, but hopefully, the template is a useful starting point.

1. Tie topic to business value.
2. Establish historical narrative. One or two sentences to answer the question “Why should anyone care?”
3. Explicit ask. What are you looking from the audience? One or two sentences.
4. Data driven diagnosis. (…)
5. Decision making principles.
6. What’s next and when it will be done.
7. Return to explicit ask. (…)

Also very useful: how to present to the press and the model, document, share approach

Approaches: common, but difficult situations engineering managers often find themselves in and dealing with these

Nothing particularly useful to me, maybe Saying No but basic

Culture: efforts that can shift the culture within an organization

Useful advice: befriend your colleagues; a tight-knit team works very well. Also, do not overwork yourself; remember that the people who will remember you working late in 20 years will be your children

Careers: hiring, evaluating performance, promoting and retaining people

Content on how to hire, and how to hire fast. It did not resonate much with me, aside from the idea of a funnel and how evaluating performance is very delicate

Appendix: tools to operate an organization at the line manager, middle manager, and manager of managers level, as well as the reading list.

Line management

Around the time your team reaches three engineers, you’ll want to be running a sprint process. There are many successful ways to run sprints, try a few and see what resonates for you. (…)

Middle management

As you move into middle management, you’ll become responsible for two to five line managers, and will need to shift away from day-to-day execution to give your line managers room to make an impact (and free yourself up to make a larger impact as well). (…)

Managing an organization

As your organization starts to get even larger and you’re mostly managing middle managers, the playbook shifts again. (…) Along the way, remember that your old problems still exist, it’s just that other folks are dealing with them instead. As you roll out new processes to solve your personal pain points, you should be handing off processes to your managers, and keeping them intact and running.

Snippets taken from the book (raw)

Teams are slotted into a continuum of four states:

• A team is falling behind if each week their backlog is longer than it was the week before. Typically, people are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied. 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. Morale is a bit higher, but people are still working hard, and your users may seem happier because they’ve learned that asking for help won’t go anywhere. 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: each piece of debt you repay leads to more time to repay more debt. 2.2.2
• A team is innovating when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs.

That said, if you don’t, then there is probably no one guiding your career. 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

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. There are a non-zero number of companies that do internal documentation well, but I’m less sure if there are a non-zero number of companies with more than 20 engineers that do this well. If you know any, please let me know so that I can pick their brains.

Your first reaction might be to confront this head-on, but it takes a while to build credibility after starting a new job. Sure, you’ve been hired for your experience, so they respect your judgment, but it’s a hard sell to convince someone that your personal experience should invalidate their personal experience. I’ve been trying something different. Model. Start measuring your team’s health (maybe using short, monthly surveys) and your team’s throughput (do some lightweight form of task sizing, even if you just do it informally with a senior engineer on the team or with yourself), which will allow you to establish the baseline before your change. 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. Have the courage to keep at it for a while, and also the courage to stop doing it if it doesn’t work after a month or two. Use the team’s health and throughput metrics to ground your decision about whether it’s working. Document. After you’ve discovered an effective approach, document the problem you set out to solve, the learning process you went through, and the details of how another team would adopt the practice for themselves. Be as detailed as possible: make a canonical document, and even get a few folks on other teams to check that it’s readable from their perspective. Share. The final step is to share your documented approach, along with your experience doing the rollout, in a short email. Don’t ask everyone to adopt the practice, don’t lobby for change, just present the approach and your experience following it. You’ll spend the majority of your time refining approaches that work effectively for your team, a bit of your time documenting how you did it, and almost no time trying to convince folks to change their approach. Strangely, in my experience, this has often led to more adoption than top-down mandates have

It took me a few years to glean a lesson from that experience, but it comes to mind frequently now when I work with folks who are just starting to present to executives. Giving a presentation to senior leadership is a bit of a dark art: it takes a while to master, and most people who do it well can’t quite articulate how they do it. Worse yet, many people who are excellent rely on advantages that resist replication: charisma, quick wit, deep subject matter expertise, or years of experience. 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. 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. 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 Answer directly. Senior leaders tend to be indirectly responsible for wide areas, and frequently pierce into areas to debug problems. Their experience “debug piercing” tunes their radar for evasive answers, and you don’t want to be a blip on that screen. Instead of hiding problems, use them as an opportunity to explain your plans to address them. Deep in the data. You should be deep enough in your data that you can use it to answer unexpected questions. This means spending time exploring the data, and the most common way to do that is to run a thorough goal-setting exercise. Derive actions from principles. One of your aims is to provide a mental model of how you view the topic, allowing folks to get familiar with how you make decisions. Showing you are “in the data” is part of this. The other aspect is defining the guiding principles you’re using to approach decisions. Discuss the details. Some executives test presenters by diving into the details, trying to uncover an area the presenter is uncomfortable speaking on. You should be familiar with the details, e.g., project statuses, but I think that it’s usually best to reframe the discussion when you get too far into the details. Try to pop up to either the data or the principles, which tend to be more useful conversations. Prepare a lot; practice a little. If you’re presenting to your entire company, practicing your presentation is time well spent. Leadership presentations tend to quickly detour, so practice isn’t 38 quite as useful. Practice until you’re comfortable, but prefer to prepare instead getting deeper into the data, details, and principles. As a corollary, if you’re knowledgeable in the area you’re responsible for, and have spent time getting comfortable with the format, over time you’ll find that you won’t need to prepare much for these specifically. Rather, whether you’re able to present effectively without much preparation will become a signal for whether you’re keeping up with your span of responsibility. Make a clear ask. If you don’t go into a meeting with leadership with a clear goal, your meeting will either go nowhere or go poorly. Start the meeting by explicitly framing your goal!

This refined list of goals, aligned to your company’s priorities, then becomes a central artifact for how you and your manager collaborate on your career evolution. Every quarter or so, take some time to refresh the document and review it together. If you’re unconvinced that it’s worth your time to write a career narrative, you certainly don’t have to write one. Most folks get away with not writing one for their entire career and have deeply fulfilling careers despite the absence. That said, if you don’t, then there is probably no one guiding your career. 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