Logo FREQUENTIS

FREQUENTIS

Etablierte Firma
Alle Videos anzeigen

Karl Wannenmacher, Head of Public Safety Products von Frequentis

Description

Der Head of Public Safety Products von Frequentis Karl Wannenmacher erzählt im Interview über die Organisation des Devteams der Abteilung Public Safety, wie dort das Recruiting geschieht und welche technischen Challenges es gibt.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In "Karl Wannenmacher, Head of Public Safety Products von Frequentis" beschreibt Karl Wannenmacher, wie ein 90-köpfiges, auf vier Standorte verteiltes R&D-Team in neun Scrum-Teams arbeitet, bevorzugt co-located ist und im Zwei-Wochen-Rhythmus mit Java-basierten Microservices sowie Web-Frontends, WebSockets und WebRTC liefert. Im Recruiting führt HR von Beginn an durch einen mehrstufigen Prozess mit frühem Fachgespräch, Skill- und Mindset-Check sowie fallbasiertem Zweitinterview; das Onboarding umfasst Welcome-Workshop und persönliches Tutoring für schnellen Teamintegrations- und Tool-Zugang. Der Vortrag betont die wachsenden Herausforderungen der Zentralisierung von Leitstellen in Rechenzentren – von Komplexität bis Cyberangriffsfläche – und warum robuste Systemarchitektur in Public Safety entscheidend ist.

Skalierte Leitstellen-Software bei FREQUENTIS: Wie Karl Wannenmacher neun Scrum-Teams, Microservices und WebRTC auf Mission Public Safety ausrichtet

Was wir aus „Karl Wannenmacher, Head of Public Safety Products von Frequentis“ mitnehmen

In der Session „Karl Wannenmacher, Head of Public Safety Products von Frequentis“ gibt Karl Wannenmacher einen selten klaren Einblick in die R&D-Organisation von FREQUENTIS im Bereich Public Safety: etwa 90 Mitarbeiter, verteilt auf vier Standorte, organisiert in derzeit neun Scrum-Teams – und alle zwei Wochen ein Release. Für uns bei DevJobs.at ist das ein Musterbeispiel, wie sich ein hochgradig verteiltes Team mit klarer Produktverantwortung, fokussierten Recruiting-Prozessen und einem konsequenten Onboarding auf einen sicherheitskritischen Markt ausrichtet.

Besonders markant: die Vorliebe für Kollokation der Teams, eine Microservice-Architektur mit Java im Backend, ein Web-Frontend mit HTML5/CSS3/JavaScript – plus WebSocket für effiziente Echtzeitkommunikation und WebRTC, um Sprache und Video direkt in den Browser zu bringen. Zusammen mit dem Trend zur Zentralisierung von Leitstellenlösungen entstehen dadurch neue Anforderungen an Sicherheit, Resilienz und Systemdesign – genau hier setzt die Engineering-Kultur von FREQUENTIS an.

„Wir fahren einen Scrum-Prozess, das heißt alle zwei Wochen wird Software releast … und alle zwei Wochen am Sprintende wird dann diese Software abgeliefert, integriert, getestet.“

Teamstruktur: 90 Personen, vier Standorte, neun Scrum-Teams

Wannenmacher beschreibt eine R&D-Organisation, die bewusst auf mehrere Standorte verteilt ist – und dennoch auf enge, teaminterne Kollaboration setzt:

  • Etwa 90 Mitarbeiter in Public Safety R&D
  • Rund 30 in Wien (Headquarter)
  • Rund 30 in Kiew
  • Jeweils ca. 15 in Bratislava und in Lublin (Polen)
  • Aktuell neun Scrum-Teams über diese Standorte hinweg

„Es ist auf vier Standorte verteilt, ist ein hochgradig verteiltes Team und wir versuchen eben so in dieser Konstellation unsere Produkte zu entwickeln.“

Das Besondere: Trotz verteilter Organisation wird Kollokation als Default gelebt. Teams sollen – wenn sie möchten – im Office zusammenarbeiten und die physischen Vorteile ausschöpfen: Whiteboards, Flipcharts, spontane Abstimmungen, schneller Wissensaustausch. Wannenmacher betont, dass Homeoffice die Situation zwar etwas verändert hat, die bevorzugte Arbeitsform jedoch weiterhin die Kollokation der Teams ist.

