Communicating Up

Imagine you are three months into a large migration. You are deep in the details — you know which team is behind, you know the exact API that is causing problems, and you know that the timeline is slipping by about two weeks. Then your VP stops you in the hallway and says, "Hey, quick — how's the migration going?"

Most engineers in this moment do one of two things. They either say "Good, good, making progress" and move on — which is a lie by omission. Or they say "Well, it's complicated — team A is behind because of the auth service refactor, and team B had a surprise dependency on the legacy batch job, and then there was the on-call incident last week that pulled two engineers off for three days, and we think we can recover but..." at which point the VP's eyes have glazed over.

Neither response is useful. The first creates false confidence. The second creates noise. Both leave the VP no better equipped to help you than they were before.

Communicating upward — to directors, VPs, and executives — is a distinct skill. It is not the same as talking to your team. It is not the same as writing a design doc. It requires you to understand something fundamental: the person above you is not failing to understand because they aren't smart enough. They're failing to understand because they don't have context, and you're not giving it to them in a form they can use.

This chapter is about fixing that.

What Executives Are Actually Managing

Before you can communicate well with a director or VP, you need to understand what their day looks like. They are not sitting at a desk reading code. They are running from meeting to meeting, making decisions on five projects simultaneously, managing upward to their own leaders, dealing with headcount and budget conversations, and fielding questions about things that have nothing to do with your project.

Their attention is, in a very literal sense, the scarcest resource in the building.

This means something important: when an executive asks you how a project is going, they are not asking for a briefing. They are asking you to help them calibrate their internal risk model. They are trying to answer three questions in their head:

• Is this project on track, or do I need to do something?
• Is there a problem I should know about before it becomes a crisis?
• Is the person running this project in control of the situation?

That's it. Everything else — the technical details, the dependency graph, the specific team that's behind — is context that supports those three questions. If you don't answer those three questions, nothing else you say matters much.

The trust equation

There is a second thing executives are doing when they ask about your project: they are calibrating how much they trust you. This is not cynical — it is how management actually works. A VP cannot deeply supervise every project under them. They use their interactions with project leads to build a mental model of who to worry about and who to trust.

Every time you give a crisp, accurate status update, you deposit trust. Every time you are vague, optimistic when things are bad, or caught by surprise, you withdraw trust. The account matters because when things get genuinely hard — when you need the VP to unblock a dependency, fight for headcount, or buy you more time — the only currency that works is trust they already have in you.

You cannot build that trust in the moment you need it. You build it in every status update for months beforehand.

The 30-Second Verbal Status

Let's start with the most common situation: someone senior asks you an informal question about your project. In a hallway, at the start of a meeting, on Slack. You have, generously, 30 to 45 seconds before their attention shifts.

The structure that works, every time, is three sentences:

Here's what that looks like in practice. Back to the migration example:

Notice what happened there. The VP now knows: overall progress (7 of 10), the problem (checkout service, 2 weeks behind), the reason (legacy batch dependency), the response (two-phase approach), and your risk posture (heads up, not a fire). All of that in about 20 seconds. They can calibrate their internal model and move on.

Compare that to either of the two bad answers from the opening of this chapter. "Good, making progress" — the VP learns nothing. The long technical answer — the VP learns something but doesn't know what to do with it.

The truth about "on track"

The phrase "on track" has been destroyed by years of overuse. Engineers say "on track" when they mean "I haven't thought about this carefully enough to give you a real answer." Executives have learned this. When you say "on track," a smart executive assumes there's something you're not telling them.

So be specific. Instead of "on track," say "we're at milestone 3 of 5 with the date unchanged." Instead of "making good progress," say "we'll hit the first launch criterion by the end of this sprint." Specificity is what separates a confident answer from a hopeful one.

The Written Status Update

Most large projects require a regular written status update — weekly or biweekly — sent to a distribution list that includes directors, VPs, and sometimes executives above that. This is the update that gets forwarded, read at 6am, and referenced in quarterly reviews. Getting it right matters.

The most common mistake is writing a status update that is actually a diary entry. It describes what you did: "This week the team worked on the auth service integration. We had a meeting with team B on Tuesday. We are still working on the performance testing." This tells the reader that things are happening but gives them no way to assess whether the project is healthy.

