Autonomy, Clarity, Delivery: What “Michael Birsak, CTO von hi.health” Reveals About Engineering at hi.health

Context: A focused product-engineering setup in a compact team

In the session “Michael Birsak, CTO von hi.health,” speaker Michael Birsak (hi.health) offered a concise look into how a small but notably professional engineering organization structures itself, hires, and makes technical decisions. At roughly 30 people overall, hi.health dedicates almost half of its headcount—around 15—to Product Development, including approximately 11 engineers. The operating model is anchored in cross-functional collaboration, streamlined decision-making, and pragmatic technology choices.

From our DevJobs.at editorial vantage point, three themes stood out: first, autonomy and responsibility sit with two cross-functional Product Development teams. Second, the company keeps recruiting and onboarding intentionally simple, transparent, and fast. Third, a Decision Logbook underpins clear, team-wide visibility into why and how decisions are made—an engine for alignment and learning.

This line carries through from team design to the technology stack and everyday collaboration.

Team structure: Cross-functional squads with explicit roles

hi.health runs two Product Development teams, each owning a different product. Both are fully cross-functional—an arrangement that accelerates collaboration and builds ownership. As Birsak outlined, each team comprises:

• Product Owner
• Product Designer
• Development team with Frontend Engineers, Backend Engineers, and QA Engineers

These teams are meant to work “as autonomously as possible.” In practice, that means feature delivery, prioritization, and day-to-day collaboration happen within a single unit that brings together all necessary disciplines. Especially at a small team size, this structure cuts handovers and places responsibility where the work is actually done.

Why this structure appeals to engineers

• More ownership, fewer silos: Decisions are made close to the problem, and team members see direct impact on outcomes and quality.
• Clear points of contact: With Product Owner and Product Designer embedded, scope, UX, and priorities are easier to align.
• Quality built in: QA sits inside the development team, reinforcing maturity and testability.

For tech talent who thrive in compact, accountable squads, this is a purposeful environment.

Recruiting: Engineering-led, three stages, intentionally uncomplicated

Recruiting at hi.health is, in Birsak’s words, “mainly driven by us directly in engineering and supported by HR.” That signals that technical fit, team collaboration, and process clarity take precedence—and that peers have a decisive voice in hiring.

The interview process comprises three stages. The philosophy: flexible, simple, fast. No sprawling loops, no unnecessary complexity—just a clean, efficient path to a decision.

What candidates can expect

• A manageable, predictable three-stage process
• Direct interaction with engineering—not only HR
• Emphasis on practice, collaboration, and team fit rather than puzzles

The throughline is pragmatic respect for everyone’s time.

Onboarding: Four weeks, a buddy system, and dual focus on company and engineering

Onboarding at hi.health lasts “about four weeks.” From day one, each new joiner is assigned an onboarding buddy. That person covers two critical areas:

1. Company onboarding: Meeting colleagues, getting to know departments, understanding the startup.
2. Engineering-specific onboarding: Role-relevant topics and systems.

Why the buddy approach works

• A clear go-to person from day one
• Structured content accelerates ramp-up
• Social integration is taken seriously, not just tooling and access

In small organizations, targeted onboarding shortens time-to-productivity and builds belonging.

Decision-making with intent: The Decision Logbook

The “Decision Logbook” is a distinctive hallmark at hi.health. For each new technology or third-party provider, the team creates a Decision Page capturing the “key points,” including:

• Why this technology or provider?
• By when should it be adopted?
• Who is driving the decision and who is responsible?
• What options were considered?

It’s more than documentation: it’s a social artifact fostering transparency and involvement. Birsak noted it’s “well received by everyone,” and it’s used not only for technical choices but also for product decisions and anything spanning the product–tech boundary.

Benefits for engineering teams

• Traceability: Decisions remain understandable and auditable over time.
• Participation: People contribute and buy into the rationale.
• Continuity: New colleagues can read the history and ramp faster.

For engineers who value considered architecture and tooling choices, this is a strong signal of quality.

Technical orientation: Modern, pragmatic choices—no tech for tech’s sake

Birsak is explicit: hi.health’s software is “very process- and functionally driven.” There are “no special AI or ML requirements.” That frees the team to pick technology based on what “makes the most sense”—aligned to team strengths, product needs, and maintainability.

It’s an anti-dogmatic stance. Instead of optimizing for hype, the team prioritizes speed, robustness, and clarity. That’s attractive to engineers who value solid systems over trend-chasing.

The tech stack: Native mobile, React on the web, Node.js/TypeScript in the backend

hi.health’s stack is intentionally modern yet “quite simple”:

• Mobile: Native Android (Kotlin) and native iOS (Swift)
• Web: React-based web applications
• Backend: Node.js, with TypeScript used in both frontend and backend

Choosing TypeScript on both sides is deliberate: it enables full-stack contributions and allows frontend and backend engineers to “help out on both platforms.” In a small team, this is a lever for responsiveness.

What this means day to day

• Broader impact: Those who want can contribute across the delivery chain.
• Shared language: TypeScript bridges client and server.
• Lower switching costs: Similar paradigms and tools reduce friction.

