Engineering bei fiskaly: GitOps-Autonomie, Open-Source-Stack und Skalierung im regulierten Umfeld – Einblicke von Patrick Gaubatz & Alexandru Stan (fiskaly GmbH)

Was wir bei DevJobs.at aus der Session mitgenommen haben

In der Session „Patrick Gaubatz, CTO & Alexandru Stan, Agile Coach von fiskaly“ (Speaker: Patrick Gaubatz & Alexandru Stan, Company: fiskaly GmbH) gaben die beiden einen selten offenen Blick in die Engineering-Organisation eines schnell wachsenden API-first-Unternehmens, das im hochregulierten Umfeld der Fiskalisierung operiert. Die Kernaussage: fiskaly ist eine stark entwicklungsgetriebene Firma, die Teams echte Produktverantwortung gibt – von „build it“ über „run it“ bis „document and support it“. Gleichzeitig balanciert das Unternehmen kompromisslos zwischen Compliance-Anforderungen und moderner Engineering-Praxis – und skaliert eine Infrastruktur, die bereits „hunderttausende Docker-Container“ bewegt.

Einige Eckpunkte, die Patrick Gaubatz und Alexandru Stan klar benannten:

• Rund 23 Personen bilden aktuell das Entwicklerteam – etwa 50 % des gesamten Unternehmens. fiskaly ist also klar engineering-zentriert.
• Mehrere Entwicklungsteams mit spezifischen Skillsets tragen Ende-zu-Ende-Verantwortung für mindestens ein Produkt – teils auch für mehrere.
• GitOps ist das Leitprinzip: Teams besitzen ihren Code, ihre Infrastruktur, ihre Prozesse – und treffen ihre Entscheidungen dort, wo die Arbeit passiert.
• Rollen wie Engineering, Technical Product Owner und Agile Coach sind klar getrennt; People Leadership ist bewusst aus dem Teamkontext herausgelöst, um flache Hierarchien und Peer-Arbeit zu fördern.
• Das Umfeld ist hochreguliert: Zertifizierungen, Security-Guidelines und lange Rollout-Zyklen prägen den Alltag – ebenso wie der Anspruch, moderne Technologien sinnvoll einzusetzen.
• Die Plattform läuft konsequent containerisiert (Docker, Kubernetes) auf Linux; PostgreSQL und Nginx sind Kernkomponenten. TypeScript/JavaScript wird Full-Stack eingesetzt, performancekritische Teile wandern in Go.
• Hiring und Onboarding sind bewusst transparent, schlank und menschzentriert gestaltet – vom Kultur-Interview über eine fokussierte Coding Challenge bis zum strukturierten Einstieg mit Buddies.

Im Folgenden fassen wir die wichtigsten Aspekte aus der Session zusammen – als Orientierung für Tech-Talente, die wissen wollen, wie fiskaly arbeitet, welche technischen und organisatorischen Entscheidungen den Alltag prägen und warum sich ein Einstieg lohnt.

Kontext: API-first im regulierten Kernsystem „Fiskalisierung“

fiskaly versteht sich als API-first-Unternehmen. Die Produkte sind vor allem Backend-Services, die eine „sehr spezifische Lösung in einem kritischen Kontext“ bereitstellen: die Fiskalisierung. Patrick Gaubatz machte klar, dass der fachliche Kontext speziell ist – und dass man sich auf der Firmenwebsite weiter einlesen kann. Wichtig ist die Tragweite: Es handelt sich um Infrastruktur, die Kassenanwendungen stützt. Schon „eine Split-Second“ Downtime kann „hunderte Kunden“ treffen. Diese Kritikalität prägt Architektur, Prozesse und Kultur.

Die technische Herausforderung hat sich laut Patrick über die Zeit verschoben: Anfangs galt es, Lösungen unter strengen Auflagen zu finden – Zertifizierungen, Sicherheitsvorgaben, klare Constraints. Heute ist diese Kompetenz etabliert. Mit dem Wachstum kamen neue Themen: Verständnis des Gesamtsystems, Observability, harte SLOs und Betrieb in einer Größenordnung, die selbst erfahrene Teams respektvoll macht.

Diese Aussage ist in regulierten Infrastrukturen keine Warnung, sondern Alltagstauglichkeit: Sie fordert konservatives Engineering, Reife in der Architektur und Disziplin im Änderungsmanagement.

Teamgröße, Struktur und Ownership

Patrick Gaubatz bezifferte das Entwicklerteam auf 23 Personen – ungefähr die Hälfte der gesamten Firma. Das ist ein außergewöhnlicher Engineering-Fokus. Die Organisation setzt auf mehrere Entwicklungsteams mit spezifischen Skillsets. Zentrales Gestaltungsprinzip ist GitOps: Teams sollen stark genug sein, „das ganze Produkt“ zu besitzen – inklusive Entwicklung, Betrieb, Dokumentation und Support-Prozessen. Entscheidungen werden dort getroffen, wo Fachwissen und Verantwortung liegen: beim Team.

