The Lobbi Delivery Team
Operational Systems Engineering
In an early-stage company, every team picking its own tool feels right. The CRM team picks the CRM. The marketing team picks the marketing automation. Finance picks the ERP. Operations picks the workflow tool. Each tool is best-in-class for its function. Each team is happy.
For about 18 months.
Then the customer says "I emailed you about this last week and now I'm getting two different responses from two different people." And nobody can find the original email, because it lives in a tool that doesn't sync with the tool the person responding is using.
This is not a tooling problem. It's an architecture problem.
The tax compounds quietly
The cost of one-tool-per-team is invisible at first because it shows up in three places that nobody adds up:
- Integration cost. Every pair of tools that needs to share data is its own integration. With N tools you have N(N-1)/2 possible integrations. At 14 tools that's 91 possible pairs. Not all need to integrate. The ones that do are never built once and forgotten — they need maintenance every time either tool changes.
- Cognitive cost. Every employee whose work spans two tools has to context-switch between them. The switching costs minutes per task and compounds across thousands of tasks per quarter.
- Customer-experience cost.* Every handoff between two tools is a place where data gets lost, duplicated, or stale. Customers feel it as inconsistency.
None of those costs hit the budget directly. They hit the operations team in the form of growing complexity, the customer success team in the form of escalations, and the customer in the form of friction.
The simple test that prevents most of it
Before any team picks a new tool, run one question through it:
Where does the data this tool produces need to go, and where does the data it consumes come from?
If the answer is "nowhere" — the tool's data lives entirely inside its own boundary — the team can pick whatever they want.
If the answer involves three or more existing systems, the right answer is almost never "buy a new tool." The right answer is usually "extend an existing tool" or "build a thin layer that produces the same outcome." Saving the integration cost up front is worth a lot of feature compromise on the tool itself.
The architectural pattern that scales
The teams that get out of the one-tool-per-team trap usually do it the same way: they define a small number of system-of-record tools (one CRM, one ERP, one ticketing system, one analytics warehouse) and treat everything else as a satellite that has to sync to one of them.
Satellites are allowed to be best-in-class for their function. They are not allowed to become a system of record for anything. That single rule prevents about 80% of the integration tax — because the data flow becomes hub-and-spoke instead of mesh.
The rule is unpopular for the first year. It saves the operation in year three.
With 14 tools you have 91 possible integration pairs. Half of them aren't built. The other half need maintenance every time either tool ships an update.
Sources
Topic clusters