Outch 😵
Find the English version below
Hi ,
Change tut weh.
Der Satz ist etwas abgebrüht.
Aber es ist mir vor einigen Wochen nochmal bewusst geworden.
Toni, ein externer DevOps Engineer (Grüße gehen raus 😉 ), war neu im Team.
Auf seiner Webseite schreibt er “Als Experte für Developer Experience habe ich das Ziel, ein Ökosystem für hochperformante & innovativ agierende Entwicklungsteams zu schaffen.”
Und das lebt er. Es gibt auch mehr als genug zutun. Und wir wollen es anpacken!
Das hat er gespürt.
Er ist mit voller Motivation losgelaufen.
Und so saßen wir an einem Dienstag in einem regelmäßigen Jour Fixe mit den Entwicklern und den Admins. Toni war das erste Mal in der Runde.
Auf der Agenda stand unsere neue CI/CD Pipeline. Wir wollen vom existierenden Jenkins auf Gitlab migrieren. Das ist Tonis erste Aufgabe.
Das schwierige ist nicht die Pipelines zu “übersetzen”. Die Arbeit liegt in der Konfiguration der Runner und der Environments, um Deployments zu ermöglichen. Und damit hat er sich hauptsächlich beschäftigt.
Aktuell ist das nicht der Verantwortungsbereich des Entwicklungsteams - in dem er aufgehangen ist. Sondern der Administration.
Und das spricht er an.
Natürlich.
Wieso auch nicht?
Mit einem modernen Verständnis der Softwareentwicklung. Mit dem Wissen über die seit 2013 anhaltenden DevOps Bewegung. Genau in der Aufteilung liegt das Problem.
Es sollte nicht in der Verantwortung der Admins sein.
Es sollte eigentlich gar kein separates Adminteam geben.
Und er spricht das an.
Absolut offen und transparent.
Objektiv - nichts daran auszusetzen.
Aber es veränderte schlagartig die Stimmung im Raum.
Jeder wusste, dass er Recht hat.
Aber es tat weh.
Dieser Change würde auf einen Schlag die Arbeitsweise jedes Anwesenden verändern.
Eine Arbeitsweise die sich seit mehr als 10 Jahren etabliert hatte.
Outch.
Change tut weh.
Nicht weil es falsch ist.
Sondern, weil es für Unsicherheiten sorgt.
Wenn man eine notwendige Änderung anspricht, dann hat der Empfänger im ersten Augenblick noch kein vollständiges Bild.
Er weiß nicht was sich für ihn ändern wird.
Und das macht Angst.
Wir stellen uns immer zu erst das Schlimmste vor.
Deswegen ist es so wichtig uns klar zu machen wie, mit wem und wann wir über Change reden.
Wenn wir wirklich einen Impact haben wollen. Wenn wir Change zum Besseren bewirken wollen. Dann müssen wir diesen verdaubar servieren.
Er muss sich natürlich anfühlen. Wir müssen jeden mitnehmen.
Und wir müssen ihn mit dem Betroffenen gestalten.
Toni hat das übrigens auch gemerkt. Wir haben uns danach direkt unterhalten. Und wir kommen da bestimmt hin - mit etwas mehr Zeit.
Rule the Backend,
~ Marcus
Hi ,
Change hurts.
The sentence is somewhat jaded.
But it became clear to me again a few weeks ago.
Toni, an external DevOps Engineer (shoutout to you 😉), was new to the team.
On his website he writes, "As an expert in Developer Experience, my goal is to create an ecosystem for high-performance & innovatively-acting development teams."
And he lives it. There is also more than enough to do. And we want to tackle it!
He felt that.
He started off with full motivation.
So, we sat on a Tuesday in a regular Jour Fixe meeting with the developers and the admins. It was Toni's first time in the round.
On the agenda was our new CI/CD pipeline. We want to migrate from the existing Jenkins to GitLab. That's Toni's first task.
The difficult part is not to "translate" the pipelines. The work lies in the configuration of the runners and the environments to enable deployments. And that's what he mainly focused on.
Currently, this is not the area of responsibility of the development team—which he is a part of. It's the administration's.
And he addresses it.
Of course.
Why not?
With a modern understanding of software development. With knowledge about the DevOps movement that has been ongoing since 2013. The problem lies exactly in this division.
It should not be the responsibility of the admins.
There should not even be a separate admin team.
And he addresses that.
Absolutely open and transparent.
Objectively—nothing to criticize.
But it suddenly changed the atmosphere in the room.
Everyone knew he was right.
But it hurt.
This change would immediately alter the working methods of everyone present.
A working method that had been established for over 10 years.
Ouch.
Change hurts.
Not because it's wrong.
But because it creates uncertainty.
When you point out a necessary change, the recipient initially doesn't have a complete picture.
They don't know what will change for them.
And that's scary.
We always first imagine the worst.
That's why it's so important to be clear about how, with whom, and when we talk about change.
If we really want to make an impact. If we want to effect change for the better. Then we need to serve it up in a digestible manner.
It needs to feel natural. We have to take everyone along.
And we have to shape it with those affected.
By the way, Toni noticed this too. We talked directly afterward. And we'll definitely get there—with a little more time.
Rule the Backend,
~ Marcus