← Alle Beiträge

Die besten Engineering-Teams können sofort umschwenken

Auf dieser Seite

Die effektivsten Engineering-Teams, die ich gesehen habe, haben eine Eigenschaft gemeinsam: Sie können Prioritäten von heute auf morgen verschieben, ohne auseinanderzufallen.

Das klingt einfach. Ist es nicht. Die meisten Engineering-Organisationen behandeln Prioritätswechsel wie Notfälle. Es wird gehetzt, neu verhandelt, und es gibt unangenehme Gespräche über versunkene Kosten. Die Entwickler bekommen ein Schleudertrauma. Die Manager fühlen sich, als würden sie Zusagen verraten.

Aber in Branchen mit harter Konkurrenz passen deine Ziele für Q1 vielleicht nicht mehr zu dem, wie der Markt in Q4 aussieht. Ein Wettbewerber liefert etwas Unerwartetes aus. Ein Vertriebsgespräch deckt eine riesige Chance auf. Ein Kunde eskaliert so, dass sich alles ändert. Die Teams, die gewinnen, sind die, die ohne Zeremonie reagieren können.

Planung bleibt wichtig

Ich bin nicht gegen Planung. Planung ist unverzichtbar. Das Problem beginnt, wenn Planung zum Ritual wird, das Anpassung verhindert.

Das klassische Modell sieht ungefähr so aus: Du verbringst am Ende jedes Quartals zwei Wochen damit, Prioritäten zwischen den Teams auszuhandeln, nagelst alles fest und verteidigst diesen Plan dann 90 Tage lang, egal was passiert. Taucht drei Wochen nach Quartalsbeginn etwas Dringendes auf, hast du Change-Management-Aufwand, Eskalationen bei Stakeholdern und unangenehme Gespräche darüber, was gestrichen wird.

Laut dem Developer Efficiency Report 2024 von McKinsey verbringen Entwickler nur 32% ihrer Zeit mit Code1. Die übrigen 68% gehen für Meetings, Unterbrechungen und Verwaltungsarbeit drauf. Ein Teil dieses Overheads ist unvermeidbar. Ein großer Teil ist Planungstheater.

Die Alternative ist nicht Chaos. Du behandelst Pläne als minimal tragfähige Wetten. Du verpflichtest dich nicht auf Ergebnisse für die nächsten 90 Tage. Du triffst die beste Entscheidung, die mit den aktuellen Informationen möglich ist, und bleibst bereit, nachzusteuern, sobald du etwas Neues lernst.

Die CTOs, die es richtig machen

Karri Saarinen, CEO von Linear, führt ein Unternehmen im Wert von 1,25 Mrd. $ ohne OKRs. Sein Team setzt keine metrikbasierten Ziele. Es führt keine A/B-Tests durch. Entscheidungen beruhen auf Geschmack und Meinungen, nicht auf Dashboards.

“We haven’t used OKRs,” Saarinen told Lenny Rachitsky2. “For goals, we like to keep it simple and sometimes have more strategic goals, like ‘Be the default tool for startups’ or ‘Get xxx number of companies,’ which we then use as the theme for figuring out the roadmap. I find these types of goals useful to align our team to what we are after without being too specific about how we get there.”

Die Teams bei Linear finden sich um Projekte zusammen und lösen sich auf, wenn sie fertig sind. Keine dauerhaften funktionsübergreifenden Teams. Keine Product Manager für jeden Bereich. Nur kleine Gruppen, die sich bilden, liefern und neu formieren. Das Unternehmen ist seit über drei Jahren profitabel, mit rund 80 Leuten.

PostHog erzählt eine ähnliche Geschichte. 2022 haben sie OKRs vorgeschrieben und wieder zurückgenommen. Die Entwickler haben sich “agonising over finding the right metrics” gequält, und gleichzeitig fühlte es sich an, als würden diese Metriken ihren tatsächlichen Fortschritt nicht abbilden3. Heute setzen die Teams ihre Ziele, wie sie wollen. Die Quartalsplanungs-Meetings dauern höchstens 60-90 Minuten.

“Sometimes we get our goals wrong and that’s okay,” PostHog writes. “Circumstances change, delays happen, engineers need the freedom to adjust.”

Wenn ein PostHog-Team merkt, dass es ein anderes Ziel braucht, ändert es das selbst und fängt sofort an, daran zu arbeiten. Kein aufwendiger Prozess für Zieländerungen. Es geht darum, wertvolle Produkte auszuliefern, nicht darum, den Plan von vor zwei Monaten perfekt zu erfüllen.

Warum Entwickler sich gegen Veränderung wehren

Wenn sich Prioritäten verschieben, hat das echte menschliche Kosten. Entwickler zieren sich nicht, wenn sie sich gegen Änderungen mitten im Sprint wehren. Sie haben geistige Energie investiert, um ein Problem zu verstehen. Sie haben Kontext aufgebaut. Neu anzufangen heißt, diese Arbeit wegzuwerfen und den Kontext von null aufzubauen.

Der Trick ist, den Leuten genug Informationen zu geben, damit sie verstehen, warum der Wechsel wichtig ist. Wenn Entwickler die kaufmännische Begründung verstehen und sehen, wie ein Kurswechsel mit echten Geschäftsergebnissen zusammenhängt, ändert sich die Psychologie. Es fühlt sich nicht mehr nach vergeudeter Mühe an, sondern nach Reaktionsfähigkeit.

Leistungsstarke Teams tolerieren Prioritätswechsel nicht nur. Sie erwarten sie. Die kulturelle Arbeit besteht darin, aus kaufmännischem Wandel etwas zu machen, das Leute annehmen, statt es zu erdulden.

