Org Topologies Case-Study by Koen Siegers >> "It started over dinner ..."

I hadn’t seen Stacy in twenty years. We were in the same math class back in high school — she was the only one who actually understood what the teacher meant when he said “assume a spherical cow.” Now she’s a product manager in a government organization, running a portfolio of public-facing digital services.

We reconnected after bumping into each other at a conference, and that night over curry and a shared bottle of wine, I asked her about her job. I could see the worry in her eyes before she said a word.

“I don’t think I can turn this ship around,” she finally admitted.

She went on to tell me about her world. Stacy is the product manager in a government organization. She manages three product owners: Oscar, Pete, and Jane. Oscar and Pete each have one development team; Jane works with two. That’s four teams total. On paper, they’re agile. They do PI planning. They have backlogs. The Jira boards are colorful and full of tasks. But the performance of their application is abysmal. New features trickle out. Budgets are tightening. And the pressure is building.

“I try to get them to work together,” she said. “But it’s not happening. Everyone’s focused on their own goals. Their own backlogs. If one team hits a blocker, the others just… watch.”

I asked about the product owners.

“They’re committed,” she said. “But maybe too much. Everyone is locked into the deadlines we set during PI planning. It’s like once they’re on the track, no one wants to switch lanes—even if the train in front of them is on fire.”

And then she told me about Pete’s analyst — the one who just quit. The only person in Pete’s team who fully understood the most obscure modeling tool in their custom-built stack.

“Replacing him will be a nightmare,” she said. “Budget-wise, I don’t even know if it’ll happen. And onboarding someone new to this spaghetti tech stack? Six months at best. Assuming we find someone.”

It didn’t end there.

Even when a team does manage to finish something, their work is passed down like a relay baton — first to the “release team,” then the “user acceptance team,” and finally to the “implementation team. By the time something hits production,” she said, “no one remembers why we built it in the first place.”

I nodded and took a sip of my wine.

“So what have you tried?” I asked.

She smiled — but it wasn’t a happy smile.

“I tried everything that seemed reasonable. We organized ‘office days’ to bring people together. Free lunch. An interesting speaker. Sometimes we’d wrap it up with drinks or a board game night. The turnout was okay. The vibe? Polite. But as soon as people opened their laptops, it was business as usual. Jira tickets. Sprint goals. Conversations in Slack with their own team and no one else.”

She leaned back and looked at the ceiling for a second, then added, “We even tried an office day without the perks — no lunch, no speaker — just nudging them to ‘work together.’ But that flopped harder. Everyone just clustered around their own squad. We were in the same building, but not together.”

“Did you try any facilitation?” I asked.

“Yeah, once. We brought in someone to run a session asking, ‘What do we have in common?’ and ‘What could we get out of these office days if we used them well?’ The whiteboards filled up with ideas: shared purpose, learning from each other, fewer handovers… all the usual suspects. But the moment the facilitator left, everyone slid right back into their silos.”

“Why do you think that is?”

Stacy didn’t answer right away. Then she shrugged.

“I think everyone’s just… doing what they’re set up to do. Their goals are team goals. Their deadlines are their own. If someone from another team struggles, it’s not that they don’t care — it’s just that helping them would mean falling behind on their own commitments.”

She sighed again.

“And don’t get me started on the sprint reviews. Each team is working on such a small slice of the product that stakeholders either don’t show up, or they sit there wondering what it all means. ‘We updated the schema for the scheduling component’—great. But if the release team, user acceptance team, and implementation team haven’t done their part yet, no one sees the change in production for another month. The reviews feel more like internal updates than real demos of value.”

She paused and then went on, her voice tinged with frustration.

“I also tried to emphasize to the teams how important it is that they keep delivering. I wanted them to understand that their velocity needed to be more transparent, so we could all see where we were. But that didn’t quite go as planned. Teams started enforcing stricter definitions of ‘ready.’ If something wasn’t fully fleshed out — a user story wasn’t completely clear, or the design wasn’t handed to them before they started — they’d just push it back. It’s like they were holding everything up until the very last detail was nailed down. We’re still not getting value delivered faster, because now, everyone’s focused on making sure everything is perfect before they start. It’s like they’re waiting for the green light that never comes.”

She glanced around the restaurant, lowered her voice

