by Will Larson
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 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!
That’s a lot to remember, so I’ve synthesized these ideas into a loose template. There absolutely is not a single right way to present to senior leaders, but hopefully the template is a useful starting point.
Figure 3.8
The expected and actual experience of presenting to executives.
My general approach to presenting to senior leaders is:
Tie topic to business value. One or two sentences to answer the question “Why should anyone care?”
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.
Explicit ask. What are you looking for from the audience? One or two sentences.
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. If you only provide analysis, then you’re asking folks to take you on trust, which can come across as evasive. This should be a few paragraphs, up to a page.
Decision-making principles. Explain the principles that you’re applying against the diagnosis, articulating the mental model you are using to make decisions.
What’s next and when it’ll be done. Apply your principles to the diagnosis to generate the next steps. It should be clear to folks reading along how your actions derive from your principles and the data. If it’s not, then either rework your principles or your actions!
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.
I’ve had a lot of luck with this format in general, and I think you’ll find it pretty useful as a starting point. That said, the first rule remains true: communication is company-specific. If things don’t quite work for this format in your company, then watch how other folks present. Given a few examples, you’ll be able to reverse engineer the discussions that go well into a workable template.
3.14 Time management
When you sit down for coffee with a manager, you can probably guess the biggest challenge on their mind: time management. Sure, time management isn’t always everyone’s biggest challenge, but once the crises of the day recede, it comes to the fore.
Time management is the enduring meta-problem of leadership. For most other aspects of leadership, you can look to more experienced 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. Yes, their degree of difficulty is certainly higher, but it’s intimidating to consider that there’s little evidence most folks ever get a solid grasp of their time.
Does that make this a lost cause? Nah.
I’m still pretty busy on a day-to-day basis, but I’ve gotten much, much better at getting things done, not by getting faster but by getting more logical about solving problems. The most impactful changes I’ve made to how I manage time are:
Quarterly time retrospective. Every quarter, I spend a few hours categorizing my calendar from the past three months to figure out how I’ve invested my time. This is useful for me to reflect on the major projects I’ve done, and also to get a sense of my general allocation of time. I then use this analysis to shuffle my goal time allocation for the next quarter.
Most folks are skeptical of whether this is time well spent, but I’ve found it particularly helpful, and it’s the cornerstone of my efforts to be mindful of my time.
Prioritize long-term success over short-term quality. As your scope increases, the important work that you’re responsible for may simply not be possible to finish. Worse, the work that you believe is most important, perhaps high-quality one-on-ones, is often competing with work that’s essential to long-term success, like hiring for a critical role. Ultimately, you have to prioritize long-term success, even if it’s personally unrewarding to do so in the short term. It’s not that I like this approach, it’s that nothing else works.
Finish small, leveraged things. If you’re doing leveraged work,40 then each thing that you finish41 should create more bandwidth to do more future work. It’s also very rewarding to finish things. Together, these factors allow large volumes of quick things to build into crescendoing momentum.
Stop doing things. When you’re quite underwater, a surprisingly underutilized technique is to stop doing things. If you drop things in an unstructured way, this goes very poorly, but done with structure this works every time. Identify some critical work that you won’t do, recategorize that newly unstaffed work as organizational risk,42 and then alert your team and management chain that you won’t be doing it. This last bit is essential: it’s fine to drop things, but it’s quite bad to silently drop them.
Size backward, not forward. A good example of this is scheduling skip-levels.43 When you start managing a multi-tier team, say 20 individuals, you can specify a frequency for skip-levels and reason forward to figure out how many hours of skip-levels you’ll do in a given week. Say you have 16 indirect reports, and you want to see them once a month for 30 minutes, so you end up doing two hours per week.
This stops working as your team grows, because there is simply no reasonable frequency that won’t end up consuming an unsustainable number of hours. Instead, specify the number of hours you’re able to dedicate to the activity, perhaps two per week, and perform as many skip-levels as possible within that amount of time. This method keeps you in control of your time allocation, and it scales as your team grows.
Delegate working “in the system.” Wherever you’re working “in the system,”44 design a path that will enable someone else to take on that work. It might be that this plan will take a year to come together, and that’s fine, but what’s not all right is if it’s going to take a year and you haven’t even started.
Trust the system you build. Once you’ve built the system, at some point you have to learn to trust it. The most important case of this is handing off the responsibility to handle exceptions. Many managers hold onto the authority to handle exceptions for too long, and at that point you lose much of the system’s leverage. Handling exceptions can easily consume all of your energy, and either delegating them or designing them out of the system is essential to scaling your time.
Decouple participation from productivity. As you grow more senior, you’ll be invited to more meetings, and many of those meetings will come with significant status. Attending those meetings can make you feel powerful, but you have to keep perspective about whether you’re accomplishing much by attending. Sometimes, being able to convey important context to your team is super valuable, and in those cases you should keep attending, but don’t fall into the trap of assuming that attendance is valuable.
Hire u
ntil you are slightly ahead of growth. The best gift of time management that you can give yourself is hiring capable folks, and hiring them before you get overwhelmed. By having a clear organizational design, you can hire folks into roles before their absence becomes crippling.
Calendar blocking. Creating blocks of time on your calendar is the perennial trick of time management: add three or four two-hour blocks scattered across your week to support more focused work. It’s not especially effective, but it does work to some extent and is quick to set up, which has made me a devoted user.
Getting administrative support. Once you’ve exhausted all the above tools and approaches, the final thing to consider is getting administrative support. I was once quite skeptical of whether admin support is necessary—and, until your organization and commitments reach a certain level of complexity, it isn’t—but at some point having someone else handling the dozens of little interruptions is a remarkable improvement.
As you start using more of these approaches, you won’t immediately find yourself less busy, but you will gradually start to finish more work. Over a longer period of time, though, you can get less busy by prioritizing finishing things with the goal of reducing load. If you’re creative and consequent, and if you don’t fall into the trap of believing that being busy is being productive, you’ll find a way to get the workload under control.
Figure 3.9
Calendar time-blocking for an engineering manager.
3.15 Communities of learning
I’ve always preferred learning in private. Got something difficult? Sure, leave me alone for a few hours and I can probably figure it out. If you want me to figure it out with you watching, I’m not even sure how to start. This is partly introversion, but altogether I’m pretty uncomfortable making mistakes in public. Like a lot of folks, I have a brain that still helpfully reminds me of public errors I made decades ago, and they still bother me.
For a very long time, this discomfort prevented me from discovering one of the most rewarding elements of being in a supportive work environment: building a community of learning with your peers. This works especially well in a gelled “first team,”45 and, recently I’ve been spending more time facilitating a broader learning community of engineering managers.
When I first started facilitating the group, we focused on content-rich presentations. Each slide was dense with important lessons and essential details. It didn’t work well. Folks weren’t engaged. Attendance dropped. Learning was not the order of the day.
Since then, we’ve iterated on format and eventually stumbled on an approach that has worked consistently:
Be a facilitator, not a lecturer. Folks want to learn from each other more than they want to learn from a single presenter. Step back and facilitate.
Brief presentations, long discussions. Present a few minutes of content, maybe five, and then move into discussion. Keep the discussions short enough that even if a group doesn’t get traction on a given topic, it doesn’t become awkward. A good time limit would be 10 minutes.
Small breakout groups. Giving folks time to discuss in small groups allows them to learn a bit about the topic in a small, safe place. It also gives everyone an opportunity to be part of the discussion, which is a lot more engaging than listening to others for an hour.
Bring learnings to the full group. After discussions, give each group an opportunity to bring their discussion back to the larger group, to allow the groups to cross-pollinate their learnings.
Choose topics that people already know about. Successful topics are ones that people have already thought about, typically because these concepts are core to their daily work. Ideally the topic is something that they do but would like to get better at, such as one-on-ones, mentorship, coaching, or career development.
People find it very hard to discuss content that they’ve just learned if it’s too far away from their previous experience. That also creates an environment where learning has to come from the facilitator instead of from the group at large.
Encourage tenured folks to attend. For many learning communities, you’ll find that the most senior or most tenured folks opt out to focus on other work. This is a shame, because there is so much for them to teach newer folks, and also because it creates an opportunity for them to learn from and get to know new members.
Optional pre-reads. Some folks aren’t comfortable being introduced to a new topic in public, and for those individuals, providing a list of optional pre-reads can help them prepare for the discussion. I find that most people don’t read them (which, surprisingly, I also found true when hosting paper-reading groups46), but for some folks they’re very helpful.
Checking in. Depending on the size of the group, it can be powerful to start by checking in with each other, having each person give a 20- or 30-second self-introduction. The format we’ve been using lately is your name, your team, and one sentence about what’s on your mind. This is especially useful in quickly growing communities, as it makes it easier for individuals to meet each other.
The thing I enjoy most about this format is that it gives folks what they really want, spending time learning from each other, and is remarkably quick for the facilitator to prepare. I’m far from a seasoned facilitator, and I’ve also found this format to be a rewarding and safe opportunity for me to grow as a facilitator.
If your company doesn’t have any learning communities, give it a try. I’ve found this one of the easiest, most rewarding things I’ve had the opportunity to work on.
Figure 3.10
Structuring a meeting to facilitate a community of learning.
4
Chapter 4
Approaches
Figure 4.1
Visual representation of a well and poorly balanced organization.
Approaches
You unravel most puzzles knowing they’re solvable. You play most games guided by a rule book. For engineering managers, challenges emerge unexpected from a hundred small decisions, with few rules and no promises. Many of these challenges are difficult in the worst sense. There are few options for next steps and pursuing any one of them feels problematic.
This chapter covers several such problems, including handling policy exceptions, pushing back on requests from your management chain, and scaling yourself in times of transition. Management is an ethical profession, and our decisions matter, especially the hard ones.
4.1 Work the policy, not the exceptions
At an early job, I worked with a coworker whose philosophy was “If you don’t ask for it, you’ll never get it.” Which culminated in continuous escalations to management for exceptional treatment. This approach was pretty far from my intuition of how a well-run organization should work, and it grated on my belief that consistency is a precondition of fairness.
Since then, I’ve come to believe that environments that tolerate frequent exceptions are not only susceptible to bias but are also inefficient. Keeping an organization aligned is challenging in the best of times, and exceptions undermine one of the most powerful mechanisms for alignment: consistency.
Conversely, organizations survive by adapting to the dynamic circumstances they live in. An organization stubbornly insisting on its established routines is a company pacing a path whose grooves lead to failure.
How do you reconcile consistency and change?
As with most seemingly opposing goals, the more time I spent considering them, the less they were mutually exclusive. Eventually, a unified approach emerged, which I call “Work the policy, not the exceptions.”
4.1.1 Good policy is opinionated
Every policy you write is a small strategy,1 built by identifying your goals and the constraints that bring actions into alignment with those goals. It’s probably easiest to dig into an example.
One of the most interesting policies that I recently worked on was designing who is able to join which teams in a company with both many remote employees and many geographically distributed offices. Our most important goa
ls were:
Make every office a first-tier office; there are no second-tier offices.
A first-tier office must own multiple critical projects, and its work shouldn’t be constrained by support from other offices. Furthermore, it must have many individuals physically present who work together closely.
Ensure that remote engineers remain an essential, well-supported cohort of the company.
Once we had agreed upon our goals, the next step was to codify some constraints in order to narrow the scope of allowed actions to those that supported our goals. In this case, a (slightly simplified) set of constraints might be:
Teams are staffed in, at most, one office. (I say “at most” in order to support the premise of teams composed entirely of remote engineers.)
Employees in an office must be members of a team in that office.
Remote employees may work on any team.
Employees within a 60 minute commute of an office must work from that office.
These are good examples of constraints because they clearly constrain allowed behaviors. You could imagine less opinionated constraints, such as “folks in an office should prefer working on teams within that office,” but that would do less to constrain behavior.
If you find yourself writing constraints that don’t actually constrain choice, it’s useful to check if you’re dancing around an unstated goal that’s limiting your options. For example, in the above, you might have an unstated goal that an employee pursuing their preferred work is more important than offices being first-tier, which would lead you toward weak constraint.