Breaking Engineering Silos: The Uncomfortable Truth About Collaboration

You’ve seen it happen. Teams that sit twenty metres apart but might as well be on different continents. Engineers who’d rather rewrite a feature from scratch than ask the team next door how their existing solution works. Slack channels full of passive-aggressive “just following up” messages between people who could literally walk over and have a conversation.

As the anthropologist Margaret Mead observed, “Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it’s the only thing that ever has.” The problem in most engineering organisations isn’t that we lack thoughtful, committed people — it’s that we’ve organised them into thoughtful, committed silos that rarely interact meaningfully with each other.

I want to talk about something that makes engineering leaders uncomfortable: sometimes you have to *push *people to collaborate. Not because your engineers are antisocial or incompetent, but because the systems we’ve built actively discourage cross-team work. And if you’re not willing to push back against those systems, don’t be surprised when your architecture starts to mirror your org chart — fragmented, duplicated, and slowly calcifying.

The Post-COVID Hangover Nobody Wants to Discuss

Here’s what I’ve observed across teams I’ve worked with: we’re still recovering from a collaboration deficit that started during remote work and never fully healed. Engineers got comfortable working in isolation. Team boundaries became harder. The informal hallway conversations that used to spark cross-team ideas simply stopped happening.

The result? Teams optimised for individual work rather than collective outcomes. Everyone’s busy. Everyone’s shipping. But somehow, three different teams have built three different authentication wrappers, and nobody thought to check if someone had already solved that problem.

The physicist Richard Feynman once said, “The first principle is that you must not fool yourself — and you are the easiest person to fool.” We’ve fooled ourselves into thinking that high individual team velocity equals organisational effectiveness. It doesn’t. Not when half that velocity is spent reinventing wheels that other teams already have in production.

Start with Shared Goals (No, Really)

Before I get into tactics, I need to address the foundation that makes everything else work: shared goals. Not the vague kind that live in a strategy document nobody reads, but genuine, measurable objectives that multiple teams believe in and are collectively accountable for.

Patrick Lencioni wrote an entire book about this — Silos, Politics and Turf Wars — and his central insight is worth repeating: silos aren’t caused by people being territorial or political. They’re caused by a lack of compelling shared objectives. When teams don’t have a reason to collaborate, they won’t. It’s not malice; it’s rational behaviour.

Here’s what this looks like in practice: as a tech department, we decide that this quarter we’re going to reduce deployment time by 40%, or improve system reliability to four nines, or migrate our core services to a new platform. Not one team’s goal — our goal. We pick the teams that will work on it. We identify dependencies and overlap. We create explicit expectations that these teams will coordinate, share learnings, and help each other succeed.

When collaboration comes from a mutual decision about what matters most, it’s not forced — it’s obvious. The basketball coach Phil Jackson put it simply: “The strength of the team is each individual member. The strength of each member is the team.” You can’t have one without the other.

Code Ownership: A Spectrum, Not a Binary

Before we talk about tactics for breaking silos, we need to understand Martin Fowler’s three models of code ownership, because where you sit on this spectrum determines what’s even possible.

Strong code ownership assigns modules to specific owners, and only those owners can make changes. Need something in another team’s service? Too bad — submit a ticket and wait. This sounds disciplined but often creates the worst kind of silo behaviour: developers copying code into their own repositories rather than waiting for changes, creating drift and duplication that compounds over time.

Weak code ownership also assigns modules to owners, but allows anyone to make changes. The owners review contributions and maintain quality, but they don’t gatekeep. This model lets developers solve their own problems while preserving institutional knowledge about why things work the way they do. The owners become filters at code review time, catching entropy-inducing changes before they merge.

Collective code ownership abandons individual ownership entirely — the team owns everything, anyone can change anything. This works beautifully when you have strong shared taste and mature engineering practices. It fails spectacularly when you don’t, because nobody feels personally invested in any area’s long-term health.

In my experience, weak code ownership is often the right starting point. It provides stewardship without bottlenecks. And can be a stepping stone toward collective ownership — where quality emerges from culture rather than gatekeeping. Collective code ownership is hard to scale though, so becareful with it.

The practical implication? Make all your repositories visible inside your organisation. Enable anyone in your tech org to open pull requests to any team’s code. Those teams must approve them, but the barrier to contribution should be code quality, not organisational boundaries. If a team needs something changed in another team’s repository, they should be encouraged to do the work themselves rather than waiting in a queue.

This has benefits beyond collaboration. It moves you closer to feature teams — groups organised around customer value rather than technical components — which is where most organisations should be heading anyway.

Architecture as Collaboration Infrastructure

Your system architecture isn’t neutral. It either encourages collaboration or discourages it, and most architectures do the latter by default.

Take monorepos. They’re controversial, and I’m not here to relitigate the monorepo-versus-polyrepo debate. But one benefit of monorepos that doesn’t get enough attention is this: they force people to collaborate. When everyone’s code lives in the same place, with shared tooling and shared standards, the friction of working across team boundaries drops dramatically. You can see what other teams are doing. You can learn from their patterns. You can contribute improvements that benefit everyone.

The downside is that monorepos can become unwieldy. Don’t let them grow without bounds — establish clear ownership boundaries and tooling to manage complexity. But recognise that the collaboration benefits are real and intentional. Sometimes architecture decisions should optimise for organisational health, not just technical elegance.

Mob Programming: Pushing the Conversation

