Workplace Image MIC
Logo MIC

MIC

Established Company
Show all Videos

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.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In 'Wolfgang Gassner, Director Produktentwicklung bei MIC,' Speaker Wolfgang Gassner details Scrum-based product teams (PO, Dev Team, Scrum Master) supported by two service teams for QA and R&D; teams aim for about seven members, split around twelve, limit WIP, and self-select sprint work from the backlog to deliver continuous customer value. Hiring uses a three-step flow—initial interview, a “Look & Feel” to meet the team, see the office and tools, then a contract discussion with the owner—with strong expectations for communication and teamwork over isolated work. Technically, MIC is moving from an Oracle/PLSQL and Eclipse-Rub stack to Java Enterprise and React, embedding test automation with Cucumber and adding BI/ML/AI via Clickhouse, Apache Superset, and Apache Knife, enabling methods like Domain-Driven Design and better developer support.

From “Data Shoveling” to Domain‑Centric Delivery: How MIC Scales Product Engineering with Wolfgang Gassner (Director Produktentwicklung)

What we learned from “Wolfgang Gassner, Director Produktentwicklung bei MIC”

At DevJobs.at, we heard Wolfgang Gassner in the session “Wolfgang Gassner, Director Produktentwicklung bei MIC” outline how MIC runs product development in a data-heavy domain: transforming ERP base data, enriching it, and producing customs declarations for authorities. In his own words:

“Our main job is data shoveling.”

That mission defines everything else: team topology, delivery cadence, hiring, and the technology stack. MIC’s setup is built for continuous value delivery, pragmatic choices, and clear prioritization—without neglecting modern engineering practices. Below is our structured recap of the organization, culture, technology, and expectations Gassner shared—and why this environment is compelling for engineers.

Mission and domain: Turning ERP data into customs declarations

MIC’s software centers on data. The core flow is precise and structured: take base data from ERP systems, transform and enrich it, then generate declarations that are sent to customs authorities. Accuracy, performance, and traceability matter.

  • Strong data orientation: relational structures and well-defined workflows
  • Business process: ERP source to official customs declarations
  • Value focus: continuously deliver the most impactful outcomes for customers

This domain demands a robust database backbone, reliable integration, and engineering that engages directly with the business process.

Two team types: Scrum product teams plus infrastructure service teams

Gassner distinguishes between product teams and infrastructure teams:

  • Product teams with end-to-end responsibility for a module
  • Organized “in the spirit of Scrum” with a Product Owner, Development Team, and Scrum Master
  • Team size: aiming for ~7; in practice from 3 to 15
  • Scaling: “When teams approach twelve, we split them and form a new product team”—with its own Product Owner and Scrum Master
  • Two infrastructure teams acting as service providers
  • Quality assurance
  • New technologies/Research & Development

This model gives product teams autonomy and clear ownership while the service teams provide methods and tooling support, keeping delivery momentum high without duplicating effort.

Why this structure? Prioritize demand and maximize customer value

MIC sees strong inflow from projects and support. Not every request can be fulfilled. The organization is designed to make hard choices and focus on what matters most.

“We are not able to fulfill all requests; we have to prioritize and focus on the most important items that bring the most benefit to the customer.”

Scrum-oriented teams, service support, and module ownership are practical answers to real-world demand, not ceremony.

Delivery discipline: Pool principle, WIP limits, continuous value

Gassner describes a “pool principle”: the dev team decides what to tackle in the next sprint based on the backlog. The goal is to limit work-in-progress, avoid harmful parallelization, and deliver value continuously.

“We want to limit the work so that not too many things are being worked on in parallel … and continuously create value and deliver it to customers.”

This is a cultural statement as much as a process: teams own their focus and outcomes, and WIP limits counter past pain from working on “too many things in parallel.”

Hiring at MIC: Three stages, team-centric, communication first

New roles begin with a jointly defined profile together with the HAE department: responsibilities, tasks, competencies. The selection process is deliberately three-step:

  1. Initial interview: assess fit—both technical and cultural
  2. “Look & Feel”: the decisive team encounter
  • Meet the team you’ll work with
  • See the office, tools, and environment
  • Get to know the people you’d collaborate with day to day
  1. Contract stage with the owner: finalize and sign

The “Look & Feel” step underlines MIC’s team-first mindset: real fit emerges in real contact.

What MIC values in candidates

“We don’t want people who lock themselves away in a dark room … we encourage them to speak daily, share problems, and work on solutions together.”

  • Team orientation and communication are paramount
  • Daily exchange is expected and supported
  • Isolation is considered an anti-pattern

The choice of Scrum as an organizing blueprint is not symbolic—it’s the operating system for how work gets done.

Tech stack, then and now: Oracle at the core, Java Enterprise on the rise

With “data shoveling” at the heart of the product, the database is central. MIC has used Oracle from the beginning—relational, structured, proven. Historically, business logic lived in PL/SQL, which delivered performance advantages for data-heavy processing by running logic directly in the database.

MIC is now migrating to Java Enterprise for new processes. The reasons are both methodological and pragmatic:

  • Better support for Domain-Driven Design
  • Stronger test automation practices
  • Talent market alignment: “People trained today already know Java when they join us; PL/SQL is something I had to learn myself.”

It’s a “big challenge,” Gassner admits, but “there’s no way around it.”

Frontend modernization: From Eclipse-based UI to React

