The Fourth Ideal: Psychological Safety

Hi,

Letzte Woche sind die Emotionen hochgekocht.

Einer meiner Kunden hat etwas außergewöhnliches geschafft. Sie betreiben seit 10 Jahren erfolgreich ein Produkt. Höchst profitabel.

Aber das Projekt wurde nicht von ausgelernten Entwicklern begonnen. Es startete als Nebenprodukt. Die ersten Entwickler waren Queereinsteiger. Super interessiert, motiviert, engagiert und Experten in der Domäne.

Und ihnen ist etwas gelungen, was in 9 von 10 Fällen schiefgeht. Ihr Produkt wird aktiv genutzt. Kunden zahlen gerne dafür. Es löst ein echtes Problem. In einer Nische, die kaum eine andere Firma besetzen kann.

Das ist außergewöhnlich!

Aber - wie du dir bestimmt denken kannst - hat sich nach diesen 10 Jahren und mit diesem Kontext auch einiges an techischer Schuld angesammelt.

Die Lösung hat sehr viele Features. Und es passiert immer wieder. Man fasst eine Seite des Projekts an und eine ganz andere geht kaputt. Es gibt keinen echten Zusammenhang.

Die Entwickler haben über die Jahre mit diesem Umstand Erfahrung gesammelt. Sie sind vorsichtig geworden. Sehr vorsichtig. Das hat ihnen die ganzen negativen Erfahrungen gelehrt. Es ist einfach zu riskant “einfach mal eben” etwas zu ändern.

Und hier ist es eskaliert.

Ich unterstütze das Team aus dieser Situation herauszukommen. Aber das erreichen wir nicht ohne Änderungen. Und es sind viele Dinge notwendig. Das weiß das Team auch ohne mich. Aber ich bin zu schnell. Ich habe manche Dinge “einfach gemacht”.

Und das geht gegen jegliche Erfahrung die das Team gesammelt hat.

Das Team hat keine psychologische Sicherheit

— das vierte Ideal, beschrieben von Gene Kim in The Unicorn Project.

Psychologische Sicherheit ermöglicht uns erst mutig zu sein. Es ermöglicht uns überhaupt Dinge anzupacken. Unser Umfeld darf uns für unseren Mut nicht bestrafen.

Es kann so viele Gründe geben warum diese Sicherheit verloren geht. Die technische Unsicherheit aus meiner Geschichte ist eine davon. Aber noch viel mehr trägt zur psychologischen Sicherheit bei.

• Wie mutig bist du, wenn du für Fehler persönlich belangt wirst?
• Wie mutig bist du, wenn bei einem Ausfall als ersten “git blame” ausgeführt wird?
• Wie mutig bist du, wenn du erst nach Monaten deinen Change in Production bekommst?

Denk darüber in deinem Projekt nach. Eliminiere alles was dich und deine Kollegen unsicher werden lässt.

Deine Produktivität wird es dir danken.

Rule the Backend,

~ Marcus