Autonomous Scrum Teams, modern stacks, and polyglot engineering: Insights from Michael Eisenbart (Bosch-Gruppe Österreich)

Why this techlead story matters

At DevJobs.at, we look for the moments where leadership, team design, and technology form a coherent narrative. In the session titled Michael Eisenbart, Senior Manager bei Bosch, speaker Michael Eisenbart from Bosch-Gruppe Österreich offered exactly that: a crisp blueprint of how global organization, local ownership, and state-of-the-art engineering come together.

What stood out for us: teams distributed across seven countries, each operating as an autonomous Scrum team with 100 percent product responsibility; hiring that emphasizes practical code and genuine team fit; a technology landscape anchored by Docker-Kubernetes, Golang, Spark, Scala, and Python; and a culture that expects engineers to master at least two programming languages and rotate across stacks and teams.

Global organization, local accountability: seven countries, many products

Eisenbart opens by describing a structure that is global in scope yet tightly local in execution. The work is not split across countries by task. Instead, end-to-end responsibility sits with dedicated teams.

• Autonomous Scrum teams: each team is self-contained and works in Scrum.
• Full product ownership: teams carry 100 percent responsibility for their product.
• Customer proximity: ideally, teams are located where their customers are.
• Team-owned stacks: each team owns its product and its technology stack and manages it directly.

The implications are clear. Autonomy is not a slogan but an organizing principle. Decisions about architecture and tools are made within the team closest to the problem and the customer. For engineers, this means unambiguous ownership and a context where decisions are made by the people who build and ship.

Engineering culture: ownership, pragmatism, and learning in motion

A culture emerges in which ownership and curiosity are essential. Because stacks differ across teams and products, one-size-fits-all is deliberately avoided. With that freedom comes expectation: engineers should be ready to learn new stacks, and they should be comfortable working in at least two programming languages.

• Responsibility over prescription: teams plan and deliver as units with end-to-end accountability for their product.
• Diversity by design: different products justify different stacks; that diversity is embraced, not normalized away.
• Learning as a steady state: moving between teams and stacks is part of how the organization works.

Eisenbart is explicit that engineers rotate and at times work in domains they do not yet know. A vivid example: Big Data developers spend time in a frontend team and work with Angular. That single detail speaks volumes about expectations and growth. Flexibility is not optional; it is part of the job.

Hiring that values practice: three interviews, direct access to leadership and team

Onboarding differs slightly by team because stacks differ. Nevertheless, the selection process follows a clear multi-step structure with a strong focus on practical ability and mutual fit.

• Step 1: a phone interview for initial introductions.
• Step 2: a video interview (traditional onsite interviews are currently suspended).
• Step 3: a third interview for further depth.
• Who you meet: candidates speak with Michael Eisenbart, his manager Alexander, and the team.

Two priorities run through this approach. First, candidates should not only be interviewed; they should learn what the job involves, what makes the team tick, and whether they can see themselves in that environment. Second, practical code matters. The team looks at what candidates have actually written, and there are stack-specific tasks depending on the team.

Why the team conversation matters

Involving the team does more than improve hiring quality. It creates transparency. New hires know who they will work with and what product they will own a piece of. The team, in turn, gets a grounded sense of whether the candidate wants to work on that product and stack. This is what a collaboration-first culture looks like in practice.

State-of-the-art by design: containerized infrastructure, Golang, Spark, and Python

Eisenbart places today’s stack in historical perspective: the company is 135 years old. That span demands constant technological renewal. The guiding principle is to remain at least at the state of the art in new solutions in order to stay relevant.

Technologies he calls out:

• Infrastructure: primarily Docker-Kubernetes.
• Backends and data pipelines: predominantly Golang; very little Java is used.
• Big Data architecture: cluster computing with heavy use of Apache Spark, some Scala, and lots of Python.

The combination is telling. Golang for backends and data pipelines, paired with Spark-centric Big Data, points to performance and scale considerations. Kubernetes and containerization provide the foundation for reproducible deployments and robust operations. The crucial part is the stance: technologies change continuously, and the organization adapts.

Polyglot expectation: at least two programming languages

