Why your team needs to be able to call you an idiot. And live.

As a passenger, every time you take-off on commercial flight, your future safe arrival back on terra firma is entirely in the hands of the crew of the aircraft. And regardless of whether you are a nervous or confident flyer, when you are hurtling through the lower reaches of the Earth’s atmosphere at over 500 miles per hour, the last thing you need is to be the victim of office politics (or more specifically, plane politics).

Thankfully, the airline industry realised this (although it did take numerous fatal crashes for the penny to drop). To eliminate office politics in the air, they came up with a system called Crew Resource Management. In short, if a junior member of the cabin crew thinks a more senior member is being an idiot, then they have full authority to say so.

Rather than encouraging full-on slanging matches at 37,000 feet, CRM provides a framework for making this sort of intervention: summarising your concern, stating why this concern is a problem, and then suggesting what the solution might be. Finally, buy-in is sought. It is this last stage that is critical. The person being challenged (normally more senior), has to engage to the extent that either the solution is adopted or an alternative, better solution is arrived at. The outcome cannot be pulling rank, or scheduling a follow-up discussion after the fatal crash.

Thankfully, there are few situations where a team developing software is faced with a literal life or death situation. However, if something analogous to CRM is not practiced, then the outcome can still be pretty suboptimal.

I was recently faced with a situation where my failure to make my team aware of my willingness to be challenged resulted in an entirely avoidable error.

We had a last minute requirement to add some additional data to an endpoint, and rather than building out any underlying business logic, I reused a module I wrote years ago that enables user entered strings to be safely converted into different data structures. It would have been better to amend it to support JSON (for that is what the endpoint was spitting out), but there wasn't enough time and there was already an option to convert a string into a hash, which was close enough.

I quickly generated a sample response, and stuck it in a card. Problem was my sample response had an error in it:

{ "first_key": "first_value", 
" second_key": "second_value" }

The second key had a sneaky little leading whitespace. The android and iOS developers responsible for consuming this endpoint duly added the functionality to the apps and produced some test builds.

At that point, I got round to implementing the changes to the endpoint, and realised that my original sample data was wrong. I refactored the code and added some better tests (this story could easily have been one about how to write better tests, or even one about why you should scrap old modules that existed in a time before there was decent JSON support in certain databases).

I told the team that they’d need to fix the bug I’d introduced. Immediately they responded (as a choir), “oh yeah, we noticed that leading whitespace”.

I could have asked them why they did not tell me about it, but this would have pushed the blame onto them, and for the wrong reasons.

As a team we’d only been working together for a few weeks and in addition to being more than a decade older, I am, titularly at least, ‘their boss’. So they’d decided, based on years of cultural and educational conditioning, not to raise this with me for fear of either looking stupid or making me angry.

It was then I recounted the concept of CRM to them, and explained that now I’d told them how to go about challenging me successfully, they were fully expected to do so.

Except about music. I get first dibs on the playlist, and my taste in music goes unchallenged…

Like what you read? Give Craig McDonald a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.