Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 138 posts at DZone. You can read more from them at their website. View Full User Profile

Compensation Strategies for Agile Teams

03.04.2014
| 8671 views |
  • submit to reddit

I don’t consider myself an expert on designing compensation systems, but as of late this issue has come up with several clients, and of course, I have to deal with compensation issues leading LeadingAgile. I’d like to share some thoughts with you guys, get some feedback, and maybe even generate a little healthy debate.

The key challenges around compensation, at least for me, center around figuring out how to reward individual performance without encouraging internal competition, local optimization, or one person feeling rewarded while another feels punished. You want compensation to motivate people, not to have a negative impact on performance.

Ever since I read Dan Pink’s Drive I’ve been very aware of the distinction between intrinsic and extrinsic motivation. While you’d like everyone intrinsically motivated… the realities of having a mortgage, consumer debt, household expenses, kids that need to go to college, or even saving for retirement drive different extrinsic needs.

Some folks want to come to work, do a great job, and go home. Some folks want to go the extra mile and really make a difference. Some poeople really want to kill it, advance their career, and be rewarded for all that hard work. Just saying that everyone should get a fair base salary, with no performance based component, isn’t going to work for some people.

So the question becomes, is it possible to use money or other rewards to recognize performance without introducing the negative side effects? Can we build a compensation system that values collaboration without creating internal competition, local optimizations, or risks leaving one person feeling punished because they didn’t get as much as their peer?

Here is what we are doing with LeadingAgile…

First, we have all our coaches is a pretty narrow salary range and we are working to narrow that range even further. When we started hiring a few years ago, I was pretty risk adverse and you really had to be a true believer to come work for me. As we grew, salaries increased and we are making things right for the people that joined us early.

As a quick aside, I want to be able to justify numbers if we ever decided to publish salaries internally. For the record, I am totally open to full transparency and think it’s a good idea. Some folks aren’t so keen on the idea, so we are respecting that for now. It does influence decision making around salaries when everything might be out in the open some day.

We believe that baseline performance is binary, you are good enough to be on the team or you aren’t. We are starting to get more explicit about what it means to be good enough to be on the team, but if we hire someone, we have very high confidence they can work in our model and be successful. Occasionally something will come up after the fact, but that has been rare.

If you are good enough to be on the team, you share in the team’s success. For us, that means a 20% bonus on top of your salary. Everyone will get the bonus or no one will get the bonus. We are toying with quarterly payouts but for now, it’s annual. The idea is that if the company is successful, we want to share that success with everyone.

Success for the time being is defined as 75% utilization. We’ve debated setting the target a little lower and we’ve discussed a sliding scale. There is a ton the utilization implies about our ability to market, sell, deliver services, and manage cash… so it’s not just about revenue. That said, revenue is what drives our ability to get people paid.

Does this fall into the category of an extrinsic motivator that might actually demotivate people? Maybe. But how else would you share financial success when things are going well? If we just added that 20% to each salary, my cost structure would be too high should we underperform financially. I’d have to let people go in a slump and that’s not the goal!

We are intentionally falling on the side of keeping our cost structure in check and rewarding the team if we are able to perform at a high level. We are building the infrastructure to help the team support marketing and sales, educating folks on how to manage engagements, and really encouraging people to pay attention when we have unexpected downtime.

I’m hoping that by taking a whole team approach, keeping everything visible, and empowering everyone to influence the goal we’ve been able to strike the right balance. Time will tell.

That said, we still haven’t addressed how to compensate the people that really want to kill it. Those consultants that want to hep market and sell, grow the practice, lead multiple accounts, and create sustainable economic value for the company. If someone is able to create that kind of value, I need to reward them or they’ll leave our company and start their own.

We are looking at introducing a variable component to our salary structure based on several other metrics we think might be relevant: overall financial contribution based on sales and marketing activity, the ability to keep yourself busy on one or more accounts, willingness to grow and develop professionally, customer feedback and peer feedback.

The idea is that for an individual component to pay, the team would have had to meet its overall goals. No local optimizations. Any compensation model over and above base salary and team based goals would have to meet certain design criteria to make sure it adequately rewards individual performance but doesn’t feel punitive to those that don’t make it.

It has to be inclusive… anything that one person is able to do, everyone is able to do. There can’t be some named subset of people able to participate in the plan.

It has to be based on abundance … everyone is able to be at the top every time. We want to build a system that assumes everyone has the ability to be a top performer.

It has to be transparent… whatever we choose to measure will be tracked openly so you can see where you are relative to your peers at all times. The measures and goals have to be clear and attainable.

It has to be cooperative… there cannot be any penalty for working together to achieve a goal. If two people work on a goal together, the reward has to be as much or greater than working on it individually.

It has to be sustainable… we will only ever reward sustainable growth. Creating incentives that encourage people to only look out for short term economic outcomes won’t help the company grow.

My hypothesis is that if we can fairly compensate people by way of base salary, give everyone something extra if we hit our financial targets, and create an inclusive, abundant, transparent, cooperative, and sustainable model for paying one person more than another… we might have a shot of making it work and allowing folks to meet their individual financial goals.

If an employee receives a fair salary, is compensated when the company does well, but decides not to participate in the broader plan… they may not like that they didn’t get anything extra, but at least they’d understand why and know what needed to happen in order to participate in the future. If your good enough to be on the team, that door is always open.

Okay… so what do you think? Is it fair or a slippery slope? What could we do differently? I realize we are a services company, but could these ideas work in a traditional software company? Would a model like this work for an agile team? An agile enterprise? If it would work, what kinds of measures might we consider for software developers and other team members?

Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)