“And now there’s this new issue. The product needs 24/7 support — we’re talking public-facing, critical services. But none of the teams knows the whole system, either in terms of functionality or the tech stack. Their scopes are just too narrow. So when something goes wrong at 3 AM, it’s always a mad scramble to find someone who might be able to help. No one wants to be on call four nights a week, even if they’re paid for it — especially not when it’s for parts of the system they barely understand. Sharing the burden doesn’t work when no one has the full picture.”

That’s when I pulled out my notebook.

“Can I draw you something?”

She raised an eyebrow. “You’re going to draw?”

“Don’t worry, no cows this time,” I said, flipping open my notebook.

I sketched a horizontal line. Then I drew four dots across the line and labeled them 1, 2, 3, 4 — like levels of maturity, but not in a judgmental way. More like, different modes of how organizations structure their teams in relation to their product.

“This is from something called OrgTopologies,” I explained. “It’s a way to map how your teams are organized around the product they’re building in terms of how work flows, where ownership lives, and how knowledge is distributed.”

Stacy leaned in.

“Type 1,” I said, pointing to the left, “are organized around functions or specialties. Think: frontend, backend, testers, release team. Value flows through handovers. Type 2 are multis skilled but unable to deliver end to end.”

She nodded. “That’s basically us. We have cross-functional delivery teams, but they still rely on the release team, user acceptance team, implementation team...”

“Right. And your teams don’t feel connected to the outcome, because delivery is decoupled from value. Now”—I moved my finger across the line—“Type 3 and 4 is the other end. You’ve got teams that own entire slices of the product, end-to-end. From customer insight to running code in production. Minimal handovers. Direct feedback. Deep context.”

“I want that,” she said immediately. Then caught herself. “Or… I think I do?”

“You probably do,” I said. “But it’s not about jumping from 1 to 4 overnight. It’s about making your current setup explicit, and deciding where you want to go on purpose. The problem isn’t your people. It’s the design—technical and organizational—that makes the behavior you see the most reasonable thing they can do.”

She sat back. Quiet for a moment. “I kept thinking we had a culture problem,” she said.

I flipped to a fresh page.

“Let’s try to place your teams,” I said.

“Where would you say each team sits in terms of autonomy and value delivery? Think about how much of the value stream they own — from idea to working product in production.”

She considered for a moment, then pointed to the first lane.

“Oscar’s team… probably somewhere between 1 and 2. They build features, but everything goes through the release team afterward. And they rely on user acceptance before anything can move.”

I placed a dot in the 1–2 range.

“Pete’s team?” I asked.

She frowned. “They were maybe a 2, but now that the analyst’s gone? More like a 0. They’ve lost a ton of domain knowledge. They’re hesitant to touch anything outside their narrow component.”

We mapped out the rest. Jane’s teams were similar: technically cross-functional, but in practice, tightly scoped to specific subsystems with lots of downstream dependencies.

When we were done, the picture was clear. All four teams clustered around the 1–2 zone — functionally capable, but structurally constrained. Handovers, limited product ownership, long feedback loops.

“This,” I said, tapping the page, “isn’t dysfunction. It’s design. Your teams are doing exactly what their environment optimizes them to do.”

“So how do I get to 3? Or 4?” she asked, already drawing arrows toward the right side of the diagram.

“Not all at once,” I said. “But we can look for one thing. A crack in the wall.”

I drew a circle around one of Jane’s teams.

“Suppose we chose one team — maybe one of Jane’s — and redefined what ‘done’ means. Instead of stopping at ‘code complete,’ what if we gave them ownership through to production? Not in a big-bang, ‘you own everything now’ way, but just for one flow, one experiment. Could we remove the release team handover for that?”

Stacy looked hesitant.

“They’d need more support. More tooling. Maybe even a direct line to stakeholders.”

“Exactly. But imagine the impact. Faster feedback. Direct learning. A different kind of sprint review — one where stakeholders actually see value released. One example of what good could look like.”

She nodded slowly.

“Okay. I can see that.”

“And while we’re at it,” I added, “we can start building shared context across teams. Not with icebreakers or pizza, but by looking at how we have set them up.”

I turned the napkin sideways and drew the same horizontal line — this time with an Y, A, B, C spectrum.

“This axis,” I said, labeling it scope of mandate, “is about what the team is allowed to do. At the bottom, teams get handed tasks. Their job is to build features, close tickets, hit deadlines. They’re told what to do.”

I paused, then drew a small dot in the lower-left quadrant.