Dynamische Szenario-Modellierung

Hier kommt es tatsächlich auf die Werkzeuge an.

Wenn eine Planänderung bedeutet, Tabellen neu zu erzeugen, Headcount über mehrere Systeme abzugleichen und Kostenfolgen von Hand neu zu berechnen, hast du einen strukturellen Widerstand gegen Anpassung gebaut. Jede Reibungsstelle ist ein Grund, nicht auf den Markt zu reagieren.

Wer schnell ein Team zusammenstellen will, um einen Piloten zu bauen und auszurollen, eine Vertriebsahnung zu prüfen oder eine Hypothese zu testen, muss die Auswirkung dieser Entscheidung sehen können, bevor er sich festlegt. Was kostet es? Was macht es mit deinen anderen Prioritäten? Wo liegt der Zielkonflikt?

Genau das bauen wir bei Flowstate: Workforce-Engineering-Tooling, das Umplanung billig macht. Verschiebe nächsten Monat eine Person mit 0,6 FTE von Team A zu Team B, und Kosten, FTE und Abweichung werden automatisch neu berechnet. Klone ein Budget und vergleiche die Auswirkung einer Reorganisation, bevor du dich festlegst. Das Ziel ist nicht weniger Planung. Es ist Planung, die sich ohne Zeremonie weiterentwickeln kann.

Wenn Umplanung billig ist, können Teams größere Würfe wagen. Sie können ein Dreierteam aufstellen, um einer Chance nachzujagen, schauen, ob es klappt, und sonst umverteilen. Diese Beweglichkeit gibt es nicht, wenn jede Änderung drei Wochen Abstimmung mit Stakeholdern braucht.

Was die besten Teams anders machen

Karri Saarinen von Linear sagt es schlicht: “Quality is our first principle. Every other metric and decision flows from that.”4

Sie sind klein und fokussiert geblieben. Rund 80 Leute bei einer Bewertung von 1,25 Mrd. $. Profitabel seit 2021. Nur zwei Personen haben das Unternehmen je verlassen. Sie setzen keine aggressiven OKRs. Sie verfolgen eine Metrik, die schwerer zu messen ist: Handwerkskunst.

PostHog arbeitet mit 26 kleinen Teams, und jedes darf seine Ziele ändern, wenn die Umstände es verlangen. Ihre Philosophie: “It’s better to change a goal to something useful than be stuck working on something useless because you said you would two months ago.”

Diese Unternehmen haben ein paar Muster gemeinsam:

  1. Kleine Teams mit echter Verantwortung. Sie führen nicht nur Aufgaben aus, sondern entscheiden, was gebaut wird und wie. Die Projektteams bei Linear bilden sich um konkrete Arbeit und lösen sich auf, wenn sie erledigt ist.

  2. Pläne als Ausgangspunkt, nicht als Vertrag. Ziele geben Richtung vor. Sie sollen niemanden an Zusagen ketten, die keinen Sinn mehr ergeben.

  3. Investition in Umplanungs-Infrastruktur. Das können raffinierte Feature Flags sein, mit denen du schrittweise auslieferst, oder Workforce-Engineering-Tools, mit denen du Änderungen modellierst, bevor du dich festlegst.

  4. Kaufmännischer Kontext, breit geteilt. Entwickler verstehen, warum sich Prioritäten verschieben, weil die Führung die geschäftlichen Gründe erklärt. Veränderung wirkt nicht mehr willkürlich.

  5. Toleranz für unperfekte Pläne. Wie es im PostHog-Handbuch heißt: “All objectives are bad. They have many compromises, are fallible, easy to game, or may be affected by external factors. So use the least bad ones.”

Du musst kein Startup sein

Die Aussage ist nicht, dass große Unternehmen wie Startups laufen sollen. Die Aussage ist, dass die Reibung beim Richtungswechsel oft eine organisatorische Entscheidung ist und kein unvermeidbarer Zwang.

Geschäftliche Beweglichkeit reicht längst weit über die Tech-Branche hinaus. Klassische Banken starten reine Digitalangebote. Hersteller passen ihre Lieferketten in Echtzeit an. Behörden richten sich neu auf Bürgerservice aus. Das World Economic Forum argumentiert, dass Resilienz und Agilität allein nicht mehr genügen. Organisationen brauchen “continuous adaptation”, um zu bestehen5.

Du kannst 10.000 Mitarbeiter haben und trotzdem die kulturelle Muskulatur aufbauen, schnell umzuschwenken. Das verlangt bewusste Arbeit. Es verlangt Investitionen in Werkzeuge. Es verlangt Führungskräfte, die das Warum hinter Veränderungen erklären, nicht nur das Was.

Dem Markt ist deine Quartals-Roadmap egal. Ihn interessiert nur, was du auslieferst.

Footnotes

  1. McKinsey Digital, “Developer Efficiency Report 2024” ↩

  2. Rachitsky, Lenny. “How Linear builds product.” Lenny’s Newsletter, 26 Sept 2023. https://www.lennysnewsletter.com/p/how-linear-builds-product ↩

  3. Vanagas, Ian. “You’re doing quarterly planning wrong.” PostHog Newsletter, 30 June 2025. https://posthog.com/newsletter/quarterly-planning-mistakes ↩

  4. First Round Review. “Linear’s Path to Product-Market Fit.” 17 Oct 2025. https://review.firstround.com/linears-path-to-product-market-fit/ ↩

  5. World Economic Forum. “Why organisations must employ continuous adaptation.” Nov 2025. https://www.weforum.org/stories/2025/11/continuous-adaptation-resilience-and-agility/ ↩