Von C++ mit 14 zum Technical Product Owner: Benjamin Auinger (fiskaly GmbH) über API-first, eRecept und den Fokus auf Konzepte

Einleitung: Ein klarer Blick auf eine technische Karriere

In unserer Session „Title: Benjamin Auinger, Technical Product Owner bei fiskaly“ mit „Speaker: Benjamin Auinger“ von „Company: fiskaly GmbH“ haben wir eine konzentrierte Reise durch eine Entwicklerkarriere erlebt, die früh beginnt, viele Technologien streift und schließlich in einer Rolle mündet, die technische Weitsicht und Produktverantwortung verbindet. Was uns besonders auffiel: Benjamin bleibt nah an den Grundlagen, auch wenn er täglich mit APIs, Roadmaps und externen Stakeholdern arbeitet. Sein roter Faden: Die richtigen Konzepte sind langlebiger als jedes Tool.

Wir fassen zusammen, was wir gehört und gelernt haben – präzise entlang der Aussagen aus der Session. Es ist die Geschichte eines frühen Einstiegs ins Programmieren, einer Lernkurve über Schule und Freelancing bis hin zur Produktausrichtung bei fiskaly. Und es ist eine Einladung, die eigene Entwicklung weniger über Tool-Listen und mehr über Prinzipien, Kommunikation und Verantwortung zu definieren.

Frühe Anfänge: Von C++ zur Vielfalt der Sprachen

Benjamin hat früh angefangen – mit etwa 14 Jahren. C++ war der Einstieg, und das ist eine Saat, die häufig tiefe Wurzeln schlägt: Wer so früh mit einer systemnahen Sprache arbeitet, trainiert ein Gefühl dafür, wie Software unter der Oberfläche funktioniert.

Der nächste Schritt führte ihn an eine HTL, „a technical college“. Dort bekam er breite technische Exposition – Sprachen, Tools, Konzepte. Er nennt konkret Java, C#, C++, PHP und JavaScript. Die Botschaft ist klar: Breite Praxis trifft auf theoretische Fundierung.

Aus unserer Sicht ist diese Kombination richtungsweisend: Wer früh unterschiedliche Paradigmen (objektorientiert, prozedural, weborientiert) streift und parallel Algorithmen sowie Datenstrukturen ernst nimmt, baut Transferfähigkeit auf. Nicht jede nächste Sprache muss dann mühsam neu erlernt werden – man „übersetzt“ bekannte Konzepte.

Lernen in der Praxis: Freelancing schon während der Schule

Noch während der Ausbildung begann Benjamin mit Freelancing. Erst Webentwicklung rund um WordPress, dann komplexere Projekte. Das ist nicht nur ein Praxisbooster, sondern auch ein früher Einblick in Kundenerwartungen, Liefertermine, und das Navigieren zwischen Machbarkeit und Wunschliste.

Für uns liegt hier eine wichtige Lektion: Praxis bleibt unschlagbar, wenn es darum geht, die „Friction“ der Realität kennenzulernen – Integration, Kompatibilität, Kommunikation. Wer Auftraggebern erklärt, warum ein Feature so und nicht anders umgesetzt wird, übt genau die Argumentationsfähigkeit, die später in Produktrollen gebraucht wird.

Einstieg bei fiskaly: Vom Junior Developer zum Technical Product Owner

Nach der Schule war fiskaly Benjamins erster „richtiger“ Job, vor rund drei Jahren. Er stieg als Junior Developer ein, in einem sehr kleinen Team – etwa fünf Personen, inklusive der drei Gründer.

Dieses Setup ist für Lernkurven ideal: Kleine Teams zwingen zur Breite. Wer dort anfängt, bekommt früh Verantwortung, Einblick in Entscheidungen und die Chance, Produkte und Prozesse sichtbar mitzuprägen. Benjamin arbeitete in der Anfangsphase am deutschen Produkt, wechselte dann zur österreichischen Lösung – und übernahm schließlich als Technical Product Owner Verantwortung für den Fahrplan (Roadmap), die Architekturabstimmung und die Schnittstellen nach außen.

