Photo by Katrina Wright on Unsplash
I found myself saying much the same thing to several colleagues a while back, so here it is.
Don't ask for confirmation you don't need
Plenty of project tasks genuinely do call for someone involved to confirm something before you take the next step. But asking the people around you to confirm when there is no need for it is a bad habit. It wastes time.
Here is what goes through the mind of the person being asked:
- "I spelled the requirement out clearly the other day — what is it you want me to confirm?"
- "Are you really a ○○ professional?"
- "If my own check misses something and a problem turns up later, I'm the one who gets blamed…"
How readily people ask for confirmation says a fair amount about national character, and Japanese people tend on the whole to be over-cautious. You see plenty of cases of tapping the stone bridge so long that the moment passes and the bridge never does get crossed. The thinking overlaps a little with our post on not writing the customary Japanese email opener, but when you are committed to producing results, asking for confirmation more than you need to gets in the way.
What we should be doing is pinning down the points that need checking beforehand, as far as we can — against how things ought to be, or by talking to the people around us — then checking those points ourselves at delivery, and following up ourselves when something goes wrong (and being ready to do that). Where the checkpoints cannot all be known in advance — and of course that happens often — and taking the work in the wrong direction could cost the project more than a little, then by all means ask. Dig past the surface request to the underlying need or problem and its solution, hold a concrete picture of it in your own head, and keep checking the result against that picture. Staying conscious of this is what matters.
In a DevOps and agile context
I said Japanese people tend on the whole to be over-cautious. Most people recognise this, I think: the structures Japan built during its high-growth years have long since fatigued, and still they barely change. Where things are rigid and change is expensive, situations keep arising in which you have little choice but to ask someone to confirm. Rigidity keeps information from being shared, and the high cost of change makes avoiding mistakes the dominant instinct. This may be too simple a picture, but my impression is that thirty years went by with everyone lobbing "please confirm" back and forth, and no real renewal to show for it.
Not that this is the only reason, but at Quartile we adopt approaches and mechanisms that spare us the cost of "please confirm" wherever we can. The ideas behind DevOps, the agile approach and CI/CD all rest on the same premise: change is going to happen, so bring down the cost of it. Controlling the scope of a change properly, automating tests and otherwise stripping out the unknowns lets you cut the chance of trouble systematically, up to a point.
Under those conditions, things that would be checkpoints elsewhere often stop being checkpoints at all. And even where uncertainty remains, the cost of confirming — communication cost included — often turns out larger than the trouble the confirmation would have prevented, because the risk has itself been narrowed down. In serving customers it works the same way: a customer who is resilient to change and values speed will often prefer to apply the change first and watch how it goes.
That is why a new joiner who brings the instincts of a rigid, expensive-to-change setting straight in with them ends up feeling a gap.
Are you saying "please confirm" too often?