Engineering, Klarheit und Tempo: Was wir aus „Michael Birsak, CTO von hi.health“ für Tech-Talente mitnehmen

Kontext: Ein Blick in ein fokussiertes Product-Engineering bei hi.health

In der Session „Michael Birsak, CTO von hi.health“ gab uns Speaker Michael Birsak (hi.health) einen konzentrierten Einblick in Aufbau, Prozesse und Technologieentscheidungen eines kompakten, aber spürbar professionellen Engineering-Setups. Was sofort auffällt: Bei rund 30 Mitarbeitenden stellt das Product-Development-Team knapp die Hälfte – etwa 15 Personen – und zählt insgesamt rund 11 Engineers. Die Organisation ist klar auf cross-funktionale Zusammenarbeit, schlanke Entscheidungswege und pragmatische Technologieauswahl ausgerichtet.

Wir bei DevJobs.at haben dabei vor allem drei Dinge beobachtet: Erstens stärkt hi.health Autonomie und Verantwortung in zwei eigenständigen Product-Development-Teams. Zweitens hält das Unternehmen Recruiting und Onboarding bewusst simpel, transparent und schnell. Drittens sorgt ein Decision-Logbook für nachvollziehbare Technologie- und Produktentscheidungen – ein wichtiger Hebel für Alignment und Lernkultur.

Diese Linie zieht sich von der Teamstruktur über den Tech-Stack bis in die tägliche Zusammenarbeit.

Teamaufbau: Cross-funktionale Squads mit klaren Rollen

hi.health arbeitet in zwei Product-Development-Teams, die jeweils unterschiedliche Produkte verantworten. Beide Teams sind cross-funktional aufgestellt – eine Struktur, die die Zusammenarbeit beschleunigt und Ownership stärkt. Laut Birsak bestehen die Teams aus:

• Product Owner
• Product Designer
• Development Team mit Frontend Engineers, Backend Engineers und QA Engineers

Ziel ist, dass diese Teams „so autonom wie möglich“ arbeiten. Das bedeutet: Feature-Entwicklung, Priorisierung und Zusammenarbeit erfolgen in einer Einheit, die alle relevanten Disziplinen vereint. Diese Entscheidung ist konsequent – besonders bei begrenzter Teamgröße, denn sie reduziert Übergaben und ermöglicht, Verantwortung dorthin zu verlagern, wo die Arbeit passiert.

Warum diese Struktur für Entwicklerinnen und Entwickler attraktiv ist

• Mehr Verantwortung, weniger Silos: Cross-funktional bedeutet, dass Entscheidungen näher am Problem fallen – und Teammitglieder direkten Einfluss auf Ergebnis und Qualität haben.
• Klare Ansprechpersonen: Mit Product Owner und Product Designer im selben Team sind Scope-Fragen, UX-Entscheidungen und Prioritäten greifbar.
• Qualität ist Teil des Teams: QA ist ins Development eingebettet. Das stärkt die Produktreife und fördert testgetriebene Arbeitsweisen.

Für Tech-Talente, die Gestaltungsfreiheit suchen und sich in kompakten, leistungsfähigen Einheiten wohlfühlen, ist das genau das richtige Umfeld.

Recruiting: Engineering-getrieben, dreistufig und bewusst unkompliziert

Das Recruiting wird, so Birsak, „hauptsächlich von uns selbst direkt im Engineering getrieben und von HR unterstützt“. Dieser Ansatz signalisiert: Fachliche Passung, Teamfit und Prozessklarheit stehen im Vordergrund – und die Peers haben eine maßgebliche Stimme bei der Auswahl neuer Kolleginnen und Kollegen.

Der Interview-Prozess besteht aus drei Phasen. Die Devise lautet: flexibel, simpel, schnell. Keine ausufernden Schleifen, keine unnötige Komplexität – stattdessen ein zügiger, strukturierter Weg zur Entscheidung.

Was Bewerbende erwarten können

• Ein überschaubarer, planbarer Ablauf mit drei Stufen
• Direkter Kontakt mit Engineering – nicht nur mit HR
• Fokus auf Praxis, Zusammenarbeit und Teamfit statt auf Puzzle-Aufgaben

