Low integrity commitments and the illusion of certainty
I’ve seen a variant of this at every single place I’ve been at, without fail.
Execs ask when the next three or five or ten big things will be delivered. Somebody, often a PM, will say that they don't know yet. This doesn't cut it. The PM goes away and spends half a day with the team, pulling together some finger-in-the-air estimates on the back of assumption-addled back-of-a-napkin designs, culminating in some roadmap Tetris and a proclamation along the lines of "It'll be end of Q3".
I can count on two hands - maybe even one - the amount of times something significant has been delivered “ahead of schedule” when this pattern has played out. And probably fewer times when the thing that’s delivered late actually has the desired effect.
It does more harm than good. It takes time and energy away from much more fruitful pursuits. It demoralises. It erodes trust. It rarely has impact.
So what, if anything, can be done about it?
This article explores why we so often find ourselves in this cycle of features and estimates and dates and how we can navigate this, or avoid it altogether.
Why does this play out time and again?
We crave certainty
It’s the most natural thing in the world to have a plan. To know where we're going. To measure our progress. Plus, it's standard operating procedure for so many other elements of business - why wouldn't you try and lock in what your product teams are looking to build in the coming year?
We’re all people pleasers
Nobody wants to upset anybody. Nobody wants conflict. We’re hardwired to say yes. To tell people what they want to hear. Were practically incentivised to do it.
With any senior role in tech, even in the healthiest of environments, comes a boatload of peer pressure. Demand always outstrips supply. There is always an undercurrent of wanting to go faster. To do more. More equals better, right? And as organisations grow, so does internal demand.
We underestimate
To compound the issue, we set ourselves up to fail by - of all things - optimism.
Add in the complexity that is involved in getting something from idea through to value realisation - so all of the other stuff either side of actual software development, and it’s easy to see why you may not consider the breadth and depth of what’s involved.
We command, we control
Somewhat unsurprisingly, people in positions of authority tend to be authoritative, and often alongside that comes a desire for awareness and control.
A lot of the time it’ll come right from the top. If a founder or CEO exerts this level of scrutiny and governance, then it’s likely that the whole pyramid will be caught up in this.
And this effect can compound, particularly if the desired results aren’t achieved, which of course they often aren’t due to, amongst other things, the reasons called out above. Perceived underperformance equals increased scrutiny equals further analysis and measurement and inertia. John Cutler's "The Black Box" blog post is the best illustration I've seen of this phenomenon.
We follow precedence
“This is the way we’ve always done it.”
Even if nobody says this, some people will be thinking this. It’s another default behaviour as somebody new starts or a new work package begins: if we’ve always been expected to see how big something is and when we expect it to be delivered, then we’ll do it again automatically.
If something was perceived to go badly last time around, we’ll intensify our efforts the second time around. We’ll be more meticulous and spend more time planning and sizing and generating perceived certainty.
Breaking the cycle
Challenge
This is probably the hardest thing to attempt, especially if there is limited support from leadership. Especially if you’re new to a role.
As a head of engineering or a product manager who is regularly asked “when?”, it can be alienating to object. Career limiting even.
But, where people have been brave enough to challenge the status quo, I have seen this have a positive impact. To open doors. Which leads nicely on to the second point…
Pilot something different
If it’s always been this way, then the first steer would be to start small. Could one team do something differently? If only for one piece of work? Or for one quarter? Frame this as an experiment. What is success? Is it delivering “the thing”? Is it moving a needle? Is it team health?
Refer to vision / strategy
If you have a direction of travel for your org and / or your product, use it. Hang your efforts on it. If you’re working towards a goal, why are you measuring your progress in the number of things that you’re building? Or how quickly you get through the things? Or how accurately you predicted how long the thing would take?
Look backwards
Measure and highlight how much time and energy has been sunk into this process.
In shining a light on all that is involved in this lengthiest of dances, you’ll help people at the very least acknowledge that it’s a thing in its own right. A cottage industry of sorts.
Assessing the accuracy of your estimates may help. Better still: highlighting the inaccuracy. The irregularity. Review the impact of your estimates not being hit. Did it matter? Did it really matter? Is there anything you could have done to bring it in earlier?
Coping mechanisms
The reality is that you may not be able to shirk regular delivery commitments. As I wrote earlier, I’ve seen some form of this everywhere I’ve been. It is commonplace. Getting away from is the exception to the rule in my experiences. So, what can help make this bearable?
Frame the problem better
Be sure to describe the problem that you’re looking to solve. Yes, everybody gravitates to the name of a feature, but going the extra mile to remind people of the problem: the evidence that led to it being tackled, how we’ll know we’ve solved it.
In doing so, it at least takes the focus off the solution and helps to draw a line in the sand; a point at which you can say “done” and move on.
Slice
Good teams will do this anyway, but by ensuring that the work is in small chunks, it makes any sizing conversations so much more easier. It reduces the margin of error, as well as total elapsed time should something “overrun”.
Minimise impact
People generally don’t like being asked to estimate. They’re reluctant to stick their neck out. Even if there are no negative effects in the event it goes beyond (which there usually are), people feel bad. People feel compelled to explain. To apologise. To blame. Being mindful of all these things is a great start. Consciously trying to mitigate them is better. Having a standard approach for your team, keeping it lightweight, and regular team temperature checks can all help.
And avoid talking in absolutes. It won’t always work, but be clear that these are indicative. Try not to emphasise drop dead dates. Be broader.
Inject rigour
Controversial, and can do harm than good, but you could choose to double down on this. If there is no end in sight, then you can swing the other way and start to take this a bit more seriously. To give it more time and consideration and science.
There are many approaches you can take here. I heard an interesting talk about probabilistic forecasting paying dividends at Co-op in Manchester recently. And ringing endorsements of Monte Carlo simulations, although I can't vouch for either of these techniques personally.
Just bringing more structure and discipline to the process can help - if nothing else it shows that this is being taken seriously.
This would be a last resort for me though. And if you do opt for this approach, I’d strongly advocate ensuring this does not detract from the day to day workings of the team - being more meticulous in how you measure, analyse, and forecast should not impact this in any way.
And be wary of comparing teams based on measures like this, or the focus drifting from user and business outcomes to “team performance”.
Delivery leads
Experts in delivery management will be able to help you with all of the above—trying to avoid low integrity commitments altogether, but particularly if they aren’t going anywhere soon and you need to shore things up.
They bring a lot more to the table than this as well. See my "Why delivery management doesn't happen by accident" article for more info on this front.
In summary
If forming a new team, avoid committing to timelines. Don't expend effort on sizing.
If you’re in an established team that doesn’t make low integrity commitments, don't change unless you have to.
If you’re in a team that does make low integrity commitments, then see if you can move away from it.
If you can’t move away from it, then do what you can to ensure that it doesn’t have a detrimental effect on your team.
And don't let it get you down! The reality is that any improvements on this front take time. You cannot change everything at once, nor should you try, and this is okay.
