Skip to main content

Search...

Remote Teams: When They Outperform Office Teams

Remote teams can work better together than office teams, but only on one condition: Knowledge must be networked, not people.

• • Updated: • 13 min read
Cover of the expert talk on 'Remote Teams: When They Outperform Office Teams' with Rainer Borg and Richard Seidl.

Remote collaboration beats working side by side in the office when teams move their collaboration onto a shared platform and attach communication to topics instead of people. Rather than juggling email, chat and SharePoint, the team keeps every piece of information in task cards that everyone can see in real time.

Key Takeaways

  • Adding a video call to email, SharePoint and group chats doesn’t digitize the old way of working, it only stretches it. Remote work doesn’t function like that.
  • Topic-based communication beats person-based communication: if you put everything straight into a Jira card instead of sending an email, you build a traceable solution path the whole team can read in real time.
  • The info-broker role of middle management, collecting information and passing it between levels of the hierarchy, adds no value and can be automated with a collaboration platform.
  • Transparency on a shared platform pulls the rug out from under office politics, because holding back information no longer works as a source of power.
  • According to Rainer Borg, seven plugins are enough to turn Jira from a plain ticket system into a complete collaboration environment where email becomes unnecessary in day-to-day project work.

Why Remote Teams Often Outperform Teams in the Same Room

Remote teams can collaborate more effectively than teams sharing an office, with one condition: the collaboration has to be rebuilt around how information is handled. Work remotely with your old office habits and you fail. Rethink how information flows and you win.

Most distributed teams today run on email, group chats and SharePoint sites, with a video call switched on top. Those are office routines plus a camera feed. They don’t work remotely. Teams that operate like this really do belong back in the office, because otherwise they lose their alignment.

What makes the difference is the principle behind the tool. As long as information travels to people, physical proximity is the stopgap that holds things together. Once information is attached to topics and available to everyone in real time, co-location stops being necessary. At that point remote work is actually the more efficient option.

Connecting People or Connecting Knowledge

Every form of digital collaboration comes down to one question: are you connecting people, or are you connecting knowledge? That is where remote work that succeeds parts ways with remote work that fails.

Platform business models show the principle. You don’t buy something on Amazon by emailing an address and asking what someone thinks of the product. The information sits with the item. Reviews, specs and ratings belong to the product, not to a person. That is topic-based communication, and it is exactly how a platform works.

The same logic runs through every digitalization of a business. A system like SAP S/4HANA doesn’t link people, it links information and makes it available to everyone in real time. That is where its efficiency comes from. Projects, by contrast, often run on a hundred isolated solutions side by side.

A typical workflow shows where things break. Tasks from a project plan land in an email and go to someone who pulls them out again, then to a SharePoint where more information has to be found, then into a meeting where decisions get made, which end up in a Word document that goes out by email. Every one of these handoffs splinters the knowledge.

What Topic-Based Collaboration Looks Like in Practice

Topic-based collaboration ties each piece of information to the object it belongs to, not to the person who sends it. In a ticket system like Jira, that object is the card.

Everything in the project plan becomes a card. The card has a team and a topic. When the team gathers around the card, the topic becomes the reference point. When the discussion goes into the card as a comment, it becomes a building block of the solution path. And when someone posts their contribution to the right card instead of sending an email, that is another building block.

You can see the effect in meetings. If the agenda is made of cards, you sort them briefly, see the full context and content, and enter the outcome straight into the card. Everyone on the team then has the information in real time, wherever they happen to be.

The principle can be carried all the way through:

  • Alignment meetings set themselves up. If the team can’t solve a problem, you link the card to the regular alignment meeting with the software architect. The card lands on their agenda without anyone writing a separate invitation.
  • Chat stays in the solution path. A chat about a topic belongs in the card, not in a loose Teams channel. That way it remains part of the solution.
  • Management minutes at the push of a button. After the meeting, one click produces a PDF or Confluence record. No follow-up work required.
  • A personal to-do board. You drag cards onto your own board, add activities, tick them off, and your entries end up in the relevant solution path. Everyone can see the work is done.

An environment like this already exists. At its core it needs a ticket system and around seven plugins, and you have a complete collaboration platform where nobody has to write email anymore.

Middle Managers as Information Brokers Are a Loss, Not an Asset

In stressed organizations, much of a middle manager’s day goes into brokering information: picking up problems from the teams, carrying them one level up the hierarchy, working out solutions there and passing part of the information back down. Sitting in the middle, they collect more background knowledge than their teams. That is how hierarchies form.

This brokering adds no value. It is firefighting, and it eats exactly the energy a middle manager should be putting into their teams: building skills, developing people, making sure people feel at home. In hierarchical structures, that leadership work gets lost.

Once information reaches the team the moment it is created, because the platform shares it in real time, the information broker is no longer needed. The go-between role can be automated. What remains is leadership: facilitating, holding things together, developing skills in the teams.

“Middle managers get stuck in that role, and it’s not out of ill will. Whoever puts out the fires and still gets something moving gets a lot of attention from senior management. It’s an identity that gives meaning, but it doesn’t create value.”

(Rainer Borg)

That is why middle management needs a transformation of its own within an agile transformation. Coaching people and getting them into flow is more fulfilling in the long run than fighting fires. But the shift doesn’t happen by itself, because the old sense of self-worth is tied to the information-broker role.

Transparency Ends Unhealthy Dynamics

A collaboration platform lives on transparency, and transparency is exactly what cuts the ground from under internal politics. It leaves no room for politics because it makes holding back information impossible.

In hierarchical organizations, withheld information is what politics runs on. Each level competes for the attention of the level above. Since every manager has their own specialty and often no longer understands what the others are doing with their people, withheld information quickly creates a political gradient that drags the whole organization into a negative cultural spiral.

