I found out my team had a reputation about six months after we'd earned it.
Not from a retrospective or a formal review. From a comment in a meeting, said by someone who'd clearly been saying it in meetings I wasn't in.
"The data team are always behind."
The pattern is easier to see now than it was at the time.
The team starts something. A pipeline. A reporting layer. Work scoped against priorities that felt settled. Then the priorities change, not because anyone made a bad decision, but because the business genuinely needed to move.
The team absorbs the change. Pivots. Starts something new.
Nobody sees the cost immediately, because the work simply moves. The bill arrives six weeks later, when everything is half-finished, everyone is tired, and nothing is ready to ship. Then the priorities change again.
After enough cycles, the team is holding unfinished work. The organisation is holding a reputation.
At the time, I believed the problem was the organisation. The priorities changed too fast for any engineering team to deliver against.
That was true. But it wasn't the whole story.
I was absorbing the impact and calling it adaptability.
Adaptability and invisibility aren't the same thing.
What I hadn't done, and what I should have done much earlier, was make the cost of those changes visible.
Not as a complaint.
Not as resistance.
As a shared understanding.
When a priority changes mid-build, the cost is real: the half-finished work, the context lost, the time before the new thing is ready to ship. My team knew that. I knew that. The people asking for the change often didn't, because I hadn't helped them see it.
At one company the situation reached a point where I handed in my notice.
At the time I told myself it was to force the conversation, that I'd tried everything else and this was the only lever left.
Looking back, I think what it actually showed was that I'd run out of ways to influence the situation from the inside. The resignation worked in the sense that it changed the dynamic. But I don't think that says much about my leadership. It says more about how late I'd left it.
The lesson I take from it now isn't "sometimes you have to draw a line." It's that I hadn't built enough shared understanding early enough for the cost to be visible before it became a crisis.
The teams I've seen navigate this well didn't do it by working faster or pushing back harder.
They did it by making the work legible, building enough of a shared picture with the business that a request to change direction came with a genuine conversation about what that meant, rather than an assumption that the team would quietly absorb it.
That takes more courage earlier, which is annoying because earlier is exactly when it still feels possible to avoid the conversation.
I haven't fully solved this one.
But I've stopped thinking of it as a delivery problem.
The reputation wasn't created by slow engineering. It was created by invisible decisions.
My job as a leader isn't just to help the team make good technical decisions. It's to make sure the organisation can see the decisions they're already making.
That's a different conversation. And it tends to start much earlier.