The Fourth Ideal: Psychological Safety
Find the English version below
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
Hi ,
Last week, emotions were running high.
One of my clients achieved something extraordinary. They have successfully operated a product for 10 years. Highly profitable.
But the project was not started by trained developers. It began as a side product. The initial developers were career changers. Highly interested, motivated, engaged, and experts in their domain.
And they accomplished something that fails in 9 out of 10 cases. Their product is actively used. Customers happily pay for it. It solves a real problem. In a niche that hardly any other company can occupy.
This is extraordinary!
But - as you can probably guess - after these 10 years and with this context, a fair amount of technical debt has accumulated.
The solution has many features. And it happens over and over. You touch one side of the project, and a completely different part breaks. There is no real connection.
The developers have gained experience with this situation over the years. They have become cautious. Very cautious. All their negative experiences have taught them this. It is simply too risky to "just" change something.
And that's where it escalated.
I'm helping the team get out of this situation. But we can't achieve this without changes. And many things are necessary. The team knows this without me. But I am too fast. I've just "done" some things.
And that goes against all the experience the team has gathered.
The Team Lacks Psychological Safety
— the fourth ideal, described by Gene Kim in The Unicorn Project.
Psychological safety enables us to be brave. It allows us to tackle things at all. Our environment must not punish us for our courage.
There can be so many reasons why this safety is lost. The technical uncertainty from my story is one of them. But much more contributes to psychological safety.
- How brave are you when you are personally held accountable for mistakes?
- How brave are you when a "git blame" is executed first in the event of a failure?
- How brave are you when you only get your change into production after months?
Think about this in your project. Eliminate everything that makes you and your colleagues feel insecure.
Your productivity will thank you.
Rule the Backend,
~ Marcus