Diese Struktur hat klare Folgen:

• Teams verantworten mindestens ein Produkt – in manchen Fällen sogar mehrere.
• Artefakte und Prozesse liegen in der Hand derjenigen, die sie bauen und betreiben.
• Qualität, Sicherheit, Deployments und Support werden als integrale Bestandteile der Produktarbeit verstanden.

Für eine junge Firma ist diese Tiefe der Ownership bemerkenswert – und sie funktioniert, weil Kompetenzen bewusst getrennt und gleichzeitig auf Augenhöhe zusammengeführt werden.

Rollen-Design: Peer-Struktur statt Mikrohierarchie

Alexandru Stan erklärte den Rollen-Mix, der klassische agile Teamrollen aufgreift und gezielt entkoppelt:

• Engineering-Teammitglieder (Engineers)
• Technical Product Owner (technisch versiert, gibt Richtung und Guidance)
• Agile Coach (Prozesspflege, Verbesserungen, Optimierungen)
• Separates People Leadership („People Management“ bewusst aus dem Team herausgelöst)

Das Ziel: Reibung reduzieren, flache Hierarchien fördern, eine Peer-Umgebung schaffen. Führung in fachlichen Themen (Technik, Produkt, Prozess) findet im Team statt. Personalführung und individuelle Entwicklung sind bewusst getrennt, um Zielkonflikte zu vermeiden. So entsteht ein Arbeitsmodus, in dem Rollen sich ergänzen statt sich zu überlagern.

GitOps als Autonomie-Versprechen

GitOps ist bei fiskaly mehr als Tooling. Es ist ein Organisationsprinzip: Teams besitzen Produktionspfade, Policies und Automatisierung – und dürfen ihre Arbeitsprozesse „so verändern, dass sie auf ihre Arbeit zugeschnitten sind“. Entscheidungen werden dorthin verlagert, wo die Arbeit passiert. Das verlangt Reife, schafft aber Tempo und Verantwortungsbewusstsein. Wer baut, betreibt auch – mit allen Konsequenzen in Sicherheit, Compliance und Zuverlässigkeit.

Für Engineering-Talente bedeutet das: echte Gestaltungsmacht. Die Organisation will, dass die Teams „autonom“ arbeiten – und sie gibt ihnen dazu die Wege, inklusive Dokumentation, Monitoring und Support.

Arbeiten im regulierten Umfeld: Balance zwischen Compliance und Moderne

Die Produkte laufen durch Zertifizierungen, unterliegen Sicherheitsrichtlinien und müssen sich in langen Zyklen bewähren. Patrick beschrieb die Herausforderung, „den Sweet Spot“ zu finden zwischen historisch gewachsenen Compliance-Praktiken und modernen Technologien/Ansätzen.

Das hat konkrete Auswirkungen:

• Nicht jede technische Option ist möglich – Constraints sind real.
• Jedes change-relevante Teil eines zertifizierten Produkts muss erneut zertifiziert werden – das dauert Monate.
• Nach dem Rollout muss man „mit der Version leben“ – ebenfalls über Monate.

Die Konsequenz: Man arbeitet sehr sorgfältig, versteht den Stack in der Tiefe und baut Änderungen so, dass sie den regulatorischen Takt respektieren. Für Engineers ist das anspruchsvoll – und lehrreich: Architekturentscheidungen müssen auditierbar, wartbar und betriebssicher sein.

Skalierung und Betriebsrealität: Wenn Erfolg neue Probleme schafft

Mit dem Wachstum kamen laut Patrick vor allem Betriebs- und Skalierungsthemen an die Oberfläche. Die Aussage ist deutlich: „hunderttausende Docker-Container“ am Laufen zu halten, ist eine Herausforderung für sich. Noch dazu in einer Domäne, in der bereits „eine Split-Second“ Ausfall „hunderte Kunden“ bemerken.

Was das im Alltag bedeutet:

• Betriebssicherheit und Observability sind erste Bürgerrechte im Systemdesign.
• Edge Cases treten ein – nicht hypothetisch, sondern sicher. Das System muss darauf vorbereitet sein.
• Änderungen erfordern zusätzliche Sorgfalt, weil Zertifizierungen Zeit beanspruchen.

Dieser Realismus ist wertvoll: Er zeigt, dass fiskaly Performance, Resilienz und Betriebserfahrung bewusst priorisiert – und dass Fehlerkultur und Systemwissen keine Nebensache sind.

Tech-Stack: Open Source, Linux-first und bewusstes Tooling

Technologisch ist fiskaly klar positioniert:

