By Reginal Campbell · October 27, 2026 · 4-minute read
It Got Better When It Stopped Being Mine
I kept sending the work back. I couldn’t say what was wrong with it.
By the third round of “bring me a rock,” I still couldn’t explain what kind of rock I wanted.
I was leading a team developing a recovery plan for a data program in distress. The program was supposed to bring data closer to users and decision-makers. But delivery had slipped, confidence was wearing thin, and the people it was supposed to help were still struggling to get answers they could use. We had a short turnaround to assess what was going wrong and recommend a way forward.
One of our leads kept bringing versions back for review. None of them landed for me. I could tell them I wasn’t satisfied. I couldn’t tell them what needed to change.
They were working against a deadline. Every review sent them back to work without a clearer target.
During the third review, the lead asked me directly what made this version wrong.
I didn’t have an answer. It was a fair question, and one I should have answered before sending the work back the first time.
Eventually, I told the lead to do their best and we would live with the results. I didn’t step back because I had suddenly become a better leader. I had run out of direction to give.
When the final version came back, it wasn’t the recovery plan I had vaguely been imagining: workstreams, dependencies, governance changes, and a revised delivery schedule.
The team had started with the decisions people needed to make. They showed where users were waiting for data, reconciling conflicting numbers, or trying to interpret information they didn’t trust. Then they organized the recovery work around removing those obstacles.
The technical work was still there. But now there was a reason for the sequence beyond finishing what had already been started.
I had been looking for a more convincing plan to deliver the program. They had built a plan that made the program answer to the people it was supposed to serve.
I found myself following a user’s question through the proposed approach. Could they find the information? Would they understand what it meant? Would they know whether it was current enough for the decision in front of them?
Instead of searching for what was missing, I became interested in how the team had worked it out.
My first reaction was embarrassment. Then relief. Then something I hadn’t left much room for during those reviews: admiration.
The team finished ahead of schedule. The client asked us to present the work to several additional groups, none of which had been part of the original engagement.
That did not mean the program was suddenly recovered. The work still had to change what users could find, understand, and use.
I can’t know exactly how much my stepping back changed the outcome. But I could see what changed in the assignment. The team was no longer trying to satisfy a preference I couldn’t articulate. They were building a way forward around the client’s problem.
The condition I didn’t know I’d set
I understood what the client needed. Somewhere along the way, I had also made my ability to picture the answer a condition of accepting it.
Those are different things.
The team needed to produce a credible path forward. They did not need to reproduce an image I couldn’t bring into focus.
Experience makes that distinction harder to see. We have reasons for our preferences. We remember what failed, what worked, what a senior stakeholder objected to five years ago. Eventually, a familiar approach can start to feel like a requirement.
Then someone brings us a different approach, and we judge its distance from what we expected before we examine whether it works.
I knew how to recognize the parts of a recovery plan. That familiarity should have helped me ask better questions. Instead, I was using a feeling I couldn’t explain as a reason to send the work back.
The irony was uncomfortable. We were trying to rescue a program that needed to get closer to its users. I was making the team’s work revolve around satisfying me.
I was still responsible for the outcome. I needed to challenge the assumptions, test whether the proposed sequence was realistic, and make sure the recommendations addressed the reasons the program was in trouble.
None of that required every good choice to originate with me.
Better than what I pictured
What stays with me is how much more interesting the work became once I stopped looking for myself in it.
I wanted to understand why the team had started with those decisions, how they had chosen what to prioritize, and what they had noticed that I had missed.
During the reviews, I had kept asking them to change the work. Looking at the finished plan, I had questions I actually wanted to hear them answer.
That was a pleasure I had nearly talked myself out of having.
“I always knew they could do it” is sometimes true.
Sometimes we didn’t know. Sometimes the work should change our assessment of the people who made it.
The honest response is to let it.
I had a part in the story. They made something of their own.
About the author
Reginal Campbell writes about enterprise technology, AI governance, leadership, and the systems organizations build to make consequential decisions.