The second most common mistake is writing a status update that is actually a technical spec. It describes what you built: APIs, architecture decisions, benchmark numbers. This is useful for your team. For executives, it's noise that buries the signal.

The format that works is built around decisions and state, not activity.

The five-field format

Let's look at two versions of the same update to feel the difference.

The first version took longer to read and left the reader knowing less. The second version takes 20 seconds to scan and leaves no ambiguity about the situation, the cause, or what help is needed.

The traffic light is not optional

Some engineers resist using the red/yellow/green status indicator because it feels reductive. "The project is too nuanced for a color," they say. This is exactly backwards.

The color is not a summary of the nuance. It is a navigation aid for the reader. It tells them in one glance whether they need to read the update carefully (red) or can skim it (green). Removing it is the equivalent of removing chapter headings from a book because the content is too complex to label.

Use the colors honestly. Green means: on schedule, no blocking risks, no asks. Yellow means: some risk or some schedule pressure, the project will probably be fine but you should know about it. Red means: the current trajectory does not end in success without a change — different resources, a scope reduction, an unblocked dependency.

How long should it be

A status update for a director-level audience should be readable in under two minutes. A status update for a VP should be readable in under one minute. These are not approximations — they are hard constraints.

If you find yourself writing more than that, you are almost certainly explaining rather than reporting. Ask yourself: am I giving context that changes what action the reader should take? If not, cut it.

The detail goes in a linked appendix, a separate doc, or in response to a follow-up question. The status update itself is the signal. The supporting material is the noise. Keep them physically separated so readers at different levels can consume at their level.

Writing for Different Altitudes

One of the hardest things about communicating upward is that the same project gets read at different levels of an organization. The tech lead wants implementation details. The director wants milestone health. The VP wants risk and timeline. The executive above them wants a single number or a single sentence.

If you write one update and send it to everyone, it will be too detailed for the top and too shallow for the bottom. The solution is not to write four different documents. The solution is to structure one document so that each layer can find their level.

The inverted pyramid

Journalists have solved this problem. The inverted pyramid is a way of structuring information where the most important thing comes first, every paragraph is complete without the ones that follow, and detail accumulates as you go deeper. A reader can stop at any point and still have the most important information.

A project update written in this style looks like this: The first paragraph is the status for a VP — one sentence, one color. The second section is the milestone view for a director — five bullet points. The third section is the dependency/risk detail for a tech lead. The appendix has raw data for whoever needs it.

Each layer of leadership reads until they have enough and stops. No one needs to skim past their relevant section or dig for it.

The executive one-liner

If your project ever gets reviewed at a level above VP — in a quarterly review, a board briefing, or an all-hands — you need to be able to describe it in one sentence. Not "one sentence that's actually three sentences joined with semicolons." One actual sentence.

This forces you to answer: what is this project, really? What changes in the world if it succeeds?

A good one-liner is not a description of the work. It is a description of the outcome. "We're migrating the payments stack" is a description of work. "We're reducing checkout latency by 40% and eliminating the billing outage that's costing us $2M/year" is a description of outcome.

When your project gets mentioned in a room you're not in — and it will — the one-liner is what gets repeated. Make sure it's the one you wrote, not a paraphrase someone invented.

Delivering Bad News

At some point in every large project, something breaks badly enough that you have to tell someone above you something they don't want to hear. The timeline is slipping by more than two weeks. A key dependency fell through. A technical assumption turned out to be wrong in a way that changes the scope significantly. The feature that was supposed to launch isn't going to make the deadline.

Most engineers approach this conversation with dread and delay it as long as possible. This is exactly backwards. The worst time to deliver bad news is when you no longer have any good options. The best time is when you still have two or three paths forward.

The structure of a bad news conversation

There is a simple four-part structure that works for almost any bad news conversation with a leader:

1. State the situation plainly. Don't bury it. Don't build up to it. Say it in the first sentence. "I have an update on the launch timeline — we're not going to hit the original date." Getting the bad news out first prevents the executive from sitting through a long context-setting section wondering why you asked for the meeting.

2. Explain the cause, not the blame. One sentence on why. "A dependency on team X's auth service took three weeks longer than planned" is a cause. "Team X dropped the ball" is blame. Even if team X did drop the ball, the blame frame makes you sound like you're managing your reputation rather than the project. The cause frame positions you as someone trying to understand and fix the system.

