En CEO siger "kan vi sende det i marts?" CTO'en siger ja. I marts er det ikke sendt. Ingen af dem løj.
CEO'en hørte: kan kunderne bruge det i marts? CTO'en svarede: bliver engineering-arbejdet færdigt i marts? Mellem de to sætninger sidder QA, app-gennemgang, en migration, et support-hold som skal have training, og en juridisk godkendelse som ingen ejer. Alle var ærlinge. Datoen var stadig forkert.
Jeg har været på begge sider af det her bord — jeg kørte en startup før jeg ledede engineering-hold — og det er, mere end noget teknisk problem, det som stilfærdigt ødelægger roadmaps.
De fire fraser som gør mest skade
- "Næsten færdig." Til en ingeniør: den hårde del er løst. Til en executive: arbejdet er næsten færdigt. De resterende 10% af det hårde arbejde er rutinemæssigt 50% af kalenderen.
- "Bare en lille ændring." Lille i interfacet er ikke lille i systemet. At ændre et valuta-felt er en eftermiddag eller et helt kvartal, og intet ved anmodningen afslører hvilken.
- "Det er teknisk gæld." Høres som: ingeniørerne vil gøre orden. Betyder egentlig: en beslutning taget under tidspres opkræver nu renter, og betalingen kommer når den skal eller ej.
- "Vi skal refactorere." Næsten altid et symptom, ikke en anmodning. Spørg hvad det vil gøre muligt. Hvis svaret ikke er et forretnings-resultat, er det en præference. Hvis det er, er det et roadmap-punkt du har prisfastsat forkert.
Hvorfor det fortsætter
Fordi begge mennesker er rationelle. CTO'en giver et teknisk estimat fordi det er den del de kontrollerer og kan forsvare. CEO'en spørger om en dato fordi en dato er hvad bestyrelsen, kunden og kampagnen alle behøver.
Ingen af dem er forkert. Men ingen i rummet ejer pladsen mellem de to — og det er hvor hver deadline dør.
Fire fikser som virkelig virker
Spørg om datoen noget er foran en bruger
Ikke "hvornår er det færdigt." Hvornår kan en rigtig kunde gøre tingene? Dette eneste nyt perspektiv afdækker alle skjulte afhængigheder — gennemgang, migration, training, juridisk — fordi de alle sidder mellem code-complete og kunde-brugbar.
Få CTO'en til at sige hvad de antager
Hvert estimat hviler på antagelser: at et API opfører sig, at tredjeparten svarer, at ingen bliver trukket på noget hurtigt. Skrevet ned bliver de til risici du kan håndtere. Uskrivet bliver de til undskyldninger i april.
Oversæt teknisk arbejde til en forretnings-sætning
Ikke "vi skal migrere databasen." I stedet: "hvis vi ikke migrerer før Q3, vil det at onboarde en kunde over 10.000 pladser tage tre uger i stedet for en dag." Nu kan CEO'en prioritere det imod alt andet, som er deres egentlige job.
Separer de tre spørgsmål du virkelig stiller
- Kan vi bygge det her? — næsten altid ja.
- Hvad ville vi holde op med at gøre for at bygge det? — spørgsmålet folk springer over, og det eneste som afslører rigtig omkostning.
- Hvad sker der hvis vi tager fejl om datoen? — bestemmer om du behøver et fast vindue eller et fleksibelt.
Tegnet at du har det her problem
Estimater som altid er cirka rigtige på task-niveau og altid forkerte på release-niveau. Det mønster betyder dine ingeniører estimerer godt og noget mellem engineering og kunden er uregnet.
Det er næsten aldrig et tilfælde af at folk arbejder for langsomt. Det er et tilfælde af at to folk beskriver forskellige mållinjer og antager de er den samme.
Hvis du ikke har nogen som oversætter
Nogle virksomheder har den person naturligt — en teknisk founder som har båret et P&L, en VP som kom op gennem engineering og blev tæt på forretningen. De fleste gør det ikke, og ansætter omkring gabet uden at navngive det.
Det er normalt hvor jeg kommer ind. Ikke for at skrive kode som et godt hold kunne skrive, men for at sidde i pladsen mellem de to svar og sikre at de handler om den samme målinje. Beslutningen om hvorvidt man skal ansætte det permanent er sit eget spørgsmål.