Diese Pragmatik zeigt sich als roter Faden: Bei hi.health wird Zeit respektiert – die der Kandidat:innen ebenso wie die des Teams.

Onboarding: Vier Wochen, Buddy-System, Company- und Engineering-Fokus

Der Onboarding-Prozess dauert bei hi.health „circa vier Wochen“. Von Beginn an wird jedem New Joiner ein Onboarding-Buddy zugewiesen. Dieser kümmert sich um zwei zentrale Bereiche:

1. Company-Onboarding: Kennenlernen des Start-ups, der Departments und der Kolleginnen und Kollegen.
2. Engineering-Specific-Onboarding: Rollenspezifische Themen, relevante Systeme und Prozesse.

Warum das Buddy-Modell wirkt

• Klarer Ansprechpartner ab Tag eins
• Beschleunigte Einarbeitung durch strukturierte Inhalte
• Soziales Ankommen wird ernst genommen, nicht nur technisches Setup

Gerade in kleinen Organisationen verkürzt ein gezieltes Onboarding die Time-to-Productivity und stärkt Bindung und Teamgefühl.

Entscheidungsfindung mit System: Das Decision-Logbook

Besonders markant ist das „Decision-Logbook“, das hi.health für Technologie- und produktnahe Entscheidungen nutzt. Für jede neue Technologie oder einen Third-Party-Provider wird eine Decision-Page erstellt – mit den „wichtigsten Eckpunkten“. Dokumentiert werden unter anderem:

• Warum diese Technologie oder dieser Provider?
• Bis wann soll die Einführung erfolgen?
• Wer treibt die Entscheidung und wer ist verantwortlich?
• Welche Optionen stehen zur Wahl?

Das Logbook ist mehr als Dokumentation – es ist ein soziales Artefakt, das Transparenz schafft und Beteiligung ermöglicht. Birsak betont, dass das „sehr gut ankommt“ und dass hi.health über dieses Format nicht nur technische, sondern auch produktspezifische Entscheidungen – sowie jene mit Schnittstellen zwischen Produkt und Technik – trifft.

Vorteile für Technik-Teams

• Nachvollziehbarkeit: Entscheidungen sind langfristig verständlich und auditierbar.
• Beteiligung: Alle können sich einbringen und die Begründungen mittragen.
• Kontinuität: Neue Kolleg:innen finden die Historie vor und steigen schneller ein.

Für Entwickler:innen, die reflektierte Architektur- und Tooling-Entscheidungen schätzen, ist das ein klares Qualitätsmerkmal.

Technische Ausrichtung: Moderne, pragmatische Wahl statt Tech um der Tech willen

Birsak sagt klar: Die Software von hi.health ist „sehr prozess- und funktional getrieben“. Es gibt „keine speziellen AI- oder ML-Anforderungen“. Das eröffnet Freiraum, Technologie nach Sinnhaftigkeit auszuwählen – entlang von Team-Kompetenz, Produktanforderungen und Wartbarkeit.

Diese Haltung wirkt spürbar anti-dogmatisch. Statt Hypethemen zu priorisieren, wird das gewählt, was Geschwindigkeit, Robustheit und Team-Fokus ermöglicht. Das ist besonders attraktiv für Engineers, die saubere Systementwicklung über Trend-Stacks stellen.

Der Tech-Stack: Native Mobile, React im Web, Node.js/TypeScript im Backend

hi.health arbeitet mit einem bewusst modernen, aber „recht einfachen Tech-Stack“:

• Mobile: Native Android (Kotlin) und native iOS (Swift)
• Web: React-basierte Web-Applikationen
• Backend: Node.js, mit TypeScript sowohl im Frontend als auch Backend

Die Entscheidung für TypeScript auf beiden Seiten ist gezielt: Sie ermöglicht Full-Stack-Arbeit und erleichtert es, dass Frontend- und Backend-Engineers „auf beiden Plattformen aushelfen und mithelfen“. In einem kleinen Team ist das ein Hebel für Reaktionsfähigkeit und Resilienz.

Was das für die tägliche Arbeit bedeutet

• Breite Wirkung: Wer möchte, kann entlang der gesamten Delivery-Kette beitragen.
• Gemeinsame Sprache: TypeScript als verbindendes Element zwischen Client und Server.
• Weniger Kontextwechsel-Kosten: Ähnliche Paradigmen und Tools reduzieren Reibung.

