What Running Taught Me About Building Enterprise Systems

At kilometre 35 of a marathon, your legs want to quit. Your systems: nutrition, pacing and preparation determine whether you finish. Enterprise architecture works the same way.

I did not start as a runner. My first marathon was a mess — no nutrition plan, and a pace strategy that consisted of "run until it hurts, then slow down." I finished, barely. But something clicked. I have run a marathon, many half marathons, and a handful of trail runs across different terrains and elevations. Each one has reinforced a lesson that applies directly to the enterprise systems I build professionally.

The Pacing Problem

In distance running, the most common mistake is starting too fast. The first 10 kilometres of a marathon feel easy, so you push. By kilometre 30, you are in a deficit you cannot recover from. The energy debt compounds, and the last 12 kilometres become a survival march instead of a run. Runners call it "hitting the wall." It is entirely preventable — if you respect the distance from the start.

Enterprise system implementations fail the same way. The first phase — requirements gathering, vendor selection, initial configuration — generates momentum and optimism. The project team pushes hard, accelerates timelines, and commits to aggressive go-live dates. By the integration testing phase, the accumulated technical debt, unresolved data issues, and skipped validations create an energy deficit that no amount of overtime can fix.

The lesson from distance running is simple: pace for the whole distance, not the first quarter. In implementation terms, this means planning for the testing and stabilisation phases with the same rigour as the build phase. The teams that finish strong are the ones that deliberately hold back velocity in the early sprints to preserve capacity for the hard work at the end.

The Nutrition System

In a marathon, you burn roughly 2,500-3,000 calories. Your body can store about 2,000 calories of glycogen. The gap must be filled by taking gels and fluids during the race — at regular intervals, without exception. Miss two nutrition windows, and the bonk is inevitable. I learned this the hard way in my first marathon when I skipped hydration because I "felt fine." I did not feel fine at kilometre 32.

Enterprise systems have their own nutrition problem: data. The system needs a continuous supply of clean, timely data to function. Miss a data feed, and the downstream calculations fail. Miss two, and the quarter-end close becomes a fire drill.

The parallel extends further: just as runners test their nutrition strategy during training (not on race day), enterprise data feeds must be tested under realistic conditions during the implementation (not at go-live). The number of tax technology projects I have seen fail because the data feeds were tested with sample data but collapsed under production volumes is depressingly high.

Trail Runs and Adaptability

Road running is predictable. Trail running is not. The terrain changes — gravel, mud, rock, elevation shifts — and your body must adapt in real time. You cannot run a trail the way you run a road. The pace fluctuates, the effort varies, and the mental model shifts from "maintain speed" to "maintain effort."

Enterprise implementations in the real world are trail runs, not road runs. The textbook methodology assumes a flat road: predictable phases, stable requirements, cooperative stakeholders. Reality delivers terrain changes. A regulatory update mid-implementation, a key team member leaving, a data migration that uncovers quality issues nobody anticipated. The project teams that succeed are the ones that trained on trails: comfortable with variability, willing to adjust pace without losing direction.

The Finish Line Is Not the End

Finishing a marathon does not end at the finish line. The 48 hours after the race: recovery, reflection and adaptation determine whether you can run the next one. Skipping recovery leads to injury, burnout, and months on the sidelines.

Enterprise go-lives work identically. The post-go-live stabilisation period — the first two to four weeks of production operation — is where the real issues surface. The teams that plan for this period, staff it appropriately, and treat it as part of the project (not an afterthought) are the ones that deliver lasting value.

I am still slower than most serious runners. But I finish every race I start. In enterprise implementations, I have the same record. The secret in both cases is not talent or speed. It is systems, pacing, and the discipline to follow the plan when everything in you wants to improvise.