3. Present your options, not just the problem. This is the most important part. The thing that separates engineers who are trusted with hard problems from engineers who aren't is this: do they come with problems or do they come with options? "I see three paths forward" — and then describe them with their trade-offs — makes you a partner in solving the problem rather than a reporter of disasters. Even if none of the options are good, having thought them through shows that you're in control.

4. Make a recommendation and ask for what you need. Don't leave the decision entirely to the executive. Tell them which option you think is best and why. Then name the specific thing you need from them — an introduction, a decision, a budget approval, air cover with another team. Vague asks ("I just wanted to flag this") don't get actioned. Specific asks do.

Notice what the good version does. It states the problem immediately. It explains the cause (race condition) without blaming anyone. It presents two options with trade-offs. It makes a recommendation with reasoning. And it asks for one specific thing.

The executive in this conversation is not happy, but they are in control. They understand the situation, they have a decision to make, and the engineer in front of them has clearly thought it through. That is the foundation of trust.

The sooner, the better — always

There is a rule that experienced principals learn and inexperienced ones learn the hard way: the cost of delivering bad news roughly doubles for every week you wait.

If you know on Monday that you're going to miss the date, and you tell your director on Monday, they have maximum time to adjust. They can restructure the roadmap, have the customer conversation early, bring in extra resources, change the launch criteria. They have options.

If you wait until Friday of the week before the launch, they have no options. They can only absorb the impact. And now they're not just dealing with the slip — they're dealing with the fact that you knew for a week and didn't tell them.

The fear that causes engineers to delay bad news is understandable. Nobody wants to walk into a room and say "I have bad news." But the version of you that walks in early with a problem and three options is an asset. The version of you that walks in late with a problem and no options is a liability.

The Escalation Conversation

Escalation is different from delivering bad news. Bad news is a status report. Escalation is a request for intervention. You are asking someone above you to use their authority or their relationships to unblock something that you cannot unblock yourself.

Escalation is one of the most underused tools in a principal engineer's toolkit. Many engineers see escalation as a sign of failure — as if needing help means they couldn't handle the problem themselves. This is completely wrong. Escalation is a sign that you understand the boundaries of your own authority and you're operating the system correctly.

There are things only a VP can do. They can call another VP and move a dependency. They can give you budget without a three-week approval process. They can walk into a meeting with a peer org and shift the priority. You cannot do these things. Sitting on a blocked dependency for two months because you don't want to "escalate" is not strength — it's failing the project for the sake of your own ego.

When to escalate

The hard part is timing. Escalate too early and you look like you can't handle problems. Escalate too late and the problem has grown into a crisis. Here is the rule of thumb:

How to escalate well

There is a right way and a wrong way to escalate. The wrong way is going to your manager and saying "team X is blocking us and won't respond." This is a complaint. It puts your manager in the position of playing referee between two teams they don't fully understand. It creates friction, bad feelings, and rarely resolves the actual problem quickly.

The right way to escalate has four ingredients:

• The specific thing that is blocked. Not "team X is difficult to work with." The specific API, decision, or resource that is not moving. "We need team X to commit to a review of the schema change by end of week."
• What you've already tried. "I've reached out to the tech lead three times over two weeks and we have not been able to get a meeting on their calendar." This shows that you are not escalating prematurely and that the problem is real.
• The impact if it isn't resolved. "If we don't get this review by Friday, the Phase 2 launch moves from week 10 to week 13." Concrete numbers make the urgency real and give your manager the context to weigh this against other things on their plate.
• The specific ask. "I think a conversation between you and their director would unblock this. Is that something you can do this week?" You are not dumping the problem in their lap. You are asking for a specific action you can't take yourself.

Escalate the system, not the person

When you escalate, you are almost never dealing with a bad person. You are dealing with a misaligned priority. The infrastructure team isn't malicious — they have thirty demands on their time and yours isn't the highest one. Your escalation should be framed around fixing the priority mismatch, not blaming the people who are in the middle of it.

This matters practically because the people you escalate around are still your collaborators after the escalation is resolved. If you burn them with a blame-laden escalation, you may get your unblock, but you've made the next six months of working with that team significantly harder. The escalation that is framed as "the system produced the wrong outcome and I need help adjusting it" leaves everyone's dignity intact.

