Autonome Scrum-Teams, moderne Stacks und Polyglot-Engineering: Einblicke von Michael Eisenbart (Bosch-Gruppe Österreich)

Warum diese Techlead-Story zählt

Bei DevJobs.at suchen wir die Momente, in denen Führung, Teamorganisation und Technologie zu einer klaren Erzählung werden. In der Session mit dem Titel Michael Eisenbart, Senior Manager bei Bosch sprach Speaker Michael Eisenbart von der Bosch-Gruppe Österreich über genau diese Schnittmenge. Die Kernaussage, die sich durch das Gespräch zieht: global organisiert, lokal verantwortlich, technologisch auf Stand der Technik – und mit einem Hiring- und Teamfokus, der praktische Fähigkeiten und Flexibilität belohnt.

Wir fassen zusammen, was wir aus dieser Techlead-Story mitgenommen haben: Wie die Teams in sieben Ländern arbeiten, was 100 Prozent Produktverantwortung in autonomen Scrum-Teams bedeutet, wie Onboarding und Recruiting aufgebaut sind, welche Technologien heute den Ton angeben und warum Polyglot-Engineering und Teamrotation nicht nur Schlagworte, sondern gelebte Praxis sind.

Globale Organisation, lokale Verantwortung: sieben Länder, viele Produkte

Michael Eisenbart macht gleich zu Beginn deutlich, wie die Bosch-Gruppe hier aufgestellt ist: global organisiert und über sieben Länder gespannt. Zentral dabei ist, dass die Arbeit nicht künstlich über Ländergrenzen hinweg zerstückelt wird, sondern in dedizierten, eigenständigen Teams stattfindet.

• Autonome Scrum-Teams: Jedes Team arbeitet als selbstständiges Scrum-Team.
• Volle Produktverantwortung: Die Teams tragen 100 Prozent Verantwortung für ihr Produkt – ohne Split zwischen entfernten Teilteams.
• Nähe zum Kunden: Idealerweise ist das Team dort lokalisiert, wo die Kundschaft ist.
• Eigenständiger Stack: Jedes Team hat sein eigenes Produkt und seinen eigenen Technologie-Stack, den es selbst verwaltet.

Diese Architektur hat Konsequenzen: Autonomie ist nicht nur Methode, sondern Strukturprinzip. Wer hier arbeitet, findet klare Verantwortungsräume, in denen Entscheidungen über Produkt, Architektur und Tools tatsächlich im Team getroffen werden – dort, wo die Expertise sitzt und wo die Nähe zum Kunden die Weichen stellt.

Engineering-Kultur: Ownership, Pragmatismus und Lernbereitschaft

Die Kultur, die zwischen den Zeilen sichtbar wird, baut auf Ownership und Neugier auf. Wenn Teams ihre Stacks selbst verwalten und bewusst unterschiedlich arbeiten, bedeutet das: kein One-Size-Fits-All, sondern kontextgetriebene Entscheidungen. Diese Freiheit geht mit Erwartungen einher – zum Beispiel, sich in neue Stacks einzuarbeiten und mindestens zwei Programmiersprachen zu beherrschen.

• Verantwortung statt Vorgabe: Die Teams planen und liefern als Einheit – mit End-to-End-Verantwortung für ihr Produkt.
• Stack-Diversität als Feature: Unterschiedliche Technologie-Stacks sind gewollt, weil die Produkte unterschiedlich sind.
• Lernbewegung als Normalfall: Wechsel zwischen Teams und Stacks sind Teil des Arbeitsalltags.

Eisenbart schildert explizit, dass Mitarbeitende zwischen Teams rotieren und bewusst in Bereiche wechseln, die sie noch nicht kennen. Ein Beispiel: Big-Data-Entwicklerinnen und -Entwickler arbeiten phasenweise im Frontend mit Angular. Das ist ein starkes Signal – an die Teams, sich breit aufzustellen, und an Bewerberinnen und Bewerber, dass Flexibilität und Lernbereitschaft nicht nur geschätzt, sondern vorausgesetzt werden.

Recruiting mit Praxisfokus: drei Gespräche, direkter Kontakt mit Führung und Team

Onboarding und Recruiting variieren je nach Team, weil die Technologie-Stacks sich unterscheiden. Dennoch liegt eine klare Struktur vor, die auf mehrstufige Gespräche und auf praktische Einblicke in das Können der Kandidatinnen und Kandidaten setzt.

