Small teams and big systems

Large organizations have operational systems that are genuinely complex — not complicated for its own sake, but because the domains they manage are intricate. Supply chains, infrastructure networks, data pipelines with regulatory constraints. These systems were often built over years, by teams that have since moved on, with requirements that have since changed.

A small consulting team working with these systems needs to be honest about two things.

First, you cannot understand everything. The discovery phase is not about mastering every subsystem. It is about understanding the constraints that matter most for the current problem — the dependencies that cannot be changed, the data that cannot leave certain boundaries, the processes that must keep running during any transition.

Second, the goal is usually not to replace what exists. It is to make targeted improvements that survive contact with the operational reality. A new tool that requires ten workflow changes to adopt will not be adopted. A targeted improvement that slots into the existing process will.

This is why the Discovery Sprint model exists. Before committing to a build, spend time with the system as it is. Document what is actually true, not what the architecture diagram says. Identify the high-leverage points. Then build precisely there.