Skip to content
All books
New

Before the Room: a field guide to leading outcomes you have no authority to command

Three moves, Surface, Shift and Secure, for the decisions your work depends on, with 16 templates, each with a completed example.

A tech lead and staff engineer book on influence without authority

Before the Room is for senior engineers, tech leads and staff engineers who are accountable for something they cannot order into existence.

Its premise is simple: for consequential decisions, the visible meeting is often not where the decision happens. The book teaches you to work on the decision while it is still forming, and to keep it decided afterward.

Read part one in order to get the engine. After that, the chapters are close to modular: open the one that matches the situation in front of you this week.

What you get

  • Three moves, always in this order: Surface the real decision, Shift it with one artifact and the exact words, Secure it with a threshold and a follow-up signal
  • Find the hidden decision, map power before you argue, and read the incentive conflict
  • Pre-alignment, strategy that can be adopted, scope and deadline negotiation, migrations when the cost is local, and green status that hides red reality
  • Escalation without status warfare, incident leadership, and conflict with high performers, product and executive pressure
  • 16 templates, each with a blank and one completed example, from the hidden-decision worksheet to the escalation brief and the evidence ledger
  • An In the field block in every chapter, a weekly operating system and a thirty-day repair plan

Where being right stops being enough

Right, and downlevelled anyway

The loop agrees you were the strongest engineer of the week, then decides you will not move anything at the next level.

The meeting was already decided

You bring your best case on Thursday to a room whose positions were settled by Wednesday night, in a hallway, a passing question and an incentive nobody named.

A status answer became a promise

You answered whether the date was on track. Ten days later it is a hard commitment to a partner, and you never agreed to one.

The nod reversed by Thursday

The review agreed. Then someone who was not in the room reopened it in a channel, and the people who nodded nodded along.

Everyone agrees, nobody moves

The migration is right for the organization and expensive for every team, so it stalls behind a dashboard that still says on track.

The escalation that worked and cost you

The blocker moved within the hour, and the working relationship you need for the next three launches got more expensive.

At senior levels your job is no longer to have the best answer in the room. It is to make the important decision easier to see, safer to make, and harder to lose.
From Before the Room

What changes when you use it

You stopYou stop answering the visible request faster.

You startYou ask which decision it scaffolds, who owns it, and what incentive will settle it.

You stopYou stop bringing a better argument to the room.

You startYou take one artifact and the exact words to the owner, before the room.

You stopYou stop leaving the meeting relieved.

You startYou set the escalation threshold and the follow-up signal before it closes.

You stopYou stop calling a date impossible.

You startYou hand over three costed options, recommend one, and let the owner choose the promise.

You stopYou stop escalating late and hot.

You startYou name the threshold in calm weather and ask one owner for one decision.

Name the kind of failure you are in

  • Nobody can say what is actually being decided. That is a decision failure: start with the hidden-decision worksheet.
  • Nobody owns it, or the wrong person does. That is an ownership failure: start with the decision-rights map.
  • The people who pay for it gain nothing from it. That is an incentive failure: start with the stakeholder and incentive map, then the migration wave plan.
  • Everyone says it works, and nobody can prove it. That is an evidence failure: start with the outcome evidence table.
  • Teams agreed, but each means something different by done. That is a coordination failure: start with the outcome contract.

Why this book exists

I have spent 15 years in mobile and sat through 500+ technical interviews from the hiring side: debriefs, hiring committees, promotion calibrations. That seat shows you the moment a decision about a person is made, and how often the reasons that settle it are not the ones anyone says out loud.

I have watched the same thing happen to technical decisions. The architecture call, the migration, the deadline, the launch everyone agreed was green. The decision was shaped earlier, in a hallway, a review comment or an incentive nobody named, and engineers lost outcomes they should have won because they prepared to win the meeting.

There are good books full of leadership principles. What I could not find was the field manual for the moments where technical risk, incentives, power and decision rights collide. So I wrote it, from the debrief room. The scenes are composites; the patterns underneath them are the point.