• Backend-zentriert, API-first.
• TypeScript/JavaScript wird Full-Stack eingesetzt, insbesondere für UI-nahe Teile.
• Performancekritische Komponenten werden zunehmend in Go entwickelt.
• Durchgehend containerisiert mit Docker; Orchestrierung via Kubernetes.
• Linux ist Basis – laut Patrick nutzen in der Entwicklung „alle Linux auf dem Desktop“.
• Open-Source-Stack bis ins Fundament: PostgreSQL als Kern-Datenbank (früher „langweilig“, heute die Stärke), Nginx als bewährter Baustein.

Eine bemerkenswerte Entscheidung: fiskaly baut so, dass „potenziell alles auf dem Laptop laufen“ kann – inklusive Prozesse und Container. Das ist nicht nur Entwicklerkomfort; es ist auch eine strategische Absage an tiefe Abhängigkeiten von Cloud-spezifischen Managed Services.

Stattdessen setzt fiskaly auf die volle Eigentümerschaft des Stacks – von Dev-Maschine bis Produktion. Das erleichtert Debugging, reduziert Lock-in und stärkt die Langfrist-Handlungsfähigkeit.

Kollaboration: Produktarbeit heißt entwickeln, betreiben, dokumentieren

Die GitOps-Idee führt zu einer gelebten Realität: Teams schreiben nicht nur Code, sie betreiben und dokumentieren die Produkte auch – inklusive Supportprozessen. Das ist anspruchsvoll, aber es schafft Sichtbarkeit und Verantwortlichkeit. Entscheidungen über Tools, Prozesse und Standards liegen im Team. Der Agile Coach hält die Prozesse in Fluss, der Technical Product Owner sorgt für fachliche Richtung und technische Orientierung, und die Engineers gestalten die Umsetzung.

Die Trennung von People Leadership aus dem Teamumfeld reduziert Rollenkonflikte und stärkt die Peer-Kultur. Führung passiert dort, wo sie hingehört – fachlich im Team, persönlich im People-Leadership-Kontext.

Recruiting: Schlank, transparent und menschenzentriert

Alexandru skizzierte ein bewusst offenes Verfahren. Schon auf der Website ist der Interviewprozess einsehbar; die Offenheit soll auch auf das Onboarding ausgeweitet werden. Der Recruiting-Prozess beginnt mit der ersten E-Mail – und er ist schlank angelegt, weil Zeit kostbar ist.

Die Schritte im Überblick:

1. Bewerbung ohne Motivationsschreiben. Ein Lebenslauf und ein GitHub-Profil genügen. Wer dabei etwas von sich zeigt, umso besser.
2. Interne Sondierung durch Entwicklungskolleg:innen: Passt das Profil zu den aktuellen Team-Bedürfnissen?
3. Erstes Gespräch als Kultur-Interview. Technische Themen spielen hier keine Rolle – es geht um Persönlichkeit, Arbeitsweise und Team-Fit.
4. Coding Challenge. Das Team stellt Boilerplate-Code bereit, damit sich Kandidat:innen auf die Aufgabe konzentrieren können. Ziel: technische Passung prüfen, „die Sprache“ sprechen, Einblick in Code und Arbeitsweise geben – in beide Richtungen.
5. Technisches Gespräch mit „den besten Kolleg:innen im Feld“. Hier geht es um Seniorität, fachliche Tiefe und um die Fähigkeit, zu erklären, zu integrieren, zu motivieren – also um die Teamwirkung.

Ein paar wichtige Signale:

• Es geht nicht nur um Code, sondern auch darum, „eine Teamatmosphäre zu fördern, die Freude macht“.
• Wenn der Fit stimmt, wird nicht „auf Vergleichskandidaten“ gewartet – es wird eingestellt.
• Lange Kündigungsfristen (3–4 Monate) sind kein Ausschlusskriterium.

Onboarding: Struktur, Buddies und frühe Nähe

Nach der Zusage startet People & Culture sofort: Informationen sammeln, Informationen bereitstellen – und ein strukturiertes Onboarding, das am ersten Arbeitstag beginnt. Ein Onboarding-Paket führt durch Unternehmen, Kolleg:innen und Kontexte. Wichtig ist der Brückenschlag über Teamgrenzen hinweg: „Die ganze Firma ist das Produkt.“

Das Onboarding ist geplant über:

• den ersten Tag,
• die erste Woche,
• den ersten Monat,
• den zweiten Monat,
• und die ersten drei Monate insgesamt.

Zwischen zwei und drei „Buddies“ begleiten den Einstieg:

• Ein Buddy aus People & Culture für administrative Themen (z. B. Urlaub beantragen).
• Ein Buddy im Team, der Kontext, Code und Arbeitsabläufe nahebringt.

