The CHALLENGE
At Quintiq, we had an unusual scaling problem.
Hundreds of engineers worked in customer-facing business units around the world. Their availability fluctuated between implementations and customer commitments. At the same time, the central Product organisation had limited capacity to develop and maintain our portfolio.
The obvious answer was to use available project engineers to accelerate the product roadmap.
But engineering capacity was not the real constraint.
The constraint was the cost of safely accepting their work into the product.
A relatively small number of senior product engineers carried responsibility for architecture, quality and long-term product integrity. If every external contribution required extensive explanation, review or rework, more developers could overload the people we most needed to protect.
Project and Product engineering were answering different questions. A project engineer needed to solve a specific customer problem against a delivery commitment. Product engineering had to ask whether that capability would work across customers, fit the architecture and remain maintainable for years.
Both perspectives were valid, but they created a structural tension. What was right for one customer and one delivery deadline was not necessarily right for the product.
The operating model had to reconcile the two.
My mandate was to turn variable business-unit capacity into useful product-development capacity while maintaining consistent product and engineering quality at scale.
The operating model
We started with a business-unit pilot around a practical question:
What work could another team take on without creating more Product overhead than the additional capacity was worth?
We selected work for its fit with the Product roadmap and reusable value across customers. That value had to justify Product’s long-term ownership.
I designed the initial operating model and refined it with Product Managers and Business Unit Directors into two paths.
Bounded, ready-to-execute work
Bounded tasks with clear requirements and, where useful, reference implementations.
- Designed for
- Progress without repeatedly drawing senior product engineers into the task.
- Acceptance
- A defined result that meets agreed criteria.
Co-development
Larger capabilities shared by the Product roadmap and a business unit’s customer work.
- Designed for
- Product and business-unit engineers working together.
- Commitment
- Agreed scope, committed people and continuing Product involvement.
Acceptance happened progressively, not simply at handover.
Some work could be specified and handed over. More consequential development required architectural context, trade-offs and product knowledge that documentation alone could not capture.
Incentives & ownership
Align incentives with usable work
Capacity alone did not make the model dependable. For business-unit leaders, customer delivery and presales activity would naturally take priority over optional Product work.
Product therefore funded contributions only when the work was accepted. This gave business units an incentive to commit capacity while keeping the model tied to usable product output rather than effort spent.
That boundary created tension when teams invested significant effort in work that Product ultimately could not accept.
We drew the ownership boundary explicitly:
Business-unit engineers could conduct an initial quality review. Product retained responsibility for deciding whether a change fitted the wider architecture and could be maintained across customers.
Once Product accepted a contribution, it inherited the defects, compatibility issues and future maintenance.
Acceptance was therefore an ownership decision, not merely a quality gate.
Protecting Product capacity
Design for absorption
Every contribution added implementation capacity—and drew on the senior engineers already responsible for Product’s roadmap, architecture and quality.
For qualifying bounded tasks, business units wanted completed work accepted without delay so they could receive the agreed internal payment and redeploy their engineers.
Product needed confidence that the change was safe, reusable and maintainable, while managing competing roadmap priorities.
Accepting too quickly risked inheriting problems. Waiting too long risked losing the people best placed to fix them. Delay or rejection could strain trust even when the engineering decision was sound.
Completion and acceptance were different events.
Finished work could wait for review or an integration window while the architecture moved on and contributors returned to customer projects. If Product then discovered a problem, the original engineer might no longer be available. Repair and integration became more expensive, while the effort already invested increased pressure to accept the result.
Contributors moved in and out with customer commitments, requiring repeated onboarding and coaching. Supporting multiple streams fragmented senior engineers’ attention between review and their own Product work.
The system therefore had two capacities to manage: the capacity to produce change and the capacity to absorb change.
Contributed hours showed how much engineering capacity the programme mobilised. I also tracked the demands that work placed on Product, including after release:
| Group | Measures |
|---|---|
| Flow | Acceptance lead time; time to first Product review |
| Capacity | Concurrent workstreams, including Product’s roadmap |
| Effort | Senior review effort; rework after submission |
| Quality | Defects after acceptance or release |
These measures informed the early audits and quality gates we put in place before Product review: tests, regression and smoke checks, modelling standards and documentation. We also restricted contributions in areas undergoing major redesign. These changes reduced avoidable review work, but could not replace architectural judgment or product knowledge.
Delivery & learning
What scaled—and what did not
The programme focused on work already in the Product roadmap or reusable capabilities needed across customers. After one year, it had brought business-unit engineering capacity into that work through both contribution paths:
After one year of running the programme
Expanded from the initial pilot.
Contributed to Product, including development of a new Rail planning product line.
Accepted through the bounded-work path.
Accepted bounded-work contributions included a merged rostering function, crew-planning usability improvements, and enhancements around depot activity and shipment constraints.
Co-development helped bring a new Rail planning product line to market under a compressed timeline. Product and the business-unit delivery organisation worked closely from architectural design, before any code was written. The project team needed the product as the foundation for customer-specific customisation, making product delivery a dependency for the customer implementation.
As the model matured, the wait for Product review shortened from roughly a quarter to within a sprint. Quality standards and contribution templates also reduced iteration cycles, and we kept refining them as the model scaled.
Yet onboarding and acceptance still consumed senior attention and could create friction with contributing business units. The underlying constraint never disappeared.
Distributed engineering only scales when implementation capacity and acceptance capacity are planned together. Otherwise, senior engineers become the shock absorbers for the operating model.
What I would change today
Product Development in the Age of Automation and AI
At Quintiq, much of the knowledge contributors needed already existed in platforms, standards, libraries and documentation. The cost was applying it consistently at the point of work.
Later, while leading a data science team building enterprise AI systems, I encountered a smaller version of the same problem. My team built lightweight tools that helped engineers navigate standards, libraries, code and working practices, alongside automated checks for routine issues before review. These reduced repeated questions and the load on senior engineers.
The principle is simple: automate repeatable work so scarce expertise stays focused on judgment. The value those tools create must also justify the cost of maintaining them as architecture and standards evolve.
Agentic workflows can make that institutional knowledge easier to apply at the point of work. The real test is how reliably agents can investigate failures, prepare tests and evidence, and resolve straightforward integration issues. Product still has to decide whether the output is safe to own.
An agent can carry the same flawed assumption through code, tests and supporting evidence. More iteration can then make a change appear better supported without challenging its premise.
That makes stopping conditions part of the engineering design. The surrounding system must halt and escalate when repeated attempts produce no new evidence or a decision exceeds the agent’s delegated scope. Autonomy only scales when there is evidence that those controls work.
The lasting question
What is worth building—and what deserves our scarcest expertise?
In an AI-enabled engineering organisation, the architecture of the acceptance system—its validation criteria, evidence, escalation rules, integration gates and ownership—may become as important as the architecture of the software itself.
The real test of scale is how much valuable, reliable change we can accept—and remain accountable for long after it ships.