Das Geheimnis von Ingenieuren, die ihr Gehalt wert sind: die Fähigkeit, „Unklares (Ambiguity)“ in „Machbares“ zu verwandeln

Kernaussagen:

• Der entscheidende Unterschied zwischen Senior- und Mid-Level-Ingenieuren ist die Fähigkeit, unklare und mehrdeutige Probleme zu konkretisieren.
• Der Wert von Seniors liegt nicht im Coding-Können an sich, sondern darin, Projektrisiken zu beseitigen und sie in umsetzbare Pläne zu überführen.
• Die aktuellen Hiring-Praktiken (z. B. Algorithmus-Tests) scheitern daran, genau diese Fähigkeit zu bewerten.
• Echtes Wachstum beginnt mit der Übung, Probleme vor dem Coding klar zu definieren.

---

Einleitung: Die Definition von Senior Engineers neu denken

• Üblicherweise werden Senior Engineers über eine Liste verschiedener Fähigkeiten definiert, etwa Architekturdesign, Kommunikation und Leadership.
• Lässt man Titel, Gehalt und Berufsjahre außen vor, gibt es jedoch genau eine Kernkompetenz, die Engineers auf Senior-Level oder darüber unterscheidet: die „Fähigkeit, Unklarheit zu verringern“.
• Alle anderen Kompetenzen (etwa technische Umsetzung) sind Ergebnisse, die auf dieser Kernfähigkeit aufbauen.

Hauptteil

1. Unterschiedliche Arten der Problemlösung: Klarheit vs. Unklarheit

• Mid-Level-Ingenieure: Liefern hervorragende Ergebnisse, wenn klare Spezifikationen (Specs) und Randbedingungen vorgegeben sind. Sie sind stark darin, gut definierte Probleme zu lösen.
• Senior Engineers: Heben sich ab, wenn sie vage und abstrakte Anforderungen erhalten wie „Performance muss besser werden“, „mehr Nutzerbeschwerden“ oder „Skalierbarkeit berücksichtigen“.
• Seniors arbeiten solche unklaren Probleme nicht einfach nur ab, sondern analysieren und zerlegen sie und verwandeln sie in konkrete Aufgaben.

2. Die zentrale Rolle von Seniors ist es, Projektrisiken zu beseitigen

• Senior Engineers reduzieren Unsicherheit bei großen und abstrakten Problemen durch Ansätze wie diese:

• Sie stellen grundlegende Fragen, die sonst niemand stellt.

• Sie trennen wichtige Signale von Rauschen (Noise).

• Sie priorisieren, was sofort angegangen werden muss und was warten kann.

• Dieser Prozess senkt Projektrisiken (De-risking) und ordnet den Zustand „wir wissen nicht genau, was das ist“ in „kleine, umsetzbare Projekte und Dinge, die beseitigt werden müssen“.

• Wenn Seniors das gut machen, läuft ein Projekt reibungslos und wirkt von außen einfach — tatsächlich ist das jedoch das Ergebnis enormer „unsichtbarer Arbeit“, die im Vorfeld geleistet wurde.

3. Konkrete Ansätze, um Unklarheit aufzulösen

• Senior Engineers stellen vor dem Coding Fragen wie die folgenden, um das Problem zu klären:
• Das Wesen des Problems: Was ist nicht die gewünschte Lösung, sondern das eigentliche zugrunde liegende Problem, das wir lösen wollen?
• Definition der Nutzer: Wessen konkreten Schmerz wollen wir eigentlich lindern? (Das pauschale Wort „Nutzer“ vermeiden.)
• Überprüfung von Annahmen: Welche falschen Annahmen stecken versteckt im aktuellen Plan?
• Risikobewertung: Was ist der schlimmste Fall, wenn sich unsere Einschätzung als falsch erweist?

4. Die Grenzen des Hiring-Systems und falsche Auswahl von Seniors

• Die meisten Unternehmen konzentrieren sich im Hiring auf Listen von Tech-Stacks oder auf das Lösen von Algorithmusaufgaben (LeetCode).
• Auf diese Weise lässt sich jedoch nicht prüfen, ob jemand vage Produktanforderungen in umsetzbare Pläne übersetzen kann.
• Das Ergebnis sind vermeintliche Senior Engineers mit starken Coding-Skills, die aber bei unvollständigen Specs handlungsunfähig bleiben.

Fazit: Empfehlungen für Wachstum

• Architektur- oder Kommunikationsfähigkeiten sind wichtig, entfalten ihren Wert aber erst, nachdem klar ist, „was gebaut werden soll“.
• Technische Exzellenz ohne die Fähigkeit, Unklarheit zu reduzieren, ist letztlich nur „das falsche Problem elegant zu lösen“.
• Ob man wirklich auf Senior-Level ist, zeigt sich daran, ob man bei einer abstrakten Aufgabe auf die Klärungsarbeit anderer wartet oder sie selbst so konkret macht, dass das Team handeln kann.
• Das ist kein angeborenes Talent, sondern Übungssache. Wer ein vages Ticket bekommt, sollte also nicht sofort mit dem Coding beginnen, sondern trainieren, das Problem zunächst zu konkretisieren.