Wie FINN seine Software Engineers abschaffte – und was das über AI-native Orgs lehrt

"We eliminated the software engineers at FINN. All of them."

Dieser Satz von Andreas Stryz, CTO & Co-Founder von FINN, ist einer der bemerkenswertesten Organisationsschnitte des Jahres. Nicht weil er dramatisch klingt. Sondern weil er logisch ist.

Not because they weren't good. Because the role itself stopped making sense.

Das ist kein Hiring-Fail. Das ist ein Rollen-Fail. Und es ist das erste Mal, dass ein europäisches Tech-Unternehmen dieser Größenordnung öffentlich zugibt: Die Rolle „Software Engineer" hat ausgedient. Nicht die Menschen. Die Aufgabenbeschreibung.

Warum die Rolle obsolet wurde

Stryz' Argument ist simpel und brutal ehrlich:

Wenn AI 80% deines Codes schreibt, was ist der verbleibende Wert von jemandem, dessen Identität „Ich schreibe Code" ist?

Es ist nicht null. Aber es schrumpft schnell. Der schwere Teil ist nicht mehr das Schreiben des Codes. Es ist das Wissen, was gebaut werden soll, warum es wichtig ist, und wie es zum Business passt.

Das ist keine technische These. Das ist eine organisationale. Und sie trifft den Kern dessen, was wir bei Till Freitag seit Monaten beobachten:

Die Constraint verschiebt sich von „Wie bauen wir es?" zu „Was ist das Richtige zu bauen?"

Das ist nicht neu. Was neu ist: Die Geschwindigkeit, mit der diese Verschiebung passiert. Und die Konsequenz, die FINN daraus zieht.

Von Software Engineer zu Product Engineer

FINN hat nicht einfach gekündigt und neu eingestellt. Same people. Fundamentally different job.

Der Unterschied zwischen einem Software Engineer und einem Product Engineer bei FINN:

Software Engineer (alt)	Product Engineer (neu)
„Ich baue, was mir gesagt wird."	„Ich own das, was ich shippe."
Wartet auf Tickets	Eigene Business-Probleme end-to-end
Kommuniziert über Jira	Spricht direkt mit Stakeholdern
Versteht die Tech-Stack	Versteht das kommerzielle Modell
Schreibt Code selbst	Bau mit AI als Heavy-Lifting-Tool

Der Product Engineer bei FINN wartet nicht auf ein Ticket. Er besitzt ein Business-Problem von der ersten Analyse bis zum Go-Live. Er spricht mit Stakeholdern. Er versteht das kommerzielle Modell. Er baut – mit AI, die den Großteil der Implementierung übernimmt.

Die Kernkompetenz ist nicht Code-Schreiben. Es ist Urteilsvermögen und Planung.

Sie bewerten, was die AI produziert. Sie finden die Fehler. Sie treffen die Entscheidungen über Architektur, Trade-offs und User Impact, die kein Agent treffen kann. Sie ownen, was shipped wird. Es gibt kein „Der Agent hat es gemacht."

Das neue Rollenmodell bei FINN

FINN hat nicht nur eine Rolle ersetzt. Das Unternehmen hat ein neues Engineering-Rollenmodell eingeführt:

• Product Engineers – Business-Problem-Owner, end-to-end, AI-gestützt
• Design Engineers – Die Schnittstelle zwischen Design-System und shippable UI
• Platform Engineers – Infrastruktur, Tooling, AI-Agent-Enablement

Auch Product Manager und Engineering Manager haben ein Facelift bekommen – Details folgen in den kommenden Wochen.

Das ist kein Kosmetik-Update. Das ist ein kompletter Neubau der Engineering-Organisation, ausgehend von einer Prämisse:

Wenn AI den Großteil der Produktion übernimmt, müssen Menschen das übernehmen, was AI nicht kann: Kontext, Urteil, Ownership.

Drei Pilot-Teams, drei Erkenntnisse

FINN testet das neue Modell seit Wochen in drei Pilot-Teams: Retention, Infleeting, Remarketing. Neue Rollen, keine Sprints. Der vollständige Rollout kommt im Mai.

