The Leadership Challenge of Quiet Compliance

The Leadership Challenge of Quiet Compliance

Jimmy is an IT infrastructure engineer. Jimmy gets an odd request from a customer to do something against his better judgement. Jimmy pushes back. The customer pushes harder, and escalates. Jimmy’s manager gets involved. Jimmy gets told to do it this time, and perhaps next time we’ll take a stand. This one is too urgent, too high profile, or too political. It’s not worth the fight. Let it go. Jimmy gets another odd request from a different customer. Jimmy doesn’t push back. Jimmy quietly complies.

Raise your hand if you are Jimmy. Raise your hand if you are the customer. Raise your hand if you are Jimmy’s manager. Anyone left with their hand still down? I don’t think there are many.

This isn’t really a problem when it happens once. But what if it happens every day, all the time for years? The answer is predictable: This organization gets hacked, experiences a debilitating operational failure, or simply slowly dies. The slow death is inevitable. The major operational failure or security breach is just a whole lot more likely.

See, the problem isn’t the issue that was escalated and not supported, it’s the subsequent one that never gets escalated because people give up. They give up because of fear, intimidation, complacency, or perhaps just simple conditioning like a Pavlovian dog. These are issues that if they were fielded by a manager, director, or CIO, would definitely be addressed, but the issues never get there.

I observe this behavior a bit like an outsider. I was born and raised in Lancaster, PA. While that’s not exactly New York City, I have enough east coast blood running through my veins that I really don’t mind conflict and confrontation, at least not as much as the majority of my mid-western brethren.

I don’t bring this up to simply pick on Minnesota Nice. I believe that mid-western culture is more of an asset than a liability. I bring this up as a leadership challenge. Given this predicament, how do we as leaders address it?

Empowerment

One of the driving reasons why I wanted to be a technology leader in the first place is to give a voice to individual contributors. As leaders, we need to empower the experts that are closest to the customer edge to make sound technology and risk decisions on behalf of the organization. We simply cannot single-thread it through management.

Support

When push comes to shove, we need to back our people. Occasionally there will be a teachable moment where the judgment call was wrong. But keep it positive, and try not to let the experience demoralize the team member. Even if the decision was wrong, the team member is still valuable. Additionally, I encourage my team members to push back on me. If I ask them to do something unreasonable, I want to hear about it. I really do. I understand how strong positional authority can be, so I don’t want to cause harm with it.

Safety

The mantra goes, “if you see something, say something.” If you are on the metaphorical factory floor and you see something going horribly wrong, don’t hesitate to pull the safety rope. We need more work stoppage, earlier in the process, not less. We need more rollbacks to a good known state and less “fix on failure.” We need less leadership crying “failure is not an option.” Failure is always a very real possibility. Saying it isn’t just raises the stakes and makes people take unreasonable risks to accomplish a goal.

Time

New leaders can’t change an organizational culture overnight. Change takes time. This whole system is based on trust, which needs to be earned. We need to be consistently on-message and walking the talk. Over time, this will take root.

Empowerment, Support, Safety, and Time, that’s what comes to mind. I don’t feel like I’ve really successfully cracked this nut. If any of you have additional ideas for solving this challenge, please share your insights below. I’m really trying to build a culture where my team feels empowered to do what’s right with confidence. Thanks for reading!

Leave a Reply