„Uns war von Anfang an immer sehr, sehr wichtig, dass diese Teams möglichst collocated sind … Die Teams haben dort ihre Flipcharts, die haben dort ihre lokalen Möglichkeiten der Zusammenarbeit, die man einfach in einem virtuellen Team so nicht hat.“

Arbeitsweise: Zweiwöchige Releases, Integration am Sprintende

Die neun Scrum-Teams liefern im Zweiwochenrhythmus Software aus – über alle Standorte hinweg. Aus Engineering-Perspektive sind zwei Prinzipien prägend:

1) Kurze, vorhersehbare Zyklen

  • Am Ende jedes Sprints: Lieferung, Integration, Test
  • Regelmäßiges, inkrementelles Voranschreiten schafft Transparenz und vermeidet Big-Bang-Momente

2) Produktlinien-Rhythmus mit Majorrelease und kleineren Releases

  • Einmal im Jahr: großes Produkt-Release mit allen Funktionen, die über die Sprints entstanden sind
  • Mehrmals im Jahr: kleinere Releases je nach Bedarf

„Alle zwei Wochen am Sprintende wird dann diese Software abgeliefert, integriert, getestet … und so geht es dann weiter, dass man halt einmal im Jahr eine große Produkt-Release erstellt … und auch mehrmals im Jahr dann kleinere Releases, je nach Bedarf.“

Domänenzuschnitt: Expertise bündeln, Ende-zu-Ende-Verantwortung stärken

Ein zentraler Hebel für Skalierung ist der klare Schnitt der Public-Safety-Domäne. Jedes Team bekommt eine „Heimat“ im Produkt – und damit eine Ende-zu-Ende-Verantwortung für seinen Bereich.

  • Teams sind nicht nur Feature-„Zulieferer“, sondern tragen Ownership
  • Der Domänenschnitt ermöglicht Spezialisierung, stabile Teamzuständigkeiten und eine klare Roadmap-Orientierung

„… jedes Team mit einer gewissen Expertise … dass jedes Team da eine Heimat findet und auch eine gewisse Verantwortung übernehmen kann im Sinne einer Ende-zu-Ende-Verantwortung.“

Für Talente bedeutet das: Wer bei FREQUENTIS einsteigt, übernimmt Verantwortung für ein abgegrenztes, geschäftskritisches Teilgebiet – mit der Chance, tiefes Domänenwissen aufzubauen und langfristig zu prägen.

Recruiting: Stringenter Ablauf, Fokus auf Skill-Level und Mindset

Wannenmacher skizziert einen gut orchestrierten Recruiting-Prozess, der ab dem ersten Tag durch HR begleitet wird:

1) Erstkontakt durch HR

  • Abgleich des Profils
  • Rasche Terminierung eines Gesprächs mit der Fachabteilung bei guter Übereinstimmung

2) Erstgespräch mit der Fachabteilung

  • Der Hiring-Manager ist üblicherweise dabei, oft auch ein Fachexperte
  • Einstieg in Technik und Erfahrung
  • Zentrale Kriterien: Skill-Level und Mindset

3) Zweitgespräch mit Fallbeispiel (rollenabhängig)

  • Fallbeispiel wird vorab übermittelt
  • Kandidat:in erarbeitet einen Lösungsansatz
  • Im zweiten Gespräch: Dialog über die Lösung mit der Fachabteilung

4) Team-Kennenlernen (rollenabhängig)

  • Insbesondere bei integrierten Rollen im Scrum-Team

„… schaut, passt die Erfahrung, passt das Skill-Level, ganz wichtig, passt das Mindset. … mitunter auch ein Fallbeispiel … und dann … bespricht man gemeinsam diese Lösung.“

Dieser Ablauf macht transparent, worauf es FREQUENTIS ankommt: technische Reife, Problemlösefähigkeit und persönliche Passung. Der Case-Dialog ist nicht nur ein Test – er ist ein beidseitiges Alignment-Instrument: Wie denken wir? Wie lösen wir? Wie kommunizieren wir in kritischen Situationen?

Onboarding: Welcome-Workshop und Tutor aus dem Team

