The Learning Organisation with João Rosa

What does "delivering value" actually mean?

Gien: When you say teams need to unlock their full potential to deliver value, what does value mean to you?

João Rosa: Value has a few dimensions. The first and most important is the customer — the people using our software, whether they're colleagues in another department or paying for a licence. Are we meeting their needs? Is the digital service we're providing actually useful? Good software can be invisible: I have my own life and I don't want to spend time inside an app wrestling with it to get something done.

The second dimension is the team building and maintaining that software. Are people happy? Is the codebase reasonable to work with? Do the boundaries make sense? Are people learning — not just about new technology, but about the domain? Highly motivated people produce better outcomes, and that's well evidenced.

The third is financial. Most of us work in companies inside a capitalist system — salaries need to be paid. I'm uncomfortable with "we exist to increase shareholder value" as the whole story, but I also recognise that without some cashflow a company can't take risks or invest in new directions. So value has to work across all three dimensions: useful software, engaged teams, and a business that can sustain itself.

Gien: When I go to software teams, I often notice that the connection to the company's financial reality has got a bit lost along the way. Do you see the same?

João Rosa: Yes. The early Agile practitioners were software engineers who shipped code and heard directly from users when things broke — they had real feedback and understood the stakes. What happened over the last 30 years is that companies, following an industrial revolution mindset, started isolating engineers. You're expensive, so you just write code — other people handle the customers. That's strange if you think about it: civil engineers building a bridge aren't isolated from the constraints it has to meet or the cost implications of their decisions. Why would we do that with software?

A financial services company in Brazil I worked with turned this around. Their FinOps reporting was connected to the sales cycle — when sales landed a large customer, the team could see exactly what the infrastructure cost impact would be. That meant architecture discussions happened proactively: if we land three customers like this next quarter, we need to rethink our architecture before costs go exponential. That's the kind of agency teams should have.

Anti-patterns that prevent teams from reaching their potential

Gien: When you talk about teams reaching their full potential, what are the common patterns you see that prevent it?

João Rosa: The first is the industrial revolution mindset of turning humans into task-executing machines through extreme specialisation. Social scientists have studied this since the forties and fifties. We are disengaged at work. The team is the unit of delivery — it has skills, it adapts, and it covers for its own gaps. Isolating individuals into narrow functions destroys that.

The second is isolating teams from their surrounding environment: their customers, their costs, their strategic context. Teams need that visibility to make good decisions. Are we building for product-market fit, where cutting corners deliberately and checking if it works is the right call? Or are we in a stable product where quality and maintainability matter more? You can't answer those questions without understanding the broader picture.

The third is locking teams out of time to think and learn. Google's Friday afternoon free time generated enormous innovation — and when they killed it in the name of efficiency, innovation dropped. Companies need to fund slack for learning. You can't put a price tag on someone going to a conference and coming back with an idea that changes how the team works. COVID accelerated remote work, which has been broadly positive, but it also removed a lot of the in-between time — the walks, the conversations, the breathing room where ideas form.

AI is making all of this more urgent. Producing code was never the real bottleneck — getting the right model of a problem was. AI amplifies throughput, which means the companies that haven't distributed decision-making to their teams are going to be outpaced by those that have, faster than ever.

Agency vs. autonomy — and why the distinction matters

Gien: One thing I keep hearing from companies is that they want teams to be autonomous. But when I look at the teams, they have no budget and every tool purchase needs three approvals. Autonomy without agency is just a recruitment story.

João Rosa: Exactly. Teams need agency — but they also need to understand the web of dependencies they sit within. A 20-person startup can make almost any decision freely. A bank with 2,000 people is a different game. A global company with 300,000 is another game entirely. The first step is really understanding that web — through Wardley Maps, user need maps, value stream mapping, anything that exposes your value chains.

What teams actually need isn't unlimited autonomy but clear boundaries within which they can act freely. There's a great example from Boeing, back when it was genuinely an engineering-led company. A major airline asked for a new aircraft to be 200–300 kilograms lighter to save fuel. Senior management told engineers: if you can save a kilo and it costs less than a few thousand dollars, just do it — don't ask us. The only constraint was not compromising safety. The engineers delivered an aircraft well under the target weight without a single unnecessary approval. That's agency with clear guardrails. Boeing threw that culture away, with consequences we know well.

The equivalent in software: telling a well-paid engineer they can't spend fifty dollars on a tool, or making them wait for a laptop that takes 20 minutes to open Visual Studio. The decision to roll out underpowered laptops to engineers might look like a cost-saving until you calculate the hours lost — you end up throwing away seven or eight times what you saved. These micro-decisions add up, and they all point to the same root cause: a management model built on command and control that can't access the potential it's paying for.

