Tech Investment Framework.

Das vage Gefühl, dass Engineering zu langsam ist

Bei der Arbeit mit Kunden und Boards höre ich oft Beschwerden über das Engineering und die Tech-Abteilung: “Wir haben das Gefühl, dass Engineering zu langsam ist.”

Aber wie kann man wirklich messen, ob Engineering zu langsam ist? Und was ist der beste Weg, das zu ändern? Lassen Sie uns einen Trick erkunden, den ich von Holger und seinem Team bei Solvares gelernt habe.

Und wenn Sie sich für mehr zu diesem Thema interessieren, schauen Sie sich meine anderen Beiträge an:

• Wie man Capex in Softwareunternehmen korrekt kategorisiert
• Warum aktivierbare Arbeit für die Geschäftsplanung wichtig ist

Softwareentwicklung ist schwierig und unvorhersehbar

Softwareentwicklung (auch im Zeitalter der KI) ist notorisch herausfordernd. Software zu erstellen und langfristig zu warten ist überraschend schwer. Die Planung und Veröffentlichung von Software geht oft schief, und die gesamte Branche ist übersät mit gescheiterten Projekten und verschwendetem Geld.

Sicher, es gibt Methoden wie agile Entwicklung, die die Erfolgswahrscheinlichkeit in der Softwareentwicklung erhöhen. Und natürlich gibt es DORA, das uns sagt, dass wir häufig releasen sollten. Es gibt auch das Microsoft Office Team, das sehr gut darin war, seine Software pünktlich zu veröffentlichen – ganz im Gegensatz zum Microsoft Windows Team, das historisch mit pünktlichen Releases zu kämpfen hatte (mehr dazu im großartigen Acquired Podcast über Microsoft).

Wild.

Ein besserer Weg zu wissen, was in Ihrer Dev-Abteilung los ist

Holger nutzt das Balancing and Budgeting Engineering Framework von Matt Eccelston bei Dropbox.

Was es tut, ist einfach:

1. Es kategorisiert die Aufgaben Ihrer Ingenieure in zwei Bereiche: “Elective”-Arbeit und “Keeping the Lights On” (KTLO).
2. Es ermöglicht Ihnen, Ihre Investitionen in diese zwei Bereiche strategisch zu planen.

Anstatt zu sagen: “Mein Engineering ist zu langsam”, können Sie dies umkehren und aktiv planen, wo Sie in neue Produktfeatures investieren, und dabei aufdecken, wo Ihre Ingenieure Zeit verbringen, die für Kunden nicht sichtbar ist. Großartig für die Jahresplanung. Großartig, um zu wissen, was gerade passiert.

Gamechanger.

Zwei Bereiche

Lassen Sie uns die zwei großen Bereiche erkunden: Keeping the Lights On und Elective. Elective wird weiter in drei Bereiche unterteilt: Neue Features, Verbesserungen bestehender Features und Produktivitätsverbesserungen.

Bereich “Keeping the Lights On”

Der Bereich für Keeping the Lights On enthält alles, was nötig ist, um Ihr Geschäft in seinem aktuellen Zustand aufrechtzuerhalten. Stellen Sie sich vor, welche wesentlichen Aufgaben Sie aus technischer Sicht erledigen müssen, um Ihr Geschäft zu betreiben.

Matt beschreibt dies als “minimale Aufgaben zur Aufrechterhaltung des aktuellen Serviceniveaus in den Augen unserer Kunden.”

Ich komme normalerweise auf folgende Aufgaben für diesen Bereich:

• Alles rund um Sicherheit (Audits, ISO 27001 Compliance, Bug-Bounty-Programme etc.).
• On-Call-Dienste zur Aufrechterhaltung der aktuellen Betriebszeit.
• Fehlerbehebung und Bug Fixing (von Kunden gemeldete funktionale Fehler), Service-Monitoring (SLAs / SLOs).
• System-Upgrades für frische Sicherheitsupdates und die neuesten Abhängigkeiten (Docker-Container, Linux-Versionen, Programmierbibliotheken, Anwendungen etc.).

Die Liste ist nicht in Stein gemeißelt und kann für Ihr Geschäft anders aussehen.

Bereich “Elective”

