Remote collaboration is more effective than co-located working when teams digitize their collaboration on a shared platform and no longer link communication to people but to topics. Instead of using email, chat and SharePoint in parallel, teams bundle all information directly into task cards that are available to every team member in real time.
Key Takeaways
- Anyone who simply adds video conferencing to email, SharePoint and group chats has not digitized old working methods, but merely extended them: remote work does not work like this.
- Topic-related communication beats person-related communication: anyone who enters all information directly into a Jira card instead of sending it by email is building a traceable solution path that the entire team can read in real time.
- The infobroker role of middle management, i.e. collecting and passing on information between hierarchical levels, has no added value and can be automated using a collaborative platform.
- Transparency on a shared platform removes the basis for organizational politics because withholding information as an instrument of power no longer works.
- According to Rainer Borg, seven plugins are enough to transform Jira from a simple ticket system into a complete collaboration environment in which e-mail becomes superfluous in day-to-day project work.
Why distributed teams often work better than teams in the same room
Remote teams can work together more effectively than teams in the same location, but only under one condition: Collaboration must be switched to information handling. Anyone who works remotely and retains old office habits will fail. Those who rethink the flow of information will win.
Most distributed teams today use e-mail, group chats, SharePoints and video conferencing. These are ways of working from the office, supplemented by a camera image. They do not work remotely. Teams that work this way really do belong back in the office, because otherwise they lose coordination.
The difference is not in the tool, but in the principle behind it. As long as information travels to people, physical proximity is needed as an emergency nail. As soon as information is linked to topics and is available to everyone in real time, co-location is no longer necessary. Remote is then even more efficient.
Networking people or networking knowledge: that is the key question
The key question for any digital collaboration is: do you network people or do you network knowledge? This is where remote work that works and remote work that fails are separated.
Platform business models demonstrate the principle. You don’t buy a product on Amazon by writing to an email address and asking what someone thinks of the item. The information is attached to the item. Reviews, data and ratings are assigned to the product, not to a person. This is topic-related communication, and this is exactly how a platform works.
The same logic applies to any digitalization of business. A system like SAP S/4HANA does not link people, but information, and makes it available to everyone in real time. This creates efficiency. In projects, on the other hand, there are often a hundred isolated solutions side by side.
A typical process makes the break visible: tasks from a project plan end up in an email, go to a person who reads them out again, then to a SharePoint where further information is searched for, then to a meeting where decisions are made, which are transferred to a Word document and distributed by email. Each of these handovers fragments 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 sending it. In a ticket system like Jira, this object is the ticket.
Everything in the project plan becomes a card. The card has a team and a topic. If the team stands in front of this card, a reference to the topic is created. If what has been discussed is written on the card as a comment, a building block of the solution path is created. If you sort your contribution into the appropriate card instead of an e-mail, you provide another building block.
The effect can be seen in the meeting. If the agenda consists of cards, you sort them briefly, see the full context and content and enter the result directly into the card. Everyone in the team then has the information in real time, no matter where they are sitting.
The principle can be applied consistently:
- **If a problem cannot be solved in the team, you link from the map to the appropriate regular coordination meeting with the software architect. The map ends up on their agenda without anyone having to write a separate invitation.
- **Chat remains in the solution ** A topic-related chat belongs in the card, not in a loose Teams channel. This way it remains part of the solution.
- **Manager minutes at the push of a button ** After the meeting, a push of a button generates PDF or Confluence minutes. No need for follow-up work.
- **Personal to-do board: You drag cards onto your own board, add activities, check them off, and at the end your entries end up in the respective solution path. Everyone can see that the work is done.
Such an environment already exists. At its core, it needs a ticket system and around seven plugins, then you have a complete collaboration platform where nobody has to write emails anymore.
Middle managers as info brokers are not an added value, but a loss
In stressed organizations, the main work of many middle managers consists of infobroking: picking up problems from the teams, taking them up a level in the hierarchy, working out solutions there and passing some of the information back to the team. Through this communication, they gather more background knowledge than their teams. This is how hierarchies are created.
This infobroking does not generate added value. It is like putting out fires, and it ties up the very energy that a middle manager should be spending on his teams: building skills, developing people, making sure that people feel at home. In hierarchical structures, this management work falls by the wayside.
As soon as information is available to the team the moment it is created because the platform shares it in real time, the information broker becomes superfluous. The intermediary role can be automated. What remains is leadership: moderating, holding the whole thing together, developing skills in the teams.
Middle managers are edge killers, and not out of malice. Those who put out the fires and get things moving get a lot of attention from senior management. This is a meaningful identity, but it does not add value.
Rainer Borg
That’s why middle management needs its own transformation in an agile transformation. Coaching people, getting them into the flow, is more fulfilling in the long term than putting out fires. But this change doesn’t happen on its own because the old self-esteem is attached to the infobroker role.
Transparency is the death of any unhealthy dynamic
A collaboration platform thrives on transparency, and that is precisely what takes away the ground from internal politics. Transparency leaves no room for politics because it makes it impossible to withhold information.
In hierarchical organizations, withholding information is the basis for politics. Levels vie for the attention of the level above them. As each manager has his or her own area of expertise and often no longer understands what the others are doing with their people, withholding information can quickly create a political divide that pulls the entire organization into a negative cultural vortex.
If you want to get out of this, you have to change the principle, and the principle changes through transparency. Genuinely confidential information, for example on personnel, can be technically secured. In Jira, the authorization per card can be broken down so that only the registered team has access. To do this, a team field is added to the standard card so that those involved can see on their board that input is expected from them.
Agility is half mindset, half structure
Agility is roughly half mindset and half structure. Both halves are intertwined, and without a platform, the structural half remains difficult to scale.
The mindset includes the willingness to allow transparency and disclose connections. The structure includes digitized collaboration on a platform. If collaboration is truly digitalized, agility can be scaled to any dimension: from individual projects to programs with many teams to global initiatives with thousands of participants. This has been tested with up to 2,000 team members in such an environment.
The team size remains limited. A single team should comprise a maximum of ten to eleven people. Scaling is not achieved through larger teams, but through more teams working together on the same platform. Travel is more of a hindrance in this model because real-time information replaces presence.
When collaboration takes place on a platform on a specific topic, teams start to manage their own tasks. It is then no longer about managing tasks, but about people and their collaboration.
Why good habits are the enemy of better solutions
The most common reason why teams stick with email and SharePoint is simple: it works somehow. Good is the enemy of better. It’s quicker to write an email to a person than to find the right card and enter the information there.
Many people rely on existing tools. Microsoft Teams has a planner with cards, so you use that, and you do the chat in Teams Chat. But this misses the point because it remains person-related communication. You have to connect topics, not people.
Once you’ve worked differently, you don’t want to go back. A project manager who has to work with emails, Word protocols and SharePoint again after a two-and-a-half-year transformation on one platform is visibly suffering. Every email takes a building block out of the solution. Everyone in the team needs to be aware of this.
How to initiate such a change, even as a small cog
A change of this magnitude begins with attention, not with a tool rollout. The most effective first step is an initial impulse for management, for example via a keynote speech by someone who knows the principle and can demonstrate it.
The lever for management is not agility, but digitalization. Agility is often of little interest to management; they want the results of agile teams. But digitalization is in every manager’s job description because the stakeholders have written it in there. Digitizing collaboration is part of this task, and a manager understands this logic.
The path can be built up step by step from the initial impulse:
- Form a leading coalition Set up a vision, involve stakeholders, form a supporting coalition.
- **Design architecture: Clarify what the principle means for the organization and where it applies.
- **Start a pilot with impact **Do not roll it out across the board, but a small pilot with real impact, preferably with innovative people.
- **Optimize until it is noticeable **Improve the pilot until outsiders say: They work differently, that’s cool, I want to be part of it.
- **Roll it out when the early adopters are ready ** As the group grows, think about a broader rollout, because nobody wants to be the last one without digitalized work.
You don’t need a majority to trigger a wave. Just around three percent of the workforce can drive an impulse through a company. The decisive factor is people who pick up on the enthusiasm and acquire the necessary confidence, for example through training as an agile coach, to stand up in front of their colleagues and ask: isn’t that a better way of working?
