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.

4 Replies to “Possibilities for Managing Individual and Team Compensation”

  1. Johanna,

    This was an extremely insightful post. I really appreciate how the combination of a “rational” ladder, coaching and and team compensation come together. I have two questions, though:

    1) Are you familiar with the work of Elliott Jaques and Stratified Systems Theory – and have you considered using his concept of Time Span of Discretion as a clear measure for constructing the ladder?

    2) How does the team compensation thinking work when the “team” report to different hiring managers (developers, testers, analysts, etc.)? Or when the “team” is bifurcated between the inventory side (product owner and BA’s) and the delivery side (devs and testers)? This seems so much simpler to implement within a traditional management hierarchy…

    1. Hi Rich, I always learn something from you–thank you for the idea the Stratified Systems Theory. I’m not sure I’ll get the book, but I will certainly look into it.

      Okay, re team member reporting and agile, here are my current thoughts:
      – If we have a job ladder, and all devs/testers/BAs/whomever have the same ladder, we have parity across the organization.
      – Then, if we have teams who get bonuses (why would we do that? I still don’t understand, but that’s a different post), the team can decide what to do

      We have to stop pitting people against each other at all levels in the organization. It’s not you against me in an org; it should be us against our competitors. (You’ve read my project portfolio book, so you know what I mean here.)

      When people “report” to different managers, what is the manager’s role? Is it to create that relationship that keeps people at work? That’s good. If it’s to direct people to work, that doesn’t work in an agile organization.

      I don’t have trouble with a management hierarchy, unless there are too many levels. I don’t particularly like a cross-functional team “reporting” into different managers, unless the managers also create their own team, so that at every level, the team, the managers all optimize up.

      We do too much optimization at the individual level (resource efficiency). We don’t realize the Cost of Delay or Cost of Delay/Duration when we don’t optimize for the team, the product, the project portfolio (flow efficiency).

      I happen to think talented managers enhance an organization’s capabilities. In my experience, talented managers are just about as rare as talented teachers. I’ve met many managers who were okay. I’ve met even more who were sub-optimal. I’ve met a few managers who were talented. (I’m not talking about making mistakes. I’m talking about not learning from them.)

  2. “When people “report” to different managers, what is the manager’s role? Is it to create that relationship that keeps people at work? That’s good. If it’s to direct people to work, that doesn’t work in an agile organization.” – good question. I think that is what we are struggling with. The manager’s role has changed and is continuing to change, but without sufficiently clear vision or consistency accross the organization.

    1. Rich, I’ve been writing around the idea of what managers do in organizations for a while. One article is Agile Managers: The Essence of Leadership. Another is Do You Value Management?

      One of our problems in more traditional orgs, is that too few people value real management. They value control, not facilitation. They value prediction over coaching and outcomes. (I am not going to do another manifesto here!)

      I am thinking about my upcoming agile management book. To me, the biggest problem is that senior management wants guarantees, incents local behavior instead of global behavior, and doesn’t actually value the work of management: to facilitate and encourage small changes all the time.

      You actually said it: we need a clear vision (strategy and outcomes from senior management) so the middle managers can create and manage the project portfolio and work across the organization so the first level managers can continue to encourage small safe-to-fail experiments. (We actually need those experiments everywhere in the org.)

      Great managers are valuable and are leaders. I still don’t understand how people can separate management and leadership. To me, if you’re a manager, you must be a leader, too. (See We Cannot Choose Between Management and Leadership.)

      I reserve the right to change my words when I write them better in the future 🙂

Leave a Reply