Arbeitsplatz Bild MIC
Logo MIC

MIC

Etablierte Firma
Alle Videos anzeigen

Wolfgang Gassner, Director Produktentwicklung bei MIC

Description

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.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In 'Wolfgang Gassner, Director Produktentwicklung bei MIC' erläutert Speaker Wolfgang Gassner die Scrum-Organisation mit Produktteams (PO, Dev-Team, Scrum Master) und zwei Infrastruktur-Teams für Qualitätssicherung sowie Research & Development, die als Service-Einheiten agieren; Teams zielen auf etwa sieben Personen, werden ab circa zwölf gesplittet, begrenzen WIP und wählen Sprint-Items selbst aus dem Backlog, um kontinuierlich Kundennutzen zu liefern. Im Recruiting gibt es einen dreistufigen Prozess mit Erstgespräch, einem „Look&Feel“ zum Kennenlernen von Team, Büro und Werkzeugen und anschließendem Vertragsgespräch mit dem Eigentümer; gesucht sind kommunikative, teamfähige Leute, die täglich Probleme teilen statt isoliert zu arbeiten. Technologisch migriert MIC vom Oracle/PLSQL-Stack und Eclipse-Rub zu Java Enterprise und React, verankert Testautomatisierung mit Cucumber und ergänzt BI/ML/AI-Funktionen via Clickhouse, Apache Superset und Apache Knife, um moderne Methoden wie Domain-Driven Design und bessere Entwicklerunterstützung zu ermöglichen.

Vom „Datenschaufeln“ zur domänennahen Plattform: So organisiert Wolfgang Gassner (Director Produktentwicklung bei MIC) agile Produktentwicklung

Ein Blick hinter die Kulissen von MICs Produktentwicklung

Bei DevJobs.at haben wir Wolfgang Gassner in der Session „Wolfgang Gassner, Director Produktentwicklung bei MIC“ erlebt – und selten lässt ein Tech-Lead so klar, so nüchtern und zugleich so konsequent in die eigene Produktentwicklung blicken. Was wir mitgenommen haben: MIC baut eine stark datenzentrierte Software, die Basisdaten aus ERP-Systemen transformiert, anreichert und daraus „Deklarationen“ erstellt, die an Zollbehörden übermittelt werden. Oder, wie Gassner es unverblümt formuliert:

„Die Hauptaufgabe bei uns ist Datenschaufeln.“

Aus dieser Aufgabe leitet MIC konsequent Organisation, Tech-Stack, Hiring und Engineering-Kultur ab. Die Produktentwicklung ist auf kontinuierliche Lieferung, Pragmatismus und klare Priorisierung getrimmt – ohne dabei den Anspruch auf moderne Methodik und Qualität zu verlieren. In diesem Artikel fassen wir die Struktur, Prinzipien, Technologien und Erwartungen zusammen, die Gassner in seinem Einblick skizziert hat – und warum das für Entwicklerinnen und Entwickler eine spannende Umgebung ist.

Auftrag und Wertversprechen: Daten transformieren, Zollprozesse sicher machen

MICs Anwendung ist um Daten gebaut. Im Zentrum steht der Fluss von Informationen: ERP-Basisdaten werden transformiert, angereichert und in Form offizieller Deklarationen an Zollbehörden übermittelt. Das ist ein eng getakteter, hochstrukturierter Prozess, bei dem Korrektheit, Nachvollziehbarkeit und Performance zählen.

  • Starker Datenbezug: Relationale Struktur, hohe Datenqualität, klar definierte Workflows
  • Business-Prozess: Von der ERP-Quelle bis zur Zoll-Deklaration
  • Ergebnisorientierung: Fokus auf kontinuierlichen Mehrwert für Kundinnen und Kunden

Dieses Geschäft setzt robuste Datenbanktechnologie, belastbare Integrationspfade und ein Engineering voraus, das sich der Domain diszipliniert annähert. Genau dafür wurde die Organisation aufgestellt.

Zwei Teamarten: Produktteams im Scrum-Rhythmus, Infrastruktur-Teams als Service

Gassner unterscheidet klar zwischen Produktteams und Infrastruktur-Teams:

  • Produktteams mit Modulverantwortung
  • Organisiert „im Sinne von Scrum“ mit Product Owner, Development Team und Scrum Master
  • Größenordnung: Orientierung an der Scrum-Empfehlung (~7), real zwischen 3 und 15 Personen
  • Skalierungsprinzip: „Wenn die Teams Richtung zwölf gehen, dann spalten wir es wieder und machen ein neues Team“ – inklusive eigenem Product Owner und Scrum Master
  • Zwei Infrastruktur-Teams
  • Qualitätssicherung
  • Neue Technologien/Research & Development
  • Auftreten als Service-Teams für die Produktteams

