As a technical leader, one of your responsibilities is to help others get better. Being great at some technology just isn’t enough when you’re leading. Being a part of a great organization is where it’s at; and that means helping the people around us be great.

People don’t start out great; they get great over time through experience. One of my favorite quotes (attributed to all sorts of different people) is “Good judgement comes from experience, and experience comes from bad judgement.” You probably realize this in your own evolution as a technical leader. You’ve gotten better because you’ve made choices that later you would realize you could have done something differently and gotten a better outcome. A strong performer is out there always looking for feedback and ways to improve.

I’m a big fan of Manager Tools and the actionable advice they provide for managers. As a technical leader, regardless of whether you directly manage someone or not, I believe they have a model that will work for you. In particular, I have found that what they call the “Peer Feedback” model is something that would work in any situation. You can read more about it on their website, and the particulars aren’t hard to master.

Here’s a brief summary of the Peer Feedback model. It’s a two-part statement that follows the format “When you…” some behavior “this is what happens…” some consequence. The behavior is observable, it’s not subjective. It’s the words you say, how you say them, your physical gestures, your work product. A simple example would be “When you say to Bob that his technical design is stupid, here’s what happens - Bob is less likely to suggest an idea next time and I think you can’t work well with your team members."

Your job as a technical leader includes giving feedback. Sure, you can model good behavior. And if you don’t actually provide feedback to your team, it will be not as effective for them to know what they’re doing that they should keep doing. Or what they’re doing that they should rethink and adjust. It can be communication based like the above example, or it can be helping share the impact of a design choice. There are all kinds of ways to use the feedback model to help people on your team know the impact of their behavior.

Here’s a shocker for many folks: not only do the most effective technical leaders give lots of feedback to the individuals on their team, it’s also mostly positive. What? I can hear you saying “I can see so many things that can be done better!” Sure, and you’re also probably not working in a technical team that’s a sinking ship. If you are, it’s not feedback that’s going to get you out of that situation. If your team is largely successful at planning and finishing sprints, completing stories, making releases; there are tons of positive feedback opportunities.

Often times it is much easier for us to see the problems than the positives. We’re used to looking for defects, looking for gaps in logic. Some of the most powerful feedback you can give folks is something you want them to keep doing. When you give lots of positive feedback, it builds up your relationship. And it helps folks see you as fair and balanced. For a good period of time (weeks to months), try giving only positive feedback and see what happens.

So what do you do now?

Start giving positive feedback once a day
Experiment with giving more than one piece of feedback a day once you consistently do one
After 6-8 weeks start giving feedback on things someone should change
Do a self-assessment after 3-months and ask yourself how you’re doing.
- Are you doing it?
- Are you keeping balance (more positive than negative)?
- How are your relationships with the people you’re working with?
- Are you getting better results?