Zum Inhalt springen

Wissensbasis

Senior Engineering Skills

Senior Engineers werden weniger an ihrem Code gemessen als an den Fähigkeiten drumherum: Meetings leiten, Design Docs schreiben, ohne Weisungsbefugnis führen, Kämpfe auswählen und Feedback annehmen. Agentisches Arbeiten erhöht den Einsatz, denn Design Docs und gemeinsame Konventionen werden zum Kontext, aus dem KI-Agenten bauen.

Verfasst von

Aktualisiert:

Software Engineering 5

Unsere Position. Wer mit Agenten wirksam entwickeln will, braucht unserer Ansicht nach mindestens ein Niveau näher am heutigen Senior Architect als am heutigen Mid-Level Engineer. Karrierestufen, gebaut für knappen Code-Output, zielen heute auf die falsche Fähigkeit. Stuft Leute nach der Qualität ihrer Entscheidungen ein, nicht danach, wie viel Arbeit sie beaufsichtigen (skills outrank titles (öffnet in einem neuen Tab)).

Die 23 Skills stammen aus An incomplete list of skills senior engineers need, beyond coding (öffnet in einem neuen Tab), erstmals veröffentlicht am 22. September 2020. Sie gelten vom Senior- bis zum Staff-Level und darüber hinaus. Zu jedem Skill steht eine Notiz, was sich ändert, wenn Agenten den Code schreiben.

Wie kommunizieren Senior Engineers, und wie nehmen sie Einfluss?

1. Ein Meeting leiten

Wie ihr ein Meeting leitet: Wer darin am meisten redet, leitet es deshalb noch nicht.

Ein Meeting zu leiten heißt, eine Agenda zu setzen, alle beim Thema zu halten, für Entscheidungen zu sorgen und Action Items nachzuverfolgen. Die lauteste Stimme im Raum treibt selten die Ergebnisse.

In der agentischen Ära: Meetings dienen zunehmend dazu, Entscheidungen zu treffen, die KI nicht autonom treffen kann. Wenn ihr ein Meeting nicht effizient leiten könnt, verschwendet ihr die eine Ressource, die KI nicht ersetzen kann: die Zeit, die Menschen für ihr Urteil brauchen.

2. Design Docs schreiben

Wie ihr ein Design Doc schreibt, Feedback aufnehmt und es in vertretbarer Zeit zur Entscheidung bringt.

Ein Design Doc ist kein Roman. Es benennt das Problem, schlägt eine Lösung vor, listet geprüfte Alternativen auf und zeigt Risiken. Feedback aufnehmen heißt, das Doc wirklich zu ändern, statt jeden Satz zu verteidigen. Zur Entscheidung bringen heißt, eine Deadline zu setzen und zu entscheiden, auch bei unvollständiger Information.

In der agentischen Ära: Design Docs sind Kontext für KI-Agenten. Ein gut geschriebenes Design Doc wird zum System Prompt für jeden Agenten, der eure Codebase anfasst. Aus schlecht geschriebenen entsteht schlecht generierter Code. Diese Fähigkeit war wichtig, jetzt trägt sie das Ganze.

3. Ranghohen Personen technische Konzepte erklären

Wie ihr einer ranghohen Person hinter verschlossenen Türen ein technisches Konzept erklärt, wenn sie sich schämt, offen zuzugeben, dass sie es nicht versteht.

Das verlangt Empathie, keine Herablassung. Die ranghohe Person hat Kontext, der euch fehlt (Budget, Politik, Strategie). Ihr habt Kontext, der ihr fehlt (wie das System wirklich funktioniert). Eure Aufgabe ist, diese Lücke zu überbrücken, ohne dass sie sich klein fühlt.

In der agentischen Ära: Nicht-technische Führungskräfte entscheiden heute über KI-Tooling, Agentenarchitekturen und die Grenzen der Automatisierung. Wenn ihr einem VP nicht ohne Jargon erklären könnt, was “context engineering” bedeutet, fallen schlechte Entscheidungen im großen Maßstab.

4. Projektstatus kommunizieren

Wie ihr Stakeholdern den Projektstatus vermittelt.

Stakeholder interessieren sich nicht für eure Sprint-Velocity oder eure Story Points. Sie wollen wissen: Liegen wir im Plan, was sind die Risiken, und braucht ihr etwas von mir? Lernt, die Engineering-Realität in Business-Sprache zu übersetzen, ohne dabei zu lügen.