Die Struktur gibt Produktteams Autonomie und Fokus auf „ihr“ Modul, während die Infrastruktur-Teams methodische und technologische Hebel bereitstellen. So bleiben die Produktteams lieferfähig, ohne jedes Rad selbst erfinden zu müssen.

Warum diese Organisation? Kundenanforderungen priorisieren und Nutzen maximieren

Traditionell war MIC „ein sehr starkes Projektschiff“ – viele Anforderungen aus Projekten und aus dem Support landen im Backlog. Die Konsequenz:

„Wir sind nicht in der Lage, alle zu erfüllen, darum müssen wir priorisieren und uns fokussieren auf die wichtigsten Punkte, die den meisten Nutzen beim Kunden bringen.“

Die Scrum-orientierte Aufstellung, klare Teamzuschnitte und Service-Funktionen sollen genau das möglich machen: fokussierte, priorisierte Umsetzung – statt Parallelitis und Kontextwechseln. Die Organisation ist also explizit als Antwort auf reale Nachfrage und Liefersituation entworfen.

Arbeitsmodus der Produktteams: WIP begrenzen, Fokus halten, kontinuierlich liefern

Gassner beschreibt den Team-Workflow als „Pool-Prinzip“: Das Dev-Team wählt auf Basis des Backlogs, woran im nächsten Sprint gearbeitet wird. Ziel ist eine balancierte, planbare Auslastung – ohne zu viele parallele Baustellen.

„Wir wollen die Arbeit limitieren, dass nicht an zu vielen Sachen parallel gearbeitet wird … und wir versuchen so kontinuierlich einen Wert … an Kunden zu liefern.“

Klar ist: WIP-Limits, Sprint-Fokus und kontinuierliche Lieferung sind nicht Selbstzweck, sondern Gegenmittel zu Altlasten der Vergangenheit, in der „an zu vielen Sachen parallel gearbeitet“ wurde. Diese Disziplin ist auch eine kulturelle Ansage: Produktteams übernehmen Ownership für Fokus und Ergebnis.

Recruiting bei MIC: Dreistufig, teamnah, auf Kommunikation optimiert

Wenn neue Positionen besetzt werden, startet MIC gemeinsam mit der HAE-Abteilung mit einem sauber definierten Anforderungsprofil: Aufgaben, Tätigkeiten, gesuchte Kompetenzen. Danach folgt ein bewusst dreistufiger Prozess:

  1. Erstgespräch: Screening der Eignung – fachlich wie kulturell
  2. „Look&Feel“: Der entscheidende Teamkontakt
  • Kandidatinnen und Kandidaten treffen das zukünftige Team
  • Einblick in Büro, Werkzeuge und Arbeitsweise
  • Gelegenheit, die Menschen kennenzulernen, mit denen man bald zusammenarbeitet
  1. Vertragsgespräch mit dem Eigentümer: Finalisierung und Unterschrift

Besonders der „Look&Feel“-Schritt unterstreicht den Teamcharakter der Organisation. Der Fit wird nicht am Whiteboard entschieden, sondern im echten Kontakt mit den Menschen und dem Arbeitsumfeld.

Was MIC im Hiring besonders wichtig ist

„Wir wollen keine Leute, die sich in finstere Kämmerlein einsperren … sondern wir wollen die Leute dazu ermutigen, dass sie täglich miteinander sprechen, ihre Probleme austauschen und gemeinsam an Lösungen arbeiten.“

  • Teamfähigkeit und Kommunikation stehen an erster Stelle
  • Täglicher Austausch wird aktiv eingefordert
  • Abkapselung ist ein Anti-Pattern

Die Entscheidung für Scrum als Organisationsrahmen ist hier nicht Dekoration, sondern gelebte Praxis: Kommunikation ist „das A und O“.

Tech-Stack heute und morgen: Oracle-DNA, Java Enterprise auf dem Vormarsch

Wenn der Job „Datenschaufeln“ ist, rückt die Datenbank ins Zentrum. MIC setzt „seit Anfang“ auf Oracle – relational, strukturiert, robust. Historisch wurde die Geschäftslogik in PL/SQL implementiert. Das hatte gerade für datenlastige Verarbeitung klare Performance-Vorteile: Prozesse „in der Datenbank direkt“ laufen zu lassen, war naheliegend.

Heute schlägt MIC ein neues Kapitel auf: die Migration Richtung Java Enterprise. Neue Prozesse werden in Java Enterprise implementiert, weil dort methodische Leitplanken besser abbildbar sind – insbesondere:

  • Domain-Driven Design
  • Testautomatisierung

Ein weiterer pragmatischer Grund ist der Talentmarkt: „Die Leute, die heute ausgebildet werden, die können Java schon, wenn sie zu uns kommen – PL/SQL habe auch ich lernen müssen.“ Die Migration ist eine „große Herausforderung“, aber „es führt an dem Weg nichts vorbei“.