Hier sind die drei wichtigsten Learnings – und warum sie für jedes Tech-Team relevant sind:

1. Cheap code is dangerous code

AI macht Bauen schnell und günstig. Das klingt großartig, bis man merkt, dass man jetzt die falschen Dinge schneller shipped.

The temptation to just build because you can is real.

FINN musste disziplinierter werden in der Auswahl, was gebaut wird – nicht weniger. Das ist das Paradoxon von AI-gestütztem Engineering: Die Barriere zu bauen sinkt. Die Barriere, das Richtige zu bauen, steigt.

Was das für dich bedeutet: Wenn dein Team plötzlich 5x schneller baut, brauchst du bessere Strategie, nicht weniger. Sonst baust du dich in eine Ecke – mit rekordverdächtiger Geschwindigkeit.

2. The constraint moved upstream

Mit AI, die Engineering supercharged, hatten FINN's Product Managers plötzlich eine viel größere Leinwand zu gestalten. Der alte Rhythmus von Specs und Handovers war nicht für dieses Tempo gebaut.

Das ist ein gutes Problem. Es bedeutet: Die Arbeit verschob sich von „Wie shippen wir es?" zu „Was ist das Richtige zu shippen?"

Strategy becomes the leverage point. Exactly where we want it.

Was das für dich bedeutet: Die Engpässe in deiner Organisation verschieben sich nach oben – zu Product, Strategy, Kontext. Wenn deine Product Manager noch primär Tickets schreiben, hast du ein Problem.

3. Micro teams don't just move faster. They think differently.

3-4 Personen, die einen KPI end-to-end ownen, treffen fundamental andere Entscheidungen als 8 Personen, die einen Backlog teilen.

Sie hören auf zu fragen: „Ist das im Scope?"

Sie fangen an zu fragen: „Löst das das Problem?"

Das ist der Unterschied zwischen Auftragsverarbeitung und Problem Ownership. Und genau darum geht es bei FINN's neuem Modell.

Was das für dich bedeutet: Kleinere Teams mit klarer Ownership sind nicht nur schneller – sie denken anders. Wenn deine Teams noch nach Scope-Listen arbeiten statt nach KPIs, bist du noch im alten Modell.

Was FINN für die Branche bedeutet

FINN ist kein Einzelfall. Aber FINN ist einer der ersten, die es öffentlich und konsequent so machen. Andreas Stryz dokumentiert den Prozess auf LinkedIn – nicht als Marketing-Gimmick, sondern als transparentes Experiment.

Für uns bei Till Freitag ist das Validation dessen, was wir seit Monaten mit unseren Kunden besprechen:

• Die Rolle „Entwickler" verschwindet nicht. Sie transformiert.
• AI ist kein Ersatz für Menschen. Sie ist ein Ersatz für repetitives Coden.
• Die wertvollsten Engineer-Talente von morgen sind nicht die besten Coder. Sie sind die besten Denker, die mit AI coden.
• Organisationsdesign ist das neue Engineering. Wer seine Struktur nicht anpasst, verschenkt 80% des AI-Potenzials.

Fazit: Die Frage ist nicht „Wie?" sondern „Wer?"

FINN's Experiment ist mutig. Es ist auch notwendig. Denn die Unternehmen, die in 12 Monaten führen werden, sind nicht die mit der besten AI. Sie sind die mit der besten Anpassung ihrer Organisation an AI.

Andreas Stryz und sein Team zeigen, wie das aussieht: Rollen neu definieren. Ownership verschieben. Teams kleiner machen. Und vor allem: Die richtigen Leute in die richtigen Rollen bringen – nicht die Rollen, die vor AI existierten.

If your engineers still define themselves by lines of code, you're holding onto a role that AI has already made obsolete.

Das gilt nicht nur für FINN. Das gilt für jedes Tech-Team auf dem Planeten.

---

Follow Andreas Stryz on LinkedIn für Updates zum FINN-Experiment.