The Six Ways Engineers Fail at This

After watching hundreds of engineering teams run projects, the same failure modes in upward communication appear again and again. Here they are, named directly.

1. The happy path narrator

This engineer only reports good news. Every update describes progress, completed work, and positive momentum. Risks are minimized. Problems are described as "being worked on." The result is that leadership has no idea the project is in trouble until it suddenly is.

This usually comes from a genuine desire to appear competent and not alarm people unnecessarily. But it achieves the opposite. When the crisis eventually comes — and it usually comes — the engineer who only reported good news is the last person anyone trusts with a difficult project again.

2. The technical deep-diver

This engineer answers every executive question with technical detail. They explain the architecture, the trade-offs, the three approaches they considered. They are not being evasive — they genuinely believe the detail is important for making good decisions.

But the executive is not making technical decisions. They are making resource and risk decisions. When a VP asks "how's the migration going," they are not asking for an architecture review. They are asking for a risk assessment. Answering with technical detail is like answering "how was your weekend" with a detailed description of each meal.

3. The problem reporter

This engineer brings every issue to leadership without thinking through solutions. They are transparent about problems — which is good — but they arrive with the problem and no options, which forces the executive to do the analytical work the engineer should have done.

The difference between a junior and a senior engineer is often this: the junior brings problems. The senior brings problems with options and a recommendation.

4. The update hoarder

This engineer sends updates infrequently — only when they have something "worth saying." Weeks go by with silence. Then they send a long update covering everything that happened.

The problem is that silence is a signal. When a project goes quiet, experienced leaders worry. They wonder if the engineer is overwhelmed or hiding something. A short weekly update — even one that just says "steady progress, no changes to share, on track for the milestone" — is more valuable than silence followed by a detailed monthly report.

5. The last-minute escalator

This engineer waits until the project is in crisis before escalating. By then, the options that a timely escalation could have unlocked are gone. The conversation that would have been "can you help me move this dependency" becomes "we have a critical problem that needs immediate intervention."

The last-minute escalation is always more expensive than the early one — in terms of leadership time, in terms of project disruption, and in terms of the engineer's reputation.

6. The confirmation seeker

This engineer communicates upward primarily to get approval and validation, not to give information. Every update is subtly seeking reassurance. Every decision comes with "does this seem right to you?" rather than "here's what I decided and why."

Leaders want to delegate authority to someone who exercises it confidently. An engineer who constantly seeks confirmation signals that they're not comfortable owning the project. The trust you're trying to build requires demonstrating that you make good decisions — not that you ask the right people before making them.

Building the Communication Habit

Everything in this chapter describes skills that feel unnatural the first time you use them. Delivering bad news early feels reckless. Sending a yellow status update feels like admitting weakness. Escalating feels like asking for help with something you should be able to handle.

These feelings are the residue of an earlier career stage where your job was to execute and your manager's job was to deal with the organizational complexity. As a principal engineer, that boundary is gone. The organizational complexity is now part of your job.

The fastest way to build these habits is to pick one thing from this chapter and do it on your current project this week. Send the five-field status update instead of the diary. Put a yellow in the traffic light even though it's uncomfortable. Have the early bad news conversation rather than waiting to see if it resolves.

What you'll find, almost immediately, is that the conversations go better than you expected. Leaders don't punish honest yellow status updates — they appreciate them. They don't blame you for bad news delivered early — they help you solve it. The fear is almost always larger than the reality.

And over months, something else happens. The leaders above you start to relax about your project. They stop asking for extra check-ins. They stop cc'ing themselves on your emails. They start giving you more autonomous direction. This is what trust looks like from the outside.

You cannot force trust with a single update. But you can earn it, one honest status at a time.

Three Questions for Your Next Project

1. If your VP asked you right now — "how's the project going" — could you answer in three sentences that cover status, biggest risk, and what you need? If not, something is unclear either in your own understanding or in how you're tracking the project.

2. Is there anything you know right now that a director or VP would want to know, that you haven't told them? If yes — why not? What is the fear, and is it more costly than them finding out later?

3. Is there a blocked dependency or a decision that has been sitting for more than a week, that you've been hoping will resolve itself? If yes — it probably won't. Who needs to hear about it, and what specifically are you asking them to do?