In der agentischen Ära: KI-beschleunigte Delivery verschiebt Zeitpläne unvorhersehbar. Status zu kommunizieren, wenn schon die Velocity selbst schwankt, verlangt noch mehr Können. “The AI wrote it fast but we are still validating” ist ein Status, den eure Stakeholder verstehen müssen.

5. Das Management von einer Investition überzeugen

Wie ihr das Management überzeugt, dass es in ein nicht-triviales technisches Projekt investieren muss.

Das Management spricht ROI, Risiko und Zeitplan. Ihr müsst “we need to refactor the auth system” übersetzen in “we are losing X hours per week and risking Y in security exposure.” Zahlen schlagen Leidenschaft, jedes Mal.

In der agentischen Ära: Genau diese Fähigkeit braucht ihr, damit die Führung investiert: in Context-Engineering-Infrastruktur, saubere CLAUDE.md-Dateien, Architecture Decision Records und agentenfreundliche Codebases. Der ROI ist real, aber für alle, die es noch nicht in Aktion erlebt haben, nicht offensichtlich.

6. Andere Teams beeinflussen

Wie ihr ein anderes Team dazu bringt, eure Lösung zu nutzen, statt eine eigene zu schreiben.

Das ist Vertrieb, ob es euch gefällt oder nicht. Ihr müsst verstehen, was dem anderen Team wichtig ist. Zeigt, wie eure Lösung seine Bedürfnisse erfüllt, und macht die Übernahme leichter als den Eigenbau. Niemand übernimmt eure Library, weil sie technisch überlegen ist. Teams übernehmen sie, weil sie ihr Problem mit weniger Aufwand löst.

In der agentischen Ära: KI-Agenten arbeiten über Teamgrenzen hinweg. Gemeinsame Lösungen, gemeinsamer Kontext, gemeinsame Konventionen: Die Kosten der Zersplitterung vervielfachen sich, wenn die KI-Agenten jedes Teams inkompatiblen Output liefern.

7. Sich wiederholen

Wie ihr euch oft genug wiederholt, bis die Leute zuhören.

Etwas einmal zu sagen ist keine Kommunikation. Kommunikation heißt, es im Meeting zu sagen, im Doc aufzuschreiben, im PR-Review zu erwähnen und im 1:1 anzusprechen. Die Leute haben viel zu tun. Eure Botschaft konkurriert mit Hunderten anderen. Wiederholung ist kein Nörgeln, so nehmen Organisationen Information auf.

In der agentischen Ära: Context Engineering ist buchstäblich die Disziplin, die richtige Information zur richtigen Zeit verfügbar zu machen. Wenn ihr das bei Menschen nicht schafft, schafft ihr es bei Agenten auch nicht.

Wie führen und mentoren Senior Engineers andere?

8. Mentoring auf jeder Stufe

Wie ihr Teammitglieder am Karrierebeginn mentort, Engineers in der Karrieremitte und neue Manager:innen, die technischen Rat brauchen.

Jede Gruppe braucht einen anderen Ansatz. Engineers am Karrierebeginn brauchen Leitplanken und Ermutigung. Engineers in der Karrieremitte brauchen Herausforderung und eigene Verantwortung. Neue Manager:innen brauchen ehrlichen technischen Rat, ohne dass ihr ihre Autorität untergrabt. Ein einziger Mentoring-Stil passt nicht für alle.

In der agentischen Ära: Mentoring heißt heute auch, Menschen den wirksamen Umgang mit KI beizubringen. Wer am Karrierebeginn vom ersten Tag an mit KI-Agenten pairt, entwickelt sich anders als jemand, der zuerst allein programmieren gelernt hat. Euer Mentoring muss das berücksichtigen.

9. Führen ohne Weisungsbefugnis

Wie ihr ein Projekt leitet, obwohl keine der beteiligten Personen an euch berichtet.

Das ist die Kernfähigkeit von Staff Engineers. Ihr könnt niemandem sagen, was zu tun ist. Ihr könnt nur dafür sorgen, dass die Leute das Richtige tun wollen. Dafür setzt ihr eine klare Vision, räumt Hindernisse weg und macht das Beitragen leicht. Einfluss schlägt Autorität, jedes Mal.

In der agentischen Ära: Ihr führt jetzt Menschen und KI-Agenten zugleich. KI-Agenten brauchen klaren Kontext, sauber definierte Grenzen und gute architektonische Guardrails. Genau das brauchen auch menschliche Teams von ihren technischen Führungskräften.

10. Jemandem zur Beförderung verhelfen

Wie ihr jemandem zur Beförderung verhelft.