If you want out of that, you have to change the principle, and the principle changes through transparency. Information that is genuinely confidential, such as HR matters, can be protected technically. In Jira, permissions can be set per card so only the assigned team has access. To make that work, the standard card gets a team field, so the people involved see on their board that their input is expected.

Agility Is Half Mindset, Half Structure

Agility is roughly half mindset and half structure. The two halves interlock, and without a platform the structural half is hard to scale.

The mindset part is the willingness to allow transparency and make connections visible. The structural part is digitized collaboration on a platform. Once collaboration is truly digitized, agility scales to any size: from single projects to programs with many teams to global initiatives with thousands of people. It has been tried with up to 2,000 team members in this kind of environment.

Team size stays limited. A single team should have no more than ten or eleven people. You scale through more teams working on the same platform, not through bigger teams. In this model, travel tends to get in the way, because real-time information takes the place of being there in person.

When collaboration happens around topics on a platform, teams start managing their own tasks. The focus shifts from managing tasks to people and how they work together.

Why Good Habits Get in the Way of Better Solutions

The most common reason teams stick with email and SharePoint is simple: it sort of works. Good is the enemy of better. Writing an email to one person is faster than finding the right card and entering the information there.

Many people fall back on the tools they already have. Microsoft Teams has Planner with cards, so they use that, and they chat in Teams chat. That misses the point, because it is still person-based communication. What you need to connect is topics, not people.

Once you have worked the other way, you don’t want to go back. A project manager who has to return to emails, Word minutes and SharePoint after a two-and-a-half-year transformation on one platform is visibly unhappy about it. Every email pulls a building block out of the solution path, and everyone on the team needs to understand that.

How to Start This Kind of Change, Even as a Small Cog

A change this big starts with attention, not with a tool rollout. The most effective first step is an initial spark for management, for example a keynote by someone who knows the principle and can demonstrate it.

With management, the lever is digitalization. Management often cares little about agility; it wants the results agile teams deliver. But digitalization is written into every manager’s remit, because the stakeholders put it there. Digitizing collaboration is part of that job, and any manager follows that logic.

From that first spark, the path can be built step by step:

  1. Form a guiding coalition. Set out a vision, bring stakeholders in, build a coalition that carries the change.
  2. Design the architecture. Work out what the principle means for the organization and where it applies.
  3. Start a pilot with impact. Don’t roll out across the board; run a small pilot with real impact, ideally with innovative people.
  4. Improve it until people notice. Keep refining the pilot until outsiders say: they work differently, that’s cool, I want in.
  5. Roll out once the early adopters pull. As the group grows, think about a broader rollout, because nobody wants to be the last one left without digitized work.

You don’t need a majority to start a wave. Around three percent of the workforce can carry an impulse through a company. What matters are people who pick up the enthusiasm and gain the confidence, for example through training as an agile coach, to stand in front of their colleagues and ask: this is how we work right now, isn’t this better?

Frequently Asked Questions

Is providing distributed teams with a video conferencing tool enough to make remote work function?

No. Anyone who sticks with email, group chats, and SharePoint and simply adds a video feed is merely prolonging old office habits, not digitizing them. Such teams lose alignment and are better off back in the office. The difference lies in the principle, not the tool: Only when information is tied to specific topics and available to everyone in real time does physical proximity become unnecessary.

What’s the problem with using many tools in parallel in projects?

Every handoff fragments knowledge. A typical workflow: Tasks from the project plan are moved into an email; one person extracts them; additional information is stored on SharePoint; decisions are made in a meeting and end up in a Word document that’s distributed via email. Platform logic works the other way around: Information is attached to the object, just as reviews are attached to a product.

What changes when the meeting agenda consists of task cards?

The context is fully present. You quickly sort the cards, view the content and background, and enter the result directly onto the card. Afterward, everyone on the team has the information in real time, regardless of location. Minutes are generated at the click of a button as a PDF or in Confluence, eliminating the need for follow-up work.

Which role of middle management becomes redundant with a collaboration platform?

Info brokering: gathering problems from the teams, taking them up one level in the hierarchy, and returning a partial answer. This intermediary role adds no value and can be automated as soon as information is available to everyone the moment it is generated. What remains is leadership work: facilitating, building skills, and developing people. The transition is difficult because self-esteem is tied to the role of the information broker.

Can confidentiality be maintained if all information is openly available on a platform?

Yes. Truly confidential information (such as HR data) can be technically secured: In Jira, authorization can be set on a per-card basis, so that only the assigned team has access. Transparency remains the norm, because withheld information is the basis for internal politics. If it’s eliminated, the competition for attention loses its fuel.

How do you scale agile work across many teams?

Not by having larger teams, but by having more teams on the same platform. A single team should consist of no more than ten to eleven people. The model has been tested with up to 2,000 team members, ranging from individual projects to programs and global initiatives. Travel tends to be a hindrance in this context, because real-time information replaces the need for physical presence.

What argument can you use to win management over to digital collaboration?

Focus on digitalization, not agility. Management often has little interest in agility; it wants the results of agile teams. Digitalization, on the other hand, is part of every manager’s job description because stakeholders have included it there, and digitizing collaboration is part of that. A good starting point is an initial impetus, such as a keynote speech by someone who can demonstrate the principle.

Does a majority of the workforce need to be on board to implement a new way of working?

No. Even as little as three percent of the workforce can be drivers of change throughout a company. The path forward doesn’t involve a company-wide rollout, but rather a small pilot project with real impact and innovative people, one that’s optimized until outsiders want to join in. Only when the early adopters take the lead is a broader rollout worthwhile.

Share this page

Related Posts