Insight
Capability before Technology
Ask a team what system they use, and they’ll answer instantly. Ask them what capability that system serves, and the room goes quiet.
That gap is worth paying attention to. A tool is a decision made under the constraints of a particular year — the vendors available, the skills on the team, the architecture that was fashionable. A capability isn’t. “Price a policy,” “onboard a customer,” “resolve a complaint” — these don’t expire when the platform underneath them does. They were true before the current system existed and they’ll be true after it’s decommissioned.
This is easy to agree with and hard to design for, because technology conversations are more concrete and more fun than capability conversations. It’s more satisfying to argue about a framework than to sit with the slower question of what the organization must always be able to do, independent of any framework. But the second question is the one that survives the framework debate.
Organizations that skip it tend to rebuild their own understanding of themselves every time the tooling changes — a new platform migration becomes an occasion to relearn, from scratch, what the old platform was actually for. Organizations that name their capabilities once, clearly, and keep the tooling conversation subordinate to it, get to treat every migration as what it actually is: a change in how, not a change in what.
Design for what must endure. Let the tools be temporary — they were always going to be.