Eric Elliott has a point when he says “The best way to be a 10x developer is to help 5 other developers be 2x developers”. The same thought can, to some degree, be transferred to people management: “The best way to be an effective people manager is to help others develop and use some people management skills.”

Teaching people management skills to others in your organization is extremely beneficial, because people are a core asset to almost any organization. Employees who feel that somebody cares about their development are more likely to stay. So, if more people are taught to express and communicate this care, employees will, on average, feel more appreciated, and your turnover rate is more likely to be low.

Moreover, if more people are able to give feedback, resolve conflicts, etc., then dangerous or awkward situations will be tackled sooner. Conversely, if feedback is only given once a year by an out-of-touch manager, misbehaviour might not be brought up, and conflicts are not resolved. They will smoulder under the surface for months and months. By the time somebody gets around to taking care of the situation, the damage might already be done and beyond repair.

Last but not least, by teaching others the skills necessary to give guidance, you effectively free up some of your own time. You won’t have to take care of every little problem yourself any more, and you stop being a bottleneck for such actions. Plus, the guidance provided might actually be better - we’ll come to that later.

Start with a small problem

So we agree that it’s a good idea to have more people in the company trained in foundational management techniques like giving feedback, or mediating in a conflict. How do we proceed from there? As an example, we will look at Marco, who works in lower management at a medium-sized software company. Marco agrees with us in that he wants to empower some of his direct reports to pick up some people management skills.

First, Marco picks a small problem or task that he would ultimately like to delegate. Example: There is a new colleague, let’s call him Peter, who has repeatedly failed to give status updates when there were delays. His teammates only ever learned very late that they had to do some re-planning. Marco does not work with Peter on a daily basis himself, but Peter’s team mates, Charlotte, Marco, and Hans, do. It is them who are affected by the problem much more than Marco is. So why shouldn’t it be them who take care of the situation?

Why is nothing happening by itself?

You might think that, in a healthy team, it should not be a problem to talk about things like that. I partly agree. However, I have found that there can be several reasons that people hesitate to give feedback to their peers:

• Insecurity: Especially when there are people involved who have known each other for a short time only, there might be some insecurity between them. They cannot assess the other person very well, and don’t know how they will react. Therefore, they prefer being quiet, and wait for somebody else to intervene.

• Conflict avoidance: A lot of people (me included) do not feel comfortable in conflict situations, and, if given the choice, tend to avoid them.

• Self-deprecation: Some people might think: “Who am I to tell Peter what to do, or not do? I’ve only been here for 6 months myself, I am not entitled to give orders around here.” A variation of this is: “Maybe it’s just my perception, and I’m wrong.”

• Too much hassle: Critical feedback should usually not be given in front of everybody, because that would blow things up unnecessarily. But maybe there is no convenient space where to have a one-on-one conversation. Maybe it feels too “official” to call somebody to a meeting room, and people feel it would be too big a deal. So, ultimately, they don’t.

All that might be needed for somebody to overcome these kinds of “blockers” is a little encouragement. Someone to give her/him a little push and say: “It’s okay to intervene here, and it’s ok for you to intervene.” You want to be that somebody who gives the little push.

Meet Charlotte, our apprentice

So Marco has identified his training situation. Who should he pick as an “apprentice”? Let’s say he picks Charlotte in our example, because she has some empathy skills, and communicates well. She should be at least somewhat open to the idea of speaking out and giving constructive, but also critical feedback to colleagues. I have known developers who just don’t want that, and that is fine. They want to keep the “human” part of the job as small as possible, and they cringe at the thought of confronting a colleague about his shortcomings. These developers are probably not good candidates to pick here.

Ask and encourage

Now that Marco has Charlotte in mind as a person who to delegate to in the future, he has to find out if Charlotte is up for a first exercise. He asks her for her help

Marco: “Charlotte, I have a one-on-one with Peter coming up, and I could use your help for the feedback part. For some of the feedback I have collected, I have no concrete examples, and it would be more effective if somebody was there who has actually witnessed the situations in question. Is it ok if I call you to the conversation later on?”

Since this is a somewhat unexpected request, Charlotte is a bit hesitant and not sure what to make of it.

Charlotte: “Hm… I don’t know. I have never done this before.”

This hesitation is rather natural. Many people in Charlotte’s situation will be concerned that the conversation might be awkward. Maybe they never saw peer-to-peer feedback go well. So Marco tries to reassure her.

Marco: “Don’t worry, I will be there and steer the conversation. I will make the situation comfortable for everyone. You can contribute as much or as little as you like. Just lean back and join the conversation when you feel like you have something to say. But I really think that you will be good at this, and that your feedback will be valuable to Peter.”

The conversation

Luckily, Charlotte agrees in the end. So when the time comes for the next one-on-one with Peter, Marco starts off as usual at first. At some point, the conversation turns towards feedback. Marco mentions that he does not feel that he is the best person to give feedback to Peter, and that he would like to get Charlotte to help. Marco leaves for a second and gets Charlotte to join.

