What does it mean that identify the system before trying to change it?

Map the current system completely before intervening. Most system change efforts fail not because the intervention was wrong but because the change agent misidentified the system — addressing a visible subsystem while the actual driver sits in a different, invisible part of the organization. System identification requires mapping the boundaries (what is inside and outside the system), the components (what elements interact to produce the outcome), the connections (how elements influence each other), and the dynamics (how the system behaves over time). Without this map, intervention is guesswork.

Example: A fintech company, Ledger, experienced a puzzling problem: feature requests from enterprise customers took an average of nine months to ship, but internally scoped features shipped in six weeks. The product VP assumed the problem was in the engineering pipeline and hired a program manager to accelerate enterprise feature delivery. Nothing changed. A systems mapping exercise revealed the actual system: enterprise feature requests arrived through sales, were translated by a solutions architect into a specification, reviewed by legal for compliance implications, approved by a product committee that met monthly, prioritized against the internal roadmap by the VP, assigned to a team, developed, reviewed by the solutions architect for fidelity to the original request, tested by the enterprise customer in a staging environment, and deployed. The nine-month timeline was not an engineering problem — engineering was the fastest part of the pipeline. The bottlenecks were the monthly product committee (which added four to six weeks of queue time), the legal review (which added three to four weeks because the legal team was shared across all product lines), and the customer staging review (which added four to eight weeks because enterprise customers had their own internal approval processes for testing). The program manager had been optimizing the wrong subsystem. When the product committee moved to biweekly meetings, legal review was embedded in the solutions architecture phase rather than sequenced after it, and customer staging was parallelized with internal QA rather than sequenced after it, the average timeline dropped to fourteen weeks.

Try this: Choose a system you want to change. Before designing any intervention, create a system map with four layers: (1) Boundary map — draw a circle around everything inside the system and list what is outside. Include upstream suppliers (who provides inputs?) and downstream consumers (who receives outputs?). (2) Component map — list every actor, process, decision point, and resource inside the boundary. Do not simplify — the components you leave out are often the ones driving the outcome. (3) Connection map — draw arrows between components showing how they influence each other. Label each arrow: information flow, material flow, authority flow, or incentive flow. (4) Dynamics map — identify the feedback loops (reinforcing and balancing), the delays (where time passes between cause and effect), and the accumulations (where things build up before being processed). Compare your map with two or three people who operate within the system. Their maps will differ from yours — the differences reveal components and connections you missed.