On Deadlines, Estimation, and Orchestration
Let’s talk for a moment about deadlines.
Kyle Arete wrote a post on LinkedIn that included this:
Business: We have to get this release out on May 2 based on 72 other commitments the rest of the business made.
One of the things that frustrates me the most in technology is that for many technologists, the understood link between the value of what they deliver and the value they personally receive for delivering is somewhere between vague and ignored.
This isn’t the technologists’ fault (in virtually 100% of the cases). This is the fault of management, who has allowed a system to evolve where that link isn’t clear.
But for many of the best technologists, they got into tech because they like making neat and useful things. So, absent a link between their ‘thing’ and value-in-their-pocket, they are rationally focused on making neat and useful things.
For more and more companies, that’s becoming important. The technology enables or unlocks the value.
But for virtually no companies is it enough.
We have a very cool car – a 2016 Volvo V60 Polestar. We love it to death. But the telematics in it were obsolete in 2016, and today are frustrating. So I did what anyone would do – I went on AliExpress and bought a new head unit.
Which is currently installed in my car. And which can’t do a damn thing, because it came with no meaningful instructions or documentation. So it doesn’t work. And so I’m going to have it pulled out and toss it.
I should have known better.
A while ago, I wrote a defense of estimates on LinkedIn. In it, I wrote:
Look, the mistake here is simple. He sees delivered software as the product. And in a world that used to exist – one where you bought Norton Utilities on a commercial floppy disk with a label printed on a line printer at the local Radio Shack (I did once, yeah I'm old…) – yes, delivered software was the product, and making the delivery of software in and of itself more efficient by eliminating waste was an awesome idea.
But as anyone who has owned a MV Agusta motorcycle can tell you, the ‘product’ isn’t just the motorcycle – in reality.
Once the motorcycle is built, now it needs to be shipped to a dealer, who has to sell it to me – meaning there has to be a logistics chain that operates efficiently, and dealers who will sell it and who are ready to receive it, and have salespeople who know enough about it to sell it to me. There has to be collateral in the form of marketing materials. There has to be collateral in the form of owner’s manuals that accurately reflect how the motorcycle as it was built works. There has to be collateral in the form of service manuals – that accurately reflect how the motorcycle was built. There has to be a supply chain of parts and tools as well as trained mechanics to use them.
Only when all that exists is there really a product.
That complete package – motorcycle – shipping – dealer network – trained salespeople – trained mechanics – collateral – parts – is the true product that a consumer buys.
So if we optimized the hell out of building the motorcycle, and in doing so, crashed all the other aspects of the product – the owner’s manual didn’t reflect how it worked; the service manual didn’t reflect how it was built; the dealer didn’t have tools or parts – what are we doing?
We’re optimizing part of the system at the expense of the whole.
Optimizing the writing of software by eliminating waste – like estimates – that permits the orchestration of all the other things that need to go with the software to deliver value isn’t smart. It isn’t lean.
Want to find other ways to handle the orchestration? More efficient ways? Absodamnlutely. Go for it. I'll bet there are #NoEstimates folks who have approached the problem, and I'd love to see their approaches.
But stop thinking that your little piece of the puzzle is the only one that matters. Think about the system as a whole, and optimize that ruthlessly.
Yup, that’s our exact problem. And as technology folks get seats at the business table, I anticipate two things happening – they will contribute new opportunities that technology can unlock; and they will increasingly understand that technology alone isn’t enough.