Engineering Operating Model

One month to a unified codebase, and direction for a team flying blind

1–2 tickets: in the backlog at any time, for a three-engineer team
4 months: the previous developer lasted before leaving over the same gap
1 person: as the team's only source of work and direction

A critical path draws itself left to right through four milestones, cycling continuously.

Case file

Industry: EdTech
Region: Germany
Service: Engineering Operating Model
Team: Wayne ArendseDelivery & Transformation LeadYurii KotulaCEO & Engineering Leader
Systems: Turborepo monorepo
Next.js admin panel
Node.js and Ruby on Rails backends
Bull MQ workers
Mollie payments
GDPR data lifecycle

Client context

The client runs a digital licensing platform in Germany. The product grew out of a WordPress and WooCommerce build, and the company decided to move it onto a modern Next.js stack while the live platform kept serving learners.

Intelvision placed three engineers to carry that work. What surfaced over the first weeks was not a coding problem. It was the layer above the code. The client had the delivery muscle. It did not have the operating model to point that muscle anywhere.

Business problem

The client's technical lead knew the codebase from the inside and reviewed every change. Planning, delegation and roadmap were a different skill, and they sat with no one. Work reached the team as single tickets, dropped into a Kanban column on request, often with a title and no description.

The texture showed in the day-to-day. An engineer would finish a task, report an empty queue, and wait for one or two more to appear. There were no sprints, no planning, no grooming, and for a long stretch no shared calls. The team could not see past its current ticket, so it could not tell whether the project had six more weeks of scope or six more months. A developer who held the same seat before this engagement left after four months, citing the absence of a managed process.

The stakes

A three-engineer team ran on a backlog of one to two tickets, leaving skilled capacity idle for stretches of each week.
The previous developer left after four months over the same operating gap, putting continuity and re-hire cost at risk.
All work and all direction flowed through a single person, so any absence stalled the whole team.

What was broken

No planning cadence: no sprints, no grooming, no roadmap the team could read.
Tickets issued on request, frequently with a title and no description.
No standing team calls for a long period after the team formed.
Prior attrition traced to the same cause, four months into the earlier stint.

Diagnostic approach

The intervention read the engagement on three levels at once, because a backlog that runs dry is never only a backlog problem.

Strategy
What is the work for?
The client is investing to lift a working product onto a modern stack, likely ahead of a raise. The spend is real, so the direction behind it has to be legible to the people delivering. Name the outcome each phase of the migration is buying; make long-term intent visible to the team, not held by one person; tie ticket flow to a goal the team can see, not to momentary requests.
Operations
Where does the time actually go?
Capacity was lost between tasks, not inside them. Engineers delivered quickly, then stalled waiting for the next unit of work to be defined. Introduce a light planning cadence sized for a three-person team; give tickets enough description to start without a round-trip; add a recurring sync so priorities are set ahead, not on demand.
Technology
Can the system carry the load safely?
The stack was already being consolidated and modernised. The gap was not the code; it was the decision-making wrapped around it. Keep the monorepo consolidation as the stable base for every change; sequence the risky migrations first, so viability is proven early; hold code review as the quality gate it already was.

What changed

The hardest migration was sequenced first, on purpose.
The checkout page was rebuilt from WooCommerce to Next.js with Mollie, ahead of the simpler pages. Checkout carried the payment logic, coupons and legal popups, so proving it first told the client the whole migration was worth completing. That decision came from the engineering seat, not from a plan handed down.
The codebase became one system instead of five.
More than five separate repositories, a mobile frontend, a Node.js backend, a Next.js admin panel, a worker and a government exam scraper, were consolidated into a single Turborepo monorepo with shared internal packages. Duplication went away and the team gained one source of truth. The consolidation took about a month.
The operating-model gap was named as the real constraint.
The diagnostic separated a healthy delivery layer from a missing planning layer. The recommendation was explicit: a three-engineer team at this stage needs a product or delivery manager and a planning rhythm, and that structure is what converts fast delivery into steady progress.

Decisions

Fix the operating model, not just the tickets.
The obvious move was to keep feeding the queue. The engagement instead named the absent planning layer as the constraint, because a deeper backlog on the same broken cadence only delays the next stall.
Infrastructure before features.
Consolidating the repositories produced nothing a learner could see. It went first anyway, because every later change depended on a single, maintainable codebase.
Hardest migration first.
Starting with checkout carried more risk than starting with the landing pages. It was the right order: the piece most likely to fail was proven early, when reversing course would have cost least.

Results

Measure	Before	After
Codebase structure	5+ disconnected repositories with duplicated shared code	Single Turborepo monorepo with shared packages, consolidated in ~1 month
Checkout stack	Legacy WooCommerce checkout	Rebuilt on Next.js with Mollie in ~4 weeks
Planning cadence	No sprints, no grooming, backlog of 1–2 tickets	Operating-model gap diagnosed, planning structure recommended
Roadmap visibility	Direction held by one person, invisible to the team	Named as the core constraint, with a defined path to fix it

Strike Team

Senior engineering leaders find the real constraint in a fixed-fee engineering diagnostic, then stay to fix it. Project rescue, fractional CTO, architecture and business cases.

About the Strike Team