I was standing outside a conference room watching my team lie to another team about a database outage. It was day four.

Through the glass door, I could see the engineer on the call, explaining with impressive confidence that our cloud provider was having issues. Any minute now, they said, the vendor would resolve it and services would come back up.

I pulled up the provider’s status page. Green across the board. Checked their Twitter. Nothing. I caught the eye of the engineer leading the response and motioned them outside.

“What actually happened?”

The way they looked at the floor told me everything. Then: “Accidental deletion. We’re working on recovery.”

Here’s the thing about inheriting a team: You don’t just inherit their code and their systems. You inherit their patterns. Their fears. The lessons they learned from whoever led them before you.

My team had learned that mistakes meant consequences. That admitting fault meant exposure. That the safest play was to redirect blame to something faceless—a cloud provider, a vendor, a system “acting weird.” They’d learned this so well that lying to the team we supported felt safer than telling their new boss the truth.

I had about thirty seconds to decide what kind of leader I was going to be.

The Conversation⌗

We found an empty office.

“I’m not mad about the database,” I said. “I’m concerned you felt you couldn’t tell me.”

They stared at their hands.

“I need you to understand something. I’m four days into this role. I don’t know your systems. I don’t know the history here. But I know this: I can’t help you fix problems I don’t know about. And the other team can’t tell us how severe this actually is if we’re feeding them fiction.”

“Previous leadership didn’t react well to mistakes.”

There it was. The inherited culture, delivered in one sentence.

“Okay. Here’s the new standard: You tell me the truth, always. I’ll handle the hard conversations. You focus on the fix. Deal?”

They looked up. “Deal.”

Falling on the Sword⌗

I walked back into that conference room.

“I need to correct something,” I said. “This isn’t a cloud outage. One of our engineers accidentally deleted the pre-production database. We’re working on recovery now, but I need your help: How critical is this to your operations? What’s the actual impact?”

The silence lasted maybe three seconds. Felt like an hour.

Then: “Thank you for being straight with us. Here’s what we need…”

They walked us through their priorities. Which services mattered most. What data they could recreate versus what needed restoration. The conversation became a collaboration instead of a performance.

We got the database back. It took six hours and some creative recovery work, but we got it back.

The Post-Mortem⌗

The next day, I gathered the team in the conference room for our first post-mortem. I’d never run one with them before, so I started by explaining how we were going to do them from now on.

“When we name people in post-mortems,” I said, “it’s only for successes. Who responded quickly. Who had the knowledge to guide recovery. Who communicated clearly under pressure.”

I looked at the engineer who’d led the recovery effort. “You did excellent work getting us back online.”

“For failures, the buck stops with me. I’m the lead. Anything that goes wrong happened on my watch. My job is to figure out what systemic failures allowed this to happen and fix them.”

I watched the team process this. Some looked skeptical. Some looked relieved. All of them looked like they were waiting for the other shoe to drop.

“Here’s what we’re changing. Permissions on production-like environments. Backup verification procedures. Documentation on recovery processes. And most importantly: the expectation that you can always tell me the truth, especially when things break.”

The Timing⌗

Looking back, week one was actually the perfect time for this to happen.

I had no history with this team. No pattern of reactions for them to predict. No baggage about “how we’ve always done things.” When I said “this is the new standard,” there was no previous version of me to contradict it.

Being new meant I had nothing to lose and everything to prove. I couldn’t lean on established trust or authority. I had to show them, in real time, what kind of leader I was going to be.

Culture isn’t built during the smooth times. It’s built in how you respond when things break. And things always break.

What Stuck⌗

That engineer never lied to me again. Neither did anyone else on the team. Not because I’d scared them straight, but because I’d shown them the alternative: honesty gets you help, not punishment.

The other team? They became one of our strongest advocates. Years later, they still reference that incident as the moment they knew they could trust us.

The post-mortem approach stuck too. Name people for successes, take responsibility for failures. It sounds simple, but it changes everything about how teams respond to pressure.

I couldn’t change what my team had learned before I arrived. I couldn’t undo whatever had taught them that self-preservation trumped transparency. But I could show them a different future, starting with one deleted database and one honest conversation.

The bad news: People will test your principles during crisis. The good news: Crisis is when principles matter most.

The job is to be ready anyway.