Bereich “Elective” ist alles, was Ihr Produkt besser macht und hoffentlich höheren Umsatz oder andere zukünftig positive Ergebnisse bringt. Er ist in drei Bereiche unterteilt:

Build New

Alles, was neue marktfähige Produktfähigkeiten beiträgt und bei Kundengewinnung und Upselling hilft. Es ist etwas Neues, das Ihr Produkt kann und das von Kunden als wertvoll wahrgenommen wird (hoffentlich). Die meisten wachsenden Unternehmen werden ihre Elective-Bereiche hierauf fokussieren.

Arbeit in diesem Bereich ist:

• Sichtbar
• Nicht “nur” eine Verbesserung einer bestehenden Fähigkeit (dafür haben wir Feature Improvements).

Beispiele:

• Ein neues Produkt hinzufügen
• Ein neues Feature hinzufügen, das vorher nicht existierte
• Eine neue Plattform oder einen Partner unterstützen (Linux, Windows, aber auch APIs anderer Unternehmen etc.)

Improve Existing

Im starken Kontrast zu “New” enthält dieser Bereich alles, was mit der Verbesserung der Qualität bestehender Features zu tun hat. Zeit in diesen Bereich zu investieren, verbessert die Kundenzufriedenheit, erhöht die Retention und erleichtert die Kundengewinnung.

Beispiele:

• Von Kunden gewünschte Verbesserungen
• Bessere Performance (Geschwindigkeit, Kosten, Akkulaufzeit etc.)
• Verbesserung der Usability, Onboarding-Zeit etc.
• Verbesserung der Produktzuverlässigkeit / schnellere Antwortzeiten
• Verbesserung der Sicherheitslage. Die Implementierung von ISO 27001 gehört hierher.

Improve Productivity

Der letzte Elective-Bereich hat keine direkte kundengerichtete Oberfläche. Die Verbesserung dieses Bereichs macht Ihre Organisation und Teams schneller. Nicht nur Ihre Engineering-Teams, sondern auch andere Teams wie den Kundensupport. Die Verbesserung dieses Bereichs ermöglicht es Ihnen, mehr mit Ihrem aktuellen Personalbestand zu schaffen.

Ergebnisse:

• Ingenieure werden produktiver
• Verbesserung des Durchsatzes für schnellere Releases
• Reduzierung des %-Anteils von KTLO

Kategorien:

• Bessere Tools und Metriken
• Testautomatisierung
• Code-Refactoring
• Framework-Upgrades zur Reduzierung zukünftigen Aufwands
• Arbeit zur Reduzierung des %-Anteils im KTLO-Bereich

Welche Prozentsätze wählen

Prozentsätze sind nicht in Stein gemeißelt und hängen stark von Ihrem Geschäft, der Unternehmensreife und anderen Faktoren ab. Für mich ist der wichtigste Teil, dass das bewusste Planen der Prozentsätze gute Diskussionen auslöst und das Festlegen der Prozentsätze den Teams hilft, die richtigen Dinge zu priorisieren.

Es ist ähnlich wie bei OKRs – OKRs dienen nicht nur dem Setzen von Zielen, sondern dem gemeinsamen Finden guter Ziele mit den Teams. Die Diskussion über die Größe der Bereiche ist sehr ähnlich – es geht nicht nur um den Prozentsatz, sondern um die Diskussion und das Finden einer Einigung über die Bereiche.

Elective-Bereich

Ich strebe normalerweise 60% Build New, 20% Improve Existing und 20% Improve Productivity an. Das ist auch das, was Matt bei Dropbox verwendet hat, und ist eine allgemein gute Faustregel.

KTLO vs Elective

Die Faustregel ist 10-30% KTLO versus 90-70% Elective.

Aber die große prozentuale Aufteilung zwischen KTLO und Elective ist variabler. Sie können zunächst damit beginnen, den KTLO-Anteil Ihrer Engineering-Aufwände zu messen. Wenn die prozentuale Aufteilung in Ordnung ist, können Sie sie einfach zur Überwachung nutzen und so belassen.

Bei einigen meiner Kunden lag die Aufteilung bei 80% KTLO und 20% Elective. In dem Fall war ganz klar, dass etwas nicht stimmte. Die Fehlausrichtung sichtbar zu machen, war der erste Schritt und ermöglichte meinem Kunden, die Dinge zum Besseren zu verändern.