Frontend-Modernisierung: Von Eclipse-Stack zu React

Neben dem Backend modernisiert MIC auch das Frontend. Aktuell setzt man auf ein Eclipse-basiertes UI; künftig soll React die Grundlage bilden. Dieser Wandel hat „natürlich auch dann andere Erfordernisse im Backend“, um das Frontend sauber anzusteuern. Die Umstellung wird also ganzheitlich gedacht – vom UI bis zur API.

Qualität als integrierter Prozess: Akzeptanzkriterien, Cucumber, keine Zusatzaufgabe

Testautomatisierung ist bei MIC kein nachträgliches Add-on, sondern soll integraler Bestandteil der Implementierung sein. Der Ansatz:

  • Bereits in der Designphase definieren Product Owner und Team die Akzeptanzkriterien
  • Funktionalitäten und Szenarien werden mit Cucumber formuliert
  • Diese Szenarien sind Grundlage für die Implementierung und automatisierte Tests

„Wir sehen das gar nicht jetzt als Extraaufgabe, sondern das soll integrierter Bestandteil werden.“

Rollout-Strategie: „Flächendeckend“ insbesondere bei Migrationen und Neueinführungen. Beim Legacy-Code ist Testautomatisierung „ganz, ganz schwer möglich“ – auch das spricht für die Priorität der Modernisierung.

Daten nutzbar machen: BI, Machine Learning, Artificial Intelligence

Aktuell stark gefragt – über nahezu alle Applikationen hinweg – sind Themen rund um Business Intelligence, Machine Learning und Artificial Intelligence. Gassner beschreibt MICs Ansatz, Nutzerinnen und Nutzern „einen Mehrwert“ zu liefern, indem sie „selbst Auswertungen tätigen können“.

Genannte Bausteine:

  • Clickhouse (Persistenz/Analytik)
  • Apache Superset (Visualisierung)
  • Apache Knife (ETL)

Damit erweitert MIC die Pipeline über den transaktionalen Kern hinaus in Richtung Self-Service-Analytik. Für Entwicklerinnen und Entwickler bedeutet das: neben klassischen Workflow- und Integrationsproblemen spielen auch Datenmodellierung, performante Aggregationen und ein sauberes Governance-Verständnis eine größere Rolle.

Legacy sinnvoll ablösen: Oracle Forms/Reports zu Java – und weiter

Historisch war MIC „Oracle-zentriert“ – Datenbank (Oracle), UI (Oracle Forms) und Reporting (Oracle Reports). Schritt für Schritt wurde das UI „in der Java-Technologie“ neu umgesetzt, ebenso die Integration. Der aktuelle Stand: „die Legacy ablösen und auch mit State-of-the-art Methoden und Technologien neu implementieren“. Modernisierung heißt hier also nicht nur Portierung, sondern ein methodisches und technologisches Upgrade.

Was diese Umgebung für Talente attraktiv macht

Aus dem O-Ton von Wolfgang Gassner entsteht ein klares Bild, warum MIC für Tech-Talente interessant ist – insbesondere für Menschen, die strukturiert arbeiten, gerne Verantwortung in einem Modulumfeld übernehmen und Freude am Modernisieren haben.

  • Arbeiten am Kern von datenzentrierter Wertschöpfung: Vom ERP-Rohdatenstrom bis zur rechtsrelevanten Deklaration – nahe an echten Geschäftsprozessen
  • Klare Teamzuschnitte mit Ownership: Produktteams tragen Verantwortung für „ihr“ Modul, unterstützt von Service-Teams (Qualitätssicherung, R&D)
  • Fokussierung statt Parallelitis: Pool-Prinzip, WIP-Limits und Sprints, die Ergebnisse priorisiert liefern
  • Modernisierung als Dauerauftrag: Migration von PL/SQL nach Java Enterprise, Umstieg von Eclipse-basiertem Frontend auf React – inklusive Backend-Anforderungen
  • Qualität integriert gedacht: Akzeptanzkriterien mit dem Product Owner, Cucumber-Szenarien als Testgrundlage
  • Analytische Erweiterung: BI/ML/AI-Anwendungsfälle mit Clickhouse, Apache Superset und Apache Knife

Kurz: Wer die Kombination aus tiefem Datenverständnis, sauberer Methodik und kontinuierlicher Modernisierung sucht, findet hier eine Umgebung, in der diese Fähigkeiten unmittelbar Wirkung entfalten.

Der kulturelle Kern: Kommunikation, Teamfähigkeit, täglicher Austausch

Gassner setzt immer wieder denselben Punkt: Kommunikation ist „das A und O“. Das bedeutet praktisch:

  • Tägliche, kurze Feedback-Schleifen im Team
  • Probleme offen austauschen und gemeinsam lösen
  • Keine heroischen Einzelleistungen im stillen Kämmerlein

