Here is a scene that plays out in every company, every week, at every level. A project is stuck. Nobody knows who owns what. The requirements doc has fourteen open questions and no answers. The meeting to discuss the meeting has been rescheduled twice. Everyone is waiting for someone else to move first.
In that moment, one of two things happens.
Either the situation keeps spinning — longer meetings, more Slack threads, more frustrated people — or one person walks in and makes the fog lift. Not by having all the answers. By structuring the question well enough that the team can find the answers. By naming the ambiguity. By calling the decision that needs to be called.
That person is the chaos absorber. And they are almost always the person who gets promoted.
The chaos absorber is not the smartest person in the room. They are the person who notices that the room needs a structure and installs one — before being asked.
This chapter is about how to become that person. Not in a heroic, center-of-attention way. In a quiet, surgical, repeatable way that makes you indispensable without making you exhausted.
The Two Types of People in Every Room
Watch any dysfunctional project meeting long enough and you'll spot the pattern. Some people make the meeting harder. They raise concerns without proposed solutions. They relitigate decisions that were already made. They ask clarifying questions that generate more confusion than clarity. They introduce new edge cases at the worst possible moment.
These are not bad people. Most of them are smart. Many of them are right. But they are chaos generators — every contribution they make increases the entropy of the system rather than decreasing it.
Then there are chaos absorbers. They say things like:
"It sounds like we have two separate debates happening. Can I try to separate them?"
"I'm hearing three open questions. Let me write them down — which one do we need to answer first?"
"We've been going back and forth on this for twenty minutes. Can I propose a decision and we see if anyone has a strong objection?"
"I'll take an action item: I'll have a proposal doc out by Thursday and we can revisit with concrete options."
Notice what those phrases have in common. They don't shut down the conversation. They don't claim authority. They install structure into an unstructured situation. And they do it in a way that makes everyone else's job easier.
This is the core skill. Not solving everything. Installing structure so the problem becomes solvable.
Most engineers think their job is to have the right answer. So they wait until they have one before speaking. Chaos absorbers understand that the more valuable contribution is often just naming the shape of the problem — even before the solution exists.
Why Ambiguity Is Your Playground
Here is something nobody tells junior engineers: the higher you go in an organization, the less defined the work becomes.
A junior engineer gets a ticket. It has acceptance criteria, a design doc, a Figma link, and sometimes even a suggested implementation approach. The ambiguity is low. The execution is the challenge.
A mid-level engineer gets a project. There are requirements, but they have gaps. The timeline is a guess. Some dependencies are unclear.
A senior engineer gets a problem. Not even a well-defined problem. A complaint from a stakeholder, a vague OKR, a "we need to do something about X." The ambiguity is the whole job. Structuring it, scoping it, breaking it into decisions — that's the actual work before any code gets written.
"At the IC4 level you're given tasks. At IC5 you're given goals. At IC6 you're given problems. At Staff+ you're sometimes just given discomfort."
Overheard at a Meta calibration sessionMost engineers treat ambiguity as a blocker. "I can't start until this is defined." "We need to align on requirements first." "I'm blocked on the PM."
High-performing engineers treat ambiguity as an invitation. It is an open space where they can demonstrate judgment. Because the moment you turn fog into clarity, everyone around you notices.
Waiting for clarity is a junior engineer habit. Creating clarity is a senior engineer skill. The person who creates it gets the credit — and the next hard problem.
The Anatomy of Chaos
Before you can absorb chaos, you have to recognize what kind you're dealing with. Not all ambiguity is the same. Treating them identically is how you "clarify" things in a way that makes them worse.
The reason this taxonomy matters: the fix for Decision Fog is completely different from the fix for Priority Paralysis. Engineers who try to "solve ambiguity" generically often make things worse. They write a document when what the team needed was a decision. They hold a meeting when what the team needed was a priority list.
Diagnose first. Then install the right structure.
The Clarifying Question as a Power Move
There is a question that unlocks almost every stuck situation. It sounds simple. Most people never ask it.
The question is: "What does a good outcome look like — specifically?"
Not "what are the requirements." Not "what do you want." Specifically: if this project ends well, what does someone say about it in the all-hands six months from now?
This question does three things simultaneously:
- It forces stakeholders to describe success in concrete terms, which instantly exposes misalignment.
- It reframes the conversation from features and tasks to outcomes — which is where senior engineers think.
- It signals that you are thinking ahead, not just executing orders.
Other versions of this question that work just as well:
- "What would make this a failure?"
- "Who else needs to be happy with this outcome for us to call it a win?"
- "What's the one thing we absolutely cannot get wrong here?"
- "If we had to cut half the scope, what's the half we'd keep?"
These questions feel soft. They are not soft. They are the scalpel that separates "we think we know what we're building" from "we actually know what we're building."
Most engineers wait to be told what success looks like. Senior engineers define it, propose it, and get agreement on it. The moment you start asking "what does good look like" before starting work, you stop being an executor and start being an owner.
The Three-Step Chaos Absorption Move
Here is the repeatable pattern. Use this in any meeting, thread, or project where things have gotten murky. It works every time.
Let's see this in action with a real scenario.
It's a weekly sync. Three engineers, a PM, and a TPM. The topic is a migration that was supposed to ship last month. The PM says customers are complaining. One engineer says the dependency service isn't ready. Another says scope was never finalized. The TPM is trying to take notes but there's nothing to write. Forty minutes pass. The meeting ends with "let's reconnect next week."
At minute 15, not minute 40:
"Can I pause us for a second? I'm hearing three separate problems and I think we're trying to solve all of them at once. Let me try to separate them. First: are we still aligned on scope? Second: is the dependency blocker a hard blocker or a risk we can ship around? Third: what's the actual customer impact timeline — is this a 'bad' or a 'we're about to lose accounts' situation? Can we take them one at a time?"
The meeting has structure now. Within 20 minutes there's a decision on scope and an owner for the dependency conversation. The chaos absorber sends a follow-up doc within the hour.
Nobody assigned that person to be the chaos absorber. They just did it. And everyone in the room noticed — including the PM and the manager who wasn't even there when they read the follow-up note.
The Follow-Up Document — Your Most Underrated Tool
This deserves its own section because most engineers never do it, and the ones who do compound their reputation faster than almost anyone else.
After any meeting that had meaningful ambiguity, send a follow-up. Not a transcript. Not "here are my meeting notes." A structured summary that looks like this:
Decisions made: What did we actually agree on? Be specific. Vague summaries create the exact ambiguity you just spent an hour clearing up.
Open questions: What is still unresolved? Who owns the answer? By when?
Action items: Name + action + deadline. Not "team will look into this." Alex will investigate the latency regression and report back by Thursday EOD.
Next touchpoint: When is the follow-up? Who is invited? What decision will be made there?
Why does this matter beyond the obvious "good documentation" reason?
Because this document travels further than the meeting did. The PM forwards it to their PM. Your manager reads it. The stakeholder who couldn't attend reads it. And every person who reads it gets the same impression: this engineer creates clarity. They can be trusted to own hard things.
The follow-up document is not an administrative task. It is the artifact that converts your in-the-moment contribution into lasting organizational memory — and lasting organizational reputation.
Handling Ambiguity That Lives Above Your Pay Grade
Sometimes the chaos isn't in your project. It's in the org. The strategy is unclear. Leadership is saying different things. Your team has been handed a goal that contradicts another team's goal. Nobody seems to notice, or everyone has noticed and nobody wants to say it.
This is the situation where junior and mid-level engineers freeze. "This isn't my problem. I just write code." And to be fair — it's not their problem to solve. But it is their problem to navigate.
Here's the move:
This is the grown-up version of "I'm blocked." You're not blocked. You've made a documented decision about how to proceed under uncertainty, you've flagged it to the right people, and you're moving forward.
The Trap: Absorbing Too Much
Before we go further, a warning. There is a version of this skill that will make you wildly effective. And there is a version that will grind you into powder.
The difference is one word: scope.
Chaos absorbers who don't set limits become the team's shock absorber for every hard thing. They get assigned the unclear projects. The risky migrations. The cross-functional nightmares. The "we need someone reliable to own this" death marches. They absorb everything and eventually collapse — or worse, they become so buried in operational chaos that they never get to the strategic work that would actually get them promoted.
| The Behavior | Chaos Sponge (Bad) | Chaos Absorber (Good) |
|---|---|---|
| When to engage | Says yes to every ambiguous situation that comes their way | Selects chaos that is visible, strategic, and teaches the org something |
| How they work | Takes ownership of the resolution personally | Installs structure so the team can resolve it without depending on them |
| After the chaos | Is exhausted and has accumulated invisible heroics | Has created a repeatable process and a visible track record |
| Long-term outcome | Reliable firefighter who never gets ahead of the fires | Known as someone who builds systems that prevent fires |
The test: when you absorb chaos, are you building something that reduces future chaos? A document, a process, a clearer ownership model, a template the team will reuse? Or are you just personally carrying something that will land on someone else next time?
Build systems. Not heroics.
Making It Visible Without Being Self-Promotional
Here's the uncomfortable part. All of this work can be invisible if you don't think about how it travels.
You absorbed chaos in a meeting. Great. Who knows? The eight people in the room. Maybe. Half of them are heads-down on their laptops.
You want this work to compound. That means it needs to travel beyond the room. Here is how to do that without once saying "hey, look what I did."
- The follow-up doc: Already covered. But make sure it goes to the right people — your manager included. Not as a brag. As a transparency mechanism. "Wanted to make sure you had visibility into where this landed."
- The retro callout: In sprint retros or project post-mortems, briefly describe the decision framework you used. Not "I did this." More like: "Something that helped here was separating the scope questions from the technical questions early — worth doing earlier next time." You're sharing a pattern, not taking a bow.
- The 1:1 mention: Tell your manager what you're noticing and doing. "I've been spending a fair amount of energy helping clarify the migration scope — I think it saved us two weeks of misaligned work. I'll write it up." Your manager needs to know this exists to advocate for you at calibration.
- The scalable artifact: If you turn your chaos absorption into a template, a process doc, or a decision framework that other teams start using, you've converted a one-time action into a permanent artifact with your fingerprints on it. That travels for years.
Chaos absorption that never gets written down is a favor to the organization. Chaos absorption that produces artifacts and documentation is a career asset.
The Long-Term Reputation Effect
Let's zoom out. What happens to your career when you do this consistently over two years?
A few things happen. First, you start getting called into the hard rooms. The restructuring conversations. The go/no-go decisions. The projects that leadership isn't sure are solvable. Not because you're the most senior person — but because you're the person who makes those rooms more productive. That is an incredibly valuable function.
Second, your manager starts describing you in a specific way at calibration. Not "ships features reliably" or "strong technical skills." More like: "Can handle ambiguous situations independently. Creates clarity where there was none. I trust them with the hard stuff." That is Staff-level language. And it travels.
Third, your peers start routing around uncertainty to come to you. Not to solve their problems — but to think through them. You become a thinking partner for people across the org. And every conversation you have in that capacity expands your network, your visibility, and your understanding of the business.
"There are engineers who are good at their job. And then there are engineers who make the organization work better by being in it. The second type is rare — and promoted fast."
Engineering Director, Stripe (paraphrased)The chaos absorber is the second type.
What to Take Away from This Chapter
Let's make this concrete. Here are the five things you can start doing this week:
The engineer who builds the org's capacity to handle ambiguity is more valuable than the engineer who personally handles every ambiguity. One is a star. The other is a multiplier. Multipliers get promoted to Staff.
Most engineers are waiting to be given clarity. The chaos absorber is the one who generates it — consistently, repeatably, and in a way that everyone can see. Not because they were asked to. Because they understand that this is what senior engineering actually looks like.
The code is the easy part. The structure around the code is where careers are made.