The Three Yeses
On Tuesday, the three stakeholders each got the answer they wanted — and what came due on Wednesday.
Tuesday morning, before your coffee has cooled enough to drink. The first email arrived at 8:47 — Alex, your staff engineer, has been awake longer than you have. A billing race condition fired overnight, three hundred and forty transactions failed silently, and the cleanest version of the fix is two weeks of work. He’s framed it the way he frames everything: clearly, soberly, with the particular weight of a person who has lived through one company’s “let’s just patch it for now” decision and has decided not to be polite about that lesson again.
You’re still reading Alex’s message when the second email lands. Priya, your product manager, has noticed the date on the bug ticket. Friday is the ACME demo. ACME is the largest deal in her pipeline — $2.1M of pipeline she has not slept well about for three weeks — and she does not yet know, because nobody has explained it to her, that Alex’s fix and her demo run through the same code. Her email is upbeat. The upbeat is what makes you flinch.
By 10:15, the third arrives. Jordan, your VP, would like a postmortem for Thursday’s exec meeting. He doesn’t say “polished.” He doesn’t have to.
You sit with three open tabs. The arithmetic is very simple and very ugly. The same engineering hours cannot be in three places at once. Alex needs you to take the fix seriously. Priya needs the demo to be solid in a room she has been preparing for. Jordan needs an artifact that explains, in adult sentences, what failed and what won’t fail again. You can almost certainly promise each of them something close to what they want, separately, in three quick replies. You will be very tempted to do this. As you compose each reply, you will tell yourself that you are managing it. You will be telling yourself a small, comfortable lie.
The lie has a specific shape, and it’s worth slowing down to look at it.
To Alex, you write that the fix is the priority and that you’ll get him the room to do it right. You mean this. You also mean, somewhere underneath, that you’ll find a way to also get Priya her demo and Jordan his document, and that the way you find won’t require Alex to compromise his fix. You don’t say this part because you don’t quite believe it yet, and the act of not saying it lets you keep almost-believing it.
To Priya, you write that the team is on top of the bug and that Friday is safe. You believe you mean this. What you actually mean is that you have not yet had to tell her the demo is at risk, and that the future has not yet forced your hand. You let her cheerfulness carry into Wednesday.
To Jordan, you write that you’ll have the postmortem to him by Thursday morning. You write this in the tone Jordan likes, which is the tone of a person who has things in hand. The thing you have in hand is a calendar and a list.
Three replies. Each one, in isolation, is defensible. Each one, taken together, tells a story about a promise you cannot deliver, distributed across three inboxes so that nobody can see the full picture except you.
This is the move. Not the dramatic kind of failure — not the “I knew the demo was at risk and I lied to Priya” kind. The quieter kind. The kind where each reply was technically true at the moment you sent it, and where the truth quietly drained out over the next 48 hours as the engineering reality refused to bend around your three commitments. By Wednesday at noon, Alex is doing a hurried version of the fix because he can sense the demo pressure even though nobody has formally told him about it. Priya is in a standup hearing words like “we’re tracking it,” and the cheerfulness has gone slightly thin. The postmortem is a half-page draft you keep telling yourself you’ll finish tonight.
What just happened, mechanically, is that you took a problem involving three stakeholders and split it into three smaller problems, each with one stakeholder. This feels like progress. It is the opposite of progress. The three smaller problems are now incubating in three separate rooms, each one losing fidelity, and the moment of reckoning — when Alex talks to Priya, when Priya pings Jordan, when Jordan reads the postmortem and notices the timeline — has only been delayed, not avoided. When the moment lands, it will land all at once.
The structural mistake is recognizable to anyone who has watched it happen. You traded a hard conversation now for three medium conversations later, and the math of medium-conversations-later includes a tax: each stakeholder, when they discover the version of reality you didn’t quite tell them, doesn’t just adjust their expectations. They adjust their estimate of you. The thing that breaks isn’t the project. The thing that breaks is the assumption that what you say to them in the morning is what you’d also say to the person in the next room.
This is the trade-off the trade-off is really about. Not which engineering work to prioritize — that’s the surface decision, and once it’s made, the team can execute. The deeper trade-off is whether you’re willing to be the person who names the impossibility out loud, on Tuesday, before the impossibility names itself on Wednesday.
Naming it isn’t dramatic. It doesn’t require a meeting. It can be done in a single email, sent to all three of them at once, with the same words in front of each pair of eyes. Something like: We have three things on the table this week — the billing fix, the ACME demo, and the postmortem for Thursday. Each one matters. The same engineering hours can’t be in all three places to the quality each of you would want. Here’s what I’m proposing, and here’s what I think we need to give up to get it.
The email is short. It is also, depending on your nervous system, very hard to send. You can feel the hesitation when you draft it. You can feel yourself wanting to add softening qualifiers — I think, possibly, we may need to consider, in light of, depending on. You can feel yourself wanting to send three different versions, each tuned to its reader, each avoiding the specific sentence the reader doesn’t want to hear.
Resist that, and the email becomes the most useful artifact of the week. Not because it solves the problem — the engineering still has to happen, the demo still has to be navigated, the postmortem still has to be written. But because it puts the three stakeholders in the same conversation, looking at the same constraint, asked to be part of the same decision. Alex sees that you’ve taken his fix seriously enough to flag the cost of doing it right. Priya hears about the demo risk from you, in the same minute Jordan hears about the postmortem timing, which means she doesn’t hear it from Alex on Wednesday in a sentence that ends “...he said the fix and the demo are the same code, didn’t you know?” Jordan reads a person in command of the situation, even when that command consists of saying we cannot do everything.
You have replaced three private fictions with one public fact. The public fact is uncomfortable. The private fictions were going to be more uncomfortable, with interest.
This is the work that the medium of email actually surfaces. In a conversation, you can deliver the trade-off in pieces, with body language, with hedging, with the social cushioning that lets a person hear “we may not have the bandwidth” without registering “we are going to drop one of these things.” Email doesn’t allow that cushion. Email forces you to say, in words that will be read after you have left the room, what the trade-off is. The cursor blinks at you until you write it.
The engineering managers who do this well aren’t braver than the ones who don’t. They’ve practiced, somewhere, the specific muscle of composing a message that names a constraint without softening it into vapor. That muscle isn’t taught in management courses. It’s not in the books. It develops in the moments where you sit down with three open tabs on a Tuesday morning, and you write the email that says, in front of all three readers, what is actually true.
Or it doesn’t develop, and the week unfolds the other way, and you spend the following Monday trying to repair what Wednesday broke.
This is the situation Prism Signal puts you inside in The Trade-Off. A billing race condition, a flagship demo, and an exec-meeting postmortem all collide on the same five engineering days. Alex, Priya, and Jordan each arrive in your inbox with a real and legitimate ask. You write the replies. There are no multiple-choice options. There are no suggested responses. Just the compose window, the three messages waiting, and the specific weight of choosing what to say to whom — and whether to say it to all three at once.
Your first scenario is free. No credit card, no commitment — just the Tuesday morning you’ve been managing by improvisation, slowed down enough to practice deliberately.