Een CEO zegt "kunnen we dit in maart verzenden?" De CTO zegt ja. In maart is het niet verzonden. Geen van hen loog.
De CEO hoorde: kunnen klanten dit in maart gebruiken? De CTO antwoordde: is het engineeringwerk in maart klaar? Tussen die twee zinnen zit QA, store review, een migratie, een supportteam dat training nodig heeft, en een juridische goedkeuring die niemand bezit. Iedereen was eerlijk. De datum was nog steeds fout.
Ik heb aan beide zijden van deze tafel gezeten — ik leidde een startup voordat ik engineering-teams leidde — en het is, meer dan enig technisch probleem, hetgeen dat voorzichtig roadmaps ondermijnt.
De vier uitdrukkingen die het meeste schade aanrichten
- Bijna klaar. Voor een engineer: het moeilijke onderdeel is opgelost. Voor een executive: het werk is bijna af. De resterende 10% van het moeilijke onderdeel is routinematig 50% van de kalender.
- Slechts een kleine wijziging. Klein in de interface is niet klein in het systeem. Een bedragveld wijzigen is één middag of één kwartaal, en niets aan het verzoek maakt duidelijk welke.
- Het is technische schuld. Gehoord als: de engineers willen opruimen. Werkelijk betekent: een besluit gemaakt onder druk eist nu rente, en betaling is verschuldigd, gepland of niet.
- We moeten refactoren. Bijna altijd een symptoom, niet een verzoek. Vraag wat het mogelijk maakt. Als het antwoord geen business-uitkomst is, het's een voorkeur. Als het wel is, het's een roadmap-item dat je onderschat hebt.
Waarom het voortduurt
Omdat beide mensen rationeel zijn. De CTO geeft een technische schatting omdat dat het onderdeel is dat ze controleren en kunnen verdedigen. De CEO vraagt om een datum omdat een datum is wat de raad, de klant en de campagne allemaal nodig hebben.
Geen van beiden is fout. Maar niemand in de kamer bezit het gat ertussen — en dat gat is waar elke deadline sterft.
Vier fixes die werkelijk werken
Vraag naar de datum waarop gebruikers het kunnen gebruiken
Niet "wanneer is het klaar." Wanneer kunnen echte klanten het ding doen? Deze enkele herformulering brengt elke verborgen afhankelijkheid aan het licht — review, migratie, training, juridisch — omdat ze allemaal tussen code-klaar en bruikbaarheid voor klanten zitten.
Laat de CTO aangeven wat ze aannemen
Elke schatting rust op aannames: dat een API zich gedraagt, dat een derde partij reageert, dat niemand ergens urgent op wordt betrokken. Opgeschreven, worden ze risico's die je kunt beheersen. Ongeschreven, worden ze excuses in april.
Zet technisch werk om in bedrijfstaal
Niet "we moeten de database migreren." In plaats daarvan: "als we niet migreren tegen Q3, duurt het onboarden van een klant met meer dan 10.000 zetels drie weken in plaats van één dag." Nu kan de CEO het prioriteren tegen alles anders, wat hun eigenlijke werk is.
Scheid de drie vragen die je werkelijk stelt
- Kunnen we dit bouwen? — bijna altijd ja.
- Wat zouden we stoppen met doen om het te bouwen? — de vraag die mensen overslaan, en de enige die werkelijke kosten onthult.
- Wat gebeurt er als we fout zijn over de datum? — bepaalt of je een vast venster of een flexibel nodig hebt.
Het teken dat je dit probleem hebt
Schattingen die altijd ruwweg juist zijn op taak-niveau en altijd fout op release-niveau. Dat patroon betekent dat jouw engineers goed schatten en iets ertussen engineering en klant is niet meegerekend.
Het is bijna nooit een geval van mensen die te langzaam werken. Het is een geval van twee mensen die verschillende eindlijnen beschrijven en aannemen dat ze gelijk zijn.
Als je iemand ontbeert die vertaalt
Sommige bedrijven hebben deze persoon van nature — een technische oprichter die verantwoordelijk was voor resultaten, een VP die door engineering is opgegroeid en dicht bij het bedrijf is gebleven. De meeste niet, en huren rond de lacune zonder het te benoemen.
Dat's meestal waar ik binnekom. Niet om code te schrijven die een goed team zou kunnen schrijven, maar om in de ruimte ertussen te zitten en ervoor te zorgen dat ze over dezelfde eindlijn gaan. De beslissing over of je daarvoor permanent aanneemt, is eigen vraag.