Warum Elektriker Autorität haben und Entwickler nicht

7 Min. Lesezeit

Wenn das Licht angeht, endet die Diskussion

Ein Freund fragte mich kürzlich, warum Elektriker nicht dieselben Probleme haben wie Software-Entwickler. Ein Elektriker führt eine Installation durch, sie funktioniert oder nicht, und damit ist die Sache erledigt. Niemand versucht, Narrative über elektrische Arbeiten zu kontrollieren. Niemand plant Meetings, um zu diskutieren, ob die Verkabelung „mit den Geschäftszielen abgestimmt” ist. Niemand engagiert Berater, um die Art und Weise zu transformieren, wie der Elektriker Klemmen anschließt.

Wenn es um Software geht, hat jeder eine Meinung. Projektmanager, Führungskräfte, Stakeholder drei Ebenen von der eigentlichen Arbeit entfernt, der Typ aus dem Marketing, der einmal eine WordPress-Seite gebaut hat. Sie alle fühlen sich qualifiziert, sich zur Arbeitsweise zu äußern.

Warum dieser Unterschied?

Das Geschenk der Objektivität

Elektroarbeit genießt etwas, das der Software-Entwicklung verzweifelt fehlt: objektive Zustände — funktioniert oder funktioniert nicht.

Entweder ist der Stromkreis korrekt verdrahtet oder nicht. Entweder geht das Licht an oder nicht. Entweder löst der Sicherungsautomat aus, wenn er soll, oder nicht. Es gibt kein Meeting, um zu diskutieren, ob das Licht “ausreichend an” ist oder ob der Stromkreis “mit der strategischen Vision abgestimmt” ist.

Normen sind gesetzlich verankert. Farbcodes, Kabeltypen, Sicherungsgrößen, Erdungsanforderungen, Schutzkonzepte — alles dokumentiert, geprüft und durchgesetzt. Prüfer kontrollieren die Einhaltung anhand expliziter Kriterien. Die Variabilität der Anforderungen ist gering. Ein 16-Ampere-Stromkreis für Küchensteckdosen ist ein 16-Ampere-Stromkreis für Küchensteckdosen. Der Elektriker erfährt nicht mittendrin: “Übrigens, wir haben beschlossen, er soll auch Kaffee kochen.”

Diese Objektivität verleiht Elektrikern etwas Wertvolles: Autorität. Wenn der Elektriker sagt “das entspricht nicht den Vorschriften”, ist die Diskussion beendet. Keine Verhandlung, keine alternative Interpretation, kein Stakeholder-Abstimmungsmeeting. Die Norm ist die Norm.

Der Fluch der Subjektivität

Software-Entwicklung operiert in einem anderen Universum. Anforderungen sind unscharf, ändern sich ständig und widersprechen sich oft intern. Ein Stakeholder will Geschwindigkeit, ein anderer Stabilität, ein dritter Funktionen, die mit beidem kollidieren. Das Anforderungsdokument — falls es existiert — war veraltet, bevor die Tinte trocken war.

Was bedeutet Erfolg überhaupt? “Schnell genug.” Schnell genug für wen? Unter welcher Last? Auf welcher Hardware? “Gut genug.” Gut genug verglichen mit was? “Wartbar.” Von welchem zukünftigen Team mit welchen unbekannten Fähigkeiten?

Es gibt kein allgemein durchsetzbares Regelwerk. Sicher, es gibt Standards — Programmierkonventionen, Sicherheitsrichtlinien, Architekturmuster — aber keiner hat Gesetzeskraft. Niemand inspiziert das Repository und stellt Bußgeldbescheide aus.

Hier wird es noch schlimmer: Jeder nutzt täglich Software. Der Geschäftsführer nutzt ein iPhone. Die Marketingleiterin nutzt Slack. Die Aufsichtsratsmitglieder nutzen E-Mail. Diese Vertrautheit erzeugt eine Illusion des Verstehens. Eine App zu benutzen lässt Menschen glauben, sie verstehen, wie sie gebaut wird. Es ist wie zu glauben, man verstehe Automobiltechnik, weil man Auto fährt.