A page from the book

Copied as printed, so you can judge the format before you buy.

Chapter 3, page 20

The engine, in three moves

Surface. Find the decision that is actually being made, who owns it, and the incentive that will decide it.

Shift. Change that decision with one artifact and the exact words to say, placed in front of the right owner, before the room.

Secure. Set the threshold that triggers escalation and the follow-up signal that proves the change held.

Before the room does not mean behind people's backs. It means surfacing constraints early enough that the room can make an honest decision.

In my experience a stuck outcome usually traces back to a skipped move. Surface gets skipped because the visible problem looks like the real one. Shift gets attempted with a better argument, aimed at the meeting instead of the owner. Secure gets skipped when the meeting nods, and the decision is reversed a week later.

Want more pages?

Before and after

A status question that is really a commitment

Before

Yes, we are on track, two risks but both have mitigations, should be fine for the fifteenth.

After

Before I confirm, are you deciding whether to commit this date to someone outside the team?

My confidence for an internal target and my confidence for a hard external promise are different numbers, and I want to give you the right one.

A date that has outrun its evidence

Before

There is no way we can hit that date.

After

I see three defensible paths, and I recommend one.

Engineering sizes the risks and recommends one. You own which promise we make. Which do you want?

A launch that is green on the dashboard

Before

This is not green.

After

The work is locally complete, but the launch path is not proven.

I recommend we move status from green to amber, integration unproven, until one production-like end-to-end path succeeds with the release sequence, permissions and rollback we actually intend to use.

Choose your edition

Both editions are on one Gumroad page: you pick the edition there, before you pay. Every edition includes free lifetime updates.

Book

The complete book

$39

The complete Before the Room book, to read and study the system.

  • PDF
  • EPUB
  • 20 chapters in five parts
  • 16 templates, each with a completed example
Choose Book, $39

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Most complete

Book + Field Kit

The book and the kit to use it at work

$59

Everything in the Book edition, plus the reusable operating kit for applying the system at work.

Best if you want to use the system, not just read about it.

  • Everything in Book
  • The complete Field Kit
  • All 16 practical artifacts
  • Fillable workbook
  • Surface, Shift, Secure Field Card
Choose Book + Field Kit, $59

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

Team

Up to 10 readers in one organization

$149

Everything in Book + Field Kit, licensed for up to 10 people inside one organization.

For staff+ development cohorts, architecture groups, platform teams and technical leadership programs.

  • Everything in Book + Field Kit
  • License for up to 10 readers
  • One organization
Choose Team, $149

Secure checkout on Gumroad. Instant PDF and EPUB download. Lifetime updates.

The hardest situations a technical leader meets

Every scene is a composite, assembled from patterns rather than from any single team, person or company. Each one runs through Surface, Shift and Secure, and ends with the artifact that carries the decision and the sentence to say.

Chapter 13

The migration no team wants to pay for

  • Six teams agree the platform is better; six months later two have moved
  • Name the adoption-cost owner and the decommission owner
  • A three-wave plan with funded first movers and a decommission date
  • When the sponsor declines: record the decision and stop absorbing the gap

Chapter 12

The deadline you cannot hit

  • A date made public before anyone counted App Store review and rollout
  • Keep the date, keep the scope, or ship the binary early behind a flag
  • Each option with a risk owner and a recovery path
  • When the sponsor picks the option you argued against

Chapter 14

Green on the dashboard, red in reality

  • Every team is green, and the feature has never run end to end
  • A three-line truth test
  • An outcome evidence table and status definitions tied to proof
  • Locally complete, integration unproven

Chapter 16

The incident

  • Forty messages in the channel and nobody in charge
  • Take command without knowing the fix: roles, tempo, next update
  • Mitigation before understanding
  • A systems postmortem that ends at one primary control and its owner

Chapter 17

The conflict with someone right too often

  • The strongest engineer leans back and the review goes quiet
  • Every objection names its failure mode and says blocker or preference
  • Reversible calls settled by replaying production traffic in staging
  • Holding one line when a sponsor's pressure keeps returning