• Erstes Kennenlernen per Telefoninterview.
• Zweites Gespräch als Video-Interview (klassische Vor-Ort-Interviews sind aktuell ausgesetzt).
• Drittes Interview als weiterer Vertiefungsschritt.
• Gesprächspartner sind konstant: Michael Eisenbart selbst, sein Vorgesetzter Alexander und das jeweilige Team.

Zwei Aspekte sind dabei besonders wichtig: Erstens sollen Bewerberinnen und Bewerber das Team und die Aufgabe realistisch kennenlernen – nicht nur sich vorstellen, sondern verstehen, was der Job ausmacht und mit wem sie arbeiten würden. Zweitens fließt praktischer Code in die Bewertung ein. Das Team schaut sich an, was Kandidatinnen und Kandidaten tatsächlich geschrieben haben. Zusätzlich gibt es je nach Team spezifische Aufgaben passend zum jeweiligen Stack.

Warum das Teamgespräch so wichtig ist

Die Einbindung des Teams in den Recruiting-Prozess dient nicht nur der Qualitätssicherung. Sie schafft Transparenz. Wer hier anfängt, weiß, mit welchen Menschen die tägliche Zusammenarbeit stattfindet. Und das Team gewinnt ein Gefühl dafür, ob die Person Lust auf die Arbeit an genau diesem Produkt und Stack mitbringt. Für uns ist das ein klares Signal einer Kultur, die Kollaboration ernst nimmt.

Technologie am Stand der Technik: Cloud-native Infrastruktur, Golang, Spark und Python

Eisenbart ordnet die technologische Entwicklung in einen historischen Kontext ein: Das Unternehmen wird 135 Jahre alt – eine Zeitspanne, die den Sprung von vorcomputationalen Anfängen bis in eine hochmoderne IT-Welt umfasst. Die Haltung dazu ist eindeutig: kontinuierliche Anpassung und das Ziel, in neuen Lösungen mindestens am Stand der Technik zu sein, um relevant zu bleiben.

Konkret genannt werden diese Schwerpunkte:

• Infrastruktur: Größtenteils Docker-Kubernetes.
• Backend und Datenpipelines: Überwiegend Golang; Java wird fast nicht eingesetzt.
• Big-Data-Architektur: Cluster-Computing mit viel Apache Spark, etwas Scala und viel Python.

Diese Auswahl ist bemerkenswert: Golang im Backend und in Datenpipelines, kombiniert mit einer Spark-getriebenen Big-Data-Landschaft, deutet auf Performance- und Skalierungsansprüche hin. Kubernetes und Containerisierung bilden das Rückgrat für wiederholbare Deployments und robuste Betriebsprozesse. Wichtig bleibt dabei, was Eisenbart betont: Technologien verändern sich kontinuierlich, und die Organisation passt sich an.

Polyglot-Engineering als Erwartung: mindestens zwei Programmiersprachen

Ein Satz bleibt besonders hängen: Es wird darauf geachtet, dass neue Kolleginnen und Kollegen mindestens zwei Programmiersprachen beherrschen. Dahinter steht nicht nur eine Vorliebe für Syntaxwechsel, sondern eine klare Erwartung an Adaptionsfähigkeit. Weil die Teams unterschiedliche Stacks fahren und Übergänge zwischen den Teams gewollt sind, ist Polyglottie praktisch. Wer Freude daran hat, Probleme je nach Kontext in unterschiedlichen Sprachen zu lösen – von Golang über Python bis zu Scala oder Angular im Frontend –, findet hier eine Umgebung, die genau das fördert.

Diese Erwartung passt nahtlos zur Idee von 100 Prozent Produktverantwortung. Wer End-to-End denkt, wählt Tools zweckmäßig aus, statt sich starr auf eine Lieblingssprache zu beschränken.

Praktische Kompetenz sichtbar machen: Code zählt

Ein weiterer Punkt, der uns bei DevJobs.at aufgefallen ist: Das Team möchte sehen, was Bewerberinnen und Bewerber praktisch geschrieben haben. Öffentliche Code-Repositories und nachvollziehbare Beiträge sind deshalb wichtig. Sie zeigen, wie jemand Probleme strukturiert, welche Qualitätsansprüche verfolgt werden und wie Entscheidungen im Code aussehen. Ergänzend führen die Teams stack-spezifische Aufgaben durch, um die Passung zum jeweiligen Produkt zu prüfen.

