„Open Source“ und „Remote Work“ sind zwei Begriffe für ein und das selbe. Auf diese Theorie haben uns die RH Leute gebracht. Der Vortrag ist sehenswert. Dieser Post soll einen Einblick geben, wie es zu der Erkenntnis kam.
Ich selber war vor 20 Jahren Entwickler bei einer erfolgreichen Internet Firma. Ich wurde auf Armen getragen und war höchst motiviert. Irgendwann hat das Management bemerkt, dass die Weiterentwicklung stockt. Projektleiter wurden installiert, das Entwickler-Team wurde erweitert.
Dies ist eine normale Vorgehensweise. Und sie führt zu einer IT Abteilung, die intern arbeitet. Niemand! Nicht der Software Entwickler, nicht der Projektleiter und auch nicht der Chef bekommt mit, dass das Potential von „Remote Workern“ dabei verloren geht.
Der Software-Entwickler wird gelobt. Und das ist gut. Er kommt aber nicht auf die Idee Dinge extern zu lösen. Er hat kein Budget und bekommt Aufträge, wie mach ein Konzept. Er macht das Konzept und die IT Abteilung setzt das Konzept um. Ganz ohne externe Hilfe. Das schweißt das Team zusammen. Auch das ist gut. Aber es erklärt, warum interne IT Teams sich schwer tun, remote zu arbeiten.
Das Thema „Remote Working“ ist natürlich für viele interessant. Schon weil Löhne weltweit stark differieren. Ein intern arbeitendes Team wird in die Falle tappen, dass man Remote Worker für einfache Arbeiten einsetzen will. Einfach weil man irgendwie anfangen will. Weil die interne IT denkt, dass man doch sehr gut ist. Im Ergebnis sammelt man häufig die Erfahrung, dass Wissenstransfers der internen IT zu Remote Workern den Benefit der „billigen Arbeitskraft“ zunichte macht.
Unsere Erfahrung mit Remote Workern ist aber diametral. Man kann von Remote Workern lernen. Und es lässt sich einfach erklären.
Technologien ändern sich schneller als man zuschauen kann. Frameworks in allen möglichen Sprachen kommen und gehen. Virtualisierung und die damit verbundene Verschiebung von Tasks in die Cloud. DevOps Aufgaben. Wenn ich dass mit meinen Aufgaben vor 20 Jahren vergleiche, dann komme ich zu dem Schluss, dass ein Detailkonzept der internen IT für ein Software Projekt immer schlechter sein muss, als ein Konzept in dem Remote Worker einbezogen werden. Man kann von Remote Workern lernen!
Man kann den Versuch unternehmen die interne IT beizubehalten und Abläufe ändern, um „Remote Worker“ in eine interne IT einzubinden. Aber wenn man sich Gitlab als Vorbild nimmt, dann kommt man schnell zu dem Schluss, dass es einfacher ist die interne IT in eine public IT zu ändern, um das Potential von Remote Workern zu genießen.