Why Team Topologies

Gien: You've mentioned Team Topologies several times. What is it about this model that you find so compelling?

João Rosa: Team Topologies is interesting to me because it's a pattern language — not a framework, not a process. Like domain-driven design, it gives you lenses to look at a problem and make decisions. The central insight that changed things in 2019 was cognitive load. Before that, people only talked about feature teams and component teams. Team Topologies stepped back and asked: what if we design team structures around cognitive load?

Cognitive load is always present in software work because we are always learning — not just about tools, but about domain nuances. That constraint never goes away. And a value stream exists on a spectrum: some things are well understood and largely mechanical, others are highly experimental. The more you own, the higher the cognitive load. This shapes your architecture: you shouldn't build a homegrown CRM if a market solution handles 90% of your needs — only build the 10% that's genuinely distinctive. In Amsterdam, you might take a standard SAP logistics platform and build the special-case routing for streets that close in the evening, because that's the bit that's actually unique.

What Team Topologies also does well is expose bottlenecks. Sometimes the bottleneck is in your pipeline, sometimes in how you use cloud services, sometimes in team organisation. It gives you a visual language for those conversations — particularly useful when you have more than five teams and you're trying to reason about flow.

Enabling teams and the learning organisation

Gien: One of the Team Topologies concepts I reach for most is enabling teams — a temporary team that helps other teams upskill or adopt new tooling. Even when the customer has never heard of Team Topologies, I introduce that pattern.

João Rosa: It connects directly back to cognitive load. John Sweller's original cognitive load research was done in learning environments, and that's exactly what makes it applicable here — software teams are always learning. Junior engineers are learning their tools, but every engineer is continuously learning about the domain. The constraint is never the code itself; it's mastering the nuances of the problem you're solving.

Enabling teams matter at two levels. At the team level, they help groups absorb new practices — test automation, cloud migration, containerisation, whatever the current wave is. At the organisational level, they're part of what makes a company a learning organisation. Companies that stop learning become vulnerable. When Broadcom acquired VMware and dramatically raised prices, many companies were trapped — partly because they'd stopped experimenting with alternatives. The organisations that had kept running low-cost experiments on Kubernetes, OpenShift, and different cloud workloads were in a much better position. Enabling teams are one of the mechanisms that keep that flywheel turning.

The mistake I see is companies treating enabling teams as a compliance stick — they're there to enforce standards, not spread learning. That inverts the whole purpose. An enabling team exists to reduce cognitive load and spread capability, not to police it.

The rant: middle managers who protect their kingdoms

Gien: What still frustrates you most about team organisation?

João Rosa: Middle managers protecting their kingdoms. That single behaviour dismantles the team concept faster than almost anything else. When individuals above teams are optimising for their own position rather than for flow, everything gets stuck. It comes down to incentives: the management model rewards the wrong things, so you get the wrong behaviour.

What I've seen work is replacing middle manager individuals with middle management teams — small, cross-functional groups that operate as a team themselves, rather than a single person sitting atop a hierarchy. Things start to flow differently when the management layer is also a collaborative unit.

This is becoming more urgent, not less. Technology is accelerating. Teams need to be able to push to production, observe what happens, validate or invalidate assumptions, and adapt — without needing a licence to act. Every unnecessary gate in that cycle makes the company slower. If organisations don't remove these blockers, the innovation rate needed to stay competitive simply isn't achievable.

What does satisfying software mean to you?

João Rosa: We are watching the enshittification of software in real time — platforms piling on ads and gamification until they become unbearable to use. That is the opposite of satisfying software. Satisfying software does one thing well and then gets out of the way. It's invisible.

I work with a lot of banks and I tell them plainly: no one wants to spend time inside a banking app. People want to spend time with their families. For big decisions — buying a house, major investments — yes, I want a good advisor. For everything else, I want the software to automate my life, flag anything suspicious, and leave me alone. A bank sells trust. The software's job is to honour that trust and then disappear.

That's the external view. Internally, satisfying software means teams can push things to production easily, run experiments side by side, take signals from the real world, and adapt quickly. Rather than arguing indefinitely about which architectural approach is correct, you put both in production and see what survives. Kill your darlings and move on. That's how the best e-commerce companies in the Netherlands grew — Bol.com, Coolblue, Booking.com — constant A/B testing, decisions pushed to teams, learning from production continuously. You can only do that if you push decision-making down to the people closest to the work.

Satisfying software, from both directions: invisible and trusted by the people using it; easy and empowering for the people building it.