fiskaly legt Wert darauf, dass neue Kolleg:innen „in den ersten Wochen on premise“ sind. Die Erfahrung zeigt: So gelingt die Integration schneller, und das Gefühl von „zu Hause sein“ stellt sich früher ein. Parallel dazu läuft ein kontinuierlicher Dialog über persönliches Wachstum und Karriereentwicklung. Das Ziel sind „langfristige Commitments“.

Warum dieser Setup für Tech-Talente attraktiv ist

Aus unserer Sicht bei DevJobs.at ergeben sich aus der Session klare Gründe, warum Entwickler:innen und Engineering-Leads sich fiskaly näher ansehen sollten – alle Punkte beruhen auf dem Gehörten:

• Echte Produktverantwortung: Teams entwickeln, betreiben, dokumentieren und supporten – mit GitOps als Rückgrat.
• Autonomie mit Wirkung: Entscheidungen werden „zu den Menschen gebracht, die die Arbeit tun“ – nicht zentral verordnet.
• Klare, flache Rollen: Engineers, Technical Product Owner, Agile Coach und getrenntes People Leadership – Peer-Struktur statt Mikrohierarchie.
• Lernkurve im regulierten Umfeld: Zertifizierungen, Security-Guidelines und lange Releasezyklen lehren Sorgfalt, Architekturdisziplin und Systemdenke.
• Skalierung auf ernstem Niveau: „hunderttausende Docker-Container“, hochverfügbare Services, in denen „jede Millisekunde zählt“ – anspruchsvoller geht es kaum.
• Open-Source-first: Linux auf dem Desktop, PostgreSQL, Nginx; die Fähigkeit, „alles auf dem Laptop laufen zu lassen“; bewusster Verzicht auf Black-Box-Abhängigkeiten.
• Bewusster Stack: TypeScript/JavaScript dort, wo es passt; Go, wo Performance kritisch ist; Docker und Kubernetes als Standard.
• Transparentes Hiring: Kurzer Prozess, klare Erwartungen, Fokus auf Kultur und technische Passung – ohne überflüssige Hürden.
• Sorgfältiges Onboarding: Buddies, Cross-Team-Verbindungen und Präsenz in den ersten Wochen für einen schnellen Start.
• Menschen im Mittelpunkt: Rücksicht auf verfügbare Zeiten, kontinuierliche Entwicklungsdialoge und langfristige Beziehungen.

Zitate und Gedanken, die hängen bleiben

Einige Aussagen aus der Session bringen die Kultur und den Anspruch von fiskaly auf den Punkt:

Diese Sätze zeigen: fiskaly verbindet Pragmatismus mit hohen Ansprüchen – in Technik, Organisation und Miteinander.

Fazit: Ownership, Sorgfalt und Tempo – ohne die Menschen aus dem Blick zu verlieren

Die Session „Patrick Gaubatz, CTO & Alexandru Stan, Agile Coach von fiskaly“ (Speaker: Patrick Gaubatz & Alexandru Stan, Company: fiskaly GmbH) zeigte eine Organisation, die konsequent auf Engineering-Exzellenz und Teamautonomie setzt – ohne die Realität eines streng regulierten Umfelds zu romantisieren. Stattdessen wird die Balance gesucht: moderne Technologie, wo sie robust und beherrschbar ist; Prozessdisziplin, wo sie Sicherheit, Compliance und Betriebsstabilität wahrt.

Für Tech-Talente bietet dieses Setup eine attraktive Mischung aus Gestaltungsfreiheit, Lernkurve und Impact. Wer Systeme bauen will, die kritisch sind, im großen Maßstab laufen und dabei nachvollziehbar, zertifizierbar und anfassbar bleiben, findet bei fiskaly genau dieses Umfeld – mit Teams, die Verantwortung wirklich tragen, und einer Kultur, die Menschen ernst nimmt.

Unser Eindruck: Hier wird nicht nur Software entwickelt. Hier wird ein Produktbetrieb im besten Sinne gelebt – von der GitOps-Pipeline über den Oncall-Blick auf die Container bis zum Buddy, der am ersten Tag die richtigen Türen öffnet. Und genau das macht fiskaly als Engineering-Arbeitgeber so spannend.

• 

  

  Kostas Plakidas, Back End Developer bei fiskaly

  Kostas Plakidas von fiskaly spricht im Interview über seinen Werdegang – angefangen bei Turbo Pascal bis hin zu seiner aktuellen Arbeit – und gibt Tipps für Anfänger.

  Jetzt ansehen
• 

  

  Benjamin Auinger, Technical Product Owner bei fiskaly

  Benjamin Auinger von fiskaly erzählt im Interview über seine Laufbahn im Programmieren, was das Spannende in seinem Job als Technical Product Owner ist und gibt Tipps für Neueinsteiger.

  Jetzt ansehen