Diese Gewichtung sagt viel über die Engineering-Kultur aus. Theoretisches Wissen ist hilfreich, aber zählend ist am Ende, was sich im Code festhalten lässt. Wer gerne baut, ausprobiert und dokumentierbar liefert, passt zu diesem Anspruch.

Nähe zum Kunden als Organisationsprinzip

Eisenbart unterstreicht, dass Teams idealerweise dort sitzen, wo die Kundschaft ist. Für die tägliche Arbeit bedeutet das: Feedback-Schleifen sind kurz, und Entscheidungen werden dort getroffen, wo Problem und Lösung aufeinandertreffen. In Verbindung mit der vollständigen Produktverantwortung wird daraus ein belastbares, kundenzentriertes Organisationsdesign. Aus unserer Sicht ist das ein Grund, warum unterschiedlichste Stacks parallel existieren können – sie sind Ergebnis echter Produktbedürfnisse, nicht akademischer Architekturdebatten.

Was diese Struktur für deine Entwicklung bedeutet

Aus der Kombination von globaler Organisation, autonomer Teamarbeit und Stack-Diversität ergeben sich klare Entwicklungspfade – ohne dass formale Programme bemüht werden müssen.

• Lernen im Projektfluss: Durch Teamwechsel und Stack-Übergänge entsteht natürlicher Wissensaufbau.
• Breite statt Engpass: Wer im Backend zuhause ist, kann Erfahrung im Frontend sammeln, und umgekehrt.
• Relevanz als Leitstern: Die Ausrichtung auf den Stand der Technik sorgt dafür, dass Skills aktuell bleiben.

Bemerkenswert ist, wie wenig Bürokratie dieser Entwicklung im Weg zu stehen scheint. Die Teams verwalten ihren Stack selbst. Sie definieren Aufgaben, die zu ihrem Kontext passen. Sie treffen Entscheidungen entlang der Produktanforderungen. So entsteht ein Umfeld, in dem Neugier belohnt wird.

Für wen dieses Umfeld passt

Wenn du dich in den folgenden Punkten wiederfindest, ist die Wahrscheinlichkeit hoch, dass du dich bei der Bosch-Gruppe Österreich gut entfalten kannst:

• Du willst echte Verantwortung für ein Produkt und liebst es, Entscheidungen im Team zu treffen.
• Du fühlst dich in Container- und Orchestrierungsumgebungen zuhause oder möchtest dich zügig hineinbewegen.
• Du bringst Erfahrung mit mindestens zwei Programmiersprachen mit – etwa Golang und Python – und wechselst bereitwillig den Kontext.
• Du arbeitest gerne dort, wo der Kunde ist, und schätzt kurze Wege zu Feedback und Wirkung.
• Du zeigst deine Fähigkeiten über nachvollziehbaren Code und hast Freude an praktischen Aufgaben im Recruiting-Prozess.

Einblicke in den Interviewablauf: was dich erwartet

Der beschriebene Prozess ist schlank und transparent:

1. Telefoninterview zum ersten gegenseitigen Kennenlernen.
2. Video-Interview als zweiter Schritt (klassische Vor-Ort-Interviews sind derzeit ausgesetzt).
3. Drittes Gespräch zur Vertiefung und Passungsprüfung.

Konstant dabei: Gespräche mit Michael Eisenbart, seinem Vorgesetzten Alexander und dem jeweiligen Team. Zusätzlich gibt es je nach Team spezielle Aufgaben, die am verwendeten Stack ausgerichtet sind. Zentral bleibt, dass Bewerbende nicht nur sich vorstellen, sondern ein Bild der Aufgabe, des Teams und des Alltags bekommen.

Zitate und Kernaussagen, die hängen bleiben

Diese Aussagen ergeben zusammengenommen ein klares Profil: eigenverantwortliche Teams, moderne Infrastruktur, polyglotte Praxis und eine Kultur, die Lernbewegung aktiv einplant.

Was Tech-Leads von dieser Organisation lernen können

