Karrierepfade bei MIC: Vom Feature-Shipping zur technischen Reife – so wächst du als Software Engineer

Der Auftakt: Eine defekte Heizung und die wahre Bedeutung von Seniorität

David Theil beginnt seine Session mit einem Bild, das sofort hängen bleibt: Winter, es wird kalt, die Heizung fällt aus – und zwei Techniker lösen dasselbe Problem völlig unterschiedlich. Der erste tauscht lediglich eine durchgebrannte Sicherung. Der zweite findet zusätzlich die eigentliche Ursache: ein korrodierter Sensor, ausgelöst durch ein Leck. Erst die Kombination aus richtiger Diagnose, passenden Werkzeugen und ganzheitlicher Reparatur löst das Problem nachhaltig.

Aus unserer DevJobs.at-Perspektive ist das der rote Faden der Session „How our career paths help you grow as a Software Engineer“ von David Theil (MIC): MIC hat eine klare, systematische Antwort darauf entwickelt, wie Software Engineers in einer Welt zunehmender technischer und fachlicher Komplexität wachsen – und zwar entlang nachvollziehbarer Rollen, mit einem Kompetenzmodell und wiederkehrendem Feedback als Motor.

Der Problemraum: Cloud-Plattform für Zoll- und Außenhandels-Compliance

Um die Karrierepfade zu verstehen, lohnt ein Blick auf den Kontext. MIC baut laut David eine Cloud-Plattform für Customs & Trade Compliance, die von global agierenden Unternehmen genutzt wird, um Waren international zu produzieren und über Grenzen hinweg zu versenden – inklusive anspruchsvoller Zollmeldungen und Compliance-Prozesse. Das ist inhärent komplex: unterschiedliche Regularien, länderübergreifende Regeln, verteilte Prozesse und hohe Datenqualitätserwartungen.

David skizziert außerdem die Breite der Techniklandschaft über einen Tech-Radar, der – ohne ins Detail zu gehen – den Alltag von MIC-Engineers rahmt: Programmiersprachen, Frameworks, Techniken, Plattformen und Tools. In Summe entsteht ein Bild stetig wachsender Komplexität, die nicht nur MIC betrifft, sondern die gesamte Softwarebranche.

Warum Jahre allein nicht zur Seniorität führen

David stellt den verbreiteten Standardpfad infrage: „Fünf Jahre im Job, jetzt bin ich Senior.“ Sein Einwand ist präzise:

Gegen dieses Missverständnis setzt MIC ein strukturiertes Entwicklungsmodell. Nicht Tenure, sondern nachweisbare Kompetenzen, Verantwortung und Wirkung entscheiden über die Seniorität. Und das lässt sich im Arbeitsalltag messen: Wer findet Ursachen, statt nur Symptome zu beheben? Wer baut das Umfeld, in dem Teams nachhaltig liefern? Wer skaliert Wissen und verändert Technik-Routinen über Teamgrenzen hinweg?

Der Karrierepfad bei MIC: Keine Hierarchie, sondern Entwicklungsachsen

David präsentiert eine Grafik, die wir als Achsenmodell verstehen: zwischen operativen und strategischen Aufgaben sowie zwischen Fokus auf Technical Excellence und auf Lead-Aufgaben. Wichtig: Es handelt sich explizit nicht um eine Hierarchie, sondern um Entwicklungsrichtungen. Einstiegspunkte sind Junior Software Engineer oder Software Engineer; von dort aus zweigen zwei Pfade ab, die beide zur Rolle des Principal Software Engineer führen können:

• Technischer Pfad: Software Engineer → Senior Software Engineer (Fokus technische Exzellenz)
• Leadership-Pfad: Software Engineer → Lead Software Engineer (Fokus Team- und Umfeldgestaltung)
• Zielbild (beider Pfade): Principal Software Engineer (höchste Reifestufe im Unternehmen)

Diese Klarheit ist entscheidend: Nicht jede Karriere muss People Management einschließen, und nicht jede Leitungsrolle ist Management – der Lead Software Engineer ist ein technischer Lead, kein Vorgesetzter. Beide Pfade haben Gewicht, beide benötigen Reife, und beide können zur höchsten Wirkungsebene führen.

Rollen im Detail: Aufgaben, Wirkung, Reife

Junior/Software Engineer: Wert liefern und Lernen professionalisieren

In den Einstiegsrollen liegt der Schwerpunkt auf dem Liefern von Kundennutzen:

• Features entwickeln
• Bugs beheben
• Nutzerbedürfnisse und -anforderungen verstehen
• Automatisierte Tests schreiben