Ihr gebt der Person sichtbare Projekte und setzt euch für sie in Runden ein, in denen sie nicht sitzt. Ihr sprecht ehrlich über ihre Lücken und coacht sie, ihre Wirkung zu zeigen. Es gehört zum Großzügigsten, was Senior Engineers tun können.

In der agentischen Ära: Die Fähigkeiten für eine Beförderung verschieben sich. Wer heute jemandem zur Beförderung verhilft, hilft der Person, Wirkung in einer KI-gestützten Umgebung zu zeigen. Dort hebt reines Output-Volumen niemanden mehr ab.

11. Anderen beibringen, dass ihnen etwas wichtig ist

Wie ihr anderen Engineers beibringt, dass ihnen wichtig wird, was euch wirklich wichtig ist (Operations, Korrektheit, Testing, Codequalität, Performance, Einfachheit usw.).

Ihr könnt niemanden zwingen, dass ihm etwas wichtig ist. Ihr könnt aber zeigen, was passiert, wenn es egal ist. Lasst sie den Schmerz eines Produktionsvorfalls spüren, den übersprungene Tests verursacht haben. Lasst sie die Schönheit eines gut entworfenen Systems sehen. Haltung steckt an, lehren lässt sie sich nicht.

In der agentischen Ära: Engineers beizubringen, dass ihnen Codequalität wichtig ist, zählt mehr denn je. KI-generierter Code, den niemand sorgfältig reviewt, wird zu technischen Schulden in Maschinengeschwindigkeit. Wer in einem Team mit agentengeschriebenem Code für die Codequalität sorgt, ist ganz auf diese Fähigkeit angewiesen.

Wie bewegen sich Senior Engineers in der Organisationspolitik?

12. Senior Manager:innen entgegenkommen

Wie ihr Senior Manager:innen begegnet, die über Technik reden wollen, ohne sie wirklich zu verstehen. Ihr rollt dabei nicht mit den Augen und lasst sie sich nicht dumm fühlen.

Senior Manager:innen, die über Technologie reden wollen, sind eure Verbündeten. Sie versuchen, eure Welt zu verstehen, um sie unterstützen zu können. Holt sie dort ab, wo sie stehen. Beantwortet ihre Fragen ehrlich. Korrigiert ihre Fehlannahmen behutsam. Die Alternative sind Manager:innen, die nicht mehr fragen und anfangen zu raten.

In der agentischen Ära: Jedes Mitglied der Unternehmensleitung hat heute eine Meinung zu KI. Manche sind fundiert, viele nicht. Wie gut ihr ihre Begeisterung aufgreift und sie zur Realität lenkt, beeinflusst direkt, ob eure Organisation KI vernünftig oder chaotisch einführt.

13. Kämpfe auswählen

Wie ihr eure Kämpfe auswählt.

Ihr könnt nicht jeden Kampf führen. Nicht jeder Streit lohnt den vollen Einsatz. Die Kunst liegt darin zu wissen, welche Kämpfe langfristig zählen und welche nur dem Ego dienen. Spart euer politisches Kapital für die Kämpfe, die Codebase, Team oder Produkt wirklich betreffen.

In der agentischen Ära: Die Zahl möglicher Kämpfe ist explodiert. KI-Codestil, Grenzen für Agenten, Praktiken im Kontextmanagement, welche Tools ihr einführt: Ihr könnt nicht alle ausfechten. Wählt die, deren Wirkung sich verzinst.

14. Netzwerken und Flurfunk

Wie ihr erfahrt, was wirklich passiert (wie ihr tratscht, wie ihr netzwerkt).

Das Organigramm zeigt euch die formale Struktur. Der Flurfunk zeigt euch die echte. Wer trifft tatsächlich die Entscheidungen? Welches Projekt wird demnächst gestrichen? Wer steht kurz vor dem Absprung? Dabei geht es nicht darum, politisch zu taktieren. Es geht darum, die Information zu haben, die ihr für gute Entscheidungen braucht.

In der agentischen Ära: Entscheidungen zur KI-Einführung fallen schnell und oft informell. Wenn ihr wisst, dass ein anderes Team einen bestimmten Ansatz schon erfolglos versucht hat, spart euch das Monate. Das informelle Netzwerk ist euer Frühwarnsystem.

15. Anderen sagen, dass sie falschliegen

Wie ihr anderen sagt, dass sie falschliegen, ohne dass sie sich schämen müssen.

