The Fourth Conversation

The Conversation That Comes After Empowerment

A few months ago I wrote about why conversations become your most critical tool and three conversations you must master as a director. Since I published that article I caught up with some former colleagues, and had some real discussions about when things go wrong. I realized there is actually a fourth conversation that comes after the Empowerment conversation: Accountability.

With one colleague we had chatted about some challenges they were facing with their team and follow through. I was relating a story about a senior engineer that reported to me a few years ago. He was very good at writing code, but avoided conflict and had poor time management skills. This meant he was almost always late with delivery because he would not challenge when scope changed, or someone asked him to include something else in his delivery.

That’s when my friend asked me “So how did you hold them accountable?”

That is the exact right question and what got me thinking.

Accountability isn’t the conversation you think it is

Most people think the accountability conversation is a difficult one. It can be. When we hear accountability we think of consequences. We think about failure where something has gone wrong and the boss is coming down hard on the person who did or didn’t do something. We’ve all been there.

That’s not it. Accountability is actually the thing that makes empowerment real.

The accountability conversation is where you are checking how your empowerment conversation landed. Was I clear on my expectations around outcomes? Did I define the guardrails appropriately? Did I explicitly delegate authority? Was my team set up for success?

Decision quality vs. Outcome quality

This is the hard thing about Accountability. A really good decision can produce a disastrous outcome. And a bad decision can get really lucky once in a while. The challenge is knowing the difference. Directors who conflate the two will either punish people for reasonable calls that didn’t pan out, or let genuinely bad decision-making slide because the numbers happened to work out. Both create a bad situation.

You can learn more from failure than success. In failure you’re forced to find out what part did not work. But in success you can believe everything you did was great, when in fact some parts may not have worked at all. Failure forces you to face reality. ~ Fred Brooks

A better way is to break it up. Evaluate the decision on its own merits and separately the outcome based on results tied to priorities and business value created.

If you separate the decision quality you can evaluate the process and steps that were used to arrive at the decision. Evaluate the inputs, the risks, cultural needs, prioritization and amount of certainty when the decision was made in order to assess its quality. Did we shoot from the hip, and make a decision based on 35% of the information or did we dig deeper to get to 70%? Then use this as a coaching opportunity to grow your teams muscle around decision making. You are not criticizing the decision, you are looking at what it took to get there so you can teach your team ways to think differently, more critically, to arrive at better decisions.

Similarly if you take the outcome and evaluate it against your business criteria you can see: did it align with priorities? Was the desired business outcome achieved? What was the business value delivered? Is there return on our investment? When you assess the outcome you want to be critical about what was achieved. Not just that we made the shot, but did it hit the target. If so, great! If not, why?

Now that you have analyzed both, bring them together to determine the overall quality. The final review will make your team stronger decision makers and you more willing to empower them to make greater decisions in the future.

Where I got this wrong

Remember that senior engineer I mentioned earlier? I got it really wrong with him.

We were working on a project to deliver a new version of our employee data platform. We’d been working on it for about 4 months and were getting close to a milestone. One day in our delivery meeting the engineer told me he shipped the code to production overnight because testing passed and he did not want to disrupt our stores in our normal change window. Also the Director of Retail Ops called him directly and told him to do it because retail could not afford for a system to be down during store hours.

You are probably asking, “what does an employee data platform have to do with retail operations?” Well, this new platform was going to serve data to the point of sale (POS) and our financial accounting systems in real time. If it was down, then employee data would not surface as needed and would not only require manual intervention but would take the POS down.

We were moving fast and I trusted the engineer. We had to do some clean up with the change management function (change ticket approval after the fact), but everything went off as a non-event. We celebrated and moved on.

Two months later we found ourselves in the same boat. We hadn’t removed the dependency yet between employee data and POS. We shipped like we did the previous release but we missed something. We had a critical failure that took not only the employee data platform offline but also the POS for two days. We were in firefighting mode for a week. We lived out of a war room with food deliveries, rapid fix deployments and constant communication until it was resolved and all systems were online.

I failed to analyze the decision because I was satisfied with the outcome.

What I should have done instead

Playing back just the first part of the story, everything seemed like it turned out fine, so why did I need to review it? This is a common trap directors fall into. They don’t want to “rehash”, “re-litigate”, “re-anything”. They want to move forward.

If there is one thing I’ve learned, it’s that your people will grow when you review and assess each phase of the process. So what do I do differently now? Here is the framework I use:

  1. Review the decision
    • Why was the decision needed? What was at stake?
    • What did we know? When did we know it?
    • What were the alternatives?
    • What if we did nothing?
    • What did we decide?
  2. Review the outcome
    • What happened?
    • Did we follow our processes?
    • Did we follow our cultural norms?
    • How did we deliver business value?
    • Was it aligned to our priorities?
    • Was there return on this investment?
    • What didn’t we know?
  3. Knowing what we know now, would we make a different decision?

You are not looking for places to assign blame or to punish mistakes. You are pausing to look for opportunities for your team to learn and grow.

The part that I forgot until that conversation with my colleague, empowerment without accountability isn’t trust, it’s just checking out. The two only work together.

Have you ever gotten a good outcome from a decision you know wasn’t actually a good call? Or the reverse, a solid decision that still went sideways? I’d love to hear how you separate the two on your own team, and what you do differently once you have. Connect with me on LinkedIn or Substack to continue the conversation.