I Added a Meeting to Feel Like a Leader

A release broke payments for 10 minutes.

So I added a meeting.

Release retrospective. Every deployment gets a review. Sounds like leadership.

Here's what actually fixed the problem.

I got into the logs with the developer who shipped the feature. It was a high priority release and I wasn't going to sit on the sidelines checking in on Slack. I wanted to be in it with the team. Turns out the third-party payment provider had different config settings in production than in their dev and staging environments.

The fix came from reading logs. Not from a meeting.

But I created one anyway. A release retrospective. Every deployment gets a review going forward. One incident, and I built a recurring process around it. Not because the data told me to. Because it felt like the responsible thing to do.

That's the trap. Reactive process dressed up as proactive leadership.

The Meeting That Was Already Dead

99% of our releases went smooth. Every week the team showed up, confirmed nothing went wrong, and left. I didn't even want to be there. But killing it felt like saying "I'm okay with the risk."

So I kept it going. For about two to three months.

Attendance dropped first. Then the energy. People showed up because it was on the calendar, not because it was useful. The conversations were hollow. Nobody was learning anything. Nobody was catching anything. The meeting was already dead. I just hadn't signed the certificate.

The moment I knew was simple. I didn't want to go. And as someone who is ruthlessly value-driven about where I spend my time and my team's time, that was the signal. If the leader who created the meeting doesn't want to attend it, the meeting has no reason to exist.

The Instinct That Creates Bad Meetings

The instinct after an incident is always the same. Add a review. Add a check. Add a sync.

It feels productive. It feels responsible. Something went wrong, so we're going to make sure it doesn't happen again by adding a process around it.

But here's what that instinct actually does. It converts a one-time incident into a permanent tax on the team's time. That payment config issue was a specific problem with a specific cause. The fix was technical. The prevention was better environment validation. Neither of those required a recurring meeting.

What required a recurring meeting was my need to feel like I was doing something about it.

That's the part nobody admits. Most meetings born from incidents aren't for the team. They're for the leader. They're a way to say "I responded. I added a process. I'm on top of this." The team sits through the meeting every week so leadership can feel informed.

The Alignment Chain

Incidents aren't the only source. Fear is the other one.

You've seen this. Everyone has. The pre-alignment meeting to prepare for the alignment meeting to prepare for the actual meeting where a decision might get made. Three or four sessions deep before anyone in the room is allowed to have a real conversation as a group.

It happens because someone is afraid of being caught off guard. Afraid of presenting something that hasn't been fully packaged. Afraid of disagreement happening in the room where leadership can see it. So every meeting gets a pre-meeting. Every pre-meeting gets a dry run. And by the time the actual conversation happens, it's been so sanitized that nothing real survives.

I've watched teams spend more time aligning on how to present a decision than they spent making the decision itself. The meeting isn't where the work happens. The meeting is where the work gets performed. That's not alignment. That's theater.

The test is simple. If the meeting exists to make the next meeting go smoother, one of them shouldn't exist. Decisions should be made by the people with the context, in the room where the context lives. If that room needs three pre-meetings before anyone feels safe enough to have an honest conversation, the problem isn't the meeting structure. The problem is the culture.

Incident meetings and alignment chains come from different fears but they create the same thing. Process that exists to make leaders feel safe instead of making teams move faster.

The meeting was never the safety net. It was the appearance of one.

In the Trenches, Not in the Way

When that release broke payments, I didn't schedule a meeting. I got in the logs. With the developer. Side by side, working through the problem.

Someone in my comments pushed back on this. "Were you the leader or the hero for reading the logs?" It's a fair question. And the distinction matters.

A hero fixes it themselves. A leader makes sure the team can fix it.

There's a difference between being in the trenches and being in the way. In incidents, I'll get in the logs with the team. Not to take over. To help shape how we think through it. Once we see it, the engineer runs with it.

That's exactly what happened. Once we identified the config issue, the developer took it from there. I didn't fix the bug. I helped navigate to the root cause faster than the team would have gotten there alone. And the next time something similar happens, that developer has a pattern they didn't have before.

The sidelines version of leadership scales poorly. You're "available if needed" but you're not in the work. The hero version scales worse. You fix everything yourself and the team never learns to operate without you. The goal is neither. It's building a team that can think and act without you. That's when you know it's working.

The Real Safety Net

Here's what I've learned about meetings and incidents.

The real safety net was never the meeting. It was staying close enough to the system to get into the logs when it mattered.

That means reading pull requests not to approve them but to understand how the system is changing. It means understanding your deployment pipeline well enough to know where config mismatches can hide. It means having the technical context to jump into an incident and be useful instead of being another person asking for a status update.

Pre-prod gives you confidence. Production gives you truth. The gap between those two is where incidents live. And no recurring meeting closes that gap. Understanding your systems does.

Now I have one test before I create any meeting after an incident. Would this meeting exist if the incident hadn't happened? If no, the fix belongs in the system, not on the calendar.

I added a meeting to feel like a leader. I read the logs and actually was one.

Your team knows the difference. Even if your calendar doesn't.

I write daily about engineering leadership at jonoherrington.com.