Technical Leader Worries: Team Members Are Whining

Table of Contents

Understanding Team Complaints

It’s very annoying when you hear whining from your team. They complain about boring work, stupid company security policy, wrong management decisions, customers not knowing what they want and changing their minds, and project managers crowding them. Doesn’t it sound familiar?

I have great news for you: it’s wonderful they are whining. Try to hear the hidden message: “there is something important for me not happening.” It would be much worse if they had that frustration and didn’t say anything. How would you know then? It would be much more difficult to learn what is really going on.

Don’t treat these complaints as attacks, and don’t take them personally because it’s not about you. It is about the person, and something important for that person that is not happening. It’s just the only way that person knows how to say it.

Instead of defending or explaining, acknowledge the message and try to learn what is important to them and what they would like to see happen. For example:

“I can hear you feel upset by this [acknowledge person’s worries], can you tell me what’s so important for you in this situation [ask what they really need] and what would you suggest we can do about it [ask for their request]?”

Responding to Complaints

You can hear anything in response. It doesn’t mean you have to comply with the request. If you can, why not do it? If you can’t, just tell them, explain what’s important for you, and then try to find a solution satisfying both your and their needs.

Example Interaction

  • (Team member is whining that tasks they do are boring)

    “I am always given these boring tasks. The work in the team is not challenging. Any monkey could do it!”

  • (Take a deep breath and remember, it’s not about you, it’s about them. They are trying to tell you something, even if it’s not pleasant.)

    “Okay, I hear that you feel frustrated because your tasks are too easy for you and you can’t learn anything new?”

  • (Wait a little bit, they may be shocked because you didn’t try to suppress them or convince them they are wrong or have no right to say so.)

    “… uhmmm …. Yes…”

    “Okay. You know, I would like to understand better why it is so important for you, because I would like us to find a solution satisfying both of us…”

  • (Wait again, especially the first time as it can be shocking for the person.)

    “… uhmmm … I think it’s obvious…”

    “It might be obvious. And I want to ensure what it is, so could you tell me…”

    “You know, I love to create something useful, do something that improves work.”

  • (You’ve just learned what this person really needs - to make a significant contribution to others’ work. Then ask if they have some ideas about what they could do.)

    “I understand you would like to do something that can contribute to others’ work… Do you know what it could be?”

    “… You know… I didn’t know how to tell it… I have some ideas on how to improve our deployment process with a little helpful tool. But during the last meeting, I was banned by others so I gave up.”

    “Hmm… Interesting… I didn’t notice it… Can you tell me more about this tool…?”

    • (They explain)

    “Okay. Try to roughly estimate how complex it is and how it would affect our work. During the next meeting, we will discuss this suggestion with the team.”

    “Oh, fine. I’ll send an email with this data.”

Just imagine what would have happened if you had said at the beginning: “Don’t be whining. It’s just how our work looks like.”

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Clean Code

The Importance of Clean Code

There are ongoing philosophical discussions on whether clean code matters and if it is worth investing time to read it. I won’t engage directly in this debate. Instead, a small example should suffice:

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

Read More