Agile

Possibilities for Managing Individual and Team Compensation

There’s a twitter conversation about how to manage team compensation. How can we pay people what they are worth and compensate a team for their value?

I know there are teams where I was quite valuable—not because I was “the” leader, but because I helped the team achieve our goals. And, there are teams where I was not as valuable. I did great work, but my contribution wasn’t as valuable as other people on the team.

That is the crux of the matter when we think about team compensation.

Here’s how I managed this problem in the past:

  • I created (with HR’s input) technical career levels. I often had 5 levels: associate engineer, engineer, senior engineer, principal engineer, consulting engineer. The principal and consulting had first-level manager and group manager as parallel. In addition, I had a couple more management levels (director and VP).
  • I wrote down expertise criteria that differentiated each level. The criteria focused on breadth of responsibility, collaboration capability, and strategic vs. tactical thinking. HR made me add “typical education” which I amended to say “or years of experience.
  • I asked my groups to provide me feedback on these criteria.
  • When I was sure the criteria were correct, I met one-on-one to make sure we each agreed where each person fit into the criteria. Some people were on the verge of a promotion. Some were not. We worked together to make sure we were both comfortable with their title and compensation.

Now, I had the ability to provide people individual compensation and promotions. And, I could provide team-based compensation. Here’s how it worked.

One guy, John, wanted a promotion to senior engineer. He was a high-initiative person. He coached and mentored people in the team. He got along with everyone quite well, and his solutions were often good. It was the often that was the difficult part. When he got an idea in his head, it would take a disaster to convince him he was wrong. His judgment was not as good as a senior engineer needed to have.

I’d provided feedback in our weekly one-on-ones explaining both my happiness and concerns with his judgment, depending on the circumstance. (This was not agile. We used staged-delivery, a feature-driven approach. I was the manager of several groups.) I asked him if he wanted coaching, and yes, he did, but not from me. That was fine. I arranged a coaching arrangement with someone who was a principal engineer (2 levels up).

The two of them met twice a week for several weeks. I think each meeting was about 20-30 minutes. The coach asked questions, provided guidance and options. The engineer learned a ton in that month and started to explore other options with his team. He started to realize his very first idea was not the be-all and end-all for the work.

It took him several months of practice, and I was able to promote him to be a senior engineer.

People need to know what the criteria are—why the org values them. If the salary ranges are too tight, there is no flexibility in hiring. If the salary ranges are too loose, it’s too easy to have discrimination in payment, especially if someone started their first job too low. (Yes, I have experienced salary discrimination.)

Let me provide a little context for team compensation. John’s team was involved in a new product. We didn’t know much about the customers and product management wasn’t much help. (I said this is before agile.) John asked the tech writer, Susan, for help in understand what customers wanted.

Susan guided the entire project. She helped the team understand the requirements. Because Susan was a principal engineer, she had customer contacts and she used them. She created what we would now recognize as a ranked backlog. John had the idea of a “pre-beta,” which were builds we provided to a select group of customers. You might think of this as a series of MVP (Minimum Viable Products) to these customers. The customers provided feedback to Susan, who used that feedback to guide the team.

We released the product and it was a great success. My VP came to me and told me I would get a $10k bonus (a ton of money back then). I said I had not enough to do with the project, and that the team would get the money. My boss cocked an eyebrow and said, “I don’t want to lose any of them.” I told him I would make it right, somehow.

I went to the team and told them I had been chosen to receive a $10k bonus, which I thought was wrong. They all agreed!

I asked them to explain how they wanted to divide the money. (I was thinking evenly.) Before I even had a chance to pass out stickies, John said, “Susan should get the most. She was the heart and soul of this project.” Everyone nodded their heads.

I said that was great, but let’s do a private vote in case not everyone agreed. I passed out stickies and asked people to write down how they wanted to divide it. Every person said: 40% to Susan, the rest evenly. Well, one person added me in the evenly part. I thanked the person and demurred.

That’s what we did. Susan asked for part of her increased percentage to be a team dinner with spouses/significant others and they invited Mark and me.

The team knows who did what. The team can manage bonuses.

I don’t know that this is the “best” approach. I have always wanted to know what my organization wanted from me. I have found a career ladder in the form of expertise criteria a great way to accomplish this. In addition, I want to know that if there is extra compensation, the team will receive that extra as a team. Every project I’ve ever been on was a team effort. Agile approaches make that even more obvious.

Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button