Pull One Layer and Another Moves

Rewrite the process and you surface a tool gap. Reconfigure the tool and you surface an ownership question nobody has answered. Work on the team and you find a process that contradicts what everyone just agreed to. The three are bound together, so a fix to one usually gets quietly undone, or reshaped in ways nobody expected, by the other two. None of that means anything was done badly. It's what happens in a growing business: people, process, and tools keep outpacing each other.

What This Looked Like on One Engagement

A client wanted a fully automated pipeline: at the right moment in their CRM, an AI research notebook would be created and shared with the right people, no human in the loop. We got most of the way there, and then the last step hit a real ceiling. Full automation needed an API tier they weren't on, and even after we cleared that, wiring the trigger to their CRM was more engineering than one step of one workflow deserved.

That's where the usual approaches break down. A tool implementer builds it anyway, because automation is the deliverable. A strategy deck writes "automate notebook creation" and leaves the ceiling for someone else to find. The call we made instead was a tradeoff: automate everything up to that step, and have the system email one named person, who creates and shares the notebook by hand. One small manual step, owned explicitly, instead of a heavy build the team would have to maintain forever.

That's not the plan falling short. It's a process decision (what's actually worth automating) and a people decision (who owns the step that stays manual), made together, instead of assuming the tool could carry all of it alone. Good enough for right now, and a better, faster solution will probably exist by the time it matters.

Why I Won't Scope One Piece at a Time

The right way to do this work is to refuse the premise that you can solve one piece at a time. When I scope an engagement, I don't sell "process improvement" or "tool implementation." I sell the messier and more honest version: we look at the people doing the work, the steps they're supposed to follow, and the systems they use to do it, all at once, and change whatever needs changing in whichever order makes sense for the business. Sometimes that's a tool change first because it unblocks everything else. Sometimes it's a hard conversation about who owns what before any document gets written. Sometimes it's removing automation because the workflow it supports never really existed.

That might sound harder to scope, and it is. It's also the version of the work that actually sticks, because nothing gets fixed in a way the other two layers can quietly undo.