Now, beware: The moment Charlotte enters the room, the atmosphere will change - at least a bit. Of course it helps if Peter and Charlotte have a good relationship, but still, the atmosphere will change. It is probably pretty obvious to Peter that Marco and Charlotte have been talking about him, and it’s natural for him to wonder what this might mean. Therefore, Marco does some initial talking to set everyone at ease, and demonstrate that nobody has to be anxious about this situation.

Marco: “So, Peter has just asked me for some more feedback, because he was wondering if there was something he can improve, and how he is perceived by the rest of the team. From what I am hearing, Peter, and from my personal interaction with you, I can say that you are doing a very good job at getting up to speed. You became familiar with our development process, and you operate confidently in it. You contribute during discussions and share your ideas, which is something that we value. You deliver good code.

Coming to improvement areas: I have heard of occasions where you surprised your team mates with the status of your tasks. Can you imagine what I am talking about?”

Peter (thinks for a bit): “Hm… No, not really.”

Marco: “I’m talking about a lack of status updates. Maybe Charlotte can help us with a concrete example. I believe it was related to the new rating algorithm, right?”

Of course, this last sentence is somewhat staged, but it might help Charlotte find her way into the conversation.

Charlotte: “Yes, that’s right. You see, you were telling us on a Monday that you expect to finish that algorithm in 2 days, but on Wednesday, you told us you would need another 2 days, and then on Friday, you told us that you don’t know exactly how much more time you would need. And this was not the first time that something like this happened. For your task on the search filters, it was similar.”

These are very reasonable, factual claims by Charlotte, but, depending on how much tension there is in the room, it can help to ease it up a bit at this point, so you could jump in: “This is probably nothing too uncommon. We as engineers have a natural tendency to get our teeth into a hard problem and struggle with it for quite some time. But what do you think, Peter? If you put yourself into the shoes of your team mates, what could be their problem here?”

Peter: “Well, I’m not sure what to say. These were hard problems to solve, so it took me a while.”

You: “I know they were hard problems. Everybody is aware of that. And the solutions you came up with are really good, and already work well in production. But being part of a team means that you have to communicate with your team mates.”

(you pause, and Charlotte takes the cue)

Charlotte: “It’s just that, if you see that things take longer, we would like to know as soon as possible. Then we can adjust other plans accordingly, and react to the new situation. When you were working on the rating algorithm, Hans was starting work on the footer. In hindsight, the sidebar would have been a better choice, but Hans is not very familiar with that code, and we thought that you could do that during that sprint. And then, when the rating algorithm took longer and longer, we had to postpone the sidebar to another sprint. We should rather have postponed the footer instead.”

Peter thinks for a little while. When he says nothing, Marco picks up.

Marco: “It’s great that you are tenacious about hard problems. But you also have to see the bigger picture, which is your team’s project or sprint plan or whatever you have agreed on as a team, and check how your individual work fits together with the plans of the team. Do you see what we are saying?”

Peter: “Yes, I think I get the idea.”

Marco: “So what can we agree on? Peter, do you have a suggestion?”

Peter: “Hm…does it make sense to give status updates every 2 hours? It sounds a bit strange to me.”

Charlotte: “Yeah, to me too. I don’t know if there has to be a hard-and-fast rule, or if there even can be. But when you’re stuck, you should let us know, and maybe get some help. Often, it helps to talk about problems, and then you find a solution just by verbalizing it. If you feel that you made hardly any progress during a whole day, this is definitely worth reporting.”

Marco: “Sounds reasonable to me. Peter?”

Peter: “Yeah, me too. I will do my best.”

Marco: “All right. Thanks, Charlotte. Any other feedback or comments, in either direction?”

Charlotte: “No.”

Peter: “No, all good. I just want to say that I’m happy to be on the team.”

Debriefing

So, this went rather well. Marco, Charlotte, and Peter reached an agreement, there was no shouting, no blaming, little to no awkwardness. Probably, it does not always work this well, but if you pick an easy problem and the right apprentice, things are likely not to blow up entirely.

In a quiet moment, Marco takes Charlotte aside, praises her for how professionally she gave her feedback, and asks her how she felt about the conversation. It’s a good idea to briefly reflect together on what happened during the conversation (5 minutes might be enough), and talk about what happened. Passing on some theory on how to give feedback is also a good idea, for the next time when Charlotte’s help is wanted.

Closing thoughts

Remember how I said that, if you delegate some people management, the guidance provided to employees might actually become better compared to you doing it all yourself? The reason is that the feedback is more concrete and more immediate. Clarifying questions can be answered. In our example, Charlotte was right there in the situations that are discussed, and can describe the consequences of Peter’s behaviour very accurately. She can provide more valuable information than you could have.

Another thought on the kind of situation that we want to pick for “training”: I think it helps if the feedback receiver is rather junior. This way, the trainee (Charlotte) might feel less intimidated by the new situation, and the feedback receiver (Peter) is less experienced in those situations, so he might not be that confused when we get a third person in the room.

Finally, I want to stress that giving feedback is one of the most critical management skills, because feedback can be very powerful - it can greatly improve your work environment, but it can also have a destructive and demotivating effect if given poorly. Therefore, feedback conversations should not be delegated to somebody unprepared, or unwilling. The person delegated to has to be objective and truly interested in helping others. Only then will she bring value to the conversation, the team, and the company.

Want to learn more about giving feedback? Check this out: