API‑first, end‑to‑end ownership, and offline‑ready mobile: Inside Kontron AG’s ITSM Development in Vienna with Florian Fiby

A clear look into the Business Unit ITSM

In the session “Florian Fiby, Teamlead ITSM Development bei Kontron AG,” we at DevJobs.at got a crisp, practice‑driven view of a team that blends modern service solutions with pragmatism, ownership, and solid engineering. The focus: tailored ITSM and Field Service solutions, implemented across frontend, mobile, and database—with a culture that puts API‑first, end‑to‑end responsibility, and long‑term customer relationships at the core.

Florian Fiby describes his Vienna‑based team in the Business Unit ITSM with precision:

What stands out immediately is that ITSM development at Kontron AG is not a “feature factory.” The team owns the entire lifecycle—from understanding requirements and implementation to testing, operations, and maintenance. This breadth is paired with an operating model designed for clear iterations, feedback loops, and robust interfaces. Projects are delivered nationally and internationally—across the DACH region and internally within the group.

For tech talent who want to take responsibility, master interfaces, and immerse themselves in customer requirements, this setup offers latitude and visibility. Below, we recap the key points from a leadership and employer‑branding angle to show how team structure, culture, hiring, and technology at Kontron AG fit together.

Team mission and scope: ITSM and Field Service with end‑to‑end thinking

Kontron AG’s Business Unit ITSM in Vienna delivers solutions that need to perform in real customer environments—over years. The mission is well‑defined yet broad in its demands:

• Tailored ITSM solutions for customers
• Solutions for Field Service Management
• End‑to‑end delivery: frontend, mobile, database
• Rollouts for customers nationally and internationally (DACH), as well as internal deployments

The combination of IT Service Management and Field Service Management demands an engineering mindset that goes beyond isolated modules. Especially in field service, offline capability is key. Accordingly, Fiby stresses the mobile dimension:

Offline scenarios raise the bar for data modeling, sync, and app state handling. Teams building here inherently think in robust APIs, conflict resolution strategies, and testability under unstable network conditions. The fact that the team tackles this explicitly shows how tightly their development aligns with real operational outcomes for customers.

Ways of working: Agile, iterative, and flexible to customer cadence

Agility here isn’t a label—it’s tied to a concrete cadence and rituals. Fiby outlines a process that works within the team and with customers:

Where the team can choose, two‑week sprints are the default. Where customer processes dictate, monthly cycles are used—deliberately aligned with realistic acceptance windows. This is a strong signal to engineers: agility is not dogma, it’s a framework that eases collaboration with stakeholders.

Sprint structure follows a clear rhythm:

• Planning meeting to start the sprint
• Daily stand‑ups
• Review meeting to gather feedback from external or internal customers
• Translating feedback into improvements and planning subsequent work packages

These feedback loops are essential for early validation—especially where mobile, frontend, and backend are tightly coupled. The team’s later responsibility for operations also benefits from regular acceptance and a culture of transparency.

API‑first as a collaboration principle: OpenAPI before implementation

A defining thread in Fiby’s statements is a disciplined interface orientation. Instead of “code first, document later,” the team commits to API‑first:

That’s more than a method; it’s an organizational choice. Early OpenAPI drives clear contracts between teams. It decouples frontend and mobile delivery from backend changes, enables testability (mocking, client generation), and cuts friction during the sprint. This pays off especially when multiple teams build in parallel and releases follow a customer cadence.

For developers, this is attractive because:

• Responsibilities are sharply defined
• Planning becomes more reliable through contractual boundaries
• Integration quality improves

In short: API‑first here is a lived practice that simplifies cross‑team collaboration and lifts overall quality.

Tech stack and platforms: A deliberate selection that enables breadth

Fiby outlines a stack that reflects contemporary practice—without tool overload, and with a direct link to the product needs:

• Python for the “DSM solutions”
• Frontend modules built on Angular
• Mobile app with Flutter
• Couchbase as the “source database” in the mobile app
• Deployments to OpenShift or Kubernetes
• GitOps pipelines to automatically roll out the latest development and test releases
• Choice of working environment: Windows laptop, Linux laptop, or MacBook

It’s a coherent mix: Python as a robust backend foundation, Angular for modular frontends, Flutter for performant cross‑platform mobile—augmented by Couchbase to support offline scenarios. Container‑based deployments to OpenShift or Kubernetes and GitOps pipelines complete the picture: continuous delivery becomes the standard, environments are reproducible, and test releases roll out reliably.