Here’s a tactic that sounds uncomfortable but works: mob programming sessions across teams.

We’ve run these successfully — a bunch of teams each send a representative for a half-day session every two weeks. They work together on a common problem, rotating the driver, sharing context, and building relationships that persist long after the session ends.

Yes, you sometimes need to mandate participation at first. That’s okay. As a manager, you can tell your people what to do. You shouldn’t make too much of a habit of it — over-directing takes away ownership — but forcing the first few interactions often sparks organic collaboration that continues independently.

A few things I’ve learned about making these work:

Keep an eye on them. Attend the first few sessions yourself to ensure alignment on how mob programming works, what the roles are, how to rotate the driver, and what outcomes you’re expecting. Don’t micromanage, but don’t assume it’ll run itself either.

Get regular feedback. These sessions can drift toward frustration if left unmonitored. Check in with participants. Adjust the format based on what’s working and what isn’t.

Be patient. The first few sessions might feel awkward or unproductive. The relationship-building benefits compound over time. Push through the initial discomfort.

The inventor Thomas Edison reportedly said, “Genius is one percent inspiration and ninety-nine percent perspiration.” Cross-team collaboration is similar — it’s one percent inspiring kickoff meetings and ninety-nine percent showing up consistently, session after session, until the habits stick.

Protected Time: Making Space for Broader Impact

If your engineers never have time to work outside their team’s sprint, they never will. This isn’t a motivation problem — it’s a capacity problem. You need to explicitly protect time for broader impact work.

At Atlassian, they’ve historically used 20% time — one day a week for individual engineers to work on whatever they think is valuable. Google famously did something similar. The challenge is that when sprint commitments mysteriously require 100% of capacity, that 20% becomes the first casualty.

Here at Agoda, we’ve institutionalised 30% tech time — a third of engineering time explicitly reserved for technical improvements and cross-cutting work. It’s not perfect, but it acknowledges a fundamental truth: if you don’t schedule the work, you’re hoping it happens by accident.

But protected time alone isn’t enough. You also need to set expectations that senior engineers will use that time for broader impact. I tell my staff and leads explicitly that they should have impact outside their immediate teams. It’s part of what separates senior individual contributors from more junior engineers — the ability to see problems at the organisational level and take initiative to solve them.

Here’s the uncomfortable reality: if you have a senior lead who never works on anything outside their team’s sprint, in a medium-to-large engineering org, they’re probably going to get bored and quit. The work that makes engineering leadership fulfilling — mentoring across teams, improving shared infrastructure, championing best practices — requires time outside the sprint backlog.

Make this visible from the top down. Get leadership and business support for the principle that technical investment and cross-team work aren’t distractions from delivery — they’re what makes sustained delivery possible.

Facilitation Infrastructure

You can’t just announce that collaboration is important and expect it to happen. You need infrastructure that makes collaboration easy.

Regular tech talks and brown bag sessions. Give engineers forums and even a bit of budget for food, to share what they’re learning, present interesting problems, and showcase solutions. This isn’t just knowledge transfer — it’s relationship building. The engineer who presents on their caching strategy today becomes the person everyone knows to ask about caching tomorrow.

Training and development budgets. Cross-team learning happens naturally when engineers attend conferences, take courses, and bring back insights to share. Invest in this.

Rooms and resources. Administrative friction kills collaboration. If booking a room requires three approvals and a blood sample, people won’t book rooms. If there’s no budget for ordering lunch during a cross-team working session, those sessions feel like obligations rather than opportunities.

Remove barriers before they form. Most administrative barriers exist because someone, somewhere, had a bad experience once and created a policy to prevent it from happening again. Review these policies regularly. Ask whether the cost of the barrier — in terms of reduced collaboration — exceeds the benefit of whatever it was designed to prevent.

The management theorist Peter Drucker observed, “The most important thing in communication is hearing what isn’t said.” Your engineers are probably not explicitly telling you that the expense approval process for ordering pizza during team sessions is killing their enthusiasm for cross-team work. But it is. Listen to what isn’t being said and remove the obstacles anyway.

The Bottom Line

Breaking engineering silos isn’t about one big intervention. It’s about systematically creating conditions where collaboration is easier than isolation.

Shared goals give people a reason to collaborate. Open code ownership removes technical barriers. Architectural choices like monorepos create shared context. Mob sessions build relationships. Protected time makes space for broader impact. Facilitation infrastructure removes friction.

None of this is complicated in theory. The hard part is consistency — maintaining these practices when deadlines loom, when budgets tighten, when the short-term pressure to just ship the feature overwhelms the long-term imperative to build a healthy organisation.

As the essayist Samuel Johnson wrote, “The chains of habit are too weak to be felt until they are too strong to be broken.” Siloed behaviour is a habit. Breaking it requires building new habits — and that takes time, repetition, and yes, sometimes a bit of managerial force to get started.

The next time you’re frustrated that teams aren’t collaborating, resist the urge to blame culture or chemistry. Look instead at the systems you’ve built. Are you measuring shared outcomes or individual team velocity? Is code ownership enabling contribution or blocking it? Do engineers have protected time for cross-team work, or is every hour spoken for?

Your organisation’s collaboration patterns aren’t random. They’re the predictable result of the incentives and structures you’ve created. Change the structures, and the collaboration will follow.

Now, if you’ll excuse me, I need to go attend a mob programming session. Apparently, someone scheduled one during my calendar’s only free slot this week — which, come to think of it, is exactly how it should work.