The Problem with Playbooks- Intro Series #3

Early in my time at UBS, we brought in outside consultants to help us think through a significant technology infrastructure challenge. They were credible, experienced, and they came prepared. What they proposed was bring in third-party software vendors, start from scratch, purchase premade platforms and customize them to fit our needs. On paper it had a certain logic to it. In practice it missed something so fundamental that it was almost impossible to explain to people who hadn't run a business like ours from the inside.

You cannot shut down a trading operation while you rebuild its infrastructure. The business doesn't pause while you work. Every day that system is running, people are making decisions that depend on it. And premade software, however well designed for other environments, almost always requires such deep customization to fit the specific way a business actually works that you end up with something harder to support and maintain than what you started with, except now the knowledge of how it works lives outside the firm rather than inside it.

The proposal was credible. The gap was invisible from the outside.

But the deeper problem wasn't the proposal itself. It was the model of how the work gets done. The consultants had conceived of it as a technology project: define the requirements, hand it to an outside team, and come back when it's built. That model has never worked in my experience, not once, in any organization I've been part of or observed closely.

There is no such thing as telling the IT department to go build something and come back when it's done. The front office and operations have to be in the room together, from the beginning, or the thing you build won't fit the reality you're building it for.

The principle I've held throughout my career is that the front office, technology and operations have to work together to achieve any significant goal. Not in sequence. Not through handoffs and sign-offs. Together, from the beginning, in the same conversation. The people who understand the business have to be in genuine dialogue with the people building the systems that support it.

The solution that worked came from occupying the space in the middle.

What eventually solved the problem at UBS was doing the development in-house, with me sitting between the front office and the operations and technology teams. Not managing the process from above, but actually occupying that space in the middle, where I could translate in both directions. I knew the business well enough to have the trust and respect of the front office. I understood enough of what operations and technology were dealing with to have credible conversations with them. The solution that came out of that was one that fit how we actually worked, maintained by people who understood it from the inside, and built without shutting anything down in the process.

I've thought about that experience often since, in contexts that have nothing to do with technology. The pattern repeats itself constantly. An outside perspective arrives with a solution shaped by experience somewhere else. It misses the specific texture of this organization, this team, this moment. Not out of incompetence but out of the structural impossibility of understanding from the outside what can only be known from within. The simple answer is that most consultants are not paid to understand the business but to create a playbook. Playbooks don't work.

The best advisors I've encountered, and the kind I try to be, don't arrive with the answer already formed. They arrive with enough genuine curiosity to understand the specific reality they're working with before they offer anything. That takes longer. It requires the kind of trust that doesn't exist on day one. And it produces solutions that actually fit, built on knowledge that stays inside the organization long after the engagement ends.