Building mission-critical control room software at FREQUENTIS: Karl Wannenmacher on nine Scrum teams, Java microservices, and browser‑native real time

What we learned from “Karl Wannenmacher, Head of Public Safety Products von Frequentis”

In “Karl Wannenmacher, Head of Public Safety Products von Frequentis,” speaker Karl Wannenmacher lifts the curtain on how FREQUENTIS structures R&D for Public Safety: roughly 90 people across four locations, currently organized into nine Scrum teams, and shipping on a two‑week cadence. From our DevJobs.at vantage point, it is a crisp example of how a highly distributed organization can stay product‑focused with clear ownership, disciplined recruiting, and a practical onboarding model for a mission‑critical market.

Standout themes: a strong preference for co‑location at team level, a Java‑based microservice architecture with multiple persistence options, a web front end built on HTML5/CSS3/JavaScript, WebSocket for efficient asynchronous communication, and growing reliance on WebRTC to stream voice and video directly in the browser. Combined with the industry shift toward centralized control room platforms, these choices raise the bar on security, resilience, and system design—precisely where FREQUENTIS aims its engineering culture.

Organization at a glance: 90 R&D teammates, four sites, nine Scrum teams

Wannenmacher outlines a distributed setup built for collaboration within teams:

• Approximately 90 people in Public Safety R&D
• Around 30 in Vienna (headquarters)
• Around 30 in Kyiv
• About 15 in Bratislava
• About 15 in Lublin (Poland)
• Currently nine Scrum teams across these sites

The twist: even with a multi‑site footprint, co‑location remains the preferred operating mode for each Scrum team. When a team chooses to be in the office, it is set up to leverage the advantages of working side‑by‑side—flipcharts, fast whiteboard sessions, and the kind of ad‑hoc problem solving that is harder to reproduce in purely virtual settings. While home office has reshaped some habits, co‑location still anchors how teams collaborate.

Delivery rhythm: Two‑week sprints, integration and testing at sprint end

All nine teams release every two weeks. Two principles stand out from an engineering perspective:

1) Short, predictable cycles

• Deliver, integrate, and test at the end of each sprint
• Incremental progress keeps risk small and transparency high

2) Product line cadence with major and minor releases

• Once per year: a major product release with the accumulated functionality
• Several times per year: smaller releases based on need

This discipline creates a drumbeat that aligns teams, stakeholders, and product goals, ensuring a steady flow of customer‑visible progress without sacrificing integration quality.

Domain boundaries and end‑to‑end ownership

FREQUENTIS deliberately slices the Public Safety domain so that each team has a “home” in the product and can assume end‑to‑end responsibility. That means:

• Teams own a coherent domain area rather than acting as generic feature factories
• Specialization deepens expertise and stabilizes accountability
• Ownership guides technical decision‑making and backlog prioritization

For engineers, this translates into true domain stewardship: you will develop and operate within a clear scope, build durable knowledge, and have a say in how your area evolves.

Hiring: HR from day one, fast technical conversations, and case‑based assessment

The recruiting process is structured and supported by HR from the start:

1) Initial HR contact

• Profile alignment
• Quick handover to the hiring team if there is a strong match

2) First interview with the hiring team

• Usually includes the hiring manager and often a subject matter expert
• Technical deep dive into experience and skill level
• Mindset and cultural fit are considered crucial

3) Second interview with a case (depending on the role)

• The case is sent in advance
• Candidates prepare a solution approach
• The conversation focuses on discussing and refining that solution together

4) Team meet‑and‑greet (depending on the role)

• Especially for integrated roles within a Scrum team

The emphasis throughout: skill, experience, and mindset. The case isn’t a trick; it’s a dialog that reveals how you reason through constraints, trade‑offs, and critical decisions—exactly the kind of thinking this domain demands.

Onboarding: Welcome workshop and a team tutor to ramp you up fast

On day one, newcomers join a welcome workshop that explains how FREQUENTIS operates and what processes matter most in the first weeks. A tutor from the relevant engineering team then picks them up from that workshop and serves as the hands‑on guide through the initial ramp‑up:

• Tools, build/run workflows, and team rituals
• Key contacts across the organization
• A support structure that helps new colleagues build their internal network quickly

The result is speed to confidence: in just a few weeks, engineers are productive and connected to the right people.

Technology stack: Java microservices, fit‑for‑purpose persistence, and web‑native real time

Wannenmacher separates backend and frontend decisions and favors fit‑for‑purpose choices over dogma.

Backend: Microservices in Java

• Microservice architecture (implemented pragmatically—focused on what’s relevant)
• Services implemented in Java
• Multiple persistence technologies depending on the use case:
• Relational databases
• Document‑oriented databases such as MongoDB
• Elasticsearch in the stack
• In‑memory data grids for specialized high‑performance applications

The takeaway: principles applied with pragmatism. Not every service needs the same data model, and the platform accommodates that diversity. Engineers are expected to choose the right tool for the job and understand the implications for performance, consistency, and fault tolerance.

Frontend: HTML5/CSS3/JavaScript with WebSocket and WebRTC

• Web frontends built as rich internet applications
• HTML5, CSS3, and JavaScript form the core
• WebSocket enables efficient, asynchronous client‑server communication
• WebRTC is used to stream voice and video directly in the browser

The practical upshot for control rooms: a dispatcher’s workstation can run in the browser, with no additional local software required.

Co‑location as a cultural backbone

Co‑location isn’t an ideological stance—it’s a practical choice for a mission‑critical domain. When latency, availability, and resilience are central, the speed of human coordination matters. Whiteboards, spontaneous huddles, and immediate feedback loops help teams iterate on hard problems quickly. While remote work patterns exist, the preferred setup is to have the team in the same space.

