Building Transparency and Scale: Inside “The MIC Tech Radar” with Wolfgang Gassner

Why MIC needs a Tech Radar

Watching “The MIC Tech Radar,” delivered by Wolfgang Gassner (Director of Product Development), the starting point was crystal clear: in a growing technology organization with roughly 450 employees, countless evaluations, prototypes, and initiatives run in parallel. Gassner articulates the resulting challenge succinctly: for a “normal” employee, it is hard to keep track of who is working on what, what is being explored, and what is already ready for use.

That visibility problem is not a minor communications issue. It determines whether teams reuse work, avoid duplication, and collectively push in the same strategic direction. MIC’s answer is to make intent and decisions explicit through a technology strategy and a Tech Radar that together explain why things are done, how decisions are made, and how everything relates back to the company vision.

A clear North Star: the “best cloud platform” for customs and trade compliance

MIC’s vision is unambiguous:

“Cloud” here explicitly means not on-premise. MIC is running an ambitious program to migrate all on-premise customers to its SaaS—its cloud platform. That’s a technical, organizational, and process shift. And it plays out in a domain where regulatory requirements are constantly changing. If you build software here, you need to handle both the dynamics of cloud and the dynamics of regulation.

Two strategic goals set to last at least five years

From this vision, MIC formulated two strategic goals that should hold for at least five years:

1) Great products and services to grow sustainably above the market

• Continuously enhance products with new features that help users do their jobs better.
• Ensure products remain compliant with evolving customs authority regulations.
• Attract new customers and make existing customers happy.

2) Scale and accelerate business processes

• Bring software to users more efficiently and reliably.
• Strengthen support and increase quality.
• Reduce overall time to market.

Gassner stresses that MIC ties every activity—technology exploration, prototypes, tools—back to these goals and to the vision. For a company that is growing, this is not optional; it’s the mechanism that preserves focus.

The organizational lever: transparent, shared decision-making

Content-wise, the Tech Radar covers the technology landscape: tools, frameworks, platforms, techniques. Organizationally, MIC added a second, crucial lever: decision transparency. A group has been set up that concentrates expertise and makes decisions together.

Gassner is deliberate about the message: decisions are not handed down by management. The group brings knowledge together, discusses, documents, and makes joint decisions. The Tech Radar is the medium to communicate those decisions: what was decided, why, and how each decision fits the company vision.

This not only improves collaboration—it also accelerates onboarding. New colleagues get a curated view into technologies, decisions, and goals, which shortens the path to making an impact.

Tech strategy meets Tech Radar: what it covers—and what it doesn’t

Gassner notes that the tech strategy and Tech Radar cover a subset of activities—the technology-centric topics around tools, frameworks, platforms, and techniques. Other important initiatives are run alongside, supported by an OKR-based framework MIC calls “MKR-MIC.” Read together, the Tech Radar and MKR-MIC imply a consistent governance story: technology decisions are made in the context of the vision and goals, while the OKR framework links into the broader company activity set.

The cloud platform focus

A core emphasis of the tech strategy is the operational and technical reality of running a cloud platform. Historically, MIC’s applications ran on-premise at customers. Moving to the cloud is not just a data-center swap; it’s a change in the entire delivery model.

Provider choices and deployment

Gassner calls out a central decision:

This is a textbook example of what the Tech Radar is for: making platform choices explicit and explaining why they fit the vision. It gives teams clear orientation on where central services run and which infrastructure is set.

Architectural transformation: from single-tenant to multi-tenant

The architectural direction is equally explicit. MIC is transforming single-tenant applications, isolating functionality, and implementing multi-tenant services centrally deployed in the cloud.

The keyword is scalability. Multi-tenancy and cloud-native criteria aren’t presented as abstract targets; they’re prerequisites to run the best platform for the domain and to improve time to market.

From vision to day-to-day execution

Gassner repeatedly emphasizes how critical it is to link every activity back to strategy. For engineering, that translates to:

• Technology evaluations are means to an end. They must demonstrate how they contribute to product quality, regulatory conformity, and user value.
• Tool and platform choices sit under the goal of “scale and accelerate.” Do they get software to users faster and more reliably? Do they improve support and quality?
• Transparency is part of the engineering process. The Radar and the strategy documents are working assets, not side documents.

This orientation matters most during a cloud transition, where coordination and shared standards determine speed and success.

Decision-making as a team sport

A recurring theme in Gassner’s talk is team-based decisions. The cross-functional group—experts, project stakeholders, support/operations, and management—shares responsibility. That has clear effects:

• Knowledge is concentrated. Evaluations and production feedback flow straight into decisions.
• Decisions earn buy-in. When those affected are involved, implementation is faster.
• Documentation becomes first-class. The Radar is a living, visible record.

In a 450-person organization, that is a scalable mechanism: getting an explained decision (“why this technology here”) spares teams long-running basics debates and frees them to focus on product outcomes.

What the Tech Radar delivers

Gassner frames the Tech Radar as a communications tool with a clear mission:

• Make discussions and decisions transparent.
• Show how choices contribute to company goals and vision.
• Give new employees a window into “what we are doing and in which direction the company is developing.”