Architecture and infrastructure: From monolith to microservices, from ECS to Kubernetes

hi.health’s technical journey is marked by purposeful simplification and professionalized operations:

• Replacing an early prototype (2018/2019) and a monolith (Ruby, partially Python)
• Migration to a “complete Node.js-based system”
• Today: a “microservice-based backend system”
• Infrastructure “completely in AWS”
• Tooling shift: “from GitHub to GitLab”
• Orchestration: “from AWS ECS to Kubernetes”

This trajectory reflects two things: a willingness to adapt choices as systems and teams evolve, and a steady push toward greater professionalism—both central in Birsak’s account.

Why this journey is compelling for talent

• Real learning opportunities: Work with microservices, Kubernetes, and AWS in production systems—not just demos.
• No change for its own sake: Shifts (e.g., GitHub to GitLab, ECS to Kubernetes) are grounded in pragmatic fit for team and architecture.
• Visible evolution: Moving from prototype and monolith to a modular architecture offers concrete lessons on when change pays off.

Quality and professionalism: Small team, outsized maturity

Birsak puts it plainly: “The more experienced people and specialists we add, the more professional everything becomes … the more we learn.” He also notes pride that, “despite the small team,” hi.health operates “relatively professionally.”

It’s the interplay of structured onboarding, documented decisions, and focused team design that turns professionalism into a function of clarity and discipline—not of headcount.

Everyday collaboration: Autonomy, embedded QA, and responsiveness

Autonomy in the two Product Development teams isn’t cosmetic. It reduces dependencies, preserves focus, and makes teams accountable. QA being integrated into development is a signal of built-in quality and testability.

The full-stack posture—TypeScript across frontend and backend—enables engineers to cover gaps, handle spikes, and deliver features end to end more quickly. The net effect: shorter feedback cycles, both functionally and technically.

Practical effects on delivery

• Fewer handovers, more ownership
• Shorter paths between design, development, and quality assurance
• Flexible staffing as priorities shift

For engineers who want responsibility and traction within empowered teams, this is fertile ground.

Hiring expectations: Clear fit, clear trade-offs

Two signals set expectations well. First, technology is chosen for fit (“the technology that makes the most sense”). Second, there are “no special AI or ML requirements.” Those seeking bleeding-edge ML stacks may find less alignment. Those who value pragmatic product engineering, solid architecture, and clean delivery will likely feel at home.

The engineering-led recruiting model also appeals to candidates who value peer evaluation and technical dialogue during hiring. The three-stage structure is a promise: quick, transparent, and competent.

Growth and learning: Professionalization as a team sport

At hi.health, learning is the product of a system: documented decisions, buddy-driven onboarding, cross-functional teams, and a deliberate influx of experience and specialization. That improves outcomes and day-to-day collaboration alike.

This dynamic is especially appealing if you want to take responsibility and help set standards. New joiners benefit from clear structures; experienced engineers can actively shape the next steps of professionalization.

Why hi.health appeals to tech talent

Grounded in the session “Michael Birsak, CTO von hi.health,” we see a compelling offer for developers and engineering professionals:

• Autonomous, cross-functional teams: More ownership, less coordination overhead.
• Clear, fast recruiting: Three stages, engineering-led, respectful of everyone’s time.
• Structured onboarding with a buddy: Four weeks, with company and engineering tracks.
• Transparent decisions: A Decision Logbook with rationale, options, and accountable owners.
• Modern, pragmatic stack: Native mobile (Kotlin/Swift), React, Node.js, TypeScript—no dogma.
• Full-stack opportunities: TypeScript in frontend and backend encourages breadth.
• Mature infrastructure: Microservices in AWS, shift to Kubernetes, working with GitLab.
• Lived professionalization: Learn with experienced peers, clear standards, visible evolution.

It’s a rare combination of pragmatism, discipline, and learning—especially at this scale.

Core principles that stand out

From Birsak’s overview, several principles appear to shape hi.health’s culture:

• Simplicity over complication: Processes and tools serve outcomes, not themselves.
• Decision transparency: Good decisions are traceable and documented.
• Autonomy with accountability: Teams deliver features and own the consequences of their choices.
• Learning through specialization: Adding seniority and deep skills raises the system’s quality.

These principles resonate with engineers who see their craft as precision work—grounded in clarity and continuous improvement.

Conclusion: Professional by design—an environment for builders

“Michael Birsak, CTO von hi.health” showcases an organization that knows what it wants: autonomy in cross-functional teams, crisp recruiting and onboarding, transparent decisions, and a tech stack optimized for speed and quality. The journey from monolith to microservices, full AWS adoption, and the shifts to GitLab and Kubernetes reflect the resolve to recalibrate and raise standards as the team and systems evolve.

For tech talent looking to own outcomes, influence decisions, and deliver end to end within a compact, professional setup, hi.health makes a strong case. The team demonstrates that maturity isn’t determined by size—but by intent, structure, and a culture of learning.

• 

  

  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.

  Watch now