Ein zweiter, gleichwertiger Block: lernen. David betont, wie wichtig es ist, Lernzeit nicht als „nice to have“, sondern als professionellen Teil der Rolle zu betrachten. Es geht darum, die Domäne zu verstehen, Architekturprinzipien zu verinnerlichen, die Werkzeuge zu beherrschen – und so die Grundlage für die nächsten Schritte zu legen.

Senior Software Engineer: Technische Exzellenz und Vorbildwirkung

Seniors liefern weiterhin Features und Kundennutzen – aber mit erweitertem Fokus:

• Coaching und Mentoring anderer
• Vorbildfunktion in Codequalität, Architektur- und Tool-Entscheidungen
• Systemdesign und die Auswahl „der richtigen Werkzeuge“
• Aktives Anheben der technischen Standards im Team

Kurz: Senior sein heißt, nicht nur selbst hochwertige Lösungen zu bauen, sondern das System zu verbessern, in dem Lösungen entstehen. Das ist der Schritt vom „Sicherung tauschen“ zur Ursachenanalyse und nachhaltigen Reparatur.

Lead Software Engineer: Ein tragfähiges Teamumfeld schaffen

Der Lead Software Engineer liefert ebenfalls Kundennutzen, ist jedoch primär technischer Lead und kein Manager. Der Fokus liegt auf dem viablen Team:

• Technische Leitung ohne formale Personalverantwortung
• Ein Umfeld schaffen, in dem andere wachsen und wirksam werden
• Prozesse, Praktiken und Zusammenarbeit so formen, dass die Teamleistung steigt

Damit verschiebt sich der Schwerpunkt Richtung strategischer Arbeit am System – nicht statt, sondern zusätzlich zur Projekt- und Produktarbeit.

Principal Software Engineer: Wissen skalieren und Veränderung gestalten

Die höchste Reifestufe kombiniert technische Exzellenz mit Change Management über Teamgrenzen hinweg:

• Neue Techniken und Tools in mehreren Teams einführen
• Wissen über Abteilungen hinweg skalieren
• Die Tech-Strategie des Unternehmens mitprägen, die Teams dann umsetzen

Ein Principal ist damit nicht „nur der beste Coder“, sondern jemand, der technische Entwicklung als Organisationsfunktion begreift und systematisch in Breite bringt.

Das Kompetenzmodell: „Skills Spiderweb“ mit 27 Kernkompetenzen

MIC hat die Rollenbilder mit einem feingliedrigen Kompetenzmodell unterlegt. Das Skills Spiderweb umfasst 27 Kernskills, die ein Software Engineer mitbringen und aufbauen sollte. David geht nicht in die Details der einzelnen Skills hinein – entscheidend ist der Zweck:

• Die eigene Rolle verstehen
• Die relevanten Kompetenzen erkennen
• Eine Entwicklung planen und transparent messen

Diese Transparenz schafft eine gemeinsame Sprache: Wo stehe ich auf meinem Pfad? Welche Lücken sind relevant? Welche Maßnahmen helfen konkret?

Feedback als Motor: 180°-Formate und fortlaufende Zyklen

Entwicklung passiert nicht „nebenbei“. David beschreibt 180°-Feedbackprozesse, die regelmäßig wiederholt werden und detailreiches, handlungsnahes Feedback ermöglichen. Ein Beispiel aus der Session: Eine Kollegin oder ein Kollege möchte Testgetriebene Entwicklung (TDD) vertiefen – das Team identifiziert Maßnahmen und erarbeitet einen Plan, wie diese Kompetenz schrittweise aufgebaut wird.

Wichtig aus unserer Sicht: Das Feedback ist nicht Selbstzweck. Es greift dort, wo der Job Wirkung entfaltet – im Code, in Architekturentscheidungen, in der Zusammenarbeit, in der Wirkung auf andere. So wird Feedback zu einem Navigationsinstrument, nicht zu einer Beurteilungsroutine.

Der Lernrahmen: MIC Academy, Konferenzen, Mentoring und Coaching

Um individuelles Wachstum zu ermöglichen, beschreibt David mehrere Bausteine:

• Ein Trainingsrahmen („MIC Academy“) für die passenden Inhalte
• Konferenzbesuche, um Impulse und Best Practices aufzunehmen
• Mentoring und Coaching durch Erfahrene – ausdrücklich Teil ihrer Jobbeschreibung

Das Bild, das entsteht: Lernen ist nicht nur selbstgesteuert, sondern systemisch unterstützt. Seniorität heißt auch, andere hochzuziehen. Dieser Gedanke zieht sich durch alle Rollenbeschreibungen.

Operativ vs. strategisch – und warum beides zählt

David ordnet die Arbeiten entlang zweier Spannungsfelder: operativ vs. strategisch und Lead-Fokus vs. Technik-Fokus. Im Alltag bedeutet das:

