Building a software delivery capability inside a mechanical engineering company

The customer base for irrigation equipment in North America is getting smaller, and the water that equipment moves is getting more closely governed. Both are on the public record, and together they explain why a mechanical engineering company needs a software organisation.

The USDA’s 2023 Irrigation and Water Management Survey, published in October 2024, counted 212,714 irrigated farms working 53.1 million acres, against 231,474 farms and 55.9 million acres five years earlier. Applied water fell 2.8 percent across the period. The resource behind it is declining too: the US Geological Survey put recoverable storage in the principal aquifer under the American irrigation belt about 10 percent below predevelopment levels as of 2019.

Then the rules. The Bureau of Reclamation published its Final Environmental Impact Statement for post-2026 Colorado River operations on July 31, 2026, covering a river that supplies more than 40 million people and 5.5 million acres of farmland. The guidelines it replaces expire at the end of this year, and their replacement is built to be rewritten in roughly two-year increments rather than set once. Western groundwater law is moving the same way, with state agencies able to put a basin under direct metering and extraction reporting.

A rule that gets rewritten every two years is a product requirement. A machine designed around a multi-year tooling cycle cannot absorb it. Software can. That is why the competitive question here has moved from what the equipment does to what it reports.

Every figure above comes from USDA NASS, the US Geological Survey or the Bureau of Reclamation. It is third party research describing the sector this client operates in, not an outcome of this engagement.

The mechanical side of this company’s product is something they have been excellent at for decades. The part that now decides whether the product wins sits on top of it: firmware, connectivity, the services behind the device, the software a customer actually touches.

That is a fundamentally different delivery problem. Hardware ships on a hardware calendar, set by tooling, moulds and physical lead times, and a decision made in a design review gets locked into steel. The practices that make that safe, heavy up-front specification and infrequent integration, are the ones that make software slow and brittle.

An organisation built around one was being asked to run both at once, on the same roadmap, with the same people making the tradeoffs, across two product lines at different levels of maturity. One had a platform programme already assembled. The other was earlier and roughly twice the size, so the harder teaching problem was also the bigger one.

The engineering manager in the programme management office who called us was trying to solve it for four teams. He had the problem diagnosed correctly and the scope too narrow. By the time the programme was running it covered both value streams and a workforce that included three delivery partners, because the dependencies hurting those four teams did not live inside them.

Two value streams, sequenced rather than run in parallel. One product line had a defined platform programme and a team already used to working in cadence. The other was further back and roughly twice the size. We started with the stronger one, in a private SAFe for Teams class built around a participant group the client chose himself.

Starting where the ground is firmest is a choice about who teaches the second wave. It produces a reference group inside the company, so the larger value stream learns from colleagues who have already run it rather than from consultants describing it. Running both at once looks faster on a plan and rarely is. Two half-supported streams generate twice the questions with no internal answer to any of them, and a stumble in either gets read as proof the method does not work here.

The second stream was large enough to need two classes, run back to back rather than spread out, because a shared vocabulary decays fast. Groups trained months apart arrive at their first joint planning event using the same words for different things, and the first two days go on renegotiating definitions. Across the programme, close to a hundred people were enabled.

Enablement from the executive level down. A leadership session first, then a custom workshop built for this company’s specific product structure. Training delivery teams without the people who fund and prioritise their work produces teams fluent in a method their leadership does not recognise. The failure shows up at the first escalation: a team says the work does not fit the increment, a leader who was never in the room hears an excuse, and the cadence loses its first argument.

The workshop ran on their own product structure rather than generic examples. Generic examples let everyone agree in the room and disagree once they are back at their desks. The argument that matters is where one value stream ends and the next begins, and it has to happen while the people who can settle it are still together.

Planning increments facilitated three times, deliberately lighter each time. The first two ran as full on site engagements. By the third, the client needed materially less of us in the room. The reduction was the design, decided before the first event rather than negotiated after the second. Every event a consultant runs beautifully is an event the client has not learned to run.

Embedded coaching for sixteen consecutive months. Continuous, with one lead coach throughout, so the teams built a working relationship rather than a series of introductions. Sixteen unbroken months inside a delivery organisation is where the change actually happens, in the arguments and tradeoffs that never reach a workshop. Rotating coaches resets that to zero each time.

Built for a mixed workforce. About a third of the people we enabled were not employees. They came from three delivery partners, one of them offshore, and sat inside the teams. A planning cadence that only holds when everyone in the room is staff is not a cadence, it is a staff meeting. The programme was designed so the practice survived partner rotation, which shaped how we structured facilitation and who we made certain could run it without us.

Partway through, we deliberately held one class on the previous minor version of the courseware rather than the current release. The class three weeks earlier had run on that version, and both groups were about to plan together for the first time. We wanted them on identical material rather than debugging a version difference during their first shared planning increment.

The framework owner refreshed the certification exam in between. A participant hit the gap and raised it. We explained the reasoning and moved to the current version from the next class forward.

The tradeoff runs both ways. Version currency matters to the individual, because the certification is theirs and follows them to the next job. Continuity matters to the organisation, because the first joint planning event decides whether people treat the cadence as a real operating rhythm or a workshop exercise. We weighted the organisation, we would make the same call again, and we would flag the exam timing up front.

Sequence your value streams, and enable the people who fund them at the same time as the teams. The instinct under this pressure is to move everywhere at once, because the pressure genuinely does apply everywhere at once. The capacity to absorb change does not. Start where the ground holds, then use those people as the teachers. A cadence is a set of agreements about how priorities get set and defended, and teams cannot hold agreements their leadership never entered into.

Put your own withdrawal in the plan on day one, as a named event rather than a gradual fade. The exit criterion that works is a person: someone inside the company certified, visible and holding the room, with the outside coach stepping back to make space for it.

Design for the workforce you actually have. In manufacturers moving into software, a large share of delivery capacity is contracted, and a rhythm that only works with employees in the room breaks at the next contract cycle.

Decide what counts as being on the same page before a shared planning event, and say it out loud. Naming the cost up front turns a surprise into a tradeoff people agreed to.

Eighteen months in, the programme is still running and the client sets its direction.

The clearest read is what they can now do without us. One of their own engineers certified as a release train engineer and took over running the planning increment for one of the two value streams. Our lead coach stepped back that same month, on purpose, to give him the room. Planning increments are a repeating event the company runs rather than a capability it buys in, and engineers book their own training without being asked.