MIC is considering open-sourcing the radar in the future, but for now it remains internal. In the meantime, it plays its intended role: create clarity.

Engineering lessons from “The MIC Tech Radar”

From our DevJobs.at editorial vantage point, Gassner’s talk yields practical takeaways you can apply without stepping beyond the transcript’s content.

1) Tie work rigorously to the vision and goals

Linking every activity to the vision—“the best cloud platform for global customs and trade compliance”—and to the two strategic goals creates focus. Evaluations and architectural changes are framed by their contribution to growth, quality, compliance, and time to market.

2) Institutionalize decision forums

A cross-functional group that blends expert knowledge, project perspectives, operations, and management prevents siloed choices. Decisions become understandable, reusable, and faster to implement because they are shared.

3) Treat the Tech Radar as a process, not a poster

The Radar is not a static artifact. It captures “what,” “why,” and “how this fits the strategy,” and it evolves with the organization.

4) Treat cloud migration as a system change

Gassner’s line—“it changes a lot when you bring applications and systems into one place”—is central. Cloud is not just infrastructure. It introduces clear responsibilities, consistent delivery paths, and an architectural target state (for MIC: multi-tenant, cloud-native, scalable).

5) Build multi-tenancy deliberately

Moving from single-tenant to multi-tenant services is more than refactoring. It’s the architectural foundation to deploy centrally in the cloud and scale predictably. The “why” at MIC is explicit: it directly serves the vision and time-to-market improvement.

6) Decide on providers early—and communicate

Choosing “AKS as our provider besides A1” creates a stable ground plan. Such choices provide orientation and prevent the combinatorial explosion of platform options.

7) Accelerate onboarding through transparency

Gassner explicitly addresses new employees: the Radar helps them see “what we are doing and in which direction the company is developing.” Clarity on what is set—and why—shortens the runway to contribution.

Concrete applications for teams

Without going beyond what the talk states, teams can draw practical applications:

• Consolidate evaluations: instead of scattered prototypes, use the Radar to structure discussions and record outcomes.
• Anchor architectural decisions: the shift to multi-tenancy should be visible on the Radar—target state and transition included.
• Nail the operating model: “cloud platform” implies clear delivery paths and responsibilities. The Radar is where this becomes visible.
• Keep regulatory change in view: evolving customs authority requirements drive product updates; the “why” behind technology decisions should reflect that need.

The role of MKR-MIC

Gassner mentions an OKR-based framework called “MKR-MIC,” which complements the Tech Radar. Read in tandem, they form a cohesive approach: the Radar curates technology decisions, while MKR-MIC helps connect them to broader company initiatives. Both are anchored in the same vision and goals, and both rely on transparency.

Communication as part of the architecture

A notable thread in Gassner’s talk: communication is part of the system architecture. If you aim for cloud-native, multi-tenant, and scalable, you must also make decisions, reasons, and objectives explainable.

• It makes the system more change-friendly.
• It eases auditability—relevant in a compliance-heavy domain.
• It reduces friction across development, operations, and support.

In short: the Tech Radar is an architectural artifact—just as critical as a diagram or an API specification—because it provides orientation and coherence.

What Gassner focuses on—and what he doesn’t

The session’s focus is direction, organization, and guiding principles. Gassner does not go into tooling or code-level specifics. Instead, he highlights the central choices (cloud over on-premise, provider selection, multi-tenancy, cloud-native with scalability) and the governance that carries them (cross-functional group, transparency, linkage to goals, MKR-MIC as an adjacent framework). That clarity empowers teams to decide details locally while aligning to a shared target state.

Closing and invitation

Gassner closes with a direct invitation and a note on openness:

For us, the core message is that MIC uses a tight weave of vision, goals, tech strategy, and a Tech Radar to synchronize cloud transformation, product development, and organizational growth. If your organization faces similar challenges—many activities, limited visibility, high change velocity—this approach is a practical blueprint: make decisions together, make them transparent, and measure them against your company direction.

Key takeaways for engineering teams

• Vision as North Star: “best cloud platform for global customs and trade compliance” sets priorities and architecture.
• Two strategic goals: above-market growth via great products; scale and accelerate processes to reduce time to market.
• Tech Radar as transparency engine: document discussions and decisions and link them to goals.
• Cross-functional decision group: experts, project stakeholders, support/operations, and management decide together.
• Cloud focus: migrate on-premise customers to SaaS; bring applications and systems into one place.
• Provider choice: AKS alongside A1 as a clear infrastructure foundation.
• Architectural path: transform from single-tenant to multi-tenant services; cloud-native; scalability as a must.
• Complementary framework: MKR-MIC (OKR-based) for activities beyond technology.
• Accelerated onboarding: the Radar serves newcomers as a compass.
• Quality and support: continually assess whether choices improve support and quality while shortening time to market.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  How our career paths help you grow as a Software Engineer

  David Theil von MIC erläutert in seinem devjobs.at TechTalk die grundlegenden Gedanken, welche hinter den verschiedenen Rollen als Software Engineer im Unternehmen stehen.

  Watch now

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now