Skip to content

The release valve

Everybody likes to complain about work. Well, maybe not likes, but feels compelled to do so from time to time.

Folks complain to one another; they reinforce each other, and the complaints can balloon and become a revolution in the political world, or a mass exodus in the corporate world.

Part of your job as a manager of people is to be a release valve for those complaints.

Software engineers, by the nature of the job, see more problems and tend to complain about work more than most.

Digging out those complaints as a manager allows you to do three things:

1. Release the pressure: Assuming you handle the complaint appropriately – as in: don’t get defensive about it, don’t immediately try to solve, but listen and acknowledge – you have a chance to explain the context of the complaint and realign expectations. Or at least to let them know you’ve heard them and will keep it in mind.
2. Identify hot spots: If you’re doing regular 1:1s, you might hear the same or similar complaints across multiple team members. That can help you identify patterns and process or personnel changes that need to happen.
3. Actually fix their problem: A lot of complaints about work are not valid, and the most you can do is listen, acknowledge and reframe. Sometimes, though, you’ll uncover actual problems that you weren’t aware of – or didn’t have the right priority on – that you can go fix right away.

How to get folks to complain about work to you

Any managerial relationship involves power dynamics. After all, you’re likely the person in charge of their salary, their day-to-day job environment, and their promotion schedule – sometimes even who they work with and on what.

You have significantly more power in the relationship and that’s one of the first things you need to diffuse to build rapport and get folks to open up.

That dynamic doesn’t go away – you just need it to fade into the background as best you can.

In this instance, it starts with doing some complaining of your own.

Keep it about process, code, culture or environment. Do not mention anything personal or complain about any individual. But you often need to be the first to ante up in a new relationship.

Once the spigot opens, you might get a small thing, almost like a test. Handle it with care, be curious, dig into it, and then talk through the resolution for what they bring to you – even if there’s not a resolution, you should fill in context and reasons why that might be.

And, critically, follow up in your next 1:1 with an update on what you’ve done to help resolve it, or simply to check if they have more thoughts about the issue they brought to you.

If all else fails, you can also directly ask.

Some of my favorite ways to do that:

The business importance of all of this

I mentioned earlier that software engineers like to complain about their jobs and work. Some of that is the nature of the job – you’re constantly fixing problems and identifying other problems. Eventually, the eye wanders outside of code and into the working environment.

Engineers will complain.

If they aren’t complaining to you or other managers, they’re complaining to each other in Slack DMs, over beers, over lunch, in text messages. These environments don’t diffuse the complaints or resolve them; they amplify them and darken their context (see previous about imagined context).

If you let this go unchecked and unmitigated, it will eat away at the core of your engineering culture. A culture that is “good vibes only” often masks an underbelly of dissatisfaction.

That underbelly manifests itself when engineers start complaining to colleagues outside of work, and then to recruiters – and then they leave for greener grass.

And start the cycle all over again.

Your job as a manager is to stop the cycle for as long as you can.

Leave a Reply

Your email address will not be published. Required fields are marked *