“I think there might be a problem with this approach” funktioniert besser als “this is wrong.” Richtet den Blick auf die Idee, nicht auf die Person. Bietet Alternativen an. Macht daraus ein Gespräch, kein Urteil. Das Ziel ist ein besseres Ergebnis, kein Sieg.

In der agentischen Ära: KI erzeugt plausibel wirkenden Code, der subtil falsch ist. Ihr werdet Kolleg:innen sagen müssen, dass ihre KI-generierte Lösung Probleme hat. Dabei dürft ihr nicht andeuten, sie seien inkompetent, weil sie der KI vertraut haben. Das verlangt Fingerspitzengefühl.

Welche persönlichen Gewohnheiten lassen Senior Engineers weiter wachsen?

16. Um Hilfe bitten

Wie ihr andere Engineers dazu bringt, etwas für euch zu tun: Ihr bittet so um Hilfe, dass sie sich wertgeschätzt fühlen.

“Can you help me with X? You know more about this than I do” funktioniert. “Do this for me” funktioniert nicht. Menschen wollen sich kompetent und geschätzt fühlen. Formuliert eure Bitte als Anerkennung ihrer Expertise, nicht als Aufgabenzuweisung.

In der agentischen Ära: KI beantwortet viele Fragen. Zu wissen, wann ihr statt einer KI einen Menschen fragt und wie ihr das gut macht, unterscheidet wirksame Engineers von isolierten.

17. Zuhören, ohne sich bedroht zu fühlen

Wie ihr den Ideen anderer Engineers zuhört, ohne euch bedroht zu fühlen.

Wenn jemand anderes eine gute Idee hat, schmälert das eure nicht. Ist der andere Ansatz besser, macht euch seine Übernahme klüger, nicht schwächer. Engineers, die nicht zuhören können, ohne sich zu verteidigen, hören auf zu wachsen.

In der agentischen Ära: KI wird Ansätze vorschlagen, an die ihr nicht gedacht habt. Engineers, die sich von den Vorschlägen einer Maschine bedroht fühlen, bekämpfen jede KI-generierte Empfehlung. Wer Ideen nach ihrem Wert beurteilt, egal woher sie kommen, wird aufblühen.

18. Andere Engineers zum Zuhören bringen

Wie ihr andere Engineers dazu bringt, euren Ideen zuzuhören, ohne dass sie sich bedroht fühlen.

Stellt Ideen zur Diskussion, statt sie als beschlossene Sache zu präsentieren. “What if we tried X?” lädt zur Zusammenarbeit ein. “We should do X” lädt zum Widerstand ein. Legt eure Begründung offen. Benennt Tradeoffs. Macht es den Leuten leicht, ja zu sagen.

In der agentischen Ära: Wer KI-getriebene Änderungen an eingespielten Workflows vorschlägt, löst Abwehr aus. Agentische Praktiken einzuführen, ohne das Kompetenzgefühl der Leute zu bedrohen, ist entscheidend für jede Engineering-Führungskraft, die die Einführung vorantreibt.

19. Das eigene Baby abgeben

Wie ihr euer Baby abgebt, das Projekt, das ihr zu etwas Großartigem aufgebaut habt, damit ihr etwas anderes machen könnt.

Eure Identität ist nicht der Code, den ihr geschrieben habt. Ein Projekt zu übergeben heißt, seine Pflege jemand anderem anzuvertrauen, auch wenn diese Person es anders pflegt als ihr. Wer zu lange festhält, bremst das eigene Wachstum und das der anderen.

In der agentischen Ära: KI wird Code refactoren, umschreiben und umbauen, an dem ihr monatelang gefeilt habt. Hängt euer Ego an bestimmten Implementierungen statt an Ergebnissen, kämpft ihr eure ganze Karriere lang gegen das Unvermeidliche.

20. Negatives Feedback annehmen

Wie ihr negatives Feedback souverän annehmt.

Negatives Feedback sind Daten, kein Angriff. Dankt der Person, dass sie es euch sagt. Stellt klärende Fragen. Lasst es sacken, bevor ihr reagiert. Am schnellsten verbessern sich die Engineers, denen andere gefahrlos ehrliches Feedback geben können.

In der agentischen Ära: KI-Code-Review-Tools geben euch ständig Feedback, und zwar ohne Diplomatie. Wenn ihr schon mit unverblümter Kritik von Menschen nicht umgehen könnt, wird automatisierte Kritik im großen Maßstab zur Qual.

21. Interessante Arbeit finden

Wie ihr selbst interessante Arbeit findet, statt zu warten, bis jemand sie euch bringt.