Architektur und Infrastruktur: Von Monolith zu Microservices, von ECS zu Kubernetes

Die technologische Reise von hi.health ist geprägt von gezielten Vereinfachungen und professionellerer Betriebsführung:

• Ablösung eines Prototyps (2018/2019) und eines Monolithen (Ruby, teilweise Python)
• Migration auf ein „komplettes Node.js-basiertes System“
• Heute: „Microservice-based Backend-System“
• Infrastruktur „komplett in AWS“
• Tooling-Wechsel: „von GitHub auf GitLab“
• Orchestrierung: „von AWS ECS auf Kubernetes“

Diese Entwicklung steht für zwei Dinge: Erstens für die Bereitschaft, Entscheidungen anzupassen, wenn das System oder das Team es erfordert. Zweitens für die kontinuierliche Professionalisierung – ein zentraler Punkt in Birsaks Ausführungen.

Warum diese Reise für Talente spannend ist

• Lernkurve inklusive: Wer Microservices, Kubernetes und AWS in der Praxis navigieren will, findet hier reale Systeme statt reiner Spielwiesen.
• Kein Selbstzweck: Jede Änderung (z. B. GitHub zu GitLab, ECS zu Kubernetes) folgt einem Pragmatismus, der zum Team und zur Architektur passt.
• Historie sichtbar: Die Evolution vom Prototyp- und Monolith-Ansatz hin zu einer modulareren Architektur liefert Anschauung, warum und wann sich Wandel lohnt.

Qualität und Professionalität: Kleine Teams, große Wirkung

Birsak formuliert es deutlich: „Je mehr erfahrene Leute wir dazubekommen, je mehr Spezialisten wir dazubekommen, desto professioneller wird das Ganze … desto mehr lernen wir.“ Das unterstreicht eine Kernbeobachtung: hi.health ist stolz darauf, „trotz des kleinen Teams schon relativ professionell unterwegs“ zu sein.

Das Zusammenspiel aus strukturiertem Onboarding, dokumentierter Entscheidungsfindung und fokussierter Teamaufstellung erzeugt ein Umfeld, in dem Professionalität nicht an Größe, sondern an Klarheit und Disziplin hängt.

Zusammenarbeit im Alltag: Autonomie, QA-Einbindung und Reaktionsfähigkeit

Die Autonomie der zwei Product-Development-Teams ist kein Selbstzweck. Sie reduziert Abhängigkeiten, stärkt Fokus und verschiebt Verantwortung ins Team. Gleichzeitig ist QA als eigene Disziplin im Development verankert – ein Signal für Qualitätsanspruch und integrierte Testbarkeit.

Das Full-Stack-Prinzip mit TypeScript auf Frontend und Backend ermöglicht es, Lücken zu schließen, Lastspitzen zu adressieren und Features schneller end-to-end zu liefern. In Summe entsteht ein Setup, das kurze Feedback-Zyklen begünstigt – sowohl fachlich als auch technisch.

Praktische Folgen für den Delivery-Prozess

• Weniger Handover, mehr Ownership
• Kürzere Wege zwischen Design, Entwicklung und Qualitätssicherung
• Flexibles Staffing, wenn sich Prioritäten schnell verschieben

Für Engineers, die Verantwortung lieben und in klaren, handlungsfähigen Teams ihr Potenzial entfalten, ist das ein produktives Habitat.

Erwartungsmanagement im Hiring: Was passt, was nicht

Die Offenheit in Sachen Technologie („die Technologie, die am meisten Sinn macht“) und die Distanz zu Hype-Themen („keine speziellen AI- oder ML-Anforderungen“) definieren ein realistisches Erwartungsbild. Wer primär wegen Cutting-Edge-ML-Stacks wechselt, wird sich hier womöglich weniger wiederfinden. Wer pragmatische Produktentwicklung, solide Architekturarbeit und saubere Delivery schätzt, findet einen idealen Kontext.

Gleichzeitig spricht das Engineering-getriebene Recruiting jene an, die Peer-Evaluation und fachlichen Austausch bereits im Bewerbungsprozess suchen. Die dreistufige Struktur ist ein Versprechen: schnell, transparent, kompetent.

