All roads lead to the inevitable
This is a story about trust
We’ve all been in that meeting. The one where you have to stand your ground, explaining to a room full of execs and managers and leaders why your deliveries are “late” or “slipping” while trying to escape relatively unscathed so you can “fix” the “problem” and bring the project back on a “plan to green”.
I’ve been there, whether inheriting old backlogs with pre-set timescales, or starting from scratch but still ending up over the original estimates that were put together during the early stages of a project where you have no concept of the future challenges that you’ll encounter.
For the former, it’s difficult to tell the people who made the original estimates that they were wrong and yours are better (all-the-while knowing that you’ll no-doubt be just as wrong).
While for the latter, it’s like trying to make out fine-line technical detail while peering through a kaleidoscope but all you can see are shapes that may resemble this or that, and have about as much chance of being an elephant as they do a fighter jet.
This is a story about trust, and we’ll get to that, but it’s also as much a story of the oppressive hegemonic taxonomy prevalent in our professional workplaces used to demean our fellow colleagues and heroes without capes, who battle the unknown every day to bring about order from chaos and deliver amazing things to our customers, which inevitably brings success to our teams, glory to our managers and return to our investors.
But that’s just the end result, right? Getting there is the hard part.
And no matter how many times a manager or exec will say they “know it’s difficult to give a delivery date this early on” and “I won’t hold you to a firm date, I just need an idea”, inevitably they do press you for a date and they do hold you to it.
I’m not saying they’re doing this maliciously or spitefully to rub it in your face when you miss a deadline. It’s just as difficult for the execs to manage and report the unknown when those above them want guarantees and certainties — shit rolls downhill, as the old adage goes.
And while that’s unavoidable, the words and phrases we use to describe our projects, and the processes we adhere to and use to force our teams to hit potentially always unattainable dates are problematic.
These words denote failure. If you “miss” a date or the timeline is “slipping” it’s inferring your failure to meet those dates, like they were set in stone and a given that delivery was guaranteed.
But in the realms of complex software development, there are seldom guarantees, and regardless of how set in stone a deadline might be, our estimates can still be wrong.
And often following these phrases comes many leaders’ exclamations that they are “disappointed” in the “slippage”. We’ve all been in that meeting.
The one where one of the attendees has nothing to provide but their Oscar-worthy performance, trying, fervently, to convince you that your failure to deliver to this Goldilocks date is the end of things as we know them.
But it’s not the end.
After this date, there’ll be another date.
After this deliverable, there’ll be another. And another project. And another programme.
So, what are we really trying to achieve with these dates? That’s for another story.
For now, this is a culture thing. If we use language of blame that presupposes our ineptitude, we foster blame culture. This is where it turns into a story about trust.
The words you use are powerful, because often you’re saying two or three things when you’re only saying one out loud.
Talking of slippage and missed dates not only infers “failure” and the negative connotations associated with them, but it also suggests that your team did something wrong or didn’t do their all to meet those targets.
When a leader exclaims they’re “disappointed”, they’re saying that you and your team aren’t doing your job well or correct.
They’re not siding with you, in the trenches, understanding and commiserating in the uncertainties of complex software delivery. No, they’re 20 miles away from the front lines, drinking tea while moving pawns across a map of what the project should look like.
At the end of the day, we can do everything in our power to uncover the fog of war and control and estimate what we learn, but as we are not able to learn everything and control for it in complex systems, at the end of the day we must remain respectful of the inevitability of the unknown.
We can find out as much as we possibly can, and we can control for it as best we can — more developers, more designers, more analysts, more architects, more planning.
We can story map, estimate features before refinement and we can give a landing zone based on pace.
But at the end of the day, the most important thing we can do is trust our teams and support them when things do inevitably pop up.
That easy feature uncovered a mountain of complexity debt that’s been ignored for years? Acknowledge that’s not anyone’s “fault", it’s the outcome of many dozens of decisions over years and inevitably they’ve come to haunt us.
An extra mandatory feature puts us past the delivery date? Fine, let’s re-evaluate our plan and get going or have the conviction to say no — but don’t expect two things for the price of one.
So, what?
The thing is, if you truly trust and believe in the abilities and commitment of your team, then the actual delivery date of the project is inevitable but unknown, and you need to support the team throughout and adjust and be flexible as required.
If you don’t truly trust and believe in the abilities and commitment of your team? Then you’re fucked, but that’s on you.
The project end date is still inevitable, but it’ll be drowning in blame and fear and oppression; instead of support, collaboration and collective effort, moving as one.
This is your choice to make.