Interessante Arbeit taucht nicht auf eurem Jira-Board auf. Sie liegt in der Lücke zwischen dem, was das System tut, und dem, was es tun sollte. Lest die Codebase. Sprecht mit Nutzer:innen. Schaut euch Metriken an. Befördert werden die Engineers, die ihre Arbeit selbst finden.

In der agentischen Ära: KI übernimmt die Routineaufgaben. Übrig bleiben die interessanten Aufgaben, bei denen es keine eindeutige Lösung gibt und Urteilsvermögen gefragt ist. Engineers, die diese Arbeit erkennen und für sich beanspruchen, sind unbezahlbar. Wer auf zugeteilte Aufgaben wartet, bekommt die zugeteilt, die KI nicht erledigen kann. Interessant sind diese Aufgaben deshalb noch lange nicht, sie sind bloß übrig geblieben.

Wie liefern Senior Engineers Wert und gewinnen Rückhalt?

22. Inkrementell Wert liefern

Wie ihr Software baut und dabei schrittweise Wert liefert.

Big-Bang-Releases sind ein Glücksspiel. Inkrementell Wert zu liefern heißt, dass jede Woche etwas für die Nutzer:innen besser wird. Dafür braucht es die Disziplin, Arbeit in sinnvolle Inkremente zu schneiden statt bloß in technische Schichten. “We refactored the database” ist kein Wert. “Users can now search 10x faster” ist einer.

In der agentischen Ära: KI beschleunigt die Implementierung, aber nicht die Validierung. Inkrementelle Delivery wird dadurch noch wichtiger. Die Lücke zwischen “built” und “verified” wächst, wenn Code schneller entsteht, als er sich testen und deployen lässt.

23. Proposals ausarbeiten

Wie ihr ein Projekt-Proposal ausarbeitet, es in der Organisation streut und Rückhalt für die Umsetzung gewinnt.

Ein Proposal braucht eine klare Problembeschreibung, einen Lösungsvorschlag, eine Kosten-Nutzen-Analyse, Risiken und einen Zeitplan. Streuen heißt, es vor dem formalen Review mit den wichtigsten Stakeholdern zu teilen, damit es keine Überraschungen gibt. Rückhalt gewinnen heißt, dass sich die Leute als Teil der Entscheidung fühlen, statt dass ihnen etwas verkauft wird.

In der agentischen Ära: Wer KI-getriebene Initiativen vorschlägt, braucht eine zusätzliche Ebene Überzeugungsarbeit. Ihr müsst auf Angst, Unsicherheit und berechtigte Bedenken zu Qualität und Kontrolle eingehen. Ein gut ausgearbeitetes Proposal für agentisches Arbeiten ist teils technisches Dokument, teils Change-Management-Plan.

Woran zeigen diese Skills, ob ein Team bereit für agentisches Arbeiten ist?

Diese 23 Skills entsprechen direkt den Lücken, die wir in Engineering-Organisationen sehen, die agentische Praktiken einführen. Technisches Können mit KI-Tools ist notwendig, reicht aber nicht. Erfolg mit agentischem Engineering haben die Organisationen, in denen Senior Engineers diese Skills schon haben oder sie aktiv entwickeln.

Wenn ihr Engineering-Teams auf ihre Bereitschaft für agentisches Arbeiten prüft, bewertet diese Skills neben der technischen Kompetenz. Angenommen, ein Team brillanter Coder:innen kann keine Meetings leiten, keine Design Docs schreiben und sich kein ehrliches Feedback geben. Dann tut es sich mit der KI-Einführung genauso schwer wie ein Team, das nicht programmieren kann.

Zentrale Fragen für die Bewertung:

  • Können eure Senior Engineers Design Docs schreiben, die KI-Agenten als wirksamer Kontext dienen würden?
  • Wissen eure Tech Leads, wie sie neue Praktiken einführen, ohne ihre Teams zu bedrohen?
  • Können eure Staff Engineers über Teamgrenzen hinweg Einfluss nehmen?
  • Finden eure Engineers interessante Probleme, oder warten sie, bis man ihnen Arbeit zuteilt?

Die Antworten sagen euch mehr über die Bereitschaft für agentisches Arbeiten als jede technische Bewertung.

Verwandte Seiten

Quellen

Artikel

Posts

  • Skills outrank titles (öffnet in einem neuen Tab) - LinkedIn-Post mit dem Argument, dass Karrierestufen Engineers nach Entscheidungsqualität einstufen sollten, weil wirksames agentisches Arbeiten das Urteilsvermögen eines Senior Architects braucht.