Growth und Lernen: Professionalität als Teamleistung

Lernen ist bei hi.health kein zufälliges Nebenprodukt, sondern das Resultat eines Systems: dokumentierte Entscheidungen, ein Buddy-gestütztes Onboarding, cross-funktionale Teams und der bewusste Zuzug von Erfahrung und Spezialwissen. Das verbessert nicht nur Outcomes, sondern auch die tägliche Arbeit und Zusammenarbeit.

Diese Dynamik ist besonders reizvoll, wenn man Verantwortung sucht und Lust hat, Standards mitzuprägen. Als New Joiner profitiert man von klaren Strukturen; als erfahrene:r Engineer kann man die nächsten Schritte der Professionalisierung aktiv mitgestalten.

Warum hi.health für Tech-Talente attraktiv ist

Basierend auf der Session „Michael Birsak, CTO von hi.health“ sehen wir folgende Argumente, die Entwickler:innen und Tech-Professionals ansprechen dürften:

• Autonome, cross-funktionale Teams: Mehr Ownership, weniger Koordinationsballast.
• Klare, schnelle Recruiting-Prozesse: Dreistufig, engineering-getrieben, respektvoll mit Zeit umgehend.
• Strukturiertes Onboarding mit Buddy: Vier Wochen, Company- und Engineering-Fokus.
• Transparente Entscheidungen: Decision-Logbook mit Begründungen, Optionen, Verantwortlichkeiten.
• Moderner, pragmatischer Stack: Native Mobile (Kotlin/Swift), React, Node.js, TypeScript – ohne Dogma.
• Full-Stack-Möglichkeiten: TypeScript auf Frontend und Backend fördert vielseitiges Arbeiten.
• Reife Infrastruktur: Microservices in AWS, Wechsel auf Kubernetes, GitLab-gestütztes Arbeiten.
• Gelebte Professionalisierung: Lernen durch erfahrene Kolleg:innen, klare Standards, sichtbare Evolution.

Diese Kombination aus Pragmatismus, Stringenz und Lernbereitschaft ist selten in dieser Dichte zu finden – insbesondere in einem Team dieser Größe.

Leitprinzipien, die hängen bleiben

Aus Birsaks Einblick destillieren sich einige Prinzipien, die die Kultur bei hi.health prägen:

• Einfachheit vor Kompliziertheit: Prozesse und Tools sind Mittel zum Zweck, nicht Selbstzweck.
• Entscheidungstransparenz: Gute Entscheidungen sind nachvollziehbar und dokumentiert.
• Autonomie mit Verantwortung: Teams liefern Features und tragen die Konsequenzen ihrer Entscheidungen.
• Lernen durch Spezialisierung: Mehr Seniorität und Spezialwissen erhöhen die Qualität des Gesamtsystems.

Diese Prinzipien sprechen Engineers an, die ihren Beruf als Handwerk begreifen – mit Anspruch auf Klarheit, Präzision und kontinuierliche Verbesserung.

Fazit: Professionell aus Prinzip – ein Setup für Macher:innen

„Michael Birsak, CTO von hi.health“ zeigt eine Organisation, die genau weiß, was sie will: Autonomie in cross-funktionalen Teams, klare Recruiting- und Onboarding-Pfade, nachvollziehbare Entscheidungen und ein Tech-Stack, der Geschwindigkeit und Qualität verbindet. Die Migration vom Monolithen zu Microservices, die vollständige AWS-Ausrichtung und die Umstiege auf GitLab und Kubernetes stehen für den Mut, Wege zu korrigieren und Standards zu heben.

Für Tech-Talente, die in einem kompakten, professionellen Umfeld Verantwortung tragen, Entscheidungen mitgestalten und End-to-End liefern möchten, ist hi.health ein starkes Angebot. Das Team beweist, dass Größe nicht über Reife entscheidet – Haltung, Struktur und Lernkultur tun es.

• 

  

  Declarative UI on Android

  Adrian Tappe von hi.health spricht in seinem devjobs.at TechTalk über deklarative UI on Android und zeigt einige Beispiele für Compose.

  Jetzt ansehen