It was 9:02 AM on Monday.
An emergency message appeared in the engineering leadership group:
PRODUCTION INCIDENT — HIGH PRIORITY
The payments API was intermittently failing.
The product team wanted an immediate fix.
The architecture team wanted a proper investigation.
The business team wanted an explanation.
And the CEO wanted to know why nobody had predicted it.
The Engineering Manager walked into the meeting.
Everyone was already arguing.
Product Head:
We need this fixed immediately. Can the team deploy a workaround in the next 30 minutes?
Engineering Manager:
Before we get into the weeds, let's zoom out for a second.
We have two different questions here:
If we mix those two conversations, we'll probably fix the symptom and miss the root cause.
Architect:
Exactly. We've been treating the timeout as the problem, but the timeout may only be the symptom.
Engineering Manager:
Right. Let's make sure we're solving the root cause, not the symptom.
But I also don't want to spend three hours designing the perfect solution while customers are unable to transact.
So let's not let perfect be the enemy of good.
First, restore service safely.
Then investigate.
Product Head:
I still think we should immediately increase the timeout from 5 seconds to 30 seconds.
Engineering Manager:
I'd like to challenge that assumption, if I may.
What makes us believe increasing the timeout will solve the problem?
Product Head:
Because requests are timing out.
Engineering Manager:
That's the symptom.
The question is: why are they timing out?
Architect:
We've noticed database connection saturation.
Engineering Manager:
Then increasing the timeout could actually make things worse.
We're allowing requests to stay alive longer while the database is already struggling.
Product Head:
Fair point.
Engineering Manager:
I want to push back on that, respectfully.
Speed matters, but the wrong fix under pressure can turn an incident into an outage.
Engineering Manager:
Let's timebox this discussion so we stay productive.
We have ten minutes.
Five minutes to understand the evidence.
Five minutes to agree on the immediate action.
After that, we execute.
Architect:
What about the longer-term architecture discussion?
Engineering Manager:
We'll come back to it.
Let's park that and come back to it, so we stay focused.
Right now, we need to boil it down to the decision in front of us.
CFO:
Before you make a decision, what's the downside of waiting another hour?
Engineering Manager:
That's the right question.
What's the cost of waiting versus the cost of acting now?
If we wait, we potentially lose transactions.
If we act too quickly, we risk introducing another failure.
So let's look for the low-hanging fruit first.
Can we reduce traffic to the affected endpoint?
Can we temporarily disable the expensive query?
Can we scale the database connection pool safely?
Architect:
Yes. The connection pool configuration is the easiest thing to change.
Engineering Manager:
Good.
That's our low-hanging fruit.
It could move the needle without introducing significant risk.
Engineering Manager:
Who can own the configuration change?
Rahul:
I can do it.
Engineering Manager:
Great. I'll own this and keep you posted on progress.
Rahul:
I can also investigate the database issue.
Engineering Manager:
Let's be careful there.
We have three separate workstreams now.
Incident mitigation.
Root-cause investigation.
Long-term remediation.
We need to separate the signal from the noise.
Rahul, own mitigation.
Priya, investigate the database behavior.
I'll coordinate with Product and keep leadership informed.
Priya:
I can also look at the architecture.
Engineering Manager:
I'd love that, but that's outside my current bandwidth, let's prioritize together.
Let's focus your bandwidth on the investigation first.
During the call, one engineer blamed another team.
Engineer:
Their API is always causing problems. They never test properly.
The Engineering Manager paused.
Engineering Manager:
Can we separate the person from the problem here?
Let's not turn an engineering incident into a blame exercise.
We're trying to understand what happened.
Help me see this from your side of the table.
What did your team observe?
Engineer:
From our side, their API started responding slowly.
Engineering Manager:
Good.
That's useful information.
Let's separate the signal from the noise here.
We don't need to decide who's at fault yet.
We need facts.
Architect:
I found something.
The API isn't actually slow.
The downstream database query is slow.
Engineering Manager:
Excellent.
Let's make sure we're solving the root cause, not the symptom.
Walk me through your reasoning on that.
Architect:
The API latency increased at exactly the same time database CPU crossed 90%.
Then connection wait time increased.
Then API requests started timing out.
Engineering Manager:
That's much stronger evidence.
I'd like to take a moment to think that through before I respond.
If that's correct, increasing API timeout would be the wrong solution.
Architect:
Exactly.
Engineering Manager:
Good.
That's why we shouldn't cut corners during incident analysis.
A five-minute shortcut can create a five-hour problem.
The CEO joined.
CEO:
What's happening?
Engineering Manager:
I'll give you the short version.
The API isn't the root problem.
The downstream database is experiencing saturation.
We've identified a safe mitigation and we're testing it now.
CEO:
When will it be fixed?
Engineering Manager:
We're targeting fifteen minutes for mitigation.
Then we'll deep dive into the root cause.
CEO:
Can you guarantee fifteen minutes?
Engineering Manager:
I don't want to give you false certainty.
We can commit to the mitigation effort.
We can't guarantee the outcome yet.
I'd like to set expectations clearly upfront.
CEO:
Fine. What do you need from me?
Engineering Manager:
Primarily alignment.
Let's align on the desired outcome before we dive into solutions.
Our desired outcome is:
Restore customer transactions safely.
Not:
Make the architecture perfect today.
CEO:
We're aligned.
Engineering Manager:
Great.
Let's make sure everyone is on the same page.
Product wants service restored.
Engineering wants service restored safely.
Architecture wants the root cause addressed.
Risk wants no uncontrolled production change.
Those aren't conflicting goals.
The deployment failed.
Rahul:
The configuration change didn't work.
Engineering Manager:
Okay.
Let's go back to the drawing board.
What changed?
Rahul:
Nothing.
Engineering Manager:
Then we need to understand why.
Don't drop the ball here.
We need a clear owner and next action.
Rahul:
I'll investigate.
Engineering Manager:
Good. Keep me in the loop.
Send me an update every fifteen minutes.
Product Head:
Why isn't this fixed yet?
Engineering Manager:
I want to be direct with you about something.
The team is working the problem.
But rushing them won't make the database recover faster.
Product Head:
Customers are waiting.
Engineering Manager:
I appreciate the urgency.
I appreciate the urgency, let's also protect the quality.
If we introduce a second production problem, we'll have made the situation worse.
Product Head:
Fair enough.
Architect:
We could disable the recommendation engine temporarily.
That would reduce database load.
Engineering Manager:
That's interesting.
What would need to be true for this to work?
Architect:
The recommendation engine has to be independently deployable.
And Product has to approve the temporary degradation.
Product Head:
I approve it.
Engineering Manager:
Good.
That's a pragmatic solution.
We're not trying to reinvent the wheel.
We already have a feature flag.
Let's use it.
Product Head:
Customers will temporarily lose recommendations.
Engineering Manager:
Yes.
But we may need to bite the bullet.
A degraded experience is better than an unavailable experience.
CEO:
Agreed.
Engineering Manager:
Good.
Let's get the ball rolling.
The deployment begins.
Then Product changes the requirement.
Product Head:
Actually, can we keep recommendations working for premium customers?
Engineering Manager:
That's a change from what we just agreed.
Are we moving the goalposts now?
Product Head:
I wouldn't call it that.
Engineering Manager:
Fair.
But we need to recognize that we're changing the requirement midway.
If we change scope during an incident, we increase execution risk.
Let's agree on what "done" looks like.
For this incident:
Customer transactions work reliably.
That's "done."
Premium recommendation behavior can be handled separately.
Product Head:
I still think premium customers should retain recommendations.
Engineering Manager:
I understand the business reason.
But technically, I don't think it's worth the risk right now.
Help me understand the constraint you're optimizing for.
Product Head:
Customer experience for premium users.
Engineering Manager:
That's fair.
Here's how I'd build on it.
Let's restore all transactions first.
Then we'll enable recommendations for premium users in a controlled experiment.
Product Head:
Okay.
Engineering Manager:
Great.
We disagree and commit.
We'll move forward with the safer approach.
Two hours later, the incident is resolved.
The team begins the investigation.
Architect:
We found the issue.
A new release introduced an inefficient query.
Engineering Manager:
Interesting.
Let's deep dive into exactly what changed.
Architect:
The query added a join against a large table.
Engineering Manager:
Why wasn't that caught in testing?
Architect:
The test environment has much smaller data.
Engineering Manager:
There's the real problem.
The production incident was only the symptom.
The root cause is our testing model.
Let's separate the signal from the noise.
We shouldn't simply say:
"Developer wrote a bad query."
That's too shallow.
We should ask:
"Why did our engineering system allow a bad query to reach production?"
Engineering Manager:
Let's read between the lines.
What is this incident telling us?
Architect:
Our performance testing isn't representative.
Engineering Manager:
Correct.
Anything else?
Priya:
Our database monitoring doesn't alert us early enough.
Engineering Manager:
Exactly.
And there's another point.
The team optimized for functional correctness, but not production-scale performance.
That's a process problem.
Engineering Manager:
We need to raise the bar.
Going forward, critical APIs need:
Architect:
That's a lot of additional work.
Engineering Manager:
Yes.
But we don't need to boil the ocean.
Let's start with our top five critical APIs.
Architect:
That sounds manageable.
Engineering Manager:
Exactly.
Start small.
Then move the dial.
CEO:
Who owns the remediation?
Everyone became quiet.
The Engineering Manager smiled.
Engineering Manager:
I'll sponsor it.
But each service owner needs skin in the game.
If everyone owns everything, nobody owns anything.
Rahul:
I'll own the payment API remediation.
Priya:
I'll own database performance testing.
Architect:
I'll own the architecture review.
Engineering Manager:
Perfect.
Now we have accountability.
Product Head:
Can we change the organization's release policy?
Engineering Manager:
That's probably above my pay grade.
We need the CTO and Risk team involved.
But I'll get the ball rolling.
I'll prepare the proposal.
Product Head:
Good.
CEO:
You seem unusually calm.
Engineering Manager:
It's not my first rodeo.
I've seen enough production incidents to know that panic rarely improves engineering decisions.
CEO:
Fair.
Engineering Manager:
The trick is to put out fires without becoming a firefighter forever.
Junior Engineer:
Can we skip the load test to save time?
Engineering Manager:
No.
This is exactly where teams cut corners.
We don't need perfection.
But we shouldn't cut corners on the controls that prevent another incident.
Junior Engineer:
Understood.
Engineering Manager:
Let's not let perfect be the enemy of good, but let's also not confuse "good enough" with "unsafe."
The next day, another project manager arrived.
PM:
Can your team also take ownership of this migration?
Engineering Manager:
I'd like to help.
But that's outside my current bandwidth.
We already have three critical priorities.
Let's prioritize together.
PM:
What can move?
Engineering Manager:
The analytics migration can move two weeks.
That gives us enough capacity.
PM:
Works for me.
Engineering Manager:
Great.
Now we're on the same page.
PM:
What about the premium recommendation issue?
Engineering Manager:
Let's circle back after the production metrics stabilize.
PM:
When?
Engineering Manager:
Tomorrow afternoon.
I'll keep you in the loop.
PM:
Perfect.
Architect:
I have a different proposal.
Instead of optimizing the query, we should redesign the entire data access layer.
Engineering Manager:
That's ambitious.
I'd like to challenge that assumption, if I may.
Do we actually need a complete redesign?
Architect:
It would solve several future problems.
Engineering Manager:
Possibly.
But what would need to be true for this to work?
What's the migration cost?
What's the operational risk?
What's the business benefit?
Architect:
The migration would take three months.
Engineering Manager:
Then let's not boil the ocean because of one incident.
Let's fix the query now.
Then circle back to the architecture redesign with proper data.
Junior Engineer:
Could we cache the expensive recommendation data instead?
Architect:
That might work.
Engineering Manager:
Good.
This is where we should think outside the box.
We don't necessarily need a bigger database.
Maybe we need less database traffic.
Architect:
Exactly.
Engineering Manager:
That's a better question.
Friday morning.
Leadership meeting.
CEO:
Status?
Engineering Manager:
Incident resolved.
Root cause identified.
Permanent fix deployed.
Performance testing improved.
Monitoring enhanced.
CEO:
What's next?
Engineering Manager:
We're tracking three outcomes:
Let's define what success looks like before we commit resources.
CEO:
Good.
Engineering Manager:
Before we move on, let's close the loop on this.
What did we learn?
Architect:
Production-scale testing matters.
Priya:
Monitoring needs leading indicators, not just failures.
Rahul:
Architecture decisions need operational data.
Engineering Manager:
Exactly.
Let's close the loop on this before we move on.
And let's document it.
After everyone leaves, the Product Head stays behind.
Product Head:
I have to admit something.
At the beginning, I thought engineering was being too cautious.
Engineering Manager:
That's understandable.
I hear the concern, let's find a path that works for both sides.
Business needs speed.
Engineering needs safety.
Our job is to find the intersection.
Product Head:
You pushed back several times.
Engineering Manager:
Yes.
I want to push back on that, respectfully when I believe we're taking unnecessary risk.
But disagreement doesn't have to become conflict.
Product Head:
I appreciate that.
Engineering Manager:
Same here.
At the end of the day, we need to move the needle, not win arguments.
Product Head:
Agreed.
Engineering Manager:
Then we're on the same page.
The Engineering Manager closed his laptop.
One thought remained:
Leadership isn't about having all the answers.
It's about asking better questions.
Let's zoom out.
What's the cost of waiting versus acting now?
What would need to be true for this to work?
Are we solving the root cause or the symptom?
What does "done" look like?
What constraint are we optimizing for?
Are we moving the goalposts?
What is the signal and what is the noise?
Those questions create better decisions.
And the phrases become natural because they're attached to a situation—not memorized from a vocabulary list.
That's the goal.
Don't try to memorize all 58 expressions at once.
Use this progression.
When you hear:
"We need to discuss this later."
Your brain should start translating it into:
Let's circle back.
When someone says:
"We don't have enough capacity."
Think:
We're facing a bandwidth issue.
When someone says:
"Let's solve the easiest thing first."
Think:
Let's go after the low-hanging fruit.
Take ordinary sentences and upgrade them.
Ordinary
"We need to talk about the bigger picture."
Executive
"Let's zoom out for a second."
Ordinary
"I disagree with your assumption."
Executive
"I'd like to challenge that assumption, if I may."
Ordinary
"We don't have enough people."
Executive
"That's outside my current bandwidth. Let's prioritize together."
Ordinary
"Let's discuss this later."
Executive
"Let's park that and circle back."
Ordinary
"What's the actual problem?"
Executive
"Let's make sure we're solving the root cause, not the symptom."
Ordinary
"Let's finish this."
Executive
"Let's close the loop on this before we move on."
Every morning, pick 3 phrases.
During the day, deliberately use each one.
"Let's zoom out for a second."
"I'd like to challenge that assumption, if I may."
"Let's agree on what done looks like."
"Let's separate the signal from the noise."
"What's the cost of waiting versus acting now?"
"Let's not boil the ocean."
"Help me see this from your side of the table."
"Let's timebox this discussion."
"I'll own this and keep you posted."
Every day, answer this imaginary situation aloud:
Your team wants to delay a release by two weeks because the solution isn't perfect. The business wants it tomorrow.
Your answer must contain at least 5 expressions from your list.
For example:
"Let's zoom out for a second. I appreciate the urgency, but let's also protect the quality. I'd like to understand what constraint we're optimizing for. Let's separate the must-haves from the nice-to-haves. I don't want perfect to become the enemy of good. Let's agree on what 'done' looks like and then timebox the remaining work."
Don't read it.
Speak it.
Replace each ordinary sentence with a leadership phrase from your vocabulary.
Rule: Don't use the same phrase twice.
Imagine you're in an architecture review.
The team says:
"We should completely rewrite the platform."
You want to challenge them without sounding negative.
Use at least 6 expressions.
You could start with:
"I'd like to challenge that assumption, if I may..."
Continue for 60–90 seconds.
Two engineers are arguing.
Engineer A says:
"This happened because their team didn't do their job."
Engineer B says:
"That's completely unfair."
You are the Engineering Manager.
Respond using at least 5 expressions.
You should include:
CEO:
"Why can't we just launch tomorrow?"
You believe launching tomorrow is risky.
Respond in 30 seconds.
You must use:
For one week, whenever you are about to say one of these:
"Let's discuss."
replace it with:
Let's circle back.
"I don't have time."
replace it with:
That's outside my current bandwidth.
"I disagree."
replace it with:
I'd like to challenge that assumption, if I may.
"Keep me updated."
replace it with:
Keep me in the loop.
"Let's start."
replace it with:
Let's get the ball rolling.
"This is easy."
replace it with:
That's low-hanging fruit.
"Let's investigate."
replace it with:
Let's deep dive.
"Don't make this too complicated."
replace it with:
Let's not boil the ocean.
Set a timer for 5 minutes.
Imagine you're running a project that is:
Give a five-minute leadership update.
You must naturally use 10 different expressions.
No notes.
No reading.
No stopping.
This is where passive vocabulary becomes active vocabulary.
At the end of every workday, ask yourself:
Example:
You said:
"We don't have enough time."
Tomorrow say:
"That's outside our current bandwidth. Let's prioritize together."
You said:
"I disagree."
Tomorrow say:
"I'd like to challenge that assumption, if I may."
You said:
"We'll fix it later."
Tomorrow say:
"Let's close the loop on this before we move on."
You said:
"Let's not overcomplicate this."
Tomorrow say:
"Let's not boil the ocean."
You said:
"I'll take care of it."
Tomorrow say:
"I'll own this and keep you posted on progress."
Tomorrow, imagine you are leading a meeting with:
CEO + CTO + Product Head + Architecture Head + Engineering Leads
The project is six weeks late.
The business wants it launched tomorrow.
Architecture says it's unsafe.
Product says customers are waiting.
Engineering says the requirements keep changing.
Your job:
Give a 3-minute leadership response.
You must naturally include at least 15 expressions from your vocabulary.
You cannot read the list.
You cannot say:
"I'm using an idiom here."
It should sound like normal leadership language.
Don't aim to sound "fluent."
Aim to sound precise.
Instead of:
"I disagree."
Say:
"I'd like to challenge that assumption, if I may."
Instead of:
"We don't have time."
Say:
"That's outside my current bandwidth. Let's prioritize together."
Instead of:
"Let's talk about the important thing."
Say:
"Let's separate the signal from the noise."
Instead of:
"What's the point?"
Say:
"Let's align on the desired outcome before we dive into solutions."
Instead of:
"Why are we doing this?"
Say:
"Help me understand the constraint you're optimizing for."
Instead of:
"Let's fix the real problem."
Say:
"Let's make sure we're solving the root cause, not the symptom."
Instead of:
"Let's just do it."
Say:
"Let's not let perfect be the enemy of good."
And eventually, you won't translate these phrases in your head.
You'll simply think in them.
That's the goal.