A production outage puts a storm cloud over the team. Upper management is thundering because customers are affected. People start looking for cover: some for their heads, some for their asses.
Customer escalations create the same pressure. So do missed deadlines. Executives pacing in Slack, asking for updates every three minutes, feel like lightning strikes landing very close to home.
The pressure changes the team. People type faster, interrupt more, jump to conclusions, and start solving the first problem they can see because movement feels better than uncertainty. Panic does not always look like screaming. In software teams, it often looks like twelve people debugging the same symptom, five theories spreading across five channels, and a leader demanding updates so often that the people fixing the problem cannot think.
Sometimes panic looks like someone turning every possibility into an emergency because they need everyone to understand how serious this is. The team already understands. When the system is on fire, the leader’s job is not to perform urgency theater. The leader’s job is to be the calm.
Calm Is Active
Gravitas is often described as seriousness, weight, or dignity. That is true, but incomplete. In engineering leadership, gravitas is the ability to project useful calm when everyone else is tempted to escalate emotionally.
Useful calm is not detachment, laziness, or denial dressed up as confidence. It is the kind of calm that lets people think again. It turns panic into diagnosis and lowers the emotional temperature enough for the right people to do the right work in the right order.
Not amplifying panic is the floor. A good leader goes further and becomes a stabilizing signal, a beacon of calm in a sea of panic.
That image matters because leadership under pressure is not passive. You are not merely standing there quietly. You are absorbing volatility, reducing noise, and creating the conditions for motion that actually helps. Calm is how action becomes useful.
The Team Already Feels The Stakes
When production is down, the team knows it is serious. When a customer escalates, the team feels the pressure. When revenue is at risk and the CEO is watching, nobody needs you to make the situation more tense.
That is one of the mistakes leaders make during incidents. They confuse emotional intensity with leadership presence. They think the team needs to see urgency. They think repeating the severity proves they care. They think asking for updates every few minutes creates accountability.
It usually creates drag. The people doing the work now have two jobs: fix the problem and manage the leader’s anxiety. That is backwards. The leader should be reducing the emotional burden on the team, not adding to it.
Your job is not to make the team feel the stakes. Your job is to make the incident channel usable.
Incident Leadership Is Attention Management
During a real incident, attention becomes the scarce resource. Intelligence, effort, and caring are usually present. What disappears first is the team’s ability to focus on one useful thing at a time.
Everyone wants to help. Everyone wants information. Everyone has a theory. Everyone wants the problem gone. That creates noise, and noise is expensive when the system is already failing.
Gravitas protects attention by asking the basic questions without drama:
- What do we know?
- What changed?
- What is affected?
- Who owns diagnosis?
- Who owns communication?
- What is the next useful step?
- When is the next update?
Notice what is missing: blame, panic, performance, and the ten-person debate about long-term architecture while customers cannot log in.
Gravitas creates sequence. First stabilize. Then diagnose. Then remediate. Then communicate. Then learn. Order matters because panic collapses the sequence. Everything becomes now, everything becomes equally urgent, and everything becomes everyone’s job.
That is how incidents get worse: the team loses sequence, attention, and the ability to make the next useful decision.
Move Slow Enough To Move Right
I have been through many large production outages. The lesson that stays with me is simple: the bigger the stakes, the clearer and colder your thinking has to be.
Early in my career, I was the on-call person when a deleted database record triggered a series of cascading deletes and removed nearly half of a multi-terabyte data warehouse. The warehouse contained customer information, so the business pressure arrived quickly and loudly.
That kind of incident creates immediate pressure to move. Executives want answers. The business wants reassurance. Everyone wants the problem to be over. But before the team could fix anything, we had to reconstruct what happened, identify the root cause, determine the correct solution, and then begin remediation.
That took hours.
The temptation in a moment like that is to answer too quickly, act too quickly, or give stakeholders more certainty than you actually have. None of that helps the team. The system is damaged. Customer data is involved. The useful thing is not performance. The useful thing is clear diagnosis, honest communication, and careful recovery.
That does not mean you move casually. It means you move deliberately: think slow, move slow, and communicate clearly.
There is an old line from tactical training: slow is smooth, smooth is fast. It fits production incidents perfectly. The point is not slowness for its own sake. The point is smoothness: fewer collisions, fewer missed dependencies, fewer fixes that create a second incident.
That sounds counterintuitive until you have watched a bad fix make an outage worse: the frantic rollback that misses a migration, the hotfix pushed without checking the dependency, the database change made while another person is running a repair script, or the executive update that says “fixed” before anyone has verified recovery.
Fast motion feels good under stress.
Correct motion matters more.
Gravitas gives the team permission to slow down enough to be right. The purpose is not delay, hiding, or avoiding responsibility. The purpose is thinking clearly before making the next move.
That is leadership under pressure.
Communication Is Part Of The Fix
Calm does not mean quiet. In a crisis, silence creates its own panic. If stakeholders do not hear from you, they will invent a story, usually a worse one.
Gravitas communicates clearly, briefly, and predictably: what happened, what is affected, what is being done, who owns the next step, and when the next update will come.
You do not need every answer to communicate well. You need to be clear about what is known, what is unknown, and what is happening next. That kind of communication gives stakeholders enough information to stop thrashing and gives the team enough cover to focus.
The leader becomes a buffer. Information passes through, but panic does not.
Calm Builds Trust Before The Incident
You cannot fake gravitas during the outage if you have practiced volatility all year. The team already knows your pattern. They know whether you blame first or diagnose first, whether you protect attention or demand constant reassurance, and whether you stay clear under pressure or become another system they have to manage.
Gravitas is built before the crisis: in sprint reviews, missed commitments, hard conversations, executive escalations, and the ordinary moments where something goes wrong and the leader chooses clarity over theater.
The outage reveals what you have practiced.
If you practice panic in small moments, you will not magically project calm in large ones. If you practice calm in small moments, the team will trust it when the stakes rise.
That trust matters. When the leader is steady, the team borrows that steadiness. When the leader is clear, the team can orient. When the leader protects attention, the team can work.
That is the practical value of gravitas. It makes the incident channel usable when pressure wants to turn everything into noise.
Be The Calm
That is why gravitas matters. It is not about looking impressive, sounding serious, or pretending you are unaffected. It is about becoming a stabilizing force when pressure tries to scatter the team.
Do not amplify panic, but do not stop there. Project calm. Create order. Protect attention. Communicate clearly. Move deliberately. Give the team enough steadiness to think again.
When the system is on fire, the team does not need your fear. They already have enough of their own.
They need you to be the calm.
Receipts
- Data warehouse incident: Early in my career, a deleted database record triggered cascading deletes that removed nearly half of a multi-terabyte data warehouse containing customer information.
- Incident pressure: The team had to reconstruct what happened, identify the root cause, determine the solution, and begin remediation while business pressure was high.
- Lesson: High-pressure incidents punish premature certainty. Clear diagnosis, honest communication, and careful recovery matter more than fast theater.