Chapter 20

The review where the evidence was missing

  • The review that decides your level is mostly over before you walk in
  • A ledger kept while the work is happening
  • A missing-proof field that keeps each claim honest
  • Calibrate the claim against evidence, not memory

What is inside

  1. 1The engineer who was right and lostp. 12
  2. 2Responsibility without controlp. 15
  3. 3The decision is made before the meetingp. 18
  4. 4Find the hidden decisionp. 25
  5. 5Map power before you arguep. 30
  6. 6Read the incentive conflictp. 34
  7. 7Credibility and decision rightsp. 39
  8. 8Pre-alignment is not politicsp. 44
  9. 9Strategy that can be adoptedp. 49
  10. 10Architecture alignment and decision systemsp. 53
  11. 11Turn ambiguity into executable workp. 58
  12. 12Scope, risk and deadline negotiationp. 62
  13. 13Lead migrations when the cost is localp. 68
  14. 14When green status hides red realityp. 74
  15. 15Escalation without status warfarep. 80
  16. 16Incident leadership when the system failedp. 86
  17. 17Conflict with high performers, product and executive pressurep. 91
  18. 18The weekly operating systemp. 97
  19. 19The thirty-day repairp. 101
  20. 20The evidence built before the reviewp. 104
  21. Appendix: the artifact systemp. 108

Books for tech leads and staff engineers: where this one fits

The established books map the territory of staff-plus and management work: Camille Fournier's The Manager's Path, Will Larson's Staff Engineer and An Elegant Puzzle, and Tanya Reilly's The Staff Engineer's Path. Before the Room names them in its further reading as the ground it operates inside.

Its own lane is narrower: the decision before the meeting, and the artifact that keeps it decided. Decision records, stakeholder maps, escalation briefs and postmortems are established practice. What the book adds is the sequence that connects them, Surface, Shift and Secure, and 16 templates that each come with a completed example.

Among my own books, it sits between two others.

  1. Ticket Taker, Outcome Owner. The companion on the individual level: vague feedback about ownership and proactivity turned into specific, countable behaviors.
  2. Before the Room. The decisions your outcome depends on, when you own the result and not the authority to command it.
  3. Altitude. The technical counterpart: staff-level mobile systems engineering across client, backend, security and reliability.

The 16 templates

The appendix is one system, not a toolbox of unrelated forms. Each template gives what it is, when to use it and when not to, a minimum version for use under pressure, the way it most often fails, a blank to copy and one completed example. Every completed example is an illustrative composite.

  1. 1Hidden-decision worksheet. When one request feels heavier than its wording.
  2. 2Stakeholder and incentive map. When a cross-team proposal keeps getting blocked.
  3. 3Decision-rights map. When nobody can say who can decide, or a decision keeps reopening.
  4. 4Decision-rights transfer. When the same class of decision keeps landing on you.
  5. 5Pre-alignment plan. When a big review is coming and you want it to ratify, not discover.
  6. 6Architecture decision record with reopen criteria. When an architecture or security call keeps getting relitigated in chat.
  7. 7Three-option scope memo. When there is a deadline you cannot hit, or pressure for a date.
  8. 8Strategy one-pager with adoption triggers. When a strategy is admired and not adopted.
  9. 9Outcome contract. When several teams agreed to a goal and done means five things.
  10. 10Migration wave plan. When no team will fund a migration because the cost is local.
  11. 11Weekly operating-system checklist. When your week is eaten by other people's requests.
  12. 12Outcome evidence table and truth test. When a launch is green on the dashboard and you do not believe it.
  13. 13Escalation brief. When you need a decision from above without it reading as going over a head.
  14. 14Systems postmortem. When an incident happened and you want a systems fix, not a blame hunt.
  15. 15Evidence ledger for promotion. When your work might become promotion evidence and memory will not hold it.
  16. 16Thirty-day repair plan. When you finished the book and want one proven repair: all three moves, once, on a single real situation.