One line crystallizes the talent bar: candidates should know at least two programming languages. That is not about syntax trivia; it is about adaptability. Because stacks differ from team to team and rotation is normal, polyglot engineering is practical and encouraged. If you like solving problems in the idiom that best fits the context — Golang for server-side and pipelines, Python and Scala for data-centric work, Angular in frontend — you will find a place that turns that habit into a strength.

This expectation meshes with end-to-end ownership. When teams own products, they choose tools purposefully rather than defaulting to a single language across the board.

Let the code speak: practical contributions carry weight

Another feature stood out in this session: the team wants to see practical code. Publicly visible repositories and tangible contributions allow them to understand how candidates structure solutions, what quality bar they maintain, and how they express decisions in code. In addition, teams run stack-specific tasks aligned with their product to validate fit.

This emphasis reveals a lot about the engineering culture. Theoretical knowledge is useful, but the decisive signal is what can be demonstrated in code. Builders who enjoy shipping and can point to concrete work are a strong fit.

Customer proximity as an organizing principle

Eisenbart emphasizes that teams are ideally located where the customer is. Day to day, that means short feedback loops and decisions made where problem and solution meet. Combined with full product responsibility, this becomes a dependable, customer-centric design. From our vantage point, this is also why parallel stacks can thrive — they are chosen to meet real product needs rather than shoehorned into a single architecture canon.

What this structure means for your growth

The interplay of global reach, autonomous teams, and stack diversity forms clear growth pathways — without needing heavy formalization.

• Learn in the flow of work: rotation between teams and stacks leads to natural skill development.
• Breadth over bottlenecks: backend specialists pick up frontend experience and vice versa.
• Relevance as a compass: aiming for state-of-the-art solutions keeps skills current.

What’s striking is how little bureaucracy seems to stand in the way. Teams own their stacks. They define tasks that match their context. They make decisions based on product needs. Curiosity is rewarded because the organizational design requires and supports it.

Who will thrive here

Chances are high you will thrive at Bosch-Gruppe Österreich if the following describes you:

• You want real ownership over a product and enjoy making decisions within a team.
• You are comfortable in containerized, orchestrated environments or eager to grow into them.
• You bring experience in at least two programming languages — for example, Golang and Python — and are willing to change contexts.
• You appreciate being close to customers and value short feedback loops.
• You prefer to demonstrate your skills through tangible code and are comfortable with stack-specific tasks in the hiring process.

The interview journey: what to expect

The described process is straightforward and transparent:

1. A phone interview for initial introductions.
2. A video interview as the second step (onsites are currently suspended).
3. A third interview to go deeper on fit and expectations.

You will speak with Michael Eisenbart, his manager Alexander, and the team. Depending on the team, there will be tasks aligned with the stack in question. Importantly, candidates do not just present themselves — they gain a real picture of the job, the team, and day-to-day work.

Quotes and takeaways that stay with you

Taken together, these points describe an organization with clear ownership, modern infrastructure, polyglot practice, and a culture that plans for learning in motion.

What tech leads can take from this model

• Make ownership real: anchor full product responsibility within teams rather than splitting it across units.
• Build for customer proximity: structure teams where feedback emerges.
• Staff for breadth: set the expectation of at least two languages and enable stack rotation.
• Let practice lead: integrate code samples and stack-specific tasks into hiring.
• Allow stack autonomy: different products merit different technologies — empower teams to manage them.

These practices reinforce one another, forming an organization that stays relevant amid technological change without drifting into inconsistency.

Why applying here makes sense — in one line

If you care about ownership, modern infrastructure, cross-stack learning, and demonstrating value through code, Bosch-Gruppe Österreich offers the right stage.

Conclusion: relevance through autonomy, tech focus, and a bias for learning

The session Michael Eisenbart, Senior Manager bei Bosch, with speaker Michael Eisenbart from Bosch-Gruppe Österreich paints a picture of a global organization with local accountability. Autonomous Scrum teams hold full product responsibility, stacks are team-driven and vary by context, and hiring foregrounds practical code and genuine team fit. The technology backbone features Kubernetes-driven containerization, Golang for backends and data pipelines, and cluster-centric Big Data with Spark, Scala, and Python.

What stands out is the clarity of expectations: know at least two languages, be ready to rotate across teams and stacks, and enjoy building at the state of the art. That combination keeps the organization adaptive — and the products 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.

  Watch now

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now