Another developer‑friendly signal: choosing your OS. It avoids needless friction and lets people work where they’re most effective.

Ownership, quality, and operations: End‑to‑end is the default

A central message to candidates is the expectation of end‑to‑end responsibility. Fiby puts it plainly:

The team doesn’t just ship once; Kontron AG supports customers “over several years.” That long‑term commitment shapes design. When you know you’ll share responsibility for operations, you build for maintainability, observability, and resilience—a maturity level many engineers seek, which in turn requires a fitting team culture.

Another notable point is how experience levels interact:

This is real learning in real projects: juniors grow on real‑world problems, seniors share expertise in practical collaboration. The result is a learning curve that rewards curiosity and nurtures responsibility.

Hiring: Fast, conversational, and team‑centric

The recruiting process is transparent and fast—an important factor for candidates:

The first conversation happens online as a mutual introduction. One person from HR is always present, plus either Fiby or his manager. The aim: check fundamental technical knowledge, let applicants learn about the team and work, and assess mutual interest.

If that goes well, a second interview follows at the office “am Start Nordwien,” this time with the whole team:

The message is clear: technical fundamentals matter—but the decisive factors are collaboration, communication, and a willingness to learn:

This mindset fits the end‑to‑end mission and customer‑aligned iterations. If you enjoy dialog‑driven work and taking ownership, this is your kind of environment.

What applicants can expect

From Fiby’s statements, we can distill clear expectations without buzzwords:

• Fundamentals in relevant technologies
• Willingness to learn: explore new domains individually and together with seniors
• Customer focus: interest in business requirements—not just technology
• Ownership: think from requirements through testing to operations/maintenance
• Team fit: respectful, constructive collaboration

Also, there’s joy in interface work: if you like API‑first and working from OpenAPI specs, you’ll feel at home.

Collaboration in practice: Iterations, feedback, and interface clarity

The combination of sprint rituals, API‑first, and GitOps shapes everyday collaboration. In practice, that means:

• Requirements are cut to fit the sprint cadence and validated via reviews.
• Interfaces are defined before implementation—preventing misunderstandings across frontend, mobile, and backend.
• Feedback from customers is captured regularly and translated into improvements.
• Development and test releases are rolled out automatically—making quality work more visible and reliable.

This operating model strengthens delivery speed and product quality—and equips engineers with the mechanisms to make transparent, well‑founded decisions.

Why this team is compelling for tech talent

From an employer‑branding perspective, several reasons stand out why engineers can be highly effective here:

• End‑to‑end ownership: impact across the entire lifecycle, including operations and maintenance
• Strong API culture: OpenAPI before implementation enables quality, planning, and low‑friction teamwork
• A modern stack with purpose: Python, Angular, Flutter, Couchbase, container orchestration, and GitOps—aligned to the product’s needs
• Offline mobile as an engineering challenge: demanding cases that require robust architecture and testing
• Customer‑aligned iteration: regular reviews with external and internal customers create relevance and steep learning curves
• Learning across experience levels: juniors build solutions together with seniors—learning by doing on real projects
• Choice of environment: Windows, Linux, or macOS—productivity over dogma
• A fast, transparent hiring process: quick responses and a genuine team focus in the on‑site step

Our takeaway from “Florian Fiby, Teamlead ITSM Development bei Kontron AG”

Kontron AG’s Business Unit ITSM in Vienna showcases an engineering setup that blends modern practice with pragmatism. Agility is genuinely lived—including adapting to customer release cycles. API‑first and OpenAPI specifications are the norm, not the exception. The stack is deliberately chosen to serve the product, especially for offline‑capable mobile. And the team owns the lifecycle end‑to‑end with a clear stance on quality and operations.

For talent who want to do more than ship code once—who want to sustain products and shoulder responsibility—this is an appealing environment. As Florian Fiby emphasizes, the decisive factors are people, their willingness to learn, and their ability to engage with customer requirements. Bring that mindset, and you’ll find a place where collaboration, ownership, and technology interlock meaningfully.

In sum, this team shows how disciplined API design, real end‑to‑end responsibility, and customer‑aligned agility can produce solutions that perform in the field—and give engineers the stage to apply their skills broadly and keep growing over time.

• 

  

  Sascha Leber, Mobile App Developer bei Kontron AG

  Sascha Leber von Kontron AG gibt im Interview einen Überblick über seinen Weg bis zur aktuellen Arbeit im Mobile App Development, was das spannend in diesem Feld ist und teilt Tipps für Neueinsteiger ins Programmieren.

  Watch now