• Operatives Arbeiten liefert kurzfristigen Kundennutzen: Features, Bugfixes, Stabilisierung
• Strategisches Arbeiten verbessert das System: Architektur-Guardrails, Tooling, Praktiken, Wissensverteilung

Entwicklung im Karrierepfad heißt, strategische Wirkung zu erhöhen, ohne den Kontakt zur operativen Realität zu verlieren. Genau deshalb bleiben auch Seniors und Leads im Liefern – aber sie erhöhen den Hebel, indem sie Ursachen analysieren, Standards heben und Teams stärken.

Was wir aus der Session für den Alltag mitnehmen

Aus redaktioneller Sicht kristallisieren sich klare Leitlinien heraus, die sich sofort auf den eigenen Kontext übertragen lassen – unabhängig davon, ob man gerade in einer Junior-, Senior- oder Lead-Rolle unterwegs ist:

1. Ursache statt Symptom beheben: Frage dich bei jeder Störung, ob du die „Sicherung“ tauschst oder die eigentliche Ursache findest. Das erfordert Zeit für Diagnose, Messbarkeit und systemische Lösungen.
2. Lernzeit institutionalisieren: Plane Lernen als Bestandteil deiner Rolle. Ohne diese Investition stagniert die Reife – gerade in komplexen Domänen.
3. Rolle und Pfad klären: Entscheide bewusst, ob dein Schwerpunkt technische Exzellenz oder technische Führung ist. Beides ist wertvoll; beides verlangt unterschiedliche Kompetenzen.
4. Kompetenzen sichtbar machen: Nutze ein einfaches Spiderweb für deine Skills (auch außerhalb von MIC). Sichtbarkeit schafft Fokus und Fortschritt.
5. Feedback als Routine: Etabliere regelmäßige, klare Feedbackschleifen (z. B. 180°). Konkrete Beispiele, konkrete Maßnahmen, wiederkehrende Überprüfung.
6. Wirkung skalieren: Frage dich, wie du Wissen und Praktiken über Teamgrenzen hinweg hebst – das ist der Weg Richtung Principal.
7. Teamviabilität gestalten: Technische Führung bedeutet, ein Umfeld zu bauen, in dem andere wachsen können – Prozesse, Rituale, Tooling und Kultur.

Ein Blick auf den Tech-Radar – ohne Tool-Bingo

David verweist auf einen Tech-Radar (in einem anderen Talk bei MIC detaillierter vorgestellt). Für diese Session ist nur eines wichtig: Die Technologieoberfläche ist breit – Sprachen, Frameworks, Techniken, Plattformen, Tools. Das zeigt, wie viel Orientierung ein Team braucht, um die richtigen Entscheidungen zu treffen. Wir lesen daraus: Ohne klare Rollen und Feedbackzyklen verheddert man sich schnell in Optionen. Mit dem Karrierepfad-Modell lässt sich diese Breite strukturieren – wer wofür Verantwortung übernimmt, wie Entscheidungen vorbereitet werden, wie Lernen skaliert.

Reife messen: Nicht die Jahre, sondern die Wirkung

Das Modell aus Rollen, Skills und Feedback koppelt die Entwicklung an Wirkung:

• Auf der Ebene des Individuums: technische Tiefe, Diagnosefähigkeit, Architekturentscheidungen, Mentoring
• Auf der Ebene des Teams: Lieferfähigkeit, Qualität, Lernkultur, Stabilität
• Auf der Ebene der Organisation: standardisierte Praktiken, geteiltes Wissen, technologische Richtung

So entsteht eine Karrierearchitektur, in der „Senior“ und „Principal“ nicht Titel, sondern Beschreibung gelebter Verantwortung sind.

Praxisnaher Transfer: So setzt du die Ideen in deinem Kontext um

Auch wenn du nicht bei MIC bist, lässt sich das Modell adaptieren. Einige Ansatzpunkte, die sich unmittelbar aus Davids Session ableiten:

• Zeichne dein eigenes Spiderweb mit 10–15 Kernskills, die für deine Rolle zählen (z. B. Domänenverständnis, Systemdesign, Testautomatisierung, Incident-Diagnose, Mentoring). Markiere Ist- und Sollstand.
• Baue einen 8–12‑wöchigen Lernzyklus: ein klar definiertes Skillziel, 2–3 Maßnahmen (z. B. Katas, Pairing, interner Talk), Review mit Feedback.
• Lege gemeinsam mit deinem Team fest, welche Entscheidungen „Lead“ vs. „Senior“ vorbereitet – und wie die Entscheidungen dokumentiert werden.
• Plane monatlich eine Session, in der ihr nicht Features shippt, sondern Ursachen analysiert (Postmortems, Architektur-Schulternblicke, Toolchain-Verbesserungen).
• Halte die Unterscheidung zwischen operativ und strategisch sichtbar (z. B. im Board) – und schützt strategische Slots vor der Feature-Flut.

