Bit-sized: The Power of Decisive Communication by Eliminating Ambiguity

Improving incident response through structured, ownership-driven communication. How subtle language quirks can undermine confidence and cost revenue and customer trust.

👋 Hey there! You’re reading The Human Side of Tech—where we dive into leadership, engineering culture, and the messy magic in between.
Sounds good? Subscribe here for free to get future posts straight to your inbox (no spam, ever).

This is the first article of my series “Bit-sized”. While my focus is on comprehensive articles, I also want to publish smaller, anecdotal pieces. I hope you’ll enjoy reading this digestion-first format. Let me know in the comments!

Read Time: 5 minutes

---

How clear, action-oriented language accelerates incident response and strengthens team dynamics

When an incident strikes, the difference between a swift resolution and a delay in MTTR¹ often comes down to communication. I’ve observed firsthand how ambiguous language can paralyze decision-making and delay critical actions. This article explores how embracing direct, action-oriented communication makes communication easy—particularly during high-pressure situations.

MTTR stands for Mean Time To Repair. It’s a metric that measures the average time it takes to restore a system.

The Hidden Cost of Ambiguous Language

“We should probably check the database.” “Maybe we could roll back the deployment.” “I think something’s wrong with the API.”

These statements share a common flaw: they identify vague problems without driving solutions. When an engineer uses phrases like “we should” or “we could,” they create a vacuum of responsibility that often results in inaction.

I’ve seen it play out in some incident cases at my current employer. We have an On-call rotation which includes team members from week one. In my experience, both junior and senior engineers can struggle with taking explicit ownership during incidents. Juniors might not yet have the system knowledge and fear making things worse, while some experienced engineers who lack incident management practice can fall into the same hesitation patterns despite their technical expertise.

This hesitation results in significant consequences: extended downtime, unnecessary context-switching for the entire team, and degraded customer experience. What appears as politeness or caution is actually creating ambiguity that prevents forward movement.

Incidents are just one example of how engineering actions carry financial consequences. From opportunity cost to poorly explained tech debt, our decisions (and how we communicate them) ripple across the business. For a deep dive into how to make technical decisions with financial impact in mind, have a read here:

Why Financial Thinking Makes You a Better Software Engineer

Actionable takeaways:

• Immediate: Review your team’s last incident response and highlight instances of ambiguous language. No blame, promise?

• Medium-term: Establish team norms that encourage explicit ownership statements.

• Long-term: Incorporate direct communication training into onboarding team members into On-call roles.

How Polite Language Causes Incident Delays

The conjunctive mode (“we could,” “we should,” “we might”) serves an important social function in regular conversation. However, during incidents, this linguistic hedging undermines action when it's needed most.

Ambiguous language enables what psychologists call the “bystander effect”²—when multiple people are present, individuals feel diminished responsibility to act. As per my example earlier, engineers with less experience of the system often hesitate to claim ownership, especially when they're unsure about systems they're still learning.

Instead of tentative suggestions like “We should probably check the database” effective incident communication requires:

1. Clear statements of intent

2. Named responsibility

3. Specific timeframes

4. Default actions

For example: “I propose a rollback. I'll execute it now unless there are objections in the next 60 seconds.”

Leading by example and shadowing inexperienced engineers in their first few On-Call shifts are a great way to help them shape their finesse in tough situations.

Balancing Formality: When to Be Direct vs. Conversational

While this article advocates for direct communication, context matters. The appropriate communication style should align with the situation’s urgency and impact.

I took the liberty to categorize communication contexts into three zones:

1. Critical Zone: Production incidents, data integrity issues, security breaches

   • Requires maximum directness, explicit ownership, and time-bound actions

   • Example: “If no one vetoes in 30 seconds, I will revert deployment X now. Jane, please verify the database load after the deployment.”

2. Collaborative Zone: Planning discussions, architecture reviews, retrospectives

   • Benefits from a mix of direct proposals and open exploration

   • Example: “I propose approach Y because of reasons A and B. What considerations am I missing?”

3. Community Zone: Team building, knowledge sharing, mentoring

   • Thrives with conversational, inclusive language

   • Example: “I’ve been exploring this approach to API design. What has your experience been?”

Understanding which zone you're operating in allows you to adjust your communication style appropriately.

What to avoid: Treating all engineering discussions with the same communication style, regardless of context or urgency.

Actionable takeaways:

• Immediate: When entering a discussion, mentally identify which communication zone applies.

• Medium-term: Set communication guidelines in specific communication channels such as Incident Calls or Slack Channels—and hold your peers accountable.

• Long-term: Incentivize and celebrate proper usage of direct language in critical contexts. (“John, you did a fantastic job in taking ownership and coordination of this incident!”)

Conclusion: Why Direct Language Accelerates Incident Response

The ability to communicate with clarity and decisiveness represents a significant competitive advantage for engineering teams. By eliminating ambiguity, embracing direct language, and establishing clear ownership, teams can significantly reduce incident resolution times while improving overall effectiveness.

The key takeaways from this article include:

1. Replace conditional language with active commitments

2. Establish clear ownership for every required action

3. Optimize the information-action ratio in critical communication

4. Adjust communication style based on the context's urgency

5. Cultivate a bias for action that eliminates the bystander effect

The next time you find yourself saying “we should probably...” pause and consider the alternative: “I will...” The difference might seem subtle, but the impact on your team's effectiveness will be profound.

---

---

I’d love to hear how you deal with passive language? What has helped you adopting a more action-oriented language? Leave a comment or get in touch with me!

Enjoyed this article? Leave a like and restack it, mentioning your favorite takeaway!

Thanks,

Tim

1. Davidovič, Š. (2020). Incident Metrics in SRE: Measuring and Analyzing Incident Response. Google Site Reliability Engineering.

2. Darley, J. M., & Latané, B. (1968). Bystander intervention in emergencies: Diffusion of responsibility. Journal of Personality and Social Psychology.