For candidates, that signals a working style: if you thrive on intense, in‑person collaboration and shared team rhythm, you’ll likely enjoy the environment. If you prefer fully virtual setups, raise that early so both sides can align on expectations.

Centralization: the industry shift and why it matters for engineers

A major theme in the session is the transition from locally installed systems per control room to centralized solutions hosted in data centers and accessed by multiple control rooms:

Before:

• Each control room operated its own on‑premise systems (e.g., voice communications, dispatch)
• A failure affected that area only—no cross‑impact on other control rooms

Now (and trending):

• Solutions are hosted in a data center (often two, for redundancy)
• Multiple control rooms access the central platform
• Local sites have workstations but not the core technical stack

This amplifies the engineering challenge:

• Larger attack surface for cyber threats
• Increased system complexity
• Cross‑control‑room interactions with real operational consequences

For engineers, this means thinking in distributed systems, designing for resilience by default, and anticipating multi‑tenant interactions in architecture and operations. It’s where microservices, asynchronous messaging, and carefully chosen data strategies earn their keep.

What tech talent can expect at FREQUENTIS

Based on the session, here’s a clear picture of the engineering experience:

• Scrum with a two‑week release cadence and integration at sprint end
• End‑to‑end ownership within a clearly defined domain slice
• Co‑located teams as the preferred collaboration model
• A purpose‑built stack for Public Safety:
• Java microservices
• Relational and document databases
• Elasticsearch
• In‑memory data grids for high‑performance needs
• HTML5/CSS3/JavaScript front ends with WebSocket and WebRTC
• Onboarding that pairs a welcome workshop with a dedicated team tutor
• Recruiting that values mindset and problem‑solving as much as raw skill

If you want to see your software move from design to tangible impact—like enabling a browser‑only dispatcher workplace—you’ll find an environment where engineering decisions matter at real‑world scale.

Compelling reasons to join

• Purpose and impact: build systems where uptime, latency, and usability are mission‑critical
• Reliable delivery: a two‑week rhythm with integrated, tested software at each sprint end
• True ownership: teams that carry end‑to‑end responsibility, not just ticket streams
• Mentorship from day one: a tutor guides your first weeks and accelerates your network
• Technical breadth: from relational vs. document data models to search/indexing (Elasticsearch) and in‑memory performance patterns
• Modern web real time: WebSocket for data exchange and WebRTC for voice/video streaming in the browser
• Systems thinking: centralization brings rich challenges in security, resilience, and multi‑site interactions

How to approach the interview process

• Demonstrate both skill and mindset: show where you took ownership and made clear decisions under constraints
• Treat the case study as a collaborative design exercise: structure your solution, discuss trade‑offs, and articulate why you chose a specific path
• Show architectural judgment: explain when you’d prefer relational vs. document databases—and why
• Exhibit real‑time awareness: demonstrate understanding of asynchronous communication (WebSocket) and media streaming (WebRTC)
• Address team style directly: share how you operate in co‑located settings and what helps you become effective quickly

What the stack says about day‑to‑day engineering

The Java microservice approach, combined with multiple persistence models, points to clear service boundaries, explicit interfaces, and nuanced data flows. Engineers will need to manage dependencies, keep interfaces stable, and design for performance and failure modes.

On the front end, HTML5/CSS3/JavaScript, coupled with WebSocket and WebRTC, implies building rich, browser‑native applications that handle more than UI polish—they must cope with real‑time data and media under operational pressure. It is a place where frontend engineering meets systems thinking.

Scaling through cadence: why two weeks matter

The two‑week sprint and release cycle synchronizes teams and stakeholders around integration and readiness. In Public Safety, predictability is risk management. The annual major release consolidates the many increments into a coherent product baseline, while smaller releases allow targeted updates without disrupting the broader plan.

This rhythm, together with end‑to‑end ownership, enables the organization to grow without overloading central decision‑making.

Closing thoughts: Engineering with purpose in Public Safety

“Karl Wannenmacher, Head of Public Safety Products von Frequentis” shows FREQUENTIS treating Public Safety engineering with rigor and intention. Co‑located Scrum teams deliver on a two‑week cadence, the stack is modern and pragmatic, onboarding and tutoring are operationalized, and recruiting leans into mindset alongside skill.

At the same time, the company squarely faces the sector’s biggest shift: centralization of control room systems, bringing complexity and expanded attack surfaces. For engineers who want their architecture and code to matter in real operations, this is an environment with clear expectations, meaningful responsibility, and a delivery rhythm that gets software into the field.

If you’re looking to apply systems thinking, real‑time web technologies, and end‑to‑end ownership to problems that truly count, FREQUENTIS Public Safety is a compelling destination.

• 

  

  Safety-critical Software Solutions

  Djamel Sahnine von Frequentis zeigt in seinem devjobs.at TechTalk mit welchen Herausforderungen sich die Software Entwicklung im Unternehmen auseinandersetzt.

  Watch now
• 

  

  Drones Swim

  Thomas Lutz von Frequentis zeigt in seinem devjobs.at TechTalk welche Rahmenbedingungen geschaffen werden, um in Zukunft mit einer hohen Zahl an Drohnen umgehen zu können.

  Watch now
• 

  

  CCR

  Richard Draxelmayr von Frequentis spricht in seinem devjobs.at TechTalk darüber, welche Vorteile eine gute Review-Kultur im Devteam hat.

  Watch now

• 

  

  Günter Graf, VP New Business Development von Frequentis

  Der VP New Business Development von Frequentis Günter Graf umreißt im Interview die Inhalte des Unternehmens, was der Fokus bei New Business Development ist und erläutert auch, warum gutes Domain Knowledge den Unterschied macht.

  Watch now