In parallel, MIC is modernizing the frontend. Today’s UI stack is Eclipse-based; the future is React. That shift “naturally” implies changes in the backend to serve the UI appropriately—this is a holistic evolution from UI to API.

Quality is built-in: Acceptance criteria, Cucumber, integrated testing

Test automation is being positioned as an integrated part of delivery, not an afterthought. The approach:

  • Define acceptance criteria together with the Product Owner in the design phase
  • Formulate functionality and scenarios in Cucumber
  • Use those scenarios as the basis for implementation and automated tests

“We don’t see it as an extra task; it should be an integrated component.”

MIC is rolling this out broadly—especially for migrations and new implementations. On legacy code, it’s “very, very difficult,” which further justifies the modernization push.

Making data useful: BI, Machine Learning, Artificial Intelligence

Across applications, BI/ML/AI is in high demand. MIC is working to provide “added value” by enabling users to perform their own analyses.

The components Gassner mentioned:

  • Clickhouse (persistence/analytics)
  • Apache Superset (visualization)
  • Apache Knife (ETL)

For engineers, this adds a rewarding dimension beyond transactional workflows: data modeling at analytic scale, performant aggregations, and a clear view of how data is explored and consumed.

Evolving the legacy: From Oracle Forms/Reports to Java—and onward

Historically, MIC was “Oracle-centered”: the database (Oracle), UI (Oracle Forms), and reporting (Oracle Reports). Over time, the UI and integration moved to Java. The current phase is to replace legacy with “state-of-the-art methods and technologies,” which is both a technical and methodological upgrade.

Why engineers should care: Clear ownership, modern practices, meaningful domain

From Gassner’s account, several reasons stand out for why MIC is an attractive engineering environment:

  • Build where value is created: from ERP data all the way to official customs declarations
  • Product-team ownership: module responsibility with support from QA and R&D service teams
  • Focus over chaos: pool principle, WIP limits, sprint discipline
  • Modernization in motion: migration from PL/SQL to Java Enterprise; moving from an Eclipse-based UI to React—with corresponding backend evolution
  • Quality as code: acceptance criteria with Product Owners and Cucumber scenarios as an executable contract
  • Analytics, not just transactions: Clickhouse, Apache Superset, and Apache Knife introduce BI/ML/AI use cases

If you enjoy deep data work, structured collaboration, and evolving real systems from legacy to modern, this is fertile ground.

The cultural backbone: Communication and teamwork, every day

Gassner anchors the culture in one simple truth: communication is everything. Practically, that means:

  • Daily team conversations and feedback loops
  • Open problem-sharing and joint problem-solving
  • No reliance on heroic solo productivity in isolation

You can see this value reflected in the structure (Scrum, team sizes, splits), the hiring process (“Look & Feel”), and engineering practices (acceptance criteria as a shared language). If you thrive on collaborative energy, you’ll thrive here.

Roles and responsibility: Scrum, but pragmatic

The roles map closely to Scrum without dogma:

  • Product Owner: prioritize and maximize customer value
  • Scrum Master: support the team and remove impediments
  • Dev Team: decide from the backlog what goes into the sprint; deliver incrementally

Team size discipline—and splitting teams around twelve—illustrates a focus on scalability and healthy dynamics. Smaller teams retain focus; splitting preserves ownership.

Engineering enablement in practice

While not labeled as such, MIC’s setup reflects an enablement mindset:

  • Service teams (QA, R&D) unblock product teams by providing expertise and tooling
  • Standardized collaboration on quality: acceptance criteria and Cucumber scenarios as a shared, executable spec
  • Future-ready stack: Java Enterprise and React provide market-aligned learning curves and patterns

This reduces drag and allows teams to spend more time on valuable increments.

What MIC expects from new colleagues

If the environment resonates with you, expect the following:

  • Strong team habits and daily communication—this is non-negotiable
  • Discipline around focus: respect WIP limits; work from the backlog; deliver in sprints
  • Interest in data and structure: relational modeling, performant processing, clean interfaces
  • Willingness to embrace migration: PL/SQL to Java Enterprise; Eclipse-based UI to React, with corresponding backend needs
  • Quality mindset: define acceptance criteria, think in Cucumber scenarios, and treat test automation as part of the work

This is a place where thoughtful, collaborative engineers can take ownership and have immediate impact.

How growth happens at MIC: Through meaningful work and proximity

Growth here emerges from the work itself and how it’s organized:

  • Ambitious modernization initiatives stretch skills and broaden experience
  • The “Look & Feel” step in hiring helps ensure you join a team whose working style matches yours
  • Collaborating with Product Owners on acceptance criteria develops product thinking and domain understanding
  • Service teams (QA, R&D) provide methodical and technological support that raises the team’s bar

It’s a learning environment that relies on real collaboration and real responsibility, not slogans.

Closing thoughts: Honest engineering, clear priorities, modernizing with intent

The session “Wolfgang Gassner, Director Produktentwicklung bei MIC” presents an engineering group that knows its reality and acts accordingly. MIC aligns a data-intensive domain with Scrum-oriented teams, prioritization discipline, and a tech evolution that supports Domain-Driven Design and test automation, while meeting the talent market where it is (Java, React, Cucumber). The culture remains grounded: communication, teamwork, and daily collaboration.

For engineers who thrive on data-centric product work, value clear collaboration, and want to help move real systems from legacy to well-tested, domain-aligned modern architectures, MIC—as described by Wolfgang Gassner—looks like a strong fit.

More Tech Talks

More Tech Lead Stories