Where this shows up on salari.dev

Free articles on this site that point to Before the Room as the place to go deeper.

Early reader reviews

Five engineers with 5 to 15 years of experience in iOS, Android, frontend, mobile, staff and tech lead roles are reading it now. Their reviews appear here in their own words as they arrive.

Read the sample while you wait

Who this is for

This is for you ifyou own an outcome that depends on decisions other people make, and being right has not been enough to move them.

  • You are accountable for a result you cannot order into existence.
  • You were right in the review and still watched the outcome drift.
  • Your name is on a migration, a launch or a date that depends on teams you do not manage.
  • You are a senior engineer, tech lead or staff engineer: the title changes, the gap does not.

Not for

  • Readers who want a list of leadership principles
  • Anyone looking for a way to route around or silence a dissenter
  • Legal, financial or employment advice
The library pathWhere this fits
  1. 01Get foundThe Silent Rejection
  2. 02Build the record and negotiateThe iOS Engineer Playbook · Leverage
  3. 03InterviewThe iOS interview blueprint · The senior signal · Top 300 React Native interview questions · 500 Flutter interview questions · The senior SDET interview handbook
  4. 04Answer practice and live roundsThe 24-hour iOS interview answer book · The 24-hour Android interview answer book · Share your screen
  5. 05Architecture and qualitySwiftUI under load · Mobile System Design blueprint · Security is a feature · The Second Pass
  6. 06Staff systems and ownershipAltitude · Ticket taker, outcome owner
  7. 07Build with AIBuild with your brain on (coming soon)
  8. 08LeadBefore the RoomYou are here
  9. 09ArchitectControlled Change
Portrait of Mike Salari

About the author

Mike Salari

Staff mobile engineer · 500+ technical interviews from the hiring side.

I wrote Before the Room after 500+ technical interviews from the hiring side and 15 years in mobile. I have watched strong engineers get downlevelled for being right and unable to move anything, and this book is the set of moves I wish they had brought into the room.

15 years building production mobile software, with experience across Apple, Adobe, Cisco, Mastercard and Visa.

Read the full story

Before or after you buy

FAQ

Before the Room: questions before you buy

What is Before the Room about?

Before the Room is a 151-page field guide for senior engineers, tech leads and staff engineers who own an outcome that depends on decisions other people make. It teaches three moves, Surface, Shift and Secure, across 20 chapters, with 16 templates that each include a completed example.

Do I have to read it in order?

Read part one in order to get the engine. After that the chapters are close to modular: open the one that matches the situation in front of you this week.

Is this about office politics?

No. The book draws a line between preparing a decision and rigging one, and says plainly where a technique could be used to silence dissent or shift risk onto someone without the authority to hold it.

Is Before the Room a book for tech leads or for managers?

It is written for senior engineers, tech leads and staff engineers who are accountable for a result they cannot order into existence. Its subject is influence without authority, so it works from the seat of someone who does not command the people involved. For the management path, its further reading points to Camille Fournier's The Manager's Path.

What templates are included?

Sixteen, in the appendix, each with a blank to copy and one completed example: hidden-decision worksheet, stakeholder and incentive map, decision-rights map, decision-rights transfer, pre-alignment plan, architecture decision record with reopen criteria, three-option scope memo, strategy one-pager with adoption triggers, outcome contract, migration wave plan, weekly operating-system checklist, outcome evidence table and truth test, escalation brief, systems postmortem, evidence ledger for promotion and thirty-day repair plan.

How is it different from other staff engineer books?

Books such as Will Larson's Staff Engineer and Tanya Reilly's The Staff Engineer's Path map the territory of staff-plus work, and Before the Room names them in its further reading. Its own lane is narrower: the decision before the meeting and the artifact that keeps it decided, worked through three moves, Surface, Shift and Secure.

Who wrote it?

Mike Salari, a staff mobile engineer with 15 years in mobile and 500+ technical interviews from the hiring side.

Share this book

XLinkedInBlueskyThreadsHacker News