3 ways to measure performance in an open organization

No readers like this yet.
A sprout in a forest

Opensource.com

Jim Whitehurst recently wrote about the performance management approach we use at Red Hat for the Harvard Business Review. In his article, Whitehurst details one aspect of the performance management process that differentiates Red Hat from other companies—its flexibility.

We have a system for tracking performance (called Compass), and we have expectations for when Compass reviews are performed (at least annually, preferably quarterly). But the details and structure of implementation are up to individual managers or teams. I lead a team of more than 100 people at Red Hat, and I’d like to share how I measure and manage performance the open source way.

First, I don’t think of it as "performance management" in the traditional sense. The starting point for this process is individual associates' personal development: How are we working to increase their capabilities? In my experience, most people are motivated by the idea of their own growth, whether their personal goal is to advance their career, learn new technologies, expand their scope of influence, achieve one of Red Hat’s many technical certifications, or something else entirely. If each person is increasing his or her skills and abilities, the team is going to be more successful, and we’ll be able to meet our higher level goals. This starting point differs from that of traditional performance management; instead of measuring what someone has done, we’re continually discussing where that person wants to go and what he or she needs to do to get there.

Along with my team, I use several tools to achieve this:

  • One-on-one meetings
  • Clear definitions of what we’re trying to achieve as a team and why, as well as clear descriptions of expectations for each role
  • Regular opportunities for associates to "keep us honest"

The one-on-one

The most important tool for helping individuals develop is regular conversations between them and their managers. Of course, what you talk about and how you use this time matters a great deal; having a standing meeting that’s ineffective is easy. Some of the managers on my team use a template to structure the conversation and ensure they cover important topics; some take a more flexible approach. I like to touch on a person’s achievements, challenges, next steps, and development.

During this discussion I try to continually make connections between what the person is working on and how that fits with our team and company goals. If we lose sight of that connection—which is easy to do in our fast paced environment—then work might lose its focus. I also like to talk through challenges (or “blockers” as we call them), and provide ideas on how to resolve them. It’s important to take time specifically to discuss progress on the individual’s development. Whether that is working on developing a particular competency, applying a newly learned technique, learning a technology, or something else. If you don’t talk about development, then development doesn’t happen. And, of course, the conversation is a great time to get feedback from associates and better understand what they need to be successful. If these conversations happen every week, the concept of the annual review—the primary performance management tool in some companies—completely changes. Rather than a major determinative event, that milestone is just a checkpoint and summary reinforcing what we’ve been discussing all year.

Definitions and expectations

I ask all of my managers to have weekly meetings with their teams. Again, using this time effectively is important. I use it to discuss our team and company goals, tying our work to those outcomes at every opportunity. Topics rotate from week to week, and we continually experiment with different formats. The important thing is that people share stories—what’s working, what isn’t working, ways we can help each other, what people are excited about, what people are worried about. I find this to be a more constructive path to achieving outcomes than focusing on operational data (especially as the work my team does is not easy to measure in a meaningful way).

In addition to meetings, I also post and share several important things on our internal collaboration tool:

  • Regular blog posts addressed to the whole team, with my take on how we are progressing toward our goals, feedback that I am hearing from customers and internal stakeholders, examples of specific things that are going really well, and ideas on what we can do differently. My goal is to help make connections, but also to encourage conversation and feedback.
  • Our team goals for the year, with monthly updates on progress, so that we all are continually thinking of why we’re doing what we’re doing and not losing sight of the bigger picture.
  • Definitions of each role on the team, with clear expectations for each level and examples of what working at that level looks like. For example, we have more than 75 technical writers, ranging from "associate" to "principal" levels, and we have provided specific examples of the expectations for each level. This helps people see where they are with their own development, and provides ideas on where to focus in order to achieve the “next level.” Some people find this very motivating, and some people are less concerned with advancement. Even if someone isn’t worried about getting promoted, we can’t keep up with the pace of change in our industry if people aren’t continually learning new skills; this tool helps motivate these discussions.

The creation of these documents comes from ongoing, open discussion with the team in several forums (in person, team meetings or one-on-ones, online, etc.). In other words, the managers don’t go off and create goals and expectations in a black box. We start by asking for ideas, then we create a draft in the open, ask for feedback, and iterate until we have something that works for the team. There are often disagreements, but everyone has a voice in the process (even if they don’t agree with the entirety of the outcome).

Asking questions that matter

While we ask for feedback continually, for the past year I’ve been trying a more direct technique to understand how the team feels about what we’re accomplishing together. You could think of this as a tool for managing the performance of people managers. For this, I turn to an adaption of Marcus Buckingham’s 12 Questions that Matter.

I ask everyone who reports up to me to fill out a questionnaire each quarter, adapted from Buckingham’s 12 questions. For example, “do I know what is expected of me at work?” or “In the past three months, has my manager talked to me about my development?” The questions are answered on a scale of 1-5, and the survey also provides an opportunity for free text answers. The response rate is high, usually around 75 percent. The numerical answers help us see if we are truly creating the environment we think we are creating, and the free text answers have provided some incredibly valuable feedback.

I take the results very seriously, share them openly with the team, and use them to coach my managers. The results also serve as a catalyst for changes to the ways I approach my work. For example, I feel that I frequently ask people for feedback, but the survey has shown that people don’t always feel like their opinions count. That’s prompted me to more directly share examples of things I’ve done in response to feedback from associates.

Measuring performance is a continual process that is taking place constantly in our daily work. The above are some of the always-evolving processes that help me determine if our team is on the right track. Do you use any of these techniques? What methodologies work for your organization?

Follow the conversation on Twitter #theopenorg

Picture of Sam in his home office smiling at the camera. Sam is a white man. He has long curly brown hair and is wearing a dark green zip up fleece hoody.
I lead a team in Red Hat focused on providing context, knowledge, connection and alignment to our Product and Technologies employees, as well as working to ensure they have an inclusive, equitable, and safe environment to work and grow in. I am a late-diagnosed autistic person and I co-chair Red Hat's neurodiversity employee resource group.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.