Heute betreut er das eRecept – das jüngste Produkt im Portfolio – und die österreichische Fiskalisierungslösung.

Was macht ein Technical Product Owner bei fiskaly?

Benjamin beschreibt die Rolle klar: Roadmap gestalten, Architektur mit dem Team besprechen, externe Partner einbinden und Termine koordinieren. Ein zentrales Ziel: Das „Warum“ im Team verankern, sodass jede Aufgabe einen nachvollziehbaren Zweck hat.

Diese Beschreibung zeigt, wie stark technische und kommunikative Kompetenzen hier zusammenlaufen:

• Roadmap: Prioritäten setzen, Abhängigkeiten verstehen, Sequenz planen.
• Architektur: Designentscheidungen mit dem Team abwägen, technische Risiken sichtbar machen.
• Externe Partner: Kunden, Business Development, Sales – Erwartungen synchronisieren.
• Team-Fokus: Sinn und Ziel jeder Aufgabe transparent machen.

Aus unserer Perspektive ist das eine Reise von „Ich implementiere Features“ zu „Ich schaffe Klarheit für ein gesamtes System aus Menschen, Anforderungen und Interfaces.“

API-first und Domänenfokus: Fiskalisierung und digitale Belege

fiskaly liefert „API-first solutions for fiscalization“. Benjamin nennt außerdem in Deutschland den „so-called DS-Finfo-Car“, einen Standard, um relevante Text-Daten zu protokollieren. Parallel arbeitet das Team mit eRecept an digitalen Belegen – mit Präsenz in Deutschland und Österreich und der Ambition, bis zum Jahresende große Teile von Europa zu erreichen.

Für Entwickler ist hier vor allem die Schnittstellenorientierung spannend: API-first bedeutet, dass der Vertrag zwischen Systemen – klar definierte Requests, Responses, Fehlerfälle – bewusst an den Anfang gestellt wird. Das stimmt Teams intern auf dasselbe Schema ein und erleichtert die Integration für Kunden.

Warum API-first die Produktarbeit prägt

• Konsistenz: Eine sorgfältig definierte API dient als gemeinsame Referenz für Frontend, Backend und Integrationspartner.
• Änderungsdisziplin: Versionierung, Deprecation-Strategien und Migrationspfade werden sichtbar und planbar.
• Zusammenarbeit: Externe Partner können früh testen; Feedback zielt präzise auf Schnittstellenqualität.

In Benjamins Rolle spiegelt sich das in der täglichen Arbeit: Architektur-Dialoge, Roadmap-Entscheidungen und Partnerabstimmungen drehen sich immer wieder um diese Verträge zwischen Systemen.

Kleine Teams, große Verantwortung: Was frühe Phasen prägen

Die Anfangsphase bei fiskaly – rund fünf Personen inklusive Gründer – ist mehr als nur eine Fußnote. Sie erklärt, wie man schnell von der Implementierung in die Verantwortung hineinwächst. Wer in kleinen Teams arbeitet,

• sieht, wie Produkt, Technik und Go-to-Market zusammenhängen,
• erlebt, wie Entscheidungen direkt auf Kunden und Systemverhalten wirken,
• lernt, Abstriche und Prioritäten bewusst zu treffen.

Benjamin hat genau diese Entwicklung vollzogen: vom Arbeiten am deutschen Produkt, über die österreichische Lösung, hin zur technischen Produktverantwortung. Heute hält er die Fäden für eRecept zusammen – mit Roadmap, Architekturgesprächen und externen Schnittstellen.

„Fokussiere dich auf Konzepte, nicht auf Tools“

Benjamins zentraler Karriere-Rat ist so klar wie nützlich:

Das heißt nicht, dass Tools bedeutungslos sind. Er sagt explizit, sie seien „nicht irrelevant“. Aber sie sind austauschbar, und was bleibt, sind die Prinzipien: Algorithmen, Datenstrukturen, Nebenläufigkeit, Architektur-Patterns, saubere Schnittstellen, Testbarkeit, Beobachtbarkeit. Wer diese Konzepte beherrscht, kann neue Tools schneller adoptieren.

