Microservices were supposed to make change easier. For a lot of companies, they did the opposite: services multiply, teams drift into silos, and every change cuts across a myriad of teams.
In a recent episode of the Dear Architects podcast, Luca spoke with Onur, a staff engineer and tech lead at Jumbo, about how they dealt with exactly that. His view is that the âivory towerâ is dead, and that every engineer now needs to think like an architect.
đ Meet Jumbo
Jumbo is the second-largest supermarket chain in the Netherlands and a 100-year-old business. When Onur joined, it ran two big monoliths. Like everyone else, Jumbo moved to microservices. Engineering grew from around 20 people to more than 350, new services appeared every week, and the monoliths were quickly strangled. The result was a very complex architecture where change wasnât easy.
đ Five promotion services and nobody talking
One of the first things Onurâs team did was run a big picture event storming session on the order flow, with business and engineering teams in the room.
They found five different promotion microservices, built by teams who didnât know the others existed. It was Conwayâs law at work. Siloed teams had produced a siloed architecture.
𧊠A simpler core domain chart
Next came Onurâs favourite exercise, a simplified version of Nick Tuneâs core domain chart:
- The team writes down everything that adds cognitive load (infrastructure, features, services, support work) on sticky notes.
- They cluster the notes together. This is where different perspectives show up, sometimes as people using different words for the same thing, like âarticleâ versus âproduct.â
- They capture pain points and proposals.
- They plot everything across the generic, supporting and core layers.
The proposals then become C4 models or ADRs, depending on whether other teams are affected.
With the loyalty team, the exercise turned up more than 20 microservices for a team of 7. Many were small services built because no single source of truth for customers or stores existed at the time. Once one did, they could be consolidated. Six to eight months later, the team was down to around 10.
đşď¸ Diagrams with intention
Jumbo models its architecture with the C4 model in IcePanel. Context diagrams barely change, so they age well. Most of the technical views live at Level 2 (Container), where you can see how applications interact and who owns what. They skip code-level diagrams entirely, because the code changes too fast.
They also donât try to capture everything. Diagrams are built around specific scenarios, like the order flow, with everything else abstracted away.
Those scenarios are also linked to incident management. When Jumboâs 24/7 on-call team gets an alert about search, they might not recognise a service thatâs named after its technology. They can find the search scenario diagram, though, and see straight away which services are probably involved. Because the diagrams get used when production is on fire, teams have a real reason to keep them current. ADRs are linked to them too.
đź Bottom up, not top down
Many teams were originally organised around technology, with names like âthe SAP teamâ or âthe integration team.â Moving to Team Topologies and stream-aligned teams was a long journey, and Onur chose to do it bottom up. Top-down decisions tend to play out like the telephone game, where the message gets lost on the way down.
The approach looked like this:
- Listen first. They sat down one-on-one with key stakeholders and most senior developers and asked what was dragging them down. They repeat this every quarter. The biggest pain point was too many hops between teams to deliver any value.
- Build a shared language. Chapters and guilds made sure everyone understood concepts like stream-aligned, enabling and complicated-subsystem teams.
- Then go to the C-suite for buy-in, and pilot a few subdomains with the business as success stories.
It didnât go perfectly. Early on, Onur wanted every team on board. Then the SAP teams pushed back. SAP is a whole ecosystem, and its natural structure doesnât always fit stream-aligned teams. Instead of forcing it, they found a sweet spot. As Luca pointed out, generic and supporting domains change at a different rate, so itâs fine to treat them differently.
đď¸ Architecture without the ivory tower
At Jumbo, senior engineers already switch between implementation, staff engineer and architect roles day to day. AI makes this more pressing. When code is quick to write, the bottleneck becomes putting changes in the right place so you donât end up with a big ball of mud. That canât depend on a few gatekeeping architects. It has to sit with the teams, through collaborative modelling.
For changes that cut across several domains, Jumbo uses two mechanisms:
- A technical leadership group of staff engineers and architects that meets biweekly.
- Working groups: temporary, time-boxed teams of 6 to 8 weeks, pulled from several streams. When a government regulation landed that touched multiple domains, a working group delivered it without restructuring any stream-aligned teams.
đ¤ A rubber duck in the pipeline
Onurâs rule for AI is to try things in your own work first, and only roll them out once youâve found the value. A recent agentic engineering workshop went well enough that teams are now asking for more sessions. Participants left with their own agent pipeline:
- An analyst agent reads the assigned Jira ticket via MCP and drafts requirements and an action plan.
- A rubber duck agent, acting like a smart senior colleague, challenges the plan and its trade-offs.
- An architect agent checks the plan against existing ADRs.
- An implementer agent writes and tests the code, using skills that encode Jumboâs API guidelines and conventions.
Those skills are what make the difference. Juniors worried about being replaced and seniors thought the output was poor. Now juniors feel more senior because their plans get challenged before the PR, and seniors came round once a central skills repository covered Jumboâs own front-end framework and design system.
Onur is just as clear that you donât need AI for everything. The first question is whether it can be done without it, and more than half the time it can. Jumbo moves slowest with AI in customer-facing systems, faster in internal tools, and fastest in developer experience, where the output is still deterministic code.
đ Conclusion
Onurâs advice for anyone starting a similar transformation comes down to three things. Pick your battles: 70% adoption might be your sweet spot, and this is a marathon, not a sprint. Make sure your engineering culture is ready, with champions and chapters to spread knowledge. And think about hiring, because you canât build stream-aligned teams while hiring for a different mindset. When architecture belongs to the teams, backed by shared language, intentional diagrams and lightweight decision records, it scales better than any ivory tower.
