In every engineering organisation I’ve been part of, I’ve noticed two parts that tend to work in very different ways.
Certain principles that apply to one don’t necessarily apply to the other. For this reason, I think it is useful to explicitly acknowledge the difference.
I think of them as two layers of a cake.
Top layer
The top layer is the software product as experienced by the user.
This layer is largely driven by the vision and priorities of product managers and product leaders.
It is also subject to constant experimentation.
In my experience, one of the hardest problems in product development is finding product-market fit. This requires teams to experiment, learn, and sometimes pivot quickly as they adapt to the market.
When the product organisation is mature enough, it will also follow a product lifecycle that includes retiring features when they no longer provide enough value or even become detrimental to the user experience.
The main value these teams aim to deliver is speed and user experience.
Bottom layer
The bottom layer is the software infrastructure on which top layer is built.
Depending on the company, this might be a relatively thin integration layer with external services, products, and libraries. For others it can be customised for the specific business (where there is no suitable off-the-shelf solution). And lastly some companies have technology, as their competitive advantage and key differentiator.
The quality of the work in the bottom layer is what enables top layer teams to move quickly without constantly having to worry about the underlying foundations.
The main value here is reliability.
About Team Topologies
If you are familiar with Team Topologies:
Team Topologies, 2nd Edition: Organizing Business and Technology for Fast Flow of Value — Manuel Pais and Matthew Skelton.
I see the top layer as being primarily composed of stream-aligned teams, supported by some platform teams.
Basically every team tightly coupled with the business.
The bottom layer is more likely to contain complicated-subsystem teams, platform teams, and enabling teams.
This isn't a strict mapping, of course, but I find the distinction useful when thinking about how engineering organisations should be structured.
The type of engineer
The engineers in top layer teams need very strong product skills.
Their engineering skills should be broad. They should be customer-centric and look at data almost as closely as their product counterparts. They should enjoy being involved in user research and understanding the problems behind the requirements.
They should also be able to contribute ideas and direction, leveraging their unique engineering perspective to understand not only what is possible, but what might be particularly easy or particularly hard to build.
The engineers in Bottom layer are different.
At this level, engineers tend to be more specialised, with deeper expertise in areas such as systems design, architecture, distributed systems, infrastructure, or particular technologies.
In my experience, product management also plays a different role here. Dedicated product management can sometimes add less value, while strong engineering leadership can be more appropriate for driving the work.
What is fundamental, however, is that bottom layer leadership works very closely with product and engineering leadership in the top layer.
Together, they need to:
- decide whether a particular capability belongs in the top layer or bottom layer
- ensure that the bottom layer investments are actually aligned with the needs of the top layer
- determine how work between the two layers should be synchronised or deliberately decoupled
- make sure that the abstractions created in the bottom layer enable rather than constrain the teams building the product
AI across the layers
The idea of these two layers predates the rise of agentic coding, but I think AI makes the distinction even more interesting.
The way AI should be used is fundamentally different across the two layers.
In the top layer, speed is the most important consideration.
Implementation details matter much less. If an implementation detail matters, it should either be small enough to be resolved quickly or significant enough that it belongs in the bottom layer.
This makes top layer a natural environment for autonomous, agentic coding: give the agent a clear problem, enough context, and appropriate constraints, and let it move quickly.
The bottom layer is different.
Here, we care deeply about the design of our services and systems. The architecture, interfaces, types, invariants, failure modes, and tests matter.
This doesn't mean that AI is less useful. Quite the opposite.
But the work shifts from asking AI to design everything towards explicitly defining the important parts of the design and letting AI fill in the implementation.
This is not because it is not possible to have AI fully coding from specs. But because it can be faster to write types, function signatures, API interfaces, constraints, and tests and then let AI implement the gaps. Rather than using natural language and hope that AI is able to come up with the implementation we want.
In his 1978 essay Edsger W. Dijkstra argued against natural language programming for its ambiguity. With modern AI, driven by natural language, formal (programming) languages have still a place. They trade off precision for speed. In the bottom layer teams sometimes precision is what you need.
AI as the glue
AI has another interesting consequence.
Historically, bottom layer teams left behind documentation to help top layer teams understand how to use what they built.
That documentation can now evolve into AI skills and AI integration (like MCP server).
Once a solid architecture, interfaces, and set of constraints have been established, those constraints can be encoded in a form that an AI agent can understand and use.
This creates an interesting possibility:
The bottom layer doesn't just provide infrastructure for the top layer. It provides the context that allows AI agents in top layer to operate safely and autonomously.
Once the architecture and constraints are solid, top layer teams can potentially delegate a very large portion of the implementation work to autonomous agents, while bottom layer provides the foundations, boundaries, and interfaces that keep that autonomy reliable.
Closing
I don't think these two layers should be seen as two separate engineering organisations.
They are two parts of the same system, optimising for different things.
Top layer exists to learn quickly, serve users, and create product value.
Bottom layer exists to provide the foundations that make that speed sustainable.
The mistake, in my view, is applying the same engineering practices, team structures, or expectations to both.
And AI makes this distinction even more important.
Product development in the top layer can then move faster than ever. But only if the bottom layer is strong enough to support it.