Four engineers, a PHP monolith, and APIs that didn’t exist yet
Delivery, ownership and the work between teams
At a glance
- Team
- Four frontend engineers reporting to me: three focused on modules and pages, one working with the Principal Engineer on the core platform.
- Problem
- Move pages out of a PHP monolith while other teams were still building the APIs those pages needed.
- Approach
- Map dependencies → choose a feasible page group → make a quarterly commitment. Keep a secondary backlog for blocked work.
- Where it stood
- Dependencies and delivery risks became clearer, and two direct reports progressed to the next grade. The new frontend did not reach production during my tenure.
The proof of concept was done
A large PHP monolith had become difficult to maintain. AUTODOC created teams to split domains into microservices while a new frontend platform and microfrontends were being built on top. The frontend proof of concept had already been tested before I joined. The next problem was moving real pages and workflows.
Four engineers, two kinds of work
I managed four frontend engineers. Three worked mainly on page-level microfrontends and features; a fourth worked more closely with the Principal Engineer on the core platform. All four were my direct reports.
Read more
Core platform
The Principal Engineer led the architecture: the frontend engine, shared infrastructure and foundational mechanisms. I coordinated our team’s work with that direction.
Modules, pages and integrations
I owned the team’s delivery work and people management: planning, refinement, cross-team coordination, feedback, 1:1s and performance reviews. The page and integration work had to turn the platform foundations into usable parts of the product.
- Design
- SEO
- QA
↕ Requirements, design and review availability.
- Core platform
- Modules and pages
↕ Data contracts, platform decisions and roadmap dependencies.
- Backend/domain APIs
- UI Kit/shared platform
- Legacy monolith
- Other product teams
What I actually did
Figure out what could move
I identified logical page groups and recovered the old PHP behaviour from documentation, Jira and engineers who knew the system. That meant mapping each module’s data requirements and undocumented corner cases before choosing what could realistically move.
Read more
Find someone who could own the dependency
The Garage API we needed had no owning team at all. I repeatedly escalated across engineering management to establish who could take responsibility. Without an owner, a promised delivery date meant very little, and a fallback did not fully resolve that gap.
Elsewhere, we could negotiate an API contract early, develop against fixtures and plan a legacy PHP data endpoint while the new microservice was delayed. Where there was no workable path, the dependency stayed visible as a blocker.
Plan around reality
Quarterly planning meant mapping page groups to components, APIs and legacy behaviour, then checking QA, SEO, our engineering capacity and other teams’ roadmaps. That gave us a basis for commitments and a secondary backlog when the critical path was blocked. Some dependencies remained unresolved.
Improve how the team worked
We made work items smaller and easier to refine and review. Retrospectives helped us see where work waited, where handoffs broke down and where code review, peer checks and manual QA needed attention.
I used 1:1s, feedback and performance reviews to help people discuss those problems candidly and work on their development. During my time managing the team, two direct reports progressed to the next grade: one from Junior to Mid-level, another from Mid-level to Senior. I supported their progression; the engineering work and growth were theirs.
How I map a page to its dependencies
A simplified model of the process I used. The modules and statuses are illustrative, but the method is the one the team followed.
Read more
A listing page was a group of modules: Header, Car Selector, Tree Catalogue, Listing, FAQ, SEO Links and Footer. Moving the page meant finding data owners and contracts for the whole group, while checking the old behaviour and arranging QA and SEO review.
The difficult part wasn’t frontend code. A module could be implementable while the API it needed was only a roadmap item, or the owning team did not exist yet. We had to work out whether an early contract or legacy data path could unblock it, and what else the team could do if it could not.
TYRES LISTING PAGES.
Illustrative module-to-dependency mapping and status examples, not a historical quarter or a claim about a particular team’s readiness.
Dependency map → select a feasible page group → quarterly commitment.
A ready module does not make a page ready. Missing data ownership or unavailable QA/SEO capacity can block the group; a legacy fallback or secondary backlog keeps useful work moving.
What changed — and what didn’t
The new frontend did not reach production during my time there. Critical upstream services still lacked the ownership or timelines we needed. A later engineering-leadership change and restructuring affected the initiative and the teams involved.
Read more
The work made dependencies and risks easier to see, gave commitments a more realistic basis and improved how we planned and reviewed changes. Early contracts, fixtures and fallback plans let some work progress while other parts remained blocked. Two engineers progressed to higher grades.
Those were meaningful outcomes for the team. The production migration remained unfinished.