Management Myth 20: I Can Compare Teams (and It’s Valuable to Do So)

[article]
Summary:

Johanna Rothman explains that you cannot measure what people do and expect that measure to be useful. Why? Because software is a team sport, and everything we do depends on other people.

Barry bustled into Sam’s office. “Hey Sam, I need to see how these teams are doing— compared to each other. How do you compare teams?”

“I don’t compare teams,” said Sam. “Why are you trying to compare teams?”

“So I can tell who’s being more productive and who’s slacking off,” Barry replied. “But I thought for sure you did this. You always seem to have really productive teams. How do you measure them?”

“I don’t measure them.”

“What do you mean you don’t measure them? You must do something. How else will you know if the teams are any good? How about the people on the teams? You must measure them. Come on, what’s your secret?”

“Barry, I don’t measure a thing about the people. I don’t measure what the teams have as output. I ask them to measure their throughput and to ask me for help if they are unhappy with it.

“My job is to help create the environment that will allow our team members to work in a reasonable way. I make sure they know which project is number one. I arrange for training for people when my managers tell me people need training. I make sure everyone knows our mission. But I don’t bother with that comparison nonsense. Is someone asking you to compare teams?”

“Well, no, but I have no idea how to know who is doing great work and who’s not doing so well,” said Barry. “I have engineering teams here in California and some in Colorado. I have some teams in France and some in Israel and Bangalore. How do I compare them? They are cross-functional teams. They are working on the same product. You would think I would be able to compare them. But I can’t figure out how.”

“Okay, let’s deconstruct this,” Sam said. “First, why do you want to? What’s the value you obtain from comparing teams? What would change if you suddenly know one team is better—which I’m not saying you will discover. But if you did discover that, what would you do?”

Barry thought for a few minutes. He said, “Well, I’d reward that team.”

Sam shook his head. “No, you wouldn’t. Not if you wanted that team to work with the other teams on the program ever again. The teams have to collaborate. Why would you pit the teams against each other?”

“Because I want to get the best out of my people,” replied Barry.

“Okay, that’s a great goal,” said Sam. “I also want to get the best out of my people. I tell them what the best is. The best is often a specific release date for the product, or some release criterion since we’re in engineering. When I ran support, it was something else. When I ran IT, it was performance for the organization. But it was never a measurement for the team. Never.

“If you want to measure something, you might start with yourself. You’re at the top of the organization. But that doesn’t make sense either, does it?”

Barry shook his head.

Sam continued, “You can’t measure the performance of a team. However, you can measure the team members’ output. In engineering, you can measure features-per-unit-time, although you can easily game that measure. Instead of doing so, tell people what you want. Do you want them to release the product by a certain date? Tell them. Do you want them to take care of customers in a certain way? Tell them.

“People come to work every day to do a good job. No one comes to work to do a bad job. If you think they want to do a good job, treat them that way. They will live up to your expectations. But you have to do your part. You have to tell them what you want, provide any necessary resources, provide training, have one-on-ones with your managers so you can provide meta-coaching and feedback, remove the impediments, and make sure the program’s goals are clear. Then you have to not get in the way of the program.

“But you don’t have to measure the teams. There’s no value in that. If you think there is, measure yourself first. See what you discover. Then apply your measurement to your teams.”

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12