“Here’s a typical team in a government setup: lots of oversight, lots of process, not much room for initiative. Even if they spot a better way to solve the problem, they’re not really allowed to change direction.”

She nodded slowly.

“And up here,” I said, drawing toward the top, “you’ve got teams who are trusted to solve problems. They’re given an outcome to achieve — like reducing waiting time for citizens or improving accessibility — and they have the freedom to figure out how.”

I boxed in a dot in the upper-right corner.

“Moving to the right is about integrating all the skills you need to create fast feedback — owning more of the product end-to-end. But moving up is about shifting from finishing tasks to solving real problems. It’s not just about speed, it’s about outcomes.”

Stacy stared at the napkin.

“So you can have a fast team… that’s still working on the wrong thing,” she said.

“Exactly,” I said. “You want teams that can move fast and know where they’re going — because they helped chart the course.”

She leaned forward, scribbling notes on a napkin now. I smiled.

The ship was starting to turn. 

It didn’t happen overnight. But over the next few weeks, Stacy started making changes. Small ones, careful ones — nothing revolutionary. Just enough to test whether the walls could shift.

Then, three months later, she called me. I could hear it in her voice before she said a word.

“I don’t know if this is working,” she said. “I feel like I’m losing them.”

She’d made progress — real progress. Releasing and user acceptance were no longer separate handovers. Those steps had been integrated into the teams, thanks to support from a forward-thinking release manager and some allies in testing. Implementation was still a separate function, but Stacy said that made sense for now: those folks worked directly with field offices, training staff and preparing internal communications before anything went live. Their involvement couldn’t just be absorbed overnight.

“The problem,” she said, “is getting the teams to work together.”

She explained that her product owners were starting to push back — saying the extra coordination was interfering with their goals, making it harder to hit deadlines. Worse, HR had come knocking. Apparently, some developers had filed complaints. One said she was forced to learn parts of the system they’d never worked on before, written in languages they’d never even heard of. Another said it wasn’t fair — that some of the code was owned by a different department, and they couldn’t even get access.

“And then one person told HR they might quit,” she added. “He said if this hurts his chances of getting promoted to a senior dev role — which he thought was about becoming the expert in one thing — then he’s out.”

I paused, letting that sink in.

“You’re running into exactly what you should expect,” I said gently. “You made a structural change. That’s a great start. But the rest of the organization has to move too. HR needs to understand what it means to support T-shaped— skill growth. Promotions shouldn’t just reward depth in one area. They should reward versatility, learning, problem-solving in context. Otherwise, you’re sending mixed messages: we want collaboration, but we only promote specialization.”

She sighed.

“I thought structural change would be the hard part,” she said. “Turns out culture doesn’t just shift because you redraw the boxes.”

“Right,” I said. “Because structure and culture feed each other. If teams still operate in isolation, culture will default to local optimization.”

“Still,” she said, “I was hoping they’d at least start collaborating more. Even just a bit.”

“Let me ask you something,” I said. “Do your product owners still maintain separate backlogs?”

“Yes,” she said. “One per team. Why?”

“And do you do any kind of multi-team refinement? Like a shared product backlog refinement session?”

“No,” she said. “Each team handles their own.”

She exhaled slowly.

“This is bigger than I thought. I’ve got a long road ahead,” she said. “But I’m not giving up.”

M — Mapping the Current Org Topology

Stacy’s original organizational structure aligns closely with what OrgTopologies™ defines as the Resource Topology. Her scope included oversight of three product owners (Oscar, Pete, and Jane), each responsible for one or two specialized development team. The underlying management objective was high resource utilization, not fast flow or customer outcomes. This structure created predictable silos: no single team could deliver customer value independently, and all relied on upstream analysis and downstream integration.

A – Assessing the Current Org Topology

Stacy’s frustrations are not unusual — in fact, they’re a predictable outcome of the organization’s current Resource Topology. Teams are structured around skills and technical components rather than around whole product outcomes. As a result, work is treated like a relay race: designed by one group, built by another, validated by a third, and implemented by yet another. This leads to fragmentation and a lack of shared ownership. No one team holds the full context, so by the time a feature reaches production, even the original intent is often forgotten. Sprint reviews attract puzzled stakeholders — or none at all — because the work being demoed is too granular or disconnected from real user value. And despite the product being a critical, public-facing system requiring 24/7 support, no team truly understands or owns it end-to-end.