Die Kosten von Software-Fehlern sind oft verzögert, unsichtbar oder auf andere verlagert. Diese architektonische Abkürzung, um den Termin zu halten? Sie wird erst in achtzehn Monaten wehtun, wenn das Team versucht, eine Funktion hinzuzufügen. Die Sicherheitslücke? Stumm, bis sie ausgenutzt wird. Die technische Schuld? Sammelt im Hintergrund Zinsen, zahlbar von einem zukünftigen Entwickler, der nicht im Raum war, als die Entscheidungen getroffen wurden.

Das Sichtbarkeitsproblem

Wenn ein Elektriker die Arbeit beendet, kann man sie sehen. Kabel enden in Dosen. Kabelkanäle verlaufen an Wänden. Sicherungen sitzen in Verteilern mit Beschriftungen. Ein Nicht-Elektriker versteht vielleicht nicht die Details, aber er kann beobachten, dass Arbeit stattgefunden hat und ungefähr erfassen, was sie tut.

Software-Entwicklung produziert unsichtbare Artefakte. Code lebt in Repositories, die Stakeholder nie besuchen. Architektur existiert als Kästchen und Pfeile auf Diagrammen, die die Realität nur annähern. Die eigentliche Arbeit — die Logik, die Datenstrukturen, die Fehlerbehandlung, die Grenzfälle — ist dem Blick entzogen.

Diese Unsichtbarkeit erzeugt ein Vakuum, das Narrative füllen. Wenn man die Arbeit nicht sehen kann, braucht man jemanden, der davon erzählt. Und sobald man Geschichten über die Arbeit braucht, hat man die Tür für konkurrierende Geschichten geöffnet. Plötzlich hat jeder ein Narrativ. Das Termin-Narrativ. Das Technische-Schulden-Narrativ. Das “Wir-müssen-uns-nur-mehr-anstrengen”-Narrativ. Das “Entwickler-sind-zu-langsam”-Narrativ.

Man kann nicht auf Code zeigen wie auf eine Verteilerdose und sagen “Schau, das haben wir gebaut, da stehen wir.” Software-Status wird immer durch Interpretation vermittelt.

Das Machtvakuum

Die Kombination aus Subjektivität und Unsichtbarkeit erzeugt ein Machtvakuum — und Machtvakuen werden gefüllt.

Wenn niemand objektiv verifizieren kann, ob Software “gut” ist, dann kontrolliert derjenige die Qualitätswahrnehmung, der das Narrativ kontrolliert. Stakeholder wollen Kontrolle, weil Software ihren Bereich betrifft. Marketing will Funktionen, die Kampagnen unterstützen. Vertrieb will Funktionen, die Abschlüsse bringen. Finanzen will Vorhersagbarkeit. Betrieb will Stabilität.

Keiner dieser Stakeholder kann die technische Arbeit direkt bewerten. Aber sie können Narrative bewerten. Sie können beurteilen, ob das Projekt “auf Kurs zu sein scheint”. Sie können einschätzen, ob Entwickler “auf Geschäftsanforderungen reagieren”.

Deshalb wird so viel Software-Entwicklung zur Performance. Status-Meetings drehen sich nicht um Status — sie drehen sich um die Kontrolle der Wahrnehmung. Demos drehen sich nicht um Funktionalität — sie drehen sich darum, Vertrauen zu erzeugen. Velocity-Metriken drehen sich nicht darum, Produktivität zu messen — sie liefern etwas Zählbares für Folien.

Was Elektriker nicht erleben

Elektriker erleben keine Management-Frameworks. Niemand implementiert Scrum für Elektroinstallationen. Niemand fragt den Elektriker, wie viele Steckdosen er in einem Zwei-Wochen-Sprint installieren kann, und verfolgt dann die Velocity über die Zeit. Niemand strukturiert das Elektroinstallationsunternehmen in Tribes und Squads um.

