Camille Fournier on the value of complaining:

If you do this well, you actually teach people how to understand which problems are important, and which problems are not. Letting people complain might seem like it will do nothing but encourage negativity and drama, but if you guide people to learn from their complaints it can instead help your team grow. It’s great when people can bring problems AND solutions to you simultaneously, but it’s more likely that they will need help to see the best solution. Helping them see the best solution starts by helping them understand how to state the problem.

How can we expect someone early in their career to look at dysfunction (technical or social), see the underlying cause, and then pattern match onto a practical suggestion for correcting it? Problem formulation is the hard part: seeing the symptoms isn’t the same thing as seeing the cause. It takes experience to find the system beneath the dysfunction and then analyze with enough clarity to find the high leverage points, the places to intervene.

You begin by expecting them not to be able to do the work successfully. In a conventional work context, this may seem like an odd qualification for a job. But in a school, if you could master the year’s curriculum on the first day, you wouldn’t belong in that grade level.

So you begin by expecting that workers cannot do the work successfully, and you provide them a teaching staff that will help them grow into the job. By hardwiring the coaching activity into the line leader’s responsibility – a line leader who has himself done this very job – you alter the sourcing, credibility, and quality of the teaching.

So say Robert Kegan and Lisa Lahey, in their excellent An Everyone Culture, on helping coworkers learn. When someone complains without a solution, they are really reaching for metacognition in their work but failing. You get a rich coaching opportunity in those moments! Camille Fournier (to be expected – @skamille is a bad-ass) has some good pointers for what to do next.

Instead, I encourage you to ask people to give you details when they have complaints. Help them put their complaints in context. If they complain a system sucks, ask them why. Maybe the answer is that they don’t like the formatting standards, in which case an appropriate response might be, unfortunately not everything goes your way. On the other hand, maybe the answer is that it takes them a long time to make changes because the system has no tests and breaks easily, in which case, perhaps you want to think about actually fixing that problem.

Even if the complaints don’t lead anywhere obviously productive with respect to their target, they provide an opportunity for two coworkers to compare mental models.

We are going to have disagreements and conflict in our teams. None of us sees the world in the same way, and that is good. We form teams because as a group, sharing our perspectives, we can create things that are greater than the sum of their parts. Trying to create conflict-free environments is a fool’s errand. But you can guide conflict and complaints to result in an increased understanding of context. Instead of discouraging all disagreement, push people to be specific about their thoughts and concerns, and attempt to understand them.

We can’t successfully write software without strong mental models for the problem domain, the technologies we’re using, our plan, and the meaning of the feedback loops we use to guide our progress. But most of the time people are applying their mental models, not discussing them. Having a breakdown or some ongoing friction on the operating table gives us a chance to surface our differences and use them as a fulcrum for better understanding.