All das spiegelt Davids Kernbotschaft wider: Wachstum braucht Struktur. Struktur macht Lernen wiederholbar – und Wirkung messbar.

Was MIC dafür bereitstellt – und was wir daran schätzen

David spricht konkret aus, welche Elemente MIC verankert hat:

• Klar definierte Rollen (Software/Junior, Senior, Lead, Principal)
• Skills Spiderweb mit 27 Kernkompetenzen
• Regelmäßiges 180°-Feedback mit konkreten Maßnahmen
• MIC Academy, Konferenzen, Mentoring/Coaching als explizite Wachstumshebel

Die Kombination aus Rollenarchitektur, Kompetenzmodell und Feedback macht aus Karrierepfaden ein System – genau das, was komplexe Produkte und Organisationen brauchen, um nicht im Tagesgeschäft zu verharren.

Zitatwürdige Momente

Einige Stellen, die wir uns markiert haben:

Diese Sätze rahmen das Rollenverständnis und machen deutlich, dass Seniorität bei MIC Wirkung in Systemen bedeutet – nicht nur Erfahrung im Einzelbeitrag.

Fazit und Takeaways

Die Session „How our career paths help you grow as a Software Engineer“ von David Theil (MIC) liefert eine klare Lektion: Reife entsteht aus dem Zusammenspiel von klaren Rollen, sichtbaren Skills und wiederholbaren Feedbackzyklen, eingebettet in eine Lernumgebung aus Training, Konferenzen und Mentoring. In hochkomplexen Domänen – wie Zoll- und Außenhandels-Compliance – ist das kein Luxus, sondern Voraussetzung für nachhaltige Wirkung.

Die wichtigsten Takeaways für deinen nächsten Schritt:

• Definiere, welche Rolle du anstrebst (Senior vs. Lead) – und welche Wirkung damit verbunden ist
• Mache deine Skills sichtbar und plane gezielte Maßnahmen – klein genug für 8–12 Wochen, konkret genug für messbaren Fortschritt
• Etabliere Feedback, das zu Entscheidungen und Ergebnissen spricht – nicht zu Eindrücken
• Suche die Ursache, nicht nur die Sicherung – im Code, im Prozess, im Team
• Hebe Wissen über Teamgrenzen hinweg – der Weg Richtung Principal

Zum Schluss verweist David auf MICs Karriere-Seite für alle, die tiefer einsteigen möchten. Aus unserer Sicht: Wer die Metapher von der defekten Heizung nicht mehr vergisst, hat das Wichtigste verstanden. Seniorität ist kein Zeitpunkt – sie ist eine Praxis.

• 

  

  Technical Agile Enabling

  Pia Otter-Bäck von MIC gibt in ihrem devjobs.at TechTalk Einblick darüber, wie im Unternehmen das Thema Technical Agile Enabling umgesetzt wird.

  Jetzt ansehen
• 

  

  7 Powerful Questions to ask your Development Teams

  Philipp Dressler von MIC spricht in seinem devjobs.at TechTalk über sieben Grundgedanken, anhand welchen ein Team von Developern reibungslos zusammenarbeiten kann.

  Jetzt ansehen
• 

  

  The MIC Tech Radar

  Wolfgang Gassner von MIC zeigt in seinem devjobs.at TechTalk die Herangehensweise, wie im Unternehmen die riesige Zahl an verwendeten Technologien überschaubar gehandhabt werden.

  Jetzt ansehen
• 

  

  Organization for Fast Flow

  Gerald Schweizer von MIC beleuchtet in seinem devjobs.at TechTalk die wesentlichen Gedanken, wie und warum die Organisation der Development Teams im Unternehmen verändert worden ist.

  Jetzt ansehen

• 

  

  Clemens Kriechbaumer, Team Manager Data Science bei MIC

  Clemens Kriechbaumer von MIC spricht im Interview über den Aufbau des Data Science Teams und dessen Themenschwerpunkte, die dort eingesetzten Technologien und wie dort das Recruiting gestaltet ist.

  Jetzt ansehen
• 

  

  Wolfgang Gassner, Director Produktentwicklung bei MIC

  Der Director Produktentwicklung bei MIC Wolfgang Gassner gibt im Interview Einblicke über das Team, wie der Recruiting Prozess abläuft und wie das Unternehmen die technologischen Herausforderungen meistert.

  Jetzt ansehen