The Developer Who Stopped Me Mid-Sentence

A couple of years into being CEO of IdeaScale, a company that sold software primarily to government organizations — federal, state, and city — I sat in on a project retrospective with one of our customers. The rollout had been stalled for eighteen months. Someone on the call — let's call him Dan — had been a project manager at a mid-sized city for a decade before going client-side, and had fifteen years of civic tech experience.

The problem, as I saw it, was the customer's leadership. We'd built something technically sound, but had assumed the client's staff would restructure their workflows to match the software. The staff refused. The implementation was dead in the water. I laid out my analysis in the retrospective: the real issue is that the customer's leadership didn't commit to change management. If they'd required the team to adopt the new system, we'd be done by now.

Dan stopped me. He said: that's not what happened. Leadership did require it. The team was told to adopt it. They didn't because — and this is the part you're missing — the people in that department had been burned by three failed IT projects in the last decade. They had a legitimate reason not to trust this one. Calling that resistance "failure to commit" is accurate as far as it goes, but it misses why.

He wasn't defending the staff. He was explaining that my framing — they just didn't want to change — was missing the institutional history that made the resistance rational.

The Pushback I Should Have Accepted Sooner

I pushed back. I said that vendors get brought in specifically because the internal culture can't drive change on its own, and that if you give people an escape hatch they'll take it.

Dan said: that's true. It's also true that if you show up with a three-year timeline and a budget that hasn't been updated since 2014, you can't be surprised when the people who live in that system every day treat you like a threat.

I didn't have a good response to that. I had a defensive response, which is different — the kind where you restate your position more loudly because you can't find the flaw in theirs. But I didn't have a response. And Dan knew it. And I knew that he knew it.

This happens to me sometimes. I have a model of how things work and the model is usually good — it's gotten me here — and sometimes the model has a gap that I can't see because the gap is in the shape of the model itself. When someone points at the gap, my first instinct is to defend the model. The better instinct is to examine the gap.

What I Updated

I moved from thinking the institution is the problem to recognizing that the institution is the people inside it, and those people have reasons for their resistance that are not the same as ignorance or laziness. I still think the project should have moved faster. I still think we were wrong about workflow migration. But Dan's point was that my impatience was aimed at the wrong target — I was frustrated with the symptoms, not the cause.

More specifically: in GovTech, the change you want to make is never just a software problem. It always runs into the accumulated weight of prior failed changes, and that weight is real. Treating it as an implementation detail rather than a structural constraint means you'll keep being surprised when the obvious solution doesn't take.

This seems simple when I write it down. It wasn't simple in the room. In the room, I had a lot of confidence and not enough information, and Dan had more information and less confidence, and the difference between those two things is what made his point land and mine not land.

Why It Stuck

I still think I was right about the outcome we needed. But Dan was right about how the outcome had to be approached. The difference matters. Most of the arguments I lose — and I've lost a few — I lose because I'm correct about the destination and wrong about the route. Dan helped me see that distinction more clearly. The same shape shows up in markets. Investors defend their models the way I defend mine—enthusiasm, anchored priors, a story that almost fits. I wrote about that in my analysis of AI-lab valuations detached from any plausible cash-flow model. The math doesn’t rage or thunder. It simply does not forgive.

This is also why I keep Buddy A in my poker circle. He spent twenty years inside a very different kind of institution, and he has opinions about power and constraint that I find useful even when I don't fully agree with them. The pattern is the same: people with more direct experience of a system see things I don't see, and the cost of not seeing them is higher than the ego cost of admitting I missed them.

I'm still working on the ego part. But the seeing-part is getting better. The same dynamic shows up in institutions I’ve worked with from the outside—city governments, in particular, are missing the FP&A function that would let them notice these gaps before they become year-end surprises. I made the case for embedded FP&A analysts as one structural fix in my piece on the case for FP&A analysts in city government.