Das Onboarding ist strukturiert und auf schnelle Wirksamkeit ausgelegt:

  • Am ersten Tag: Welcome-Workshop
  • Verständnis: „Wie tickt die Frequentis?“
  • Überblick: relevante Abteilungen und Prozesse für die ersten Wochen
  • Tutor aus dem jeweiligen Team
  • Holt die neue Kollegin / den neuen Kollegen vom Workshop ab
  • Begleitet die ersten Wochen, erklärt Tools und Arbeitsweise
  • Baut aktiv erste Kontakte auf

„… so haben die Mitarbeiter innerhalb weniger Wochen dann schon ein eigenes, kleines Netzwerk aufgebaut und finden sich erfahrungsgemäß sehr gut und sehr schnell zurecht.“

Für neue Kolleg:innen heißt das: Ein schneller Anschluss an Team, Tooling und Domäne – und ein klarer Pfad, um sich in einer sicherheitskritischen Produktlandschaft zurechtzufinden.

Technologie-Stack: Java-Microservices, vielseitige Persistenz, moderne Webfrontends

Wannenmacher trennt Technologieentscheidungen sauber nach Backend- und Frontend-Schichten und zeigt ein Stack-Bild, das moderne Prinzipien mit pragmatischer Auswahl verbindet.

Backend: Microservices in Java

  • Microservice-Architektur (bewusst nicht „vollständig“ nach Buch, sondern auf Relevantes fokussiert)
  • Implementierung in Java
  • Verschiedene Persistenztechnologien je nach Use Case:
  • Relationale Datenbanken
  • Dokumentorientierte Datenbanken, z. B. MongoDB
  • Elasticsearch als Such-/Index-Technologie
  • In-Memory-Data-Grids für spezielle High-Performance-Anwendungen

„Wir versuchen eine Microservice-Architektur umzusetzen … Diese Microservices werden in Java implementiert … wir verwenden verschiedenste Persistenz-Technologien … wir haben Elasticsearch mit dabei … wir haben In-Memory-Data-Grids mit dabei für spezielle High-Performance-Applikationen.“

Die Botschaft: Prinzipiengeleitet, aber pragmatisch. Nicht jeder Dienst braucht dasselbe Datenmodell; die Auswahl folgt der Funktion. Für Engineers bedeutet das: Architekturgespür und Technologiebreite sind gefragt – gepaart mit der Fähigkeit, das passende Tool für die Aufgabe zu wählen.

Frontend: HTML5/CSS3/JavaScript – Rich Internet Applications

  • Fokus auf Webtechnologie (HTML5, CSS3, JavaScript)
  • Rich-Internet-Applications, die Darstellung und Datenfluss effizient abbilden
  • WebSocket für asynchrone, performante Kommunikation mit dem Backend
  • WebRTC für Video- und Sprachstreams direkt im Browser

„… für den Datenaustausch verwenden wir Websocket-Kommunikation … seit circa zwei Jahren auch recht intensiv … WebRTC, … mit der wir Videos und auch Sprache direkt in den Browser streamen können.“

Konkreter Nutzen im Leitstellenkontext: Der Dispatcher-Arbeitsplatz kann über den Browser bedient werden – ohne zusätzliche lokale Installation.

„… so auch die Möglichkeit, am Arbeitsplatz des Disponenten … wirklich nur mehr den Browser zu nutzen und brauchen keine weitere Software dort zu installieren.“

Kollokation als Kulturanker: Geschwindigkeit, Fokus, Teamrhythmus

Kollokation ist kein Selbstzweck. In einer Domäne, in der Ausfallsicherheit, Latenz und Verfügbarkeit nicht verhandelbar sind, zählt jedes interdisziplinäre Detail – vom Domänenverständnis bis zur operativen Feinabstimmung im Sprint. Das Setting im Büro – Flipcharts, kurze Wege, spontane Whiteboard-Sessions – gibt Teams die Möglichkeit, sich schnell zu synchronisieren und Reibungsverluste zu reduzieren. Homeoffice bleibt möglich, aber die bevorzugte Form ist klar: das Team gemeinsam am Standort.