Aus unserer Perspektive ist das der Unterschied zwischen kurzfristiger Produktivität und langfristiger Wirksamkeit. Tools wechseln; Konzepte tragen.

Praktische Umsetzung für Entwickler

• Lies Code – in verschiedenen Sprachen. Erkenne wiederkehrende Ideen.
• Baue kleine Systeme, die ein Konzept isoliert zeigen (z. B. Warteschlangen, Caching, Retry-Strategien).
• Übersetze Features in Konzepte: „Welche Datenstruktur? Welches Protokoll? Welche Invariante?“

Bildung: Fundament ja, aber nicht nur im Hörsaal

Zum Thema formale Ausbildung ist Benjamin differenziert:

Er verweist darauf, dass im Team auch Menschen mit wirtschaftswissenschaftlichem Hintergrund arbeiten, die starke Selbstlerner sind. Entscheidend ist die Haltung:

Für uns zeigt das: Ein Studium kann Struktur, Tiefe und Tempo bringen – besonders bei Grundlagen. Aber Karrierewege in Tech sind vielfältig. Wer sich Konzepte aktiv erschließt und konsequent lernt, kann den gleichen Boden erreichen.

Hinweise für Lernpfade

• Grundlagen gezielt aufbauen: Datenstrukturen, Algorithmen, Komplexität, Netzwerkgrundlagen.
• Praxis als Verstärker: Projekte, Freelancing, Open-Source-Beiträge.
• Mindset pflegen: Neugier, Feedback suchen, Lernroutinen etablieren.

Die Alltagsarbeit eines Technical Product Owner – aus Benjamins Blick

Wenn wir Benjamins Beschreibung auf konkrete Tätigkeiten herunterbrechen, ergibt sich ein Arbeitsprofil mit klaren Schwerpunkten:

• Roadmap und Sequenzierung: Welche Meilensteine sind nötig, um eRecept und die österreichische Fiskalisierungslösung zuverlässig voranzubringen?
• Architektur-Diskurs: Welche Designentscheidungen sichern Sicherheit, Wartbarkeit und Erweiterbarkeit? Wie werden Risiken früh sichtbar?
• Partnerdialoge: Kunden, Business Development und Sales haben verschiedene Blickwinkel – der TPO orchestriert Erwartungen, damit Umsetzung, Qualität und Termine zusammenpassen.
• Sinnvermittlung im Team: „…making it clear what needs to be done and for what reason…“ – Der vielleicht wichtigste Punkt. Klarheit motiviert und macht Qualität messbar.

Aus der Perspektive von DevJobs.at ist das die Übersetzung von Technik in Richtung und Kontext. Es geht nicht nur um die nächste Story im Sprint, sondern um die Fähigkeit, „Warum“ und „Wie“ zu verknüpfen.

Digitale Belege mit eRecept: Ein junges Produkt mit Ambition

Benjamin nennt eRecept als „our newest product“. Der Anspruch: für digitale Belege einen Standard mitzuprägen und mit einem API-first-Ansatz nutzbar zu machen. Heute ist das Team in Deutschland und Österreich aktiv, mit dem Ziel, bis Jahresende eine größere Abdeckung in Europa zu erreichen.

Was wir hier mitnehmen:

• „Neu“ heißt nicht unklar – es heißt, die Schnittstelle früh zu definieren und das Ökosystem mitzunehmen.
• Standards sind Teamarbeit: Gespräche mit Kunden, Business Development und Sales fließen in die Roadmap ein.
• Ambition braucht Sequenz: Schritt für Schritt planen, aber das Zielbild sichtbar halten.

Von der Codezeile zum Systemdenken: Ein Muster der Entwicklung

Benjamins Weg lässt sich als Übergang von „Implementieren“ zu „Systemdenken“ lesen:

