Note: this post was scheduled to go out long after the issue it talks about faded into ancient history. The issue got resolved, but the learnings are worth considering.
On the whole, I’d like to think that if someone asked me for an outcome, I’d:
- Work with them to ensure what I was doing met that outcome
- Be flexible in putting it right if my first attempt didn’t get them there
- Take a holistic approach
- Consider a half-working thing to be technical debt that needs urgently prioritising
However, if someone specifically asks me for a half of the solution and I unwittingly make only half their solution, it might be reasonable to put the blame back on the requester for not asking for the right thing. It might be… but only in a world where it’s quick to put these things right.
I’ll be honest with you. I cannot agree with the idea that “You asked for the wrong thing” equates to a good working practice within an organisation. Similarly, I cannot accept that “because what you asked for doesn’t work, we’re going to reprioritise you” is the right solution.
A Timeline
We started testing some piece of network connectivity in lower environments in mid 2023.
We decided to go live to production, and switch on the production version of this, in mid-December 2023. The connection failed.
They eventually scheduled a production deployment for the “right connection” two months later in February 2023.
At the time of writing this, that deploy either didn’t happen or didn’t work.
Depending on when you start the clock on getting this connection ready to go for production, this is either two months or 9 months of waiting for the right people to get the right bits and pieces into shape.
Victim Mentality
Ok. Stuff happens. Let’s get over it and move on. Priorities change, and if what we were doing was incredibly urgent, maybe we’d have had a faster response.
There’s no need to go round playing the victim on this.
But. There’s also no value in victim blaming.
Because as a team, non-specialist in making this change, we did the right sort of thing and asked specialists. And we took the advice around what to ask for, and we asked for it.
The ask was taken at face value and the wrong thing was implemented.
This sort of thing happens, but when it happens, we should respond promptly and learn from the mistake. We should quickly go back to the full requirement, establish all the component parts required to achieve that requirement, and get on and do it.
What we shouldn’t do is agree that the request was wrong, and then reboot the entire process, especially if it comes with delays measurable in months. We shouldn’t point the finger at the wording on the request, but instead at the process that doesn’t solve problems.
If the cost of failure is low, then we can improvise, experiment, and generally be loose.
If the cost of failure is high and slow, then people need to focus more on outcomes, rather than actions. If the outcome isn’t met, then there should be commitment to keep going until it is.
TL;DR
Quit the process and politics and get the damned thing working. It’s been months.
The Coding Craftsman 