Elektriker erleben keine Modezyklen. Es gibt keinen Thought-Leader-Zirkus, der fordert, wir müssten fundamental überdenken, wie Kabel an Klemmen angeschlossen werden. Niemand verkauft Zertifizierungen für den neuesten Durchbruch beim Verlegen von Kabelkanälen. Die Arbeit ändert sich, wenn sich die Technologie ändert — als LED Glühbirnen ersetzte, als Smart-Home-Systeme aufkamen — nicht weil jemand einen Buchvertrag brauchte. Wie ich in Management-Frameworks und die Nähe zu Schlangenöl dargelegt habe, begünstigen die Anreizstrukturen in der Software-Beratung den Verkauf von Prozessen gegenüber überprüfbaren Ergebnissen.

Elektriker erleben nicht die Annahme, dass Geschwindigkeit Abkürzungen erfordert. Wenn ein Gebäude schneller elektrisch ausgestattet werden muss, stellt man mehr Elektriker ein oder zahlt Überstunden. Man bittet die vorhandenen Elektriker nicht, die Erdung wegzulassen oder dünnere Kabel zu verwenden. Die Vorschrift erlaubt es nicht. Der Prüfer wird es nicht abnehmen. Das Gebäude funktioniert nicht sicher ohne sie.

Der Ausweg

Was kann Software-Entwicklung also von Elektroarbeit lernen? Nicht alles lässt sich übertragen — Software ist tatsächlich komplexer und variabler — aber einiges schon.

Objektive Signale schaffen. Kontinuierliche Integration, die besteht oder fehlschlägt. Automatisierte Tests, die durchlaufen oder brechen. Auslieferungspipelines, die entweder funktionierende Software liefern oder nicht. Diese sind nicht perfekt — sie erfordern immer noch Urteilsvermögen darüber, was getestet und gemessen werden soll — aber sie sind objektiver als Status-Meetings und Vertrauensabstimmungen.

Arbeit sichtbar machen. Nicht durch Folien und Berichte — durch funktionierende Software. Häufig ausliefern, damit Stakeholder sehen können, was existiert, anstatt nur davon zu hören. Wenn die Funktion in Produktion läuft, endet der Narrativwettbewerb. Entweder können Nutzer die Sache tun oder nicht.

Standards kodifizieren. Interne Programmierstandards, architektonische Entscheidungsprotokolle, Sicherheitsanforderungen mit automatisierter Durchsetzung. Diese haben keine Gesetzeskraft, aber sie etablieren Erwartungen, die den Interpretationsspielraum reduzieren.

Anerkennen, was nicht zu ändern ist. Manche Subjektivität ist Software inhärent. Anforderungen werden sich ändern, weil sich die Welt ändert. Erfolgskriterien werden unscharf bleiben, weil Unternehmen in unscharfen Umgebungen operieren. Man kann das nicht eliminieren — man kann nur aufhören, so zu tun, als existiere es nicht. Ehrliche Unsicherheit ist besser als falsche Präzision.

Der Kernunterschied

Elektroarbeit bleibt faktenbasiert, überprüfbar und unbeeinflusst von Mode oder Management-Frameworks. Das Licht geht an. Der Stromkreis ist geschützt. Der Prüfaufkleber kommt auf den Verteiler.

Software-Entwicklung wird narrativgetrieben, weil die Arbeit unsichtbar ist. Meinungsbeladen, weil Qualität früh schwer zu beurteilen ist. Management-kontrolliert, weil messbare Ingenieurdisziplin oft fehlt.

Wenn das nächste Mal jemand fragt, warum Entwickler Einmischung erleben, die Elektriker nicht haben, haben Sie die Antwort: Elektriker arbeiten mit objektiver Realität. Entwickler arbeiten in einem Narrativvakuum, das jeder füllen will.

Die Lösung ist nicht, Elektriker zu werden — Software ist tatsächlich anders. Die Lösung ist, genug objektive Signale zu schaffen, dass das Narrativvakuum schrumpft. Wenn die Auslieferungspipeline grün ist, wenn Produktionsmetriken zeigen, dass Nutzer ihre Aufgaben erledigen, wenn der Code alle automatisierten Prüfungen besteht — das werden zu den Fakten, die begrenzen, wie viel Meinung eindringen kann.

Nicht jede Diskussion wird enden. Aber manche werden es. Und das ist ein Anfang.