The squad behind all the other squads

A supermarket with a technology company inside it

Downstairs from our desks on Elizabeth Street in Surry Hills was a tiny Woolworths Metro that felt part shop, part technology laboratory.

The office stretched across five levels, but that downstairs space was where the building’s personality collected. People met informally, played table tennis and gathered around a stage for regular technology talks. Internal teams presented there. External speakers visited. The frontend group helped host Angular discussions and meetups.

Inside the small shop, new retail ideas could be explored in something closer to a real environment. I remember experiments around recognising products without traditional scanning. They were experiments, not a claim about what eventually reached customers, but the setting made the intent obvious.

This was a major retail company investing seriously in technology.

I joined Woolworths Group in March 2019 as a six-month contractor and Senior Frontend Engineer. The technology organisation worked through autonomous, Scrum-oriented squads whose makeup changed with the problem: frontend and backend engineers, QA and shared project management working together around a product area.

The office showed how seriously Woolworths treated technology. Helios showed how that investment reached the code.

Not every squad built features

Helios was an unusual squad.

There were three frontend engineers, including me, with the Head of Frontend Engineering working directly alongside us and close involvement from the Head of Backend Engineering. We were occasionally described, with a wink, as the “ninja developers.” It was never a formal title, which is probably for the best.

Most squads delivered work inside the existing path. Helios was often asked to build the path first.

We explored frontend architecture, modernised foundations and took on difficult problems before they spread across several product teams. We would build the first real implementation, test it against an e-commerce journey, document what we had learned and help another squad continue from there.

That distinction mattered. Helios did not own the entire Woolworths Group e-commerce frontend, and the architecture was never the work of one engineer. The squad’s strength came from experienced people challenging one another and senior engineering leaders being willing to solve problems beside us.

Being asked to solve the first version came with a second responsibility: make sure we were not the only people who could understand it.

Building the first version so someone else could build the next ten

Our first implementation was not the finish line. The work was complete when another squad could understand the architecture and take it forward.

The rhythm was practical. Establish a foundation. Apply it to a real journey. Find where the idea bent or broke. Document the decisions. Then run a technical walkthrough, often for an hour or two depending on the complexity, and hand the pattern to the people who would live with it.

Helios worked this way across initial implementations and architecture for major e-commerce surfaces: a homepage connected to a headless CMS, product pages, checkout and shared frontend foundations.

We were not claiming permanent ownership of those pages. The first version existed to make the architectural direction concrete. A reusable architecture is not reusable simply because its code lives in a shared library. Another team has to understand it well enough to trust it.

Documentation and teaching were therefore part of delivery, not administration left until everyone had forgotten why the decisions were made.

That model worked well until the architecture had to run somewhere much of the original frontend code did not expect: the server.

Rendering the shop before the browser arrived

We introduced Angular Universal server-side rendering gradually across the e-commerce experience.

On paper, rendering earlier sounded straightforward. In a large browser application, it uncovered years of reasonable assumptions: direct access to window, browser storage, DOM measurements, client-only services and third-party code that behaved as though a browser must always exist.

There was no useful giant switch marked “SSR.”

We worked through the affected areas incrementally. Produce a meaningful server-rendered result where possible. Avoid browser-only behaviour on the server. Activate or replace that behaviour when the application continued in the browser. Then take the lesson into the next surface.

The direction supported faster initial delivery, perceived performance and search visibility. Page speed also mattered commercially in e-commerce, but I will not attach invented conversion or performance figures to the work.

What I remember most is how the difficult moments were handled. When SSR exposed a stubborn assumption, nobody threw it over a departmental wall. The senior frontend and backend leaders pulled up their sleeves and worked through it with the squad.

Angular Universal did not solve those problems for us. It made them impossible to ignore, and collaboration made them solvable.

Rendering the page earlier helped it arrive sooner. Shared primitives helped ensure every squad did not rebuild that page differently.

A design system trying to travel further than one squad

I brought strong opinions about reusable interface architecture from earlier e-commerce work. Large pages become easier to reason about when they are composed from smaller responsibilities, and atomic-design ideas gave us a useful guide without becoming a rigid taxonomy.

We worked with the design team to establish primitive UI elements in shared libraries and compose larger page structures from them. The interesting work was rarely creating the first button. It was keeping design and implementation aligned while giving several squads enough flexibility to build different journeys without producing a new local interface language each time.

The component library began prompting conversations beyond the immediate e-commerce teams. Woolworths Business and Rewards were among the areas where wider reuse was discussed and explored.

We did not complete that broader adoption during my six-month contract. I would rather say that plainly than turn an ambitious conversation into a group-wide design-system launch that did not happen.

Still, the conversation changed the scale at which we thought about the library. A component created for one journey might become a shared piece of language for several parts of Woolworths Group, but only if ownership, design intent and adoption travelled with the code.

I was not arriving at those decisions empty-handed.

Bringing old lessons into a much larger system

Appliances Online had taught me to think about e-commerce performance as part of architecture rather than a final optimisation pass. It had also taught me what happens when a frontend platform grows across years, teams and framework changes.

That experience helped me recognise familiar risks earlier at Woolworths Group: page-level decisions becoming platform conventions, shared code without clear ownership and performance work that needed cooperation across frontend and backend boundaries.

Dan Murphy’s added a more specific product lesson. I had previously worked with checkout and pickup-slot selection, where choosing a date was followed by a practical time window such as 9 a.m. to 11 a.m. or 11 a.m. to 1 p.m.

Dan Murphy’s was part of Woolworths Group at the time, but its technology operation and teams were separate. I did not copy an internal implementation from one system into another. I brought an understanding of the interaction and the questions it creates into Woolworths Group checkout work.

That is one of the quiet advantages of consulting. A solution learned in one environment helps you recognise the shape of a problem earlier in the next.

The most valuable part was not carrying an old answer into a new company. It was learning how to turn experience into something an entire squad could use.

Architecture that leaves the room

I am proud of the openness around architecture during those six months.

Experienced technical people worked through hard problems together. Senior engineering leaders stayed close enough to the implementation to understand its friction. Helios influenced direction through working examples, architecture walkthroughs and honest discussion rather than guarding difficult knowledge.

The stage downstairs, the Angular meetings and the handovers to other squads all expressed the same idea: technical knowledge became more valuable when it travelled.

After I completed the contract in September 2019, Woolworths Group offered me a permanent role. I appreciated the offer and the confidence behind it, but I declined respectfully because consulting was still teaching me too much to stop. I wanted to keep experiencing how other organisations approached technology.

It was not a rejection of Woolworths Group. I left grateful for the people, the scale of the problems and the chance to work inside a squad designed to make other squads stronger.

The best architecture team is not the one that keeps ownership of every difficult problem. It solves the problem first, explains the reasoning clearly and makes itself less necessary the next time.