Diese Haltung zieht sich durch Organisation (Scrum, Teamgrößen, Splitting), Recruiting (Look&Feel, Teamfit) und Engineering (gemeinsame Akzeptanzkriterien) gleichermaßen. Wer dazu passt, wird in der Kultur nicht nur bestehen, sondern sie aktiv prägen.

Rollenverständnis: Product Owner, Scrum Master, Dev-Team – klar, aber pragmatisch

MIC orientiert sich an Scrum, ohne es dogmatisch zu überhöhen:

  • Product Owner: Priorisierung und Nutzenfokus
  • Scrum Master: Unterstützung des Teams, Beseitigung von Hindernissen
  • Dev-Team: Entscheidet auf Basis des Backlogs, was in den Sprint geht; liefert inkrementell

Die Teamgrößen und das Splitting ab ~12 Personen zeigen: Man nimmt Skalierbarkeit und Teamdynamik ernst. Zu große Teams verlieren Fokus – also wird aufgeteilt und Ownership neu zugeschnitten.

So sieht „Engineering Enablement“ bei MIC aus

Auch wenn der Begriff nicht fällt, beschreiben die Aussagen ein klares Enablement-Modell:

  • Infrastruktur-Teams als interne Dienstleister (Qualitätssicherung, R&D): Produktteams müssen nicht alles selbst stemmen
  • Standardisierte Methodik: Akzeptanzkriterien und Cucumber-Szenarien als gemeinsame Sprache von Product und Engineering
  • Tech-Stack-Modernisierung: Java Enterprise und React schaffen eine Lernkurve, die am Markt anschlussfähig ist

Das wirkt wie eine bewusst gestaltete Umgebung, in der die „happy path“-Arbeit erleichtert wird – und Teams Zeit für das Wesentliche haben: wertstiftende Inkremente.

Erwartungsmanagement: Was MIC von neuen Kolleginnen und Kollegen braucht

Wer sich angesprochen fühlt, sollte mit diesen Erwartungen rechnen:

  • Freude an Teamarbeit und Gesprächsbereitschaft – täglicher Austausch ist Standard
  • Disziplin im Fokus: WIP-Limits respektieren, Backlog-getrieben arbeiten
  • Interesse an Daten und Strukturen: Relationale Modellierung, performante Verarbeitung, saubere Schnittstellen
  • Bereitschaft zur Migration: Von PL/SQL nach Java Enterprise, Frontend-Umstieg auf React mit Blick auf Backend-Anforderungen
  • Qualitätsbewusstsein: Akzeptanzkriterien ernst nehmen, Cucumber-Szenarien mitdenken, Testautomatisierung als Teil der Umsetzung betrachten

Wer genau darauf Lust hat, wird in der Produktentwicklung bei MIC schnell Verantwortung übernehmen und Wirkung entfalten können.

Wie MIC Wachstum ermöglicht – durch Aufgaben, Nähe und Klarheit

Aus dem Gesagten lässt sich ablesen, wie Wachstum im Alltag tatsächlich stattfindet:

  • Anspruchsvolle Modernisierungsvorhaben fordern und fördern neue Fähigkeiten
  • Das „Look&Feel“ im Hiring sorgt dafür, dass man in ein Team mit passendem Arbeitsstil kommt
  • Die Zusammenarbeit mit Product Ownern an Akzeptanzkriterien schult Domänenverständnis und Produktdenken
  • Service-Teams (QS, R&D) geben methodischen und technologischen Rückenwind

Nicht durch große Versprechen, sondern durch konkrete Arbeitsweisen entsteht eine Lernumgebung, die sich täglich auszahlt.

Fazit: Eine ehrliche, fokussierte Produktentwicklung – mit klarer Perspektive

Die Session „Wolfgang Gassner, Director Produktentwicklung bei MIC“ zeigt eine Entwicklungseinheit, die ihre Realität kennt und daraus konsequente Schlüsse zieht. MIC verbindet datenlastige Domäne mit Scrum-orientierter Organisation, setzt auf Fokus statt Parallelismus und modernisiert den Stack mit Blick auf Methodik (Domain-Driven Design, Testautomatisierung) und Talentmarkt (Java, React, Cucumber). Gleichzeitig bleibt die Kultur bodenständig: Kommunikation, Teamfähigkeit, täglicher Austausch.

Für Tech-Talente, die datengetriebene Produktentwicklung ernst nehmen, die Wert auf klare Zusammenarbeit legen und die Lust haben, Legacy sinnvoll in moderne, getestete, domänennah designte Software zu überführen, ist MIC – so, wie es Wolfgang Gassner beschreibt – eine äußerst reizvolle Adresse.

Weitere Tech Talks

Weitere Tech Lead Stories