EP-Tech-Reihe – Teil 3: Remote-first mit InnerSource

Im Bereich von Open Source-Projekten ist es bereits seit Jahrzehnten üblich, im Unternehmensbereich seit einigen Jahren mehr und mehr verbreitet – mit der Pandemie wurde es plötzlich in der Breite zum Alltag: Remote First. Vieles ist anders, manches neu – aber in vielen Aspekten kann man bei der Umstellung von erfolgreichen Open Source-Projekten lernen.

Wenn von Büro auf Remote-Arbeit umgestellt wird, werden das Meeting und der Austausch vom realen in den virtuellen Konferenzraum verlegt. Videokonferenzen sind ausgereift und Arbeitnehmer haben zuhause oft Internetanschluss mit großer Bandbreite. Mit diesem Ansatz kommt man schon weit. Dennoch bleiben große Herausforderungen:

• Viele Informationen flossen vorher informell, bei Gesprächen an der Kaffeekanne, bei Unterhaltungen, die zufällig von Wissensträgern gehört und ergänzt wurden.
• Manche Informationen sind am Arbeitsplatz offensichtlich: „Michael ist nach drei nicht mehr im Office, sondern auf dem Weg zur Kita.“ Im Remotesetting ist das weit weniger sichtbar.
• Fragen werden im Büro fast im Vorbeigehen schnell mündlich beantwortet.
• In Meetingsituationen ergeben sich oft im Gespräch zwischen einzelnen Agendapunkten schon Lösungen für kleinere Probleme.

Wer remote arbeitet, arbeitet zunächst alleine und asynchron zu den Kolleg:innen. Aus unserer Erfahrung heraus können wir sagen, dass InnerSource diese asynchrone Arbeit fokussiert. Insbesondere die folgenden beiden Prinzipien zahlen darauf ein:

Mehr Zeitinvest für schnelleren Austausch?

Man braucht mehr Zeit, wenn man schriftlich kommuniziert, anstatt die Frage einfach nur schnell mit dem Kollegen am Schreibtisch zu klären. Langfristig ergeben sich aber aus der maximalen Transparenz eine Reihe an Vorteilen:

• Fragen werden direkt beantwortet und sofort profitieren alle, die mitlesen.
• Transparent diskutierte Problemen bringen viele Perspektiven ein, die bei der Lösungsfindung helfen können. Auch die, die nicht im direkten Umfeld des Teams sitzen, wirken an der Lösung mit.
• Archivierte Kommunikation erhält dieses Wissen über Monate und Jahre. Gelerntes kann in Form von Zusammenfassungen und Links geteilt werden, anstatt immer wieder komplett neu formuliert zu werden.
• Statt alle Teilnehmer in ein umfangreiches Meeting einzuladen, findet der Austausch schon direkt bei der Entstehung der Frage asynchron statt. So reduziert sich die Anzahl an Meeting und in Meetings bleibt mehr Zeit für komplexe Themen.

Sensibel Daten und Unternehmensgeheimnisse

Natürlich sind nicht alle Themen unbedingt und mit allen Mitarbeitenden teilbar. Personalentscheidungen gehören nicht in öffentliche Kanäle – weder in Open Source noch in InnerSource-Projekten. Der Umstieg auf mehr schriftliche Kommunikation fordert auch eine gewisse Sensibilisierung dafür, welche Themen und Inhalte nicht geteilt werden können. Wichtig hierbei sind immer Fragen wie:

• Welche Themen gehören in öffentliche Kanäle, welche sollten vertraulich behandelt werden?
• Welche Regularien müssen im Unternehmen umsetzen, um sensible Daten sachgemäß zu behandeln?
• Wer sollte Themen, die vertraulich geteilt wurden, in öffentliche Kanäle ziehen – und wie macht man das am besten?
• Ab welchem Punkt lohnt es sich, auf einen synchronen Kanal zu wechseln, um vom Mehr an Bandbreite zu profitieren, und wie viel aus der synchronen Kommunikation muss wieder in den asynchronen Kanal zurückgetragen werden?

„Lass uns schnell telefonieren“ – eine Nachricht, die frustriert, wenn sie die einzige und letzte Nachricht auf eine Frage ist, die man gerade selbst hat. Die Lösung ist sehr einfach: Für alle Fragen, die asynchron aufkommen, aber synchron geklärt wurden, sollte wenigstens ein Lösungsansatz wieder im asynchronen Medium geteilt werden.

Und: Missverständnisse entstehen an Teamgrenzen schnell dort, wo sich Arbeitsweisen im Detail unterscheiden. Das passiert immer dann schnell, wenn Dinge nicht explizit, sondern implizit an neue Teammitglieder weitergegeben werden. In InnerSource-Projekten, die darauf ausgelegt sind, teamübergreifend Teilnehmer zu finden, werden genau wie in Open-Source-Projekten sehr viel mehr Annahmen explizit gemacht: Dokumentation dient nicht nur der fachlichen Dokumentation, sondern auch der von Prozessen, nach denen gemeinsam gearbeitet wird. Oft formulieren Teams zu diesem Zweck die Mission des Projekts, welche Kommunikationskanäle das Projekt nutzt und in welchen Zeiträumen mit Reaktionen auf Anfragen zu rechnen ist.