Für Bewerber:innen ist das ein wichtiges Signal: Wer Freude an hoher Dichte in der Zusammenarbeit hat, findet hier den passenden Rahmen. Wer lieber vollständig virtuell arbeitet, sollte das im Prozess ansprechen – um gemeinsam die beste Lösung für Rolle und Team zu finden.

Zentralisierung als Branchentrend – und als Engineering-Herausforderung

Ein zentrales Thema der Session ist der Wandel der Leitstellenlandschaft: von lokal installierter Technik je Leitstelle hin zu zentralen Rechenzentrums-Lösungen, auf die mehrere Leitstellen zugreifen.

Früher:

  • Jede Leitstelle hatte ihre eigene Technik vor Ort (z. B. Sprachkommunikationssystem, Einsatzleitsystem)
  • Fiel ein System aus, betraf es „nur“ den jeweiligen Einzugsbereich – andere Leitstellen waren unbeeinflusst

Heute/Trend:

  • Zentrale Systeme in einem (oft zwei) Data Center
  • Mehrere Leitstellen greifen auf die zentrale Lösung zu
  • Am Standort der Leitstelle stehen Arbeitsplätze, aber keine lokale Kerntechnik mehr

„… man versucht, mehr und mehr Leitstellen über ein zentrales System zu versorgen … da gibt es dann irgendwo ein Data Center, üblicherweise auch ein zweites aus Redundanzgründen … und die Leitstellen greifen nur mehr auf diese Lösung zu.“

Das schafft neue, anspruchsvolle Designanforderungen:

  • Größere Angriffsfläche für Cyberattacken
  • Höhere Systemkomplexität
  • Wechselwirkungen zwischen Leitstellen

„… die Angriffsflecke für Cyberattacken … wird wesentlich größer … die Systeme werden komplexer, es gibt Wechselwirkungen über die Leitstellen hinweg … und all das gilt es zu designen, zu beachten und in unseren Softwarelösungen dann auch umzusetzen.“

Für Engineers bedeutet das: verteilte Systeme denken, Resilienz als Leitprinzip verankern, Bezüge zwischen Tenants/Standorten verstehen, und Sicherheitsfragen früh im Architekturentwurf berücksichtigen. Genau hier zeigt sich der Wert einer Architektur, die Microservices, asynchrone Kommunikation und flexible Persistenzstrategien pragmatisch kombinieren kann.

Was Tech-Talente bei FREQUENTIS erwartet

Aus dem Gesagten ergibt sich ein klares Erwartungsbild:

  • Arbeiten in einem Scrum-Framework mit zweiwöchigem Takt und regelmäßiger Integration
  • Ende-zu-Ende-Verantwortung innerhalb eines geschärften Domänenschnitts
  • Kollokation im Team als bevorzugte Arbeitsform
  • Ein moderner, auf Public Safety zugeschnittener Technologie-Stack (Java-Microservices, relationale/Dokumentendatenbanken, Elasticsearch, In-Memory-Data-Grids; Frontend mit HTML5/CSS3/JavaScript, WebSocket, WebRTC)
  • Onboarding mit Welcome-Workshop und Tutor, der die ersten Wochen aktiv begleitet
  • Recruiting mit technischer Tiefe (Fallbeispiel) und Fokus auf Mindset

Wer sich für sicherheitskritische Software begeistert und sowohl Systemtiefe als auch Nutzerwirkung sehen möchte – etwa, wenn eine Leitstelle mit einem Browserarbeitsplatz zuverlässig arbeiten kann – findet hier ein Umfeld, in dem technische Entscheidungen unmittelbare Bedeutung für reale Systeme haben.

Konkrete Gründe für eine Bewerbung

  • Sichtbare Wirkung: Lösungen für Leitstellen, bei denen Verfügbarkeit und Latenz zählen
  • Stabile Delivery: zweiwöchiger Release-Takt, verlässlich integrierte Software am Sprintende
  • Tiefe Ownership: Teams mit Ende-zu-Ende-Verantwortung statt reiner „Ticket-Abarbeitung“
  • Mentoring-Kultur: Tutor ab Tag 1, schneller Aufbau eines belastbaren Netzwerks
  • Technische Breite: von Datenmodellen (relational, dokumentenorientiert) bis zu Such-/Indexierung (Elasticsearch) und High-Performance (In-Memory-Data-Grids)
  • Moderne Frontends: HTML5/CSS3/JavaScript, WebSocket-Kommunikation, WebRTC für Echtzeit-Medien
  • Lernkurve im Systemdesign: Zentralisierungstrend fordert Security-, Resilienz- und Integrationskompetenz

