MIC

Established Company

Show all Videos

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.

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

Video Summary

In Organization for Fast Flow, Gerald Schweizer (MIC) details MIC’s shift from a classic functional setup to a Team Topologies-inspired model: stream-aligned product and service-delivery teams supported by platform, enabling, and complicated-subsystem teams to cut cognitive load, reduce handovers, and speed delivery across a global, highly regulated customs software portfolio. Using his 24-person CAST Germany & Austria team, he illustrates end-to-end ownership, biweekly Scrum cycles, ITIL-oriented support with mostly waterfall testing, and a Customer Success Manager as the single contact—practices viewers can adopt to scale product development in complex, distributed environments.

Organization for Fast Flow at MIC: Stream-aligned teams, platform leverage, and end-to-end ownership in a complex customs domain

What this session covered

In Organization for Fast Flow by Gerald Schweizer (Speaker) at MIC (Company), we heard a first-hand account of a company-wide organizational shift: from a classic functional setup to value stream–oriented, cross-functional teams. Schweizer leads the CAST Germany & Austria value stream—the import/export filing solution for those countries—and helped pilot the change before it expanded more broadly. His core message: to move faster in a complex domain, you need team boundaries that match value, reduced cognitive load, and tight feedback loops across development, projects, and support.

The context: broad product portfolio, 55+ countries, and global teams

MIC has grown continuously since 1988—on average around 10% headcount per year—reaching 500+ employees across multiple locations worldwide. Over the decades, the product portfolio expanded substantially:

CAST: customs filing (import/export) with country-specific modules, including Germany and Austria.
CCS: classification of parts and master data.
OCS: origin calculation, leveraging free trade agreements.
ECM: export control management—checking whether business with an entity is permitted, in a world of sanctions.
Global trade content services (e.g., tariff data).
A data analytics product to make sense of the accumulated data.
Additional modules like GAM and functionality for recalculations.

Country coverage stands at 55+ nations, with direct or broker-based communication to customs authorities across many time zones. The process landscape is equally diverse:

Standard import/export declarations.
Bonded warehouse procedures.
Inward processing relief (e.g., automotive use cases with globally sourced parts and final export).
Outward processing relief.
Recalculations and after-the-fact changes.

Schweizer emphasized how this breadth magnifies cognitive load. Not everyone can be an expert in every module, every country, and every process. That’s where the pains of the old structure became evident.

Where the functional organization started to fail

Previously, MIC was organized by function—development, projects, support. Development already had product-oriented splits (CAST per country, OCS, ECM, etc.), but project and support teams often had to operate across the entire portfolio. That created several systemic issues:

High cognitive load in support: a single ticket could span OCS, CAST across multiple countries, and ECM—frequently interwoven with customer-specific processes. That requires wide knowledge across products, regulations, and integrations.
Distributed coordination overhead: development in one region, support in another, enterprise customers in a third—setting up the right people in the same call across time zones became a chore. In between: time lags, knowledge loss, and lots of coordination.
Handovers as friction: large rollouts often run for years, and when the project ends, all learning must transition to support. Compressing “two to three years of knowledge” into a few meetings is a recipe for gaps.
Meetings about meetings: too much time went into aligning how to solve a problem instead of solving the problem.

In short, the organization’s horizontal slices didn’t match the vertical flow of value. The result: slow feedback, diluted ownership, and unnecessary handoffs.

The redesign: Organization for Fast Flow

MIC’s new structure leans heavily on the concepts in Team Topologies, adapted to their context and product suite. The model uses four team types.

1) Stream-aligned teams

These are the primary delivery units. MIC runs two flavors:

Product teams: end-to-end responsibility for a product slice, including development, project delivery, and maintenance/support. Schweizer’s CAST Germany & Austria team is an example.
Service delivery teams: focused on enterprise customers; they rely on product teams for complex matters or product adaptations.

This shifts the organization to vertical slices that own value end to end, reducing handovers and tightening feedback loops.

