En CEO säger "kan vi skicka det här i mars?" CTO:n säger ja. I mars är det inte skickat. Ingen av dem ljög.
CEO:n hörde: kommer kunderna att kunna använda det här i mars? CTO:n svarade: kommer ingenjörsarbetet att vara klart i mars? Mellan dessa två meningar sitter QA, store-review, en migrering, ett supportteam som behöver träning, och ett juridisk godkännande ingen äger. Alla var ärliga. Datumet var ändå fel.
Jag har varit på båda sidor av det här bordet — jag körde en startup innan jag ledde ingenjörsteam — och det är, mer än något tekniskt problem, det som tyst förstör roadmaps.
De fyra fraser som gör mest skada
- "Det är nästan klart." Till en ingenjör: svåra biten är löst. Till en ledare: arbetet är nästan färdigt. De återstående 10% av den svåra biten är rutinmässigt 50% av kalendern.
- "Det är bara en liten ändring." Litet i gränssnittet är inte litet i systemet. En valutafältändring är en eftermiddag eller ett kvartal, och ingenting i begäran avslöjar vilket.
- "Det är teknisk skuld." Hörd som: ingenjörerna vill städa upp. Faktiskt betyder: ett beslut gjort under tidstryck betalar nu ränta, och betalningen kommer när den än inte är planerad.
- "Vi måste refaktorera." Nästan alltid ett symptom, inte en begäran. Fråga vad det kommer att möjliggöra. Om svaret inte är ett affärsresultat är det en preferens. Om det är det är det ett roadmap-objekt du har prissatt fel.
Varför det fortsätter
För att båda människor är rationella. CTO:n ger en teknisk uppskattning för det är delen de kontrollerar och kan försvara. CEO:n frågar efter ett datum för ett datum är det styrelsen, kunden och kampanjen alla behöver.
Ingen har fel. Men ingen i rummet äger utrymmet mellan de två — och det utrymmet är där varje deadline dör.
Fyra fixar som faktiskt fungerar
Fråga efter datumet något är framför en användare
Inte "när är det klart." När kan en verklig kund göra saken? Denna enda omformulering exponerar varje dolt beroende — review, migrering, träning, juridik — för de sitter alla mellan kod-färdig och kund-användbar.
Få CTO:n att säga vad de antar
Varje uppskattning vilar på antaganden: att ett API beter sig, att en tredje part svarar, att ingen blir dragen in på något brådskande. Skrivna ned, blir de risker du kan hantera. Onskrivna, blir de ursäkter i april.
Översätt tekniskt arbete till en affärsmening
Inte "vi måste migrera databasen." Istället: "om vi inte migrerar senast Q3, kommer det ta tre veckor istället för en dag att lägga till en kund över 10 000 platser." Nu kan CEO:n prioritera det mot allt annat, vilket är deras faktiska jobb.
Separera de tre frågorna du faktiskt ställer
- Kan vi bygga det här? — nästan alltid ja.
- Vad skulle vi sluta göra för att bygga det? — frågan folk hoppar över, och den enda som avslöjar verklig kostnad.
- Vad händer om vi har fel om datumet? — bestämmer om du behöver ett fast fönster eller ett flexibelt.
Tecknet att du har det här problemet
Uppskattningar som alltid är ungefär rätt på task-nivå och alltid fel på release-nivå. Det mönstret betyder att dina ingenjörer uppskatta bra och något mellan ingenjörsarbete och kund är oräknat.
Det är nästan aldrig ett fall av människor som arbetar för långsamt. Det är ett fall av två människor som beskriver olika mållinjer och antar de är samma.
Om du inte har någon som gör översättningen
Vissa företag har denna person naturligt — en teknisk founder som burit en P&L, en VP som kom upp genom ingenjörsarbete och höll sig nära affären. De flesta gör det inte, och anställer runt gapet utan att namnge det.
Det är vanligtvis där jag kommer in. Inte för att skriva kod som ett bra team kunde skriva, utan för att sitta i utrymmet mellan de två svaren och se till att de är om samma målinje. Beslutet om att anställa för det permanent är sin egen fråga.