Presentation Tips for Engineering Managers: Talking Upward
By Daniel Harper · Career & Business
How should an engineering manager present to non-technical leaders? Start from the decision they need to make, not from how the system works. Translate each piece of work into its effect on customers, revenue or risk, use one concrete example instead of an architecture tour, and try the explanation on someone outside engineering first, because experts are the worst judges of what is obvious.
An engineering manager presents in three directions. Down, to the team, where everyone shares the vocabulary. Across, to product, design and sales, where most of it is shared. And up, to directors and executives who decide budgets and priorities and do not build software. The third is where most engineering managers struggle, and it is the one that decides whether the team gets the time and people it needs.
Your sense of what is obvious is the problem
The hardest part of explaining technical work is not the complexity. It is that you can no longer see it from the outside.
Pamela Hinds asked experts, intermediates and novices to predict how long beginners would take to learn a task on a mobile phone.1 The experts were the most wrong, underestimating the difficulty more than people with less experience. When she asked them to think back to their own early experience, or to consider what makes the task hard for a beginner, neither helped much. Knowing a thing well makes it hard to imagine not knowing it.
The practical fix is not to try harder to imagine. It is to test. Before a presentation that matters, explain the core of it to someone outside engineering, for five minutes, and watch where they stop following. Those are the places to rewrite.
Translate the work into what it changes
Executives fund outcomes. Every item you present should end in an effect they already care about: customers, revenue, cost, risk, speed.
| What engineers say | What the room needs to hear |
|---|---|
| We migrated the payments service to the new queue. | Checkout no longer fails when traffic spikes, which it did twice last quarter. |
| We added observability to the API. | We now find outages in minutes instead of hearing about them from customers. |
| We need to refactor the billing module. | Every billing change currently takes three weeks; after this it takes one. |
The left column is accurate. The right column is what makes the work fundable. If you cannot write the right-hand version for an item, ask whether it belongs in this presentation at all.
Asking for time for technical debt
The presentation engineering managers most often lose is the request for time to fix things nobody outside engineering can see. It loses because it is framed as a favour to engineers. Frame it as a business risk with a price:
- The cost of leaving it. In time, incidents or delay, with the best number you have. "Each release now needs two days of manual testing because the old test suite is unreliable."
- The smallest useful fix. Not the full rewrite: the first stage, with a time box.
- How you will know it worked. A measure the room can check next quarter.
Expect pushback, and grant what is true in it: yes, it delays two features. Objection handling covers answering that without turning it into a negotiation.
Reporting an incident to leadership
After an outage, leadership wants four things, in this order: what happened to customers, whether it is fixed, why it happened, and why it will not happen again. Give them in that order, in plain language, before any timeline or graph.
"For 40 minutes on Tuesday, about a third of customers could not log in. It's fixed. A configuration change went out without the check that would have caught it. That check is now mandatory, and we're adding an automatic rollback by the end of the month."
Keep the review blameless in the room as well as on paper. Naming a person in front of executives teaches the whole team to hide the next incident, and it moves the conversation from the system that failed to the person who happened to touch it.
One concrete example beats an architecture tour
A diagram with forty boxes tells a non-technical audience that the system is complicated, which they already believed. A single concrete example tells them how it works. In studies by Mark Sadoski and colleagues, concreteness was one of the strongest predictors of how easy a passage was judged to understand and how much of it people remembered.2
So instead of the architecture, follow one thing through it: "Here is what happens when a customer presses Pay." If you need a diagram, show only the boxes the decision depends on.
With your own team, it is the opposite talk
When you present to your team, skip the translation and give them what executives never need: the context behind a decision, the options you rejected and why, and what you do not know yet. A team that understands why a priority changed will make better decisions on its own than one that only hears the new priority.
References
- Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance. Journal of Experimental Psychology: Applied, 5(2), 205–221. https://doi.org/10.1037/1076-898X.5.2.205
- Sadoski, M., Goetz, E. T., & Fritz, J. B. (1993). Impact of concreteness on comprehensibility, interest, and memory for text: Implications for dual coding theory and text design. Journal of Educational Psychology, 85(2), 291–304. https://doi.org/10.1037/0022-0663.85.2.291