2) Platform teams

They reduce cognitive load by providing reusable infrastructure and services. Concrete examples from the talk:

Interfacing (e.g., ADIS) as a shared service, including country-specific routes; product teams consume APIs instead of each building and maintaining their own interface stack.
Cloud infrastructure: product teams “don’t want to deal with Kubernetes clusters; they just use them.”

3) Enabling teams

These are temporarily “rented” to help teams improve, set up processes, or develop strategies. Agile coaches are a prime example—embedded with a value stream while needed, and moving on when the team stabilizes.

4) Complicated subsystem teams

Specialized expertise that doesn’t have to live in every team permanently. Schweizer cited the SAP team: they engage on customer projects to handle SAP specifics without requiring every project manager to be an SAP expert.

Collaboration patterns

Platform teams collaborate with and provide services to stream-aligned teams.
Enabling teams facilitate and catalyze improvements; they remain temporary by design.
Complicated subsystem teams are brought in where and when their expertise is needed.

The combined effect is faster delivery, clearer accountability, more scalability, and reduced cognitive load on the stream-aligned teams.

Product streams: vertical value, fewer handovers

A product stream is vertically integrated around business value. Unlike the old functional cuts, each stream houses the roles needed to deliver and operate its value slice:

One team is responsible end to end: development, project delivery, and ongoing maintenance/support.
Direct feedback loops: what emerges in delivery or support feeds back immediately into product and engineering decisions.
Fewer and simpler handovers: project managers, support, and engineers collaborate daily; knowledge stays within the team.

For enterprise customers who might worry about navigating many internal teams, MIC introduced a main customer contact in the form of a Customer Success Manager (CSM). The CSM plans joint activities, keeps the relationship, and routes requests to the right stream/team. Externally, the path is simple; internally, the organization can stay modular.

Inside the CAST Germany & Austria product stream

Schweizer’s team carries end-to-end responsibility for CAST in Germany and Austria. When the team formed, they set a clear vision:

“A simple, reliable, and complete CAST DA and RTA solution that meets customer needs—achieved by supporting each other and working together as a team.”

Team makeup and roles (24 people)

Value Stream Lead: the people lead who ensures the team has what it needs to perform well; also handles administrative topics like vacations and salary discussions.
Product Owner: accountable for product development, legal changes, and market success; must understand customer needs and ensure regulatory compliance in the software.
Agile Coach: embedded as part of the enabling approach; co-designs processes with the lead and PO, and supports team development and collaboration.
Developers: implement and evolve product functionality.
Business and third-level analysts: work on projects and development; they translate business requirements, support specifications, and handle complex problem tickets.
Incident managers: focus on support and customer care.
Project managers: lead implementations, working closely with the customer and the team over months or even years for large rollouts.

Service-centered and development-centered lanes

Given team size, MIC differentiates work focus:

Service-centered: incident managers and project managers.
Development-centered: developers.
Bridging roles: business analysts and third-level analysts move between both.

This isn’t about creating new silos—it’s about focus while keeping cross-functional collaboration as the default.

Operating model and delivery processes

Biweekly, Scrum-based development cadence

The team plans on a two-week rhythm and reviews outcomes at the end of each cycle—keeping progress visible and feedback tight.

Support flows guided by established practices

Schweizer described support as “highly orientated about the ETL guidelines,” with incidents, service requests, and, for severe issues, problem records to drive long-term fixes. The key is clear separation between urgent restoration of service and deeper, systemic resolution.

Testing and delivery: context first

Agile or Waterfall depending on the situation.
In customs, Waterfall dominates: the target (a legally defined customs declaration with a set of data) is known upfront. Teams must decide ahead of time where data comes from, how it is processed, and the degree of automation. Still, most projects keep room for small agile iterations.

Domain onboarding and shared understanding

