The bottom-up performance review

The performance review is a common way to regularly give or get feedback about the work that has been done. Some company performs those once a year, other twice a year. Agile teams may do it more frequently. In my previous experiences, the retrospective we were doing after each sprint was a way to give personal feedback, and once a year we were doing a yearly retrospective to summarize the whole past year, as a team.

What defines a good manager? Who is in the best position to judge?

That being said, in a bigger company, where management and middle management are necessary, the engineering manager performance reviews are usually done by higher level managers as if the positive or negative impact an engineering manager may have on their team and each one of the engineers part of the team may only be judged from a higher point of view.

As if giving feedback on management skills makes more sense when it comes from more experienced managers. As if management may only be judged good or bad regarding a “standard”, some kind of “best practices” collectively defined and perfectly known by senior managers.

In a way, this approach is not very different from the way we measure software engineering performance. We expect good software engineers to use development best practices such as design patterns, using the right tool for the right job, sharing knowledge, etc. And we judge a software engineer's performance by his skills, his commitment, and his capabilities to make good use of those practices.

It may be true for a part of management evaluation. There are, indeed, management best practices. I won't write about “Management 3.0” and the practices that make a manager, a good manager. There are plenty of books and blog posts defining what a good manager should do. One of them is “High Output Management” by Andrew S. Grove.

Thus, it makes sense for a middle manager to take feedback from a senior or higher-level manager, regarding those best practices and the experience a more experienced manager may have.

But, considering management as an exact science defined by long-term established laws is not sufficient. There is another bias: the impact on the managed team and people part of it.

A manager may be considered as “good” by a higher manager in that he contributes to a more global management objective and, at the same time, considered as “bad” in the point of view of people part of the team.

Let's see how those different points of view may change the kind of feedback we, as a manager, could have, with an example.

A company may consider investing time and effort in a new technology: a new framework, a new programming language, a new workflow, etc. From the point of view of a CTO, the objective is reached when/if every software engineer becomes comfortable with the technology. It's the responsibility of each middle manager to make sure everyone in the team succeeds in mastering the technology. And, in the end, if the goal is reached, it may be perceived as a success from a higher point of view.

But the way the middle manager makes sure everyone learn this new technology change everything. It may be forced. The manager may ask team members to work on those new skills at home. He/she may ask everyone to stop whatever they are doing to start learning this new technology. There are plenty of “bad” ways to make people get new skills. For software engineers, it may be a source of stress. One may fear getting this new skill slower than the others. One may reject the idea based on his knowledge of a concurrent technology considered better, etc.

Thus, to get complete and objective feedback on his work, a manager should ask for feedback from his team as well as from a higher-level manager.

Getting collective bottom-up feedback

I recently experienced such feedback from my team. About 6 months after becoming manager of the team, I asked for feedback to senior software engineers I work with. I could have done that during a one-on-one meeting. But getting feedback from the whole team is very different from getting individual feedback which may be context-oriented, and subjectively influence by personal considerations that have nothing to do with work.

Getting collective feedback from the whole team is a good way to measure how positive or negative may be a behavior, a decision or a methodology. When more than one of the team gives you the same feedback, it's a smell that you should take action (when it is negative) or take rewards (when it is positive).

Getting collective feedback also makes everyone more responsible. It forces each one to ask himself/herself how valuable is the feedback he/she is about to give. As a result, I found out the feedback I received was very relevant.

In some cases, I already knew I was doing wrong. In some cases, I discovered things that I would never suspect to have any impact on the team at all. It turns out, by the way, that the impact was quite negative, largely because the team did not have all the data they needed to understand what was going on.

In some cases, it helped me to realize that even if I can solve an issue or answer a question, my responsibility is to let the team take this responsibility. Seems obvious, right? Not that much. The feedback wasn't about “let us make our job”, or responsibility, or even reading skills. It was about the feeling that the top management seems to be more and more distant from the team. The difference was that because I feel confident answering questions from the top management instead of asking a member of the team to answer, there were fewer opportunities for members of the team to talk with the top management directly.

None of those learnings could have come from my manager. Some feedback may have been given during my team members’ performance reviews or during a one-on-one meeting. But I am quite sure it would have had less impact on me. Probably because I would have seen it more like a sum of individual feedback, which may be subjective, and less like something proven by the number of concordant feelings. You may wonder how we perform a collective performance review. It was pretty clear.

I ask the team to take a few minutes to think about :

• What was going wrong
• What they have found good
• If they have an improvement suggestion
• If they have any idea about team management.

Then, each one spoke. One after another. I was just listening.

In the end, I took the list of things that were going wrong and explained for each item what was my feelings or my thoughts about that. It was the right moment to explain some of my decisions and help the team to understand. I also had the opportunity to recognize my failures. Finally, it was also a way to make the whole team grow up by asking them to think if they were me, what would they have done?

Personal feedback is the key to continuous improvement

Of course, performing a 360° review is not sufficient. You still need to get more personal feedback. It is especially true when doing a performance review with one of your team members. In many cases, suggested improvements or negative feedback must be considered not only as a breach of the team member but also as a breach of yourself. A lack of skills may be the responsibility of the person you are reviewing the performance (when he/she did not do the necessary effort, for example) but also your responsibility, as a manager (when you have not given enough time to this person to master a particular skill).

For all those reasons, a performance review must be seen much more like an exchange between two people working together and needing to improve the way they collaborate than top-down feedback.