This isn’t due to incompetence or lack of effort. It’s an organizational design issue. In a Resource Topology, individuals and teams are grouped by role or skillset (e.g., developers here, testers there), and work flows between them. It creates clear divisions of labor but obscures product ownership.

What Stacy is yearning for — cross-functional collaboration, shared goals, teams that understand and support the whole system — is better supported by an Adaptive Topology. In an adaptive topology, team structures flex around the shape of the product itself, aligning closely to user-facing outcomes. Ownership is end-to-end. Teams are empowered to not just deliver features but to learn from production and adapt based on feedback. The problems Stacy sees aren’t surprising; they’re the logical result of an org optimized for efficiency in silos, not for adaptability or product ownership.

D – Design the Future Org Topology

In an ideal setup, Stacy’s organization would shift toward an adaptive topology, where cross-functional teams are aligned to whole product domains rather than narrow slices of functionality or technical components. Instead of handing off work from team to team — from development to release, to user acceptance, to implementation — each team would be capable of delivering, validating, and operating the product end-to-end. This shift would support Stacy’s desire for deeper collaboration, clearer product goals, and stronger feedback loops.

Rather than three product owners managing competing backlogs in isolation, each focused on their own domain, the organization would move toward value-aligned teams working within shared product boundaries. Stakeholders would engage more meaningfully because they’d be invited into a narrative that connects to real user outcomes — not just technical updates.

Importantly, each team would understand not only what they’re building but why, because they’d be part of continuous discovery and delivery cycles. Their work would be traceable to real user needs and system behavior in production. This also addresses Stacy’s concern about 24/7 support: in an adaptive topology, teams that build the product also operate and support it. That sense of end-to-end ownership leads to greater accountability, system knowledge, and resilience.

By moving away from the resource-based relay race and toward long-lived, outcome-focused teams with shared context and product boundaries, Stacy’s organization would be positioned not just to deliver more effectively — but to learn, adapt, and truly serve its public mission.

E – Elevate the Organization

Stacy had already experimented with what Org Topologies refers to as Elevating Katas—deliberate steps to help teams shift from a resource topology toward a more adaptive, outcome-oriented structure. One of her first moves was to introduce shared code ownership and a shared Definition of Done across teams, particularly trying to integrate the release and user acceptance teams horizontally. The goal was to reduce handovers and improve flow, allowing multiple teams to contribute to the same product increment with a shared understanding of quality and readiness.

However, she ran into resistance. If we think of Galbraith’s Star Model, it becomes clear that while she was attempting to shift the structure—by encouraging cross-team collaboration and shared responsibility—other parts of the organization remained misaligned. The processes still reinforced sequential, waterfall-style delivery with late-stage sign-offs. Rewards systems, especially in HR, favored specialization and siloed ownership: developers were promoted for deep expertise in a narrow stack, not for cross-functional teamwork or shared delivery. There was also resistance from some senior developers who rejected shared code ownership, arguing that “the code they found was very obscure,” and expressing concern over the lack of clear boundaries or accountability.

The consultant introduces a set of next-step katas that help operationalize the adaptive topology Stacy is aiming for. These include starting a multi-team Product Backlog Refinement (PBR) session to align understanding across teams, merging product backlogs to reflect a shared mission rather than fragmented initiatives, thereby gradually building teams with true product responsibility. These katas are designed not just to tweak the structure, but to bring alignment across people, processes, and incentives—so that the organization can begin to behave like a cohesive product system, not just a collection of parts.

Conclusion

What you’ve just read isn’t just about fixing a few broken processes—it’s a deep dive into how an organization can evolve from struggling with silos and misalignment to something far more dynamic. Stacy’s journey showcases the power of Org Topologies and agile collaboration in breaking down walls and fostering true ownership. But this transformation is messy, filled with setbacks, and far from linear. What’s clear is that the surface-level changes aren’t enough; the real shift happens when the culture begins to change with the structure. The work doesn’t end here—it’s only just begun.

The style of this article aims to mirror Stacy’s journey—a blend of insights, challenges, and real-world complexity, presented in a way that mirrors the messy reality of change. Through narrative, we’ve explored the importance of agile collaboration and Org Topologies, while also underscoring the human side of transformation. My hope is that this approach sparks something in you, the reader—not just as an observer of Stacy’s story, but as a potential change agent within your own organization. Because like Stacy, the work you do isn’t just about fixing the surface—it’s about creating lasting, meaningful transformation.