• Produktverantwortung sichtbar machen: 100 Prozent Verantwortung im Team verankern, statt sie über Einheiten zu zerteilen.
• Kundennähe strukturell sichern: Teams dort ansiedeln, wo Feedback entsteht.
• Engineering breit aufstellen: Mindestens zwei Sprachen als Erwartung formulieren und Übergänge aktiv fördern.
• Praxis vor Theorie: Codebeispiele und stack-spezifische Aufgaben ins Recruiting integrieren.
• Stack-Autonomie zulassen: Unterschiedliche Produkte brauchen unterschiedliche Technologien – und Teams, die sie selbst verwalten.

Diese Prinzipien ergeben zusammen eine robuste Organisation, die mit technologischer Veränderung Schritt hält, ohne in Beliebigkeit zu verfallen.

Warum sich eine Bewerbung lohnt – in einem Satz

Wer Verantwortung liebt, moderne Infrastruktur schätzt, gerne in verschiedene Stacks eintaucht und seinen Wert im Code zeigt, findet bei der Bosch-Gruppe Österreich die passende Bühne.

Fazit: Relevanz durch Autonomie, Technikfokus und Lernbereitschaft

Die Session Michael Eisenbart, Senior Manager bei Bosch mit Speaker Michael Eisenbart von der Bosch-Gruppe Österreich zeichnet das Bild einer Organisation, die globale Aufstellung mit lokaler Verantwortung verbindet. Autonome Scrum-Teams tragen volle Produktverantwortung, Stacks sind teamgetrieben und variieren kontextabhängig, und das Recruiting prüft praktische Fähigkeiten konsequent. Technologisch baut die Gruppe auf Containerisierung mit Kubernetes, auf Golang in Backends und Datenpipelines sowie auf clusterbasierte Big-Data-Verarbeitung mit Spark, Scala und Python.

Was diese Techlead-Story besonders macht, ist die Klarheit der Erwartungen: mindestens zwei Programmiersprachen beherrschen, bereit sein, zwischen Teams und Stacks zu wechseln, und Freude daran haben, Lösungen am Stand der Technik zu bauen. Damit bleibt die Organisation beweglich – und die Produkte relevant.

• 

  

  Why you shouldn't build a microservice architecture

  Michael Eisenbart von Bosch stellt in seinem devjobs.at TechTalk die Vor- und Nachteile einer Microservice Architektur gegenüber – mit dem Hintergedanken, stets die Dinge etwas kritisch zu beleuchten.

  Jetzt ansehen

• 

  

  Jürgen Webersinke, Gruppenleiter Softwareapplikation bei Bosch

  Gruppenleiter Softwareapplikation bei Bosch Jürgen Webersinke spricht im Interview über den Aufbau des Teams, wie das Recruiting und Onboarding abläuft und wie mit den technologischen Challenges umgegangen wird.

  Jetzt ansehen
• 

  

  Florian Berg, Digital Leader bei Bosch

  Digital Leader bei Bosch Florian Berg gibt im Interview einen Überblick über die Teamorganisation, den Ablauf des Recruitings und die eingesetzten Technologien.

  Jetzt ansehen

• 

  

  Jasmin Grabenschweiger, Data Scientist bei Bosch

  Data Scientist bei Bosch Jasmin Grabenschweiger spricht im Interview über ihren Werdegang und gibt Tipps für Neueinsteiger und Einblicke in den Data Science Alltag mit Beispielen.

  Jetzt ansehen
• 

  

  Liam Rafael, Data Engineer bei Bosch

  Liam Rafael von Bosch spricht im Interview von seinen ersten Berührungspunkten mit dem Programmieren bis hin zur aktuellen Arbeit als Data Engineer und gibt Tipps für Neueinsteiger.

  Jetzt ansehen
• 

  

  Dominik Steininger, DevOps Engineer bei Bosch

  DevOps Engineer bei Bosch Dominik Steininger spricht in seinem Interview über seinen Werdegang – angefangen von den ersten Gehversuchen, bis hin zur aktuellen Arbeit – und gibt Ratschläge für Einsteiger.

  Jetzt ansehen
• 

  

  Melika Parpinchi, Data Scientist bei Bosch

  Melika Parpinchi von Bosch erzählt im Interview über ihren ursprünglichen Zugang zum Programmieren, das Besondere an ihrer aktuellen Arbeit bei Bosch und was ihrer Meinung nach wichtig für Anfänger ist.

  Jetzt ansehen