Wann das Balanced Investment Framework nutzen

Das Balanced Investment Framework ist ein unverzichtbares Werkzeug für Organisationen, die ihre Ressourcenallokation optimieren und strategische Ausrichtung über verschiedene Projekte und Initiativen sicherstellen wollen. Hier sind Schlüsselszenarien, in denen sich dieses Framework als unschätzbar wertvoll erweist:

• Strategische Jahresplanung und aktive Budgetierung: Das Framework ist besonders vorteilhaft während strategischer Jahresplanungsphasen. Es fördert proaktive Budgetierung und Ressourcenallokation und ermöglicht Organisationen, die Entwicklung neuer Features zu priorisieren, anstatt in die Falle reaktiver Messung zu tappen. Durch aktives Planen und Budgetieren können Organisationen die Überraschung vermeiden, festzustellen, dass wenig Fortschritt bei der Entwicklung innovativer Features gemacht wurde.

• Sicherstellung der Team-Ausrichtung über das Jahr (Vierteljährliche Check-Ins): Sobald strategische Pläne stehen, hilft das Balanced Investment Framework sicherzustellen, dass Teams das ganze Jahr über auf die vereinbarten Projekte und Initiativen fokussiert bleiben. Diese Ausrichtung verhindert Ressourcendrift und stellt sicher, dass alle Bemühungen zu den übergeordneten Organisationszielen beitragen.

• Finanzberichterstattung und Unterscheidung zwischen Capex und Opex: Das Framework ist besonders nützlich für die Finanzberichterstattung, insbesondere bei der Unterscheidung zwischen Investitionsausgaben (Capex) und operativen Ausgaben (Opex). Capex, das neue Investitionen und Entwicklungen repräsentiert, fällt in ‘Bucket One’ (NEW), während Opex, das mit Keeping the Lights On (KTLO) verbunden ist, in ‘Bucket Two’ kategorisiert wird. Diese klare Unterscheidung unterstützt die Finanzplanung und -berichterstattung und gewährleistet Transparenz und strategische Allokation finanzieller Ressourcen.

Wie messen und einführen

Prozentsätze und Arbeitsbereiche sind alle schön, aber Sie müssen die Zahlen erst einmal bekommen. Und um die Zahlen zu bekommen, brauchen Sie die Unterstützung Ihrer Dev-Teams. Ihre Ingenieure (oder PMs) müssen den Arbeitstyp den Tickets zuweisen, Sie müssen dann den Zeitaufwand (grob) tracken und die Zahlen in Ihren vierteljährlichen Check-Ins zurückmelden.

Es gibt eine große Gefahr: Das System auszutricksen ist real. Kommunizieren Sie klar, dass es hier nicht um Zeiterfassung, Produktivität und Schuldzuweisungen geht, wenn Prozentsätze nicht wie erwartet ausfallen. Das ist entscheidend. Die vom Team gelieferten Zahlen dienen einzig dazu, die richtigen Fragen zu stellen und gemeinsam ein Werkzeug zu haben, um klar zu sehen, dass Dinge nicht stimmen, und gemeinsam zu diskutieren, wie der Kurs korrigiert werden kann.

Zusammenfassung

Bewusst KTLO vs. Elective-Themen zu planen, versetzt Sie in eine aktive Position. Es ist oft sehr aufschlussreich, wenn Teams beginnen, diese Bereiche zu messen. In vielen Fällen ist die KTLO-Arbeit weit mehr als erwartet, was hilft, die Frage zu beantworten: “Warum ist Engineering zu langsam?”

Das Framework ermöglicht es Ihnen auch, dies zu ändern, indem Sie mehr Zeit für “Elective Productivity Improvements” einplanen, was letztlich den KTLO-Prozentsatz senkt.

Referenzen

• Wie man Capex in Softwareunternehmen korrekt kategorisiert
• Warum aktivierbare Arbeit für die Geschäftsplanung wichtig ist
• Matts exzellenter Artikel über das Framework mit mehr Praxisinformationen und wie es bei Dropbox eingesetzt wurde.