A cornerstone of the culture is domain literacy across roles. Developers need to understand why a process must be built a certain way from a legal standpoint; project and support colleagues must grasp regulatory details to operate effectively. New joiners receive an in-depth introduction to German and Austrian customs processes over their first days, weeks, and months.

Culture: no silos, shared ownership

The team operates as a true cross-functional unit.

Developers can pick up support incidents—together with incident managers or independently where appropriate.
Project colleagues may handle support tickets when needed.
Support colleagues can contribute to specifications or validation for development work.

The norm is mutual support. The effect: faster learning, fewer handovers, and problems solved where the knowledge is.

Outcomes: a successful pilot and a company-wide rollout

According to Schweizer, the product stream approach is working well. MIC is now rolling it out across the company. The core improvements are visible in flow: fewer handovers, tighter feedback, and clearer ownership from development through delivery to support—exactly what’s required when operating in a highly regulated, multi-country customs domain.

Actionable takeaways for engineers and leaders

From the DevJobs.at editorial seat, several practical patterns stand out from Organization for Fast Flow:

1) Align team boundaries with value

Slice vertically so a team can deliver end to end: development, project delivery, and support within the same value stream.
Reduce handovers; keep the learning close to where the work happens.

2) Proactively manage cognitive load

Create platform teams for reusable infrastructure (interfaces, cloud) so product teams consume services, not rebuild commodities.
Keep rare expertise in complicated subsystem teams you can “rent” when needed (e.g., SAP).

3) Use enabling teams to accelerate

Embed agile coaches and other enablers temporarily to help a stream set up processes, align roles, and establish continuous improvement.

4) Simplify the customer interface

Internally, keep modular teams; externally, provide a main contact (CSM) who knows the relationship and routes work efficiently.

5) Make domain knowledge a team asset

Onboard every role into core business processes; don’t outsource legal/regulatory understanding to a single function.
Encourage developers to understand why—not just what—they are implementing.

6) Choose delivery models by context

Iterate where uncertainty is high; adopt Waterfall where legal certainty dictates fixed outcomes and upfront design.

7) Design for distributed reality

Acknowledge time zones and minimize dependencies that require synchronous alignment across regions.
Favor small, frequent team touchpoints over large cross-departmental alignment calls.

How to get started toward fast flow

Map your portfolio: products, countries, legal procedures, integrations. Identify the hotspots of handovers and knowledge loss.
Define product streams: choose vertical boundaries aligned with value (e.g., a country cluster like CAST Germany & Austria) rather than slicing by function.
Isolate platform services: interfaces, routing, and cloud infrastructure that multiple streams can consume as a service.
Staff streams end to end: include PO, engineering, project, support/incident management, plus bridging roles (business/third-level analysis).
Add enablers: bring in an agile coach to bootstrap cadence, ceremonies, and continuous improvement.
Establish cadence: biweekly planning and reviews for development; clear incident/service/problem flows for support.
Introduce a CSM: one main customer contact to hold the relationship and orchestrate internally.
Pilot, then scale: validate the cuts and collaboration, then roll out to adjacent areas.

Signs you’re on the right track

Without inventing extra metrics, you can look for qualitative shifts consistent with Schweizer’s account:

Fewer and shorter handovers between project and support because roles collaborate in one team.
Less time lost to cross-time-zone coordination; more problems solved in the stream’s daily rhythm.
Higher domain fluency across roles, leading to better first-time-right outcomes.
A smoother customer experience via a main contact, even as internal structure becomes more modular.

Closing

Organization for Fast Flow by Gerald Schweizer at MIC illustrates how an enterprise operating in a complex, regulated space can realign around value streams. The transformation is not just about changing reporting lines—it’s about reducing cognitive load with platform services, bringing rare expertise in when needed, and giving one team end-to-end accountability from build to run. The outcome: faster flow, fewer handovers, tighter feedback, and a scalable model that respects both the depth of the domain and the realities of global delivery.

More Tech Talks

More Tech Lead Stories