Tipps für den Bewerbungs- und Interviewprozess

  • Skill- und Mindset-Fit belegen: Bringe Beispiele, wie du Verantwortung übernommen und in kritischen Situationen sauber entschieden hast.
  • Case Study ernst nehmen: Arbeite das Fallbeispiel strukturiert aus, skizziere Alternativen, trade-offs und begründe deine Wahl.
  • Engineering-Klarheit zeigen: Erkläre, in welchen Szenarien du relationale vs. dokumentenorientierte Datenbanken einsetzen würdest – und warum.
  • Echtzeitdenken demonstrieren: Zeige Verständnis für asynchrone Kommunikation (WebSocket) und mediennahe Anforderungen (WebRTC).
  • Teamkultur adressieren: Reflektiere, wie du in kollokierten Settings arbeitest und welche Rituale dir helfen, schnell effektiv zu werden.

Engineering in der Praxis: Was der Stack über die Arbeit verrät

Die Wahl von Microservices in Java, kombiniert mit mehreren Persistenzmustern, deutet auf domänenspezifische Schnittstellen und klare Servicegrenzen hin. Engineers müssen Abhängigkeiten beherrschen, Schnittstellen stabil halten und Datenflüsse mit Blick auf Performance, Konsistenz und Ausfallsicherheit gestalten.

Das Frontend-Setup mit HTML5/CSS3/JavaScript, WebSocket und WebRTC zeigt den Anspruch, komplexe Informationen und Medienströme in einer robusten, browserbasierten Oberfläche zu bündeln. Für Frontend-Entwickler:innen ist das die Gelegenheit, Rich-Internet-Applications zu bauen, die nicht nur UI-Interaktionen bedienen, sondern auch reale Echtzeitbedingungen erfüllen.

Skalierung durch Rhythmus: Warum zwei Wochen den Takt angeben

Der Zweiwochenrhythmus synchronisiert Teams, Stakeholder und Integration. In sicherheitskritischen Umfeldern ist Planbarkeit keine Formalie, sondern Risikomanagement. Der jährliche Majorrelease kanalisiert die vielen Inkremente in eine klare Produktlinie, die kleineren Releases sorgen für schnelle Nachsteuerung – ohne den Gesamtplan zu verwässern.

Diese Klarheit im Takt, gepaart mit Ende-zu-Ende-Verantwortung je Team, schafft eine Organisation, die wachsen kann, ohne an Entscheidungsbelastung zu kollabieren.

Fazit: Public Safety Engineering mit Haltung und Handwerk

„Karl Wannenmacher, Head of Public Safety Products von Frequentis“ zeigt: FREQUENTIS baut Public-Safety-Lösungen mit einem klaren Engineering-Kern. Kollokierte Scrum-Teams liefern im Zweiwochenrhythmus, der Tech-Stack ist modern und zweckmäßig, Onboarding und Mentoring sind gelebte Praxis, und der Recruiting-Prozess fokussiert bewusst auf Mindset neben Skill.

Gleichzeitig nimmt FREQUENTIS die großen Branchentrends ernst – insbesondere die Zentralisierung von Leitstellenlösungen und die damit verbundene Zunahme an Komplexität und Angriffsflächen. Wer als Engineer genau dort arbeiten will, wo technisches Design reale Wirkung entfaltet, findet hier ein Umfeld mit Ambition, Verantwortung und einem Rhythmus, der liefert.

„… all das gilt es zu designen, zu beachten und in unseren Softwarelösungen dann auch umzusetzen. Und das ist … eine der großen Herausforderungen, mit denen wir uns aktuell beschäftigen.“

Für Tech-Talente, die Verantwortung suchen und ihren Impact sehen möchten, ist FREQUENTIS Public Safety ein überzeugendes Ziel – mit klaren Erwartungen, starker Teamkultur und Produkten, die zählen.

Weitere Tech Talks

Weitere Tech Lead Stories