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.

[mhj5730]

Ich finde auch, dass der Versuch, Senior-Entwickler mit „algorithmischen Coding-Tests“ zu überprüfen, eine Grenze des Recruiting-Systems ist. Ich denke, dass Senior-Entwickler, die ihr Gehalt wert sind, diejenigen sind, die dem Kern eines Problems nähergekommen sind oder ihm näherkommen können.

[elbanic]

Aus diesem Beitrag lernt man, dass es je nach Blickwinkel ganz unterschiedlich sein kann. Nach meinen Maßstäben ist das Kriterium zur Unterscheidung zwischen Senior- und Mid-Level-Ingenieur:innen schlicht der Scope.
Ambiguity zu konkretisieren, gehört zu den grundlegenden Fähigkeiten von Ingenieur:innen, und ich finde, dass man das ab dem Mid-Level beherrschen sollte, damit der Titel Ingenieur:in angemessen ist. Insofern könnte dieser Beitrag für mich ein Kriterium sein, das Mid-Level- von Junior- (Associate-)Ingenieur:innen unterscheidet.

[bichi]

Bei Tests für Senior-Entwickler kann ich es noch nachvollziehen, wenn es sogar einen Programmier-Test gibt.
Aber wenn dann Algorithmusaufgaben gestellt werden, bin ich völlig fassungslos (so überrumpelt, dass ich mich nicht mal mehr daran erinnere).

[mbh023]

Technische Exzellenz, wenn man das Problem nicht klar definieren kann,
ist letztlich nichts weiter als „das falsche Problem elegant zu lösen“.

Ein wirklich schaurig treffender Satz

[baeba]

1. Die Kunst des Fragens und soziales Kapital (Social Capital)

• Strategische Unwissenheit: Die Fragen von Seniors entspringen nicht Unwissenheit, sondern sind absichtliche Handlungen, um Unsicherheit zu beseitigen. Eine zentrale Kompetenz ist es, grundlegende Fragen ("Wofür steht dieses Akronym?") ohne Scham zu stellen.
• Nutzung von sozialem Kapital: Anders als Juniors haben Seniors bereits „soziales Kapital“ (Vertrauen) aufgebaut und gelten deshalb nicht als unfähig, selbst wenn sie „dumme Fragen“ stellen. Es ist die Rolle von Seniors, dieses Kapital zu nutzen, um Unklarheiten in Meetings auszuräumen.
• Berücksichtigung des politischen Kontexts: Direkte Fragen können für Manager, die Klarheit meiden, als Bedrohung wirken. Deshalb ist ein hohes Maß an Fingerspitzengefühl gefragt, um politisch sichere Fragen auszuwählen, die das Projekt dennoch voranbringen.

2. Autonomie und Risikomanagement (Autonomy & Risk)

• Problemlösung ohne Sicherheitsnetz: Als Senior gilt, wer Probleme auch ohne externe Hilfe oder klare Vorgaben eigenständig durchdringen (Plough through) und zu Ende bringen kann.
• Chaos kontrollieren: Statt bedingungslos auf Klarheit zu bestehen, entscheiden Seniors situationsabhängig zwischen „Stopp“ und „Weiter“. Sie warten nicht auf perfekte Specs, sondern handeln auf Basis angemessener Annahmen und shippen, um Verwirrung zu verringern.
• Kalkuliertes Risiko eingehen: Dazu gehört, nicht kompilierenden Code zur Laufzeit zu korrigieren oder groß angelegte Refactorings durchzuziehen — also mutige technische Entscheidungen zu treffen, die Juniors nicht treffen können, und die Verantwortung für das Ergebnis zu übernehmen.

3. Titelinflation und die strukturellen Widersprüche beim Hiring

• Titelinflation (Title Inflation): Es ist weit verbreitet, unvorbereitete Juniors zu Seniors zu befördern, um Leistungskennzahlen zu erfüllen. Dadurch entsteht eine Lücke zwischen Titel und tatsächlicher Kompetenz.
• Grenzen der Einstellungsverfahren: Unternehmen konzentrieren sich beim Hiring nicht auf die Fähigkeit, vage Anforderungen zu konkretisieren, sondern nur auf das Lösen von Algorithmusaufgaben (LeetCode). Das Ergebnis ist eine Masse von „Seniors“, die ohne Specs nichts zustande bringen.
• Stellvertretende Übernahme der PM-Rolle: Senior Engineers verbringen viel Zeit damit, unfertige Konzepte (Half-baked specs) auszuarbeiten, die ein fauler PM hingeworfen hat. Das ist zwar auch eine Fähigkeit von Engineers, zugleich aber ein Beleg für organisatorische Ineffizienz.

4. Bloße Betriebszugehörigkeit (Tenure) vs. bewusstes Training

• Qualitativer Unterschied in der Berufserfahrung: „10 Jahre Wachstum“ und „1 Jahr Erfahrung, zehnmal wiederholt“ müssen klar voneinander unterschieden werden. Ein echter Senior entsteht durch bewusstes Üben und Herausforderungen außerhalb vertrauter Bereiche.
• If vs. What-if: Juniors konzentrieren sich darauf, vorgegebene Bedingungen (If) zu verarbeiten, während Seniors annehmen und vorbereiten, dass sich Bedingungen ändern könnten (What-if).
• Definition der Entwicklungsstufen: Ein branchenweit verbreitetes Modell unterscheidet zwischen der „Phase unter Anleitung (Junior)“ → „Phase der eigenständigen Ausführung (Regular)“ → „Phase der Anleitung anderer (Senior)“.

5. Skeptische Sicht auf den Senior-Titel

• Bloße Gehaltsstufe (Pay Grade): Es gibt die zynische Ansicht, dass die Bezeichnung „Senior“ weniger ein Indikator für Kompetenz als vielmehr eine administrative Kategorie ist, die HR für die Gehaltsfestlegung geschaffen hat.
• Unterschiede zwischen Unternehmen: Zwischen Seniors in Big Tech (die mit hoher Ambiguität und großem Scope umgehen) und Seniors in gewöhnlichen Unternehmen (oft nur langjährige Mitarbeiter) gibt es enorme Unterschiede bei Fähigkeiten und Vergütung.