Ein CEO sagt: "Können wir das bis März ausliefern?" Der CTO sagt ja. Im März ist es nicht ausgeliefert. Keiner von beiden hat gelogen.
Der CEO hörte: Können Kunden das im März verwenden? Der CTO antwortete: Ist die Engineering-Arbeit im März fertig? Dazwischen sitzen QA, Store Review, eine Migration, ein Support-Team, das Training braucht, und eine Freigabe durch Legal, die keiner besitzt. Alle waren ehrlich. Das Datum war trotzdem falsch.
Ich habe auf beiden Seiten dieses Tisches gesessen — ich habe ein Startup geleitet, bevor ich Engineering-Teams geführt habe — und das ist mehr als jedes technische Problem das, was Roadmaps leise zerstört.
Die vier Sätze, die den meisten Schaden anrichten
- "Eigentlich schon fast fertig." Für einen Engineer: Der schwierige Teil ist gelöst. Für eine Führungskraft: Die Arbeit ist fast abgeschlossen. Die restlichen 10 % des schwierigen Teils sind regelmäßig 50 % des Kalenders.
- "Nur eine kleine Änderung." Klein in der Oberfläche ist nicht klein im System. Ein Währungsfeld zu ändern ist ein Nachmittag oder ein Quartal, und an der Anfrage ist nichts zu sehen, das beiden unterschiedlich ist.
- "Das sind technische Schulden." Gehört als: Die Engineer wollen Ordnung schaffen. Bedeutet eigentlich: Eine unter Zeitdruck getroffene Entscheidung wird jetzt teuer, und die Rechnung ist fällig, ob geplant oder nicht.
- "Wir müssen das Refactoring machen." Fast immer ein Symptom, nicht eine Anfrage. Frage, was es möglich macht. Wenn die Antwort kein Business-Ergebnis ist, ist es eine Vorliebe. Wenn es ist, ist es ein Roadmap-Punkt, den Sie zu niedrig kalkuliert haben.
Warum es so bleibt
Weil beide Menschen rational handeln. Der CTO gibt eine technische Schätzung, weil das der Teil ist, den er kontrolliert und verteidigen kann. Der CEO fragt nach einem Datum, weil ein Datum das ist, was der Board, der Kunde und die Kampagne brauchen.
Keiner von beiden hat unrecht. Aber niemand im Zimmer besitzt den Raum dazwischen — und in diesem Raum sterben alle Deadlines.
Vier Fixes, die tatsächlich funktionieren
Fragen Sie nach dem Datum, an dem es vor einem Benutzer liegt
Nicht "wann ist es fertig." Wann kann ein echter Kunde das Ding tatsächlich verwenden? Dieser einzelne Perspektivwechsel bringt jede versteckte Abhängigkeit an den Tag — Review, Migration, Training, Legal — weil sie alle zwischen Code-Complete und Customer-Usable sitzen.
Lassen Sie den CTO seine Annahmen aussprechen
Jede Schätzung beruht auf Annahmen: dass eine API sich verhält, dass ein Dritter antwortet, dass niemand auf etwas Dringendes gezogen wird. Aufgeschrieben, werden sie zu Risiken, die Sie verwalten können. Unaufgeschrieben, werden sie zu Ausreden im April.
Übersetzen Sie technische Arbeit in einen Business-Satz
Nicht "wir müssen die Datenbank migrieren." Stattdessen: "Wenn wir bis Q3 nicht migrieren, dauert das Onboarding eines Kunden mit über 10.000 Plätzen drei Wochen statt eines Tages." Jetzt kann der CEO es gegen alles andere priorisieren, was sein eigentlicher Job ist.
Trennen Sie die drei Fragen, die Sie wirklich stellen
- Können wir das bauen? — fast immer ja.
- Was würden wir aufgeben, um es zu bauen? — die Frage, die die Leute überspringen, und die einzige, die echte Kosten zeigt.
- Was passiert, wenn wir beim Datum falschliegen? — entscheidet, ob Sie ein fixes Fenster oder ein flexibles brauchst.
Das Zeichen, dass Sie dieses Problem haben
Schätzungen, die auf Task-Ebene immer ungefähr korrekt sind und auf Release-Ebene immer falsch. Dieses Muster bedeutet, dass Ihre Engineer gut schätzen und etwas zwischen Engineering und Kunde nicht gezählt ist.
Es ist fast nie eine Frage von Leuten, die zu langsam arbeiten. Es ist eine Frage von zwei Menschen, die verschiedene Ziellinien beschreiben und annehmen, dass sie gleich sind.
Wenn Sie niemanden haben, der übersetzt
Manche Unternehmen haben diese Person natürlich — ein technischer Gründer, der eine P&L getragen hat, eine VP, die aus Engineering kam und der Business nahgeblieben ist. Die meisten nicht und stellen um die Lücke herum ein, ohne sie zu benennen.
Da komme ich gewöhnlich rein. Nicht, um Code zu schreiben, den ein gutes Team schreiben könnte, sondern um in dem Raum zwischen den zwei Antworten zu sitzen und sicherzustellen, dass sie von der gleichen Ziellinie sprechen. Die Entscheidung, ob man dafür permanent einstellt, ist ihre eigene Frage.