The Pre-Read

I was right about everything. That was the problem.

The project had started six months ago, and this was my first meeting. It was also my first IT project, and I badly wanted to add value. The team was at an impasse. So I listened to the project team. I listened to the engineering team. I listened to the operations team. They were all saying the easy, neat things.

Project Team: This is a change management problem.

Engineering Team: This is a training and accountability problem.

Operations Team: This is working great. We’ll get better over time.

And from that, nothing made sense. I had no assumptions. I hadn’t chosen a side. I needed to see, to observe first hand, to push through the rhetoric and figure out what was going on.

So I hopped a flight to Georgia and sat down to observe next to the teams that were using this new technology.

What did I find? The tool hadn’t been built for 90% of use cases. It had been built for 40%. The teams were doing what they could with the 40%, and their adoption of that piece was actually really high. But if we wanted this thing to work, we had to build the rest.

I had my answer. And I was proud of it.

So I flew back to LA and built the presentation. The engineering group had built for 40% of the use cases. Here were the gaps. Here was the proof. Before I took it to the leadership team, I gave my senior leader a pre-read.

She told me it was “personally offensive”.

Not the data but the framing. I had reduced six months of engineering work to a number that made them look like they’d failed, without one ounce of credit for how hard the thing was they were trying to build. I’d been so pleased to have figured it out that I didn’t think about how it would land.

She caught it before I walked into the room. If I’d delivered it the original way, no one would have been able to hear it. The engineering team would have spent the whole meeting defending themselves, and the truth, which could fix the project, would have gotten lost. Being right wouldn’t have mattered at all.

Wasn’t I building the same kind of easy, neat story that I’d flown to Georgia to investigate?

The three teams had each handed me a neat, easy story that kept the problem off their desk. And then I’d done the same, a neat, easy story that put the problem squarely on engineering. “They only built 40%” was just the gist. I’d stopped at the surface, same as everyone else.

So I went back. I rebuilt the story, this time tracking the actual use cases, documenting the gaps, and crediting what had been built and why the rest was hard. Then I sat with the project and engineering teams, not across from them, and we prioritized the work together.

This was the first line of business to use this tool, and with its success we had a blueprint for the rest. After the next year, all lines of business had launched. All 20k front-line teams were adopted at more than 90%, an industry-leading rate.

But we only got over that first hump because I brought the facts back without the blame.

Going to the front got me the facts. Getting them heard was the harder part.

When you finally get to the truth, are you delivering it so people can hear it?

To read attentively – not to be satisfied with “just getting the gist of it.” And not to fall for every smooth talker. – Marcus Aurelius