In den letzten Monaten arbeiten viele Teams spürbar anders, und auf den ersten Blick sieht das vor allem nach Tempo und Effizienz aus.

Aufgaben, die früher zwei Tage gedauert haben, sind an einem Vormittag erledigt. Ein Skript, das jemand mühsam zusammensuchen musste, steht in zehn Minuten. Konfigurationen, Migrationen, Testdaten entstehen mit Tools, die den Großteil der Arbeit abnehmen.

Das ist ein echter Gewinn, denn niemand, der einmal so gearbeitet hat, möchte zurück.

Was mir auffällt

Je mehr entsteht, desto seltener kennt jemand das große Ganze, und das merkt man am ehesten im Vergleich zu früher. Damals hat derjenige, der einen Dienst eingerichtet hat, meistens auch verstanden, warum er genau so eingerichtet wurde. Heute läuft eine Konfiguration, in die niemand genauer hineingeschaut hat, weil sie ja funktioniert.

Was dabei leicht untergeht

Genau darin liegt aus meiner Erfahrung die eigentliche Schwierigkeit, denn weil etwas schnell fertig war und auf Anhieb funktioniert, wirkt es erledigt.

Fällt später ein System aus, nützt das schnellste Tool wenig. Dann braucht es jemanden, der die Umgebung kennt, der weiß, was, warum und wie geändert wurde, und der sich zutraut, die Verantwortung für Entscheidungen und ihre Tragweite zu übernehmen.

Diese Person lässt sich nicht erzeugen, sie muss vorher da gewesen sein.

Was ich empfehlen würde

Aus der Ferne konkrete Ratschläge zu geben ist schwierig, weil jede Umgebung anders gewachsen ist. Zwei Dinge lassen sich aber allgemein sagen.

• Durchlesen, bevor es in Betrieb geht. Halten Sie dabei in zwei Sätzen fest, warum etwas so gebaut ist. Ein paar Minuten der gerade gesparten Zeit sind dafür gut angelegt.
• Zuständigkeit festlegen. Wenn Sie länger als ein paar Sekunden überlegen müssen, wer für die Umgebung verantwortlich ist, führen Sie das Gespräch besser jetzt als im Ernstfall.

Tools erleichtern die Arbeit. Verantwortung übernehmen sie nicht, denn keines davon sitzt am Montag mit im Besprechungsraum.