1. Frühe technische Neugier (C++ mit 14) schafft Tiefe.
2. Breite Tool-Erfahrung (Java, C#, C++, PHP, JavaScript) schafft Flexibilität.
3. Theoretische Grundlagen (Algorithmen, Datenstrukturen) schaffen Transfer.
4. Praxisdruck (Freelancing) schärft Priorisierung und Kommunikation.
5. Produktfokus (fiskaly, kleine Teams) fördert Verantwortung und Überblick.
6. Technical Product Ownership verknüpft Technik, Roadmap und Stakeholder.

Für Entwicklerinnen und Entwickler, die ihren nächsten Schritt planen, steckt darin ein Vorschlag: Stärke deine Konzepte, suche Praxis, öffne dich für Verantwortung – und lerne, das „Warum“ genauso sauber zu formulieren wie das „Wie“.

Arbeit mit Standards: Das Beispiel „DS-Finfo-Car“

Benjamin streift den „so-called DS-Finfo-Car“ als Standard zum Protokollieren relevanter Text-Daten in Deutschland. Gerade in solchen Umfeldern entscheidet die Schnittstellenqualität über Umsetzungsgeschwindigkeit. Standards sind keine Last – sie sind ein gemeinsamer Nenner, über den Qualität messbar wird.

Was das für technische Teams bedeutet:

• Prüfe früh, wie dein API-Design zum Standard passt.
• Verankere Logging und Protokollierung als Feature – nicht als Nachgedanke.
• Plane bewusst Zeit für Konsistenzprüfungen, damit Integrationen halten.

Handlungsempfehlungen für Entwicklerinnen und Entwickler

Aus der Session mit Benjamin lassen sich konkrete Schritte ableiten, die wir an die Community weitergeben möchten:

• Lerne die Konzepte hinter den Tools: Nutze Sprachenvielfalt als Trainingsfeld für Paradigmen.
• Nutze Praxis früh und oft: Freelancing, Projekte, interne Prototypen – Hauptsache reales Feedback.
• Denke API-first: Definiere Schnittstellen so, dass Team und Partner früh andocken können.
• Übe Sinnvermittlung: Erkläre dem Team (und dir selbst) das „Warum“ jeder Aufgabe – Klarheit ist ein Produktivitätsfaktor.
• Pflege ein Lernmindset: Formale Ausbildung hilft – aber noch wichtiger ist die Bereitschaft, kontinuierlich dazuzulernen.

Zitate, die hängen bleiben

• „Focus on concepts rather than tools.“
• „…making it clear what needs to be done and for what reason…“
• „…API-first solutions for fiscalization…“
• „…I started freelancing… and then continued to more complex projects.“

Diese Sätze sind keine Schlagworte – sie sind eine Arbeitsmethode.

Schluss: Klarheit als Hebel

„Title: Benjamin Auinger, Technical Product Owner bei fiskaly“ war eine kompakte, dichte Session. Der Weg von Benjamin – vom 14-jährigen C++-Tüftler über eine breite technische Ausbildung und Freelancing bis zur Produktverantwortung für eRecept und die österreichische Fiskalisierungslösung – zeigt, was in Tech zählt: Konzepte, Praxis, Kommunikation und ein offenes Lernmindset.

In einer Rolle, in der API-first und Standards wie „DS-Finfo-Car“ eine zentrale Rolle spielen, wird Klarheit zum wichtigsten Artefakt: über Roadmaps, Architekturen, Stakeholder – und über das „Warum“ jeder Story. Genau diese Klarheit lässt Teams wachsen und Produkte tragen.

Wenn wir aus dieser Session eine Sache mitgeben dürfen, dann diese: Baue dein Fundament aus Konzepten, suche das Gespräch über Schnittstellen – menschlich wie technisch – und halte den Blick auf das „Warum“ geschärft. Der Rest folgt.

• 

  

  Patrick Gaubatz, CTO & Alexandru Stan, Agile Coach von fiskaly

  CTO und Agile Coach von fiskaly Patrick Gaubatz und Alexandru Stan erzählen im Interview über die Organisation des Teams, was neue Bewerber bei fiskaly erwartet und mit welchen Technologien dort gearbeitet wird.

  Jetzt ansehen

• 

  

  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