Aligning Incentives for Agile Success
In this episode of the Scrum.org Community Podcast, Dave West and Dimitrios Dimitrelos, Business Agility Lead, Accenture Greece, PST, explore the powerful role incentives play in Agile transformations and the Agile Product Operating Model (APOM). Dimitris shares a striking story of QA teams inflating bug counts to meet performance metrics, highlighting how poorly designed incentives can undermine collaboration.
They discuss strategies for balancing individual and team incentives, the limits of financial motivation, and how organizations can redesign performance management to support true Agile behaviors. Listen to learn practical insights for fostering collaboration, transparency, and sustainable motivation across your teams.
Key Takeaways:
- How misaligned incentives can derail Agile transformations
- Balancing individual vs. team incentives for collaboration
- Understanding motivation beyond money using Herzberg’s theory
- Practical steps to redesign performance management systems
Transcript
Lindsay Velecina 0:00
Announcer, welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.
Dave West 0:19
Hello and welcome to the scrum.org community podcast. I'm your host, Dave West, CEO here@scrum.org in today's podcast, we're going to continue our discussions on aligning incentives with the Agile product operating model and how incentives can ultimately undermine any change program around moving to a product model. This podcast was inspired by a recent webinar on the subject and a subsequent podcast on the questions from that webinar. All of those links will, of course, be included in the podcast notes, so you can click on them and read them at your leisure. You don't have to do the pre reading or the pre listening, I guess, or viewing to get something out of this podcast. Don't worry, but you might be interested in some of those discussions as well. So I'm really lucky today, because I've got somebody that knows a lot about incentives and and really a lot about change really. I'm not saying he's old, don't, sorry, but he has experienced quite a lot of change programs and has seen the horror of incentive programs. I'm joined by Dmitry, Dimitrios, PST and business agility. Lead for Accenture in Greece, Dimitri has experienced incentives having both a positive and negative effect on the move to a product model. So welcome to the podcast, Dimitri.
Dimitris Dimitrelos 1:56
Hello, Dave. Very nice to be here. Thanks for
Dave West 2:00
having me. It's great to have you. I know you. You've got a lot of scars, sorry, no, a lot of knowledge and experience. Some of them are scars on this, on this topic. So before we jump into talking about a palm and particular incentives and things like that, why are we even talking about incentives? What you know? Do you want to set the scene for our listeners? I
Dimitris Dimitrelos 2:27
want to start with with a story from my early days as an Agile coach. So one of my first assignments was with a company that worked in a hierarchical, very hierarchical way and in separate teams that did development and QA and bug fixing were done by three different teams, and they wanted to examine whether it made sense to switch to Agile or cross functional teams, et cetera, et cetera. So during my observation period with the team, as I was sitting with the people doing the work, I saw that the software had an abnormally large number of bugs. So it was not usual for this size of software to have so many bugs. So I sat with a QA team to see what was going on there. And what I saw is the people, whenever they found a bug, they opened the same bug four times in their bug tracking system, one for every browser that the system was supporting. So they opened one for Internet Explorer was the browser at the time they opened one for opera and one for Mozilla and one for Chrome. So when I asked them why they do this, they told me they were reluctant to answer at first, but when I press a little bit, they told me, you know, our performance is based on the number of bugs we are discovering. So since this is a system that runs for four browsers, it's four times a bug, so my performance will be better. I said, Okay. And then I moved on to the other side of the world, where the developers were fixing bugs the supportive right? And I asked them, guys, you get an enormous size, an enormous number of bugs, right? Four times a bug, don't you? Don't you? Isn't it difficult for you? And you know what they said, you can imagine, right? They said, Well, you know, our performance is based on the number of bugs we're solving.
Dave West 4:38
Oh, it's like, I remember the sort of, it's now become an urban myth, but the IBM used to measure software developers on lines of code. And there is that classic sketch where, you know, I'm off to, what are you doing? I'm off to write myself a minivan. You know, be. Because they're they're being incentivized to to do lines of code. So alright, so hang on a minute, but most organizations aren't as silly as that. Dimitri,
Dimitris Dimitrelos 5:12
no, no, that's, that's, it's a true story, but it's not a very usual one. But what this story shows is that incentives and performance management and goal management are very tightly knit with any transformation effort. And the reason is that they affect, they seriously affect behavior, right? And behavior creates culture as change agents that we are you know we know that we cannot directly change culture. You cannot direct culture. You cannot command an organization to change the culture by doing training, by doing whatever you can do. You cannot change the culture unless you change the system. If you change the system that affects the behaviors, then the behaviors will be affected, and then the culture will slowly start to shift in the direction you want it to go. So this is why incentives and performance management and goal management are so important in any big change initiatives, like adopting a product operating model.
Dave West 6:29
And from what I observed, where from talking to prior to the webinar, I interviewed a number of organizations and and I was also fortunate to have a colleague who had who has rolled out the product model in a few places, a Darryl Fernandez and the financial services sector. And I talked to those organizations and and learned quite a lot. And one of the things that I realized was incentives are not like just because the in the example you used, the team is measured on numbers of bugs, doesn't necessarily mean that every single person is aligned to that incentive in quite the same way that you would expect, meaning that individuals build their own things that motivate them and things that don't. And some of them are tangible. That's a great example of a very tangible incentive. There's, you know, every week we talk about this number, and every week it, you know, we measure on that, numbers of bugs open, numbers of bugs closed. And, you know, there's, there's those very tangible and very intangible things as well, like power, position, authority. Because one of the things that I heard a number of times on my discussions, and I'd love your perspective on it, was this, this idea of cross functional teaming was sort of like a direct opposite hole to the incentives for individuals to become the go to people to become the everybody goes today for x or, you know, to have that ability, that that sort of positional authority in the organization. It sort of undermined their desire to help other people become skilled in a particular thing. Have you seen that as well? Dimitri,
Dimitris Dimitrelos 8:31
yes, yes, absolutely. The thing is, the way you balance the team versus the individual incentives may again influence behaviors. So if, if we were an organization where out of the 100% let's say, of a person's evaluation, 80% was based on individual performance, and only 20% was based on the team performance, what you do it this way is you. You encourage individualism, you encourage hero behaviors, right? So I will save the team. I will do and I will make sure my personal, my individual work, is known across the people that should be no. One of the first things we did in this organization, even before we completely rolled out the product operating model, was try to reverse the relationship between these two, these two areas. So not not directly at first, but at least we got at 5050, so 50% was based of a person's performance, was based on the individual contribution, and 50% was based on the team, with the intention of completely reversing it. 20% individual, 80% of. In. And what this created is a change of behavior. Now you are really interested, if you're a team member, you're really interested in your team performance. And what happens is you start to look beyond your role, right? Because you know that your individual performance is not good enough. The team, the product you're building has to succeed, and therefore you start challenging other people. It was we had cases where the product owner was challenged by the engineers, the developers, on the things that she brought in to build right because the engineers did not believe it was the right thing to do. And it was this was a healthy tension in the team, because it, you know, it forced the product owner to rethink if these were the right things to do so, putting in a lot of a big percentage of Team objectives and putting in in the performance management a big percentage of focusing on the team results, makes the individual go beyond the role, makes the individual focus on team performance, on Team issues, on collaboration issues, and not just on their individual performance, yeah,
Dave West 11:23
and that's very consistent with what Darryl talked about in a you know, it took them quite a while at, I don't, he can't say what the company is, but you just look at his resume, and I think you could work it out. But it took them a while to adopt that approach and a lot of experimentation around it, but so is it at the end of the day? Is it all about if you have a money, and is it if you have incentives that are, like a bonus, for instance, that's directly connected to some financial outcome, which is, in the case of most financial organizations, they have this bonus that runs, usually in the US, in February, January, February, you get it and it's and it's it. Ultimately, there's a the number comes from a big pool, and then the sort of like the the multiplier or the Subtractor is determined by the thing. But, yeah, that is it all about. That is, is that the I mean, there are other incentives, these less tangible ones, but at the end of the day, does money always win?
Dimitris Dimitrelos 12:33
Every time I'm doing a class, I ask this question, what motivates people, right? What creates the urge to get up in the morning and go to work with a smile on your face. And the instinctive replies I get at first is money, but if you start to think about it and dig into it, the truth is much more complex. So I'm a big fan of Herzberg theory. Let's call the hygiene factors. And what this theory says is that there are certain things that demotivate you, that create dissatisfaction, right? And there are other things that motivate and what's what is strange and interesting is that the things that motivate you are not the exact opposite of the things that demotivate. For example, having a lack of job security, seeing people fire, getting fired around you is a very big source of dissatisfaction, right? Yeah. So if you are in this environment, then you are completely demotivated. But if you take it to the other extreme, so if you provide to someone job security for life, does it mean he will be very motivated? No, he will just be satisfied. The same goes with working conditions, right? The same goes with micromanagement. So if you if you have a manager over your head, looking at everything you do, you will be extremely demotivated, right? But if you have a manager that is good, that is not enough, you will not be motivated. So it turns out that there are different things that demotivate you, not many things that motivate, yeah, and the funny thing is that money is all the things that demotivate you in what sense, if you don't have enough money to have a healthy, a healthy living, to support your family, to have, you know, an average living status, right then you will be completely demotivated, no matter how awards of employee of the month you get, no matter how autonomy you get, or how many mastery or how aligned you. Are to the vision. If you're not paid enough to support your family, then you will be demotivated. Now, yes, if you your salary, it's a point where you're paid enough to make a healthy living, then doubling your salary will not motivate you, and it's actually proven that a pay rise has a very limited effect on the productivity increase that lasts a few months at maximum, then your productivity and your motivation as well, drops to the previous level. So money, lack of money is a dissatisfaction factor, but not the abundance of money. Is not a motivation factor, as Daniel Pink very well put it, you should pay your employees enough to get the money think of the table so they you should pay them enough so that they think about the work and not about the lack of money.
Dave West 16:04
So would you disencourage? Discourage? Disencourage organizations? I'm sure discourages a word. But would you just stop organizations having bonuses? Because it's a really nice way of of paying people and keeping the the big wigs happy, because it's not, you know, you've not committed to it. It's going to be based on company performance or or whatever. So it's from a from a leadership point of view. A bonus is a really nice way of of giving money to people that won't come and necessarily work for you because the your salary is not enough. And it's a really nice way of packaging that so that the management above you accept that, you know, it's a variable, right? So they're like, Oh, well, if we don't do well, then we're not going to pay this. So it's, it's, I must admit, I have been incentivized to bring bonuses in. But would you discourage bonuses? And I know this is sort of broader than a palm,
Dimitris Dimitrelos 17:13
but in general, I wouldn't. I would just keep them in balance with other motivation factors. So if you pay decent salaries, right then autonomy, purpose, so vision, so status, so recognition of the people, self fulfillment, stuff you know that are on the top of Maslow Pyramid, of Maslow's pyramid, then this works very well. Of course, you should combine it with some bonuses, but not we should not, for a moment, believe that giving people money will substitute the the other things that are really important for a motivated, autonomous worker. So autonomy, purpose, mastery, that are really important now, on the top of the pyramid on sea level, then, you know money, seems to me, is not really about money. So getting money in a C level position is probably more about the recognition of your work than the money itself. Right? You already, you already, you probably, if you are in a big company, you have a sea level position, you have already more than enough to support your mother, your families, more than enough to support a luxurious way of living. But the bonus are more, I think, a recognition of your efforts. So again, it's a sentimental thing, not a money thing.
Dave West 19:05
Just for the record, if Ken scruber, who's my boss, is listening today, completely ignore anything Dimitri is saying at the moment, I'm here for the money, total total money. Actually, hate to say it, and I certainly hope Ken's not listening now, but you're exactly right. It's about prestige, status. It's about, you know, the authority. It's about being able to say, I run this group or this company. In my case, this this organization, and we've grown to 360 trainers where we get 1.5 million. And I know they're vanity metrics, but it makes me feel like I'm my organization is having an impact, and people are talking about it and and that is very, very, very motivating, and gets me a. Every day, the sort of the mission, and connecting that mission, I think, is important before we Yeah, so I come 100% agree with money, though. I think it's in I think different cultures have different perspectives on money, a little bit and and so I think this just you have to look at it very holistically and be very cognizant that different individuals are on different stages of their life and also have different commitments and and so money is a complicated thing, a lot more complicated, but I want to talk about the other side, which is this sort of more, this promotions and positions. You know, everybody's a VP and a bank in the US. You know, Janet is a VP because status is, is really, really important. And status can also lead to, you know that challenge that we talked about with cross functional teams, you know that ultimately I want to be the bottleneck, I want to be the hero. And I personally have had challenges in my organizations I've worked in when some of the best software engineers in the world, mean some of these people are famous, literally famous, but that fame, they were a bit like scientists. You know, they were always the first name on the scientific paper. They didn't really want to transfer those skills. And I've, I've spent a lot of time wrestling with this. So what about that, that sort of promotion status stuff? How do you align that to some of the needs of a palm, which is cross functional teams? Really
Dimitris Dimitrelos 21:49
well, there are always cases, such as the ones you mentioned that of people that ultimately want to work more or less alone. They value very much individual contribution. They consider themselves and might be very well experts in the field. They want to build their own knowledge. They want to, you know, become number one in their field. And they don't like working a lot with other people. And in this it's not, it's not a lot of people, but we do, we do get some of these in software development right? Yes, these people. It would not be wise to put them in a cross functional product team. We might find other areas in the organization where these people can contribute more. But the majority is not like this. The majority are people who are inspired by vision. The majority are people who care about the impact of the work. The majority are people that really like looking left and right beyond their narrow area of specialization. And they like learning new things. They like influencing the outcomes. And when they see an ad on TV about the product, about the product they built, they feel a bit proud about it. So when, when switching to product operating models, I think the companies should take a very good look at their incentive system, at their performance management system, and they should definitely spend some time on this. So what do you measure? Is very important. Here we have the difference between outputs and outcomes. The bug story shows where measuring outputs can lead. Right. Who is your measurement focused on, do you measure mostly individual performance or team performance? Who is doing the measurement? So who is doing the performance evaluation of a person? Is it just one person, the functional manager, or do you, do you take into account other people that are working with their person. So if this person is working in Agile team, does the scrum master have a say about this person's attitude performance in the team, right? Does the product owner have a saying? Or some organizations have taken this further, and they're doing crowd source evaluation, so a big percentage of your overall evaluation comes from everyone you're working with. Yeah, yeah, so, and also one. What on what level do you measure? On what abstraction level do you measure? Do you measure the very detailed, specific things that the team is working on, or do you measure the overall product or company performance? Both have, you know advantages and disadvantages. If you measure very on very detailed level, if you measure on on on 30 feet, on the height of 30 feet, then probably the team you have, you run the risk of the team focusing on just the target, the numbers, right, and forgetting about the overall goal. On the other hand, if you measure too high, if you have 30 teams working on a product, and you only reward them when the product is doing well, that means that the level of influence each of these individual team has on the overall product is probably limited, so you need to stand somewhere in the middle. You need to make sure that the teams are rewarded based on a generic on generic performance measures that cannot be handled by the team, right? The teams cannot cheat, but at the same time, it has to be something that the team can really influence with their work. So they they feel they're working for something, and they see the numbers moving when they're doing a good job. Yeah, it is. I think that
Dave West 26:43
the thing I think that looking at it holistically, which is exactly what you described mutually, was, is super important, which sort of brings me to ownership. And how do you as a change agent influence these things. Because, let's be honest, you know, you're working at Bank of America, or you're you're working maybe on a really important product, but you're in a machine in terms of how you paid, how you promote it, how you which is fair. You know, it's an incredibly successful institution that's doing amazing things. However, you're a very small cog in a system that's incredibly complicated. It. I remember when I worked at IBM, so we were bought, we're a Rational Software and bought by IBM. When I was at rational I had a really clear line of sight to my bonus and to my stock grants and to my promotions, and I knew exactly how to get and then IBM took over. And then lovely, you know, so waved goodbye to free soda and and took this wave goodbye to Outlook as well, and we had Lotus Notes for a while, which was not a pleasant experience, but the the it was, it was, it was impossible. I would get random numbers sent to me in terms of my bonus. And I used to ask my boss, and he'd say, no idea. Dave, sorry, absolutely no idea we even got HR involved once, and they were like, Yeah, well, it's complicated. They didn't really know either. So if you're working in these sort of situations, in these big institutions, what can you do? Who? How do you drive change? And the incentive program isn't aligned, particularly, what do you do in those situations? Do you what would you be your recommendation?
Dimitris Dimitrelos 28:47
First of all, I completely agree, when you're in a smaller company with a with a startup mentality, then the company is usually much more open about these things, much more transparent, and people you know, they know the salaries around them, and they understand the bonus system, they understand the reward system. And it's easier for everyone. When a company scales, it's much more difficult to maintain this level of transparency, or if the company adopts a more corporate mentality and moves away from startup, as usually happens when you scale, right? Yeah. So a way that some companies deal with it is they create they provide more autonomy to the new product units that are created by applying the product operating model that that takes a lot of of of change, and I have to admit that we don't see it a lot in. In in more conservative organizations like like banks, right financial institutions, but the companies that have done this, they seem to have been able to create a new level of transparency that comes, of course, with challenges. That means that if you're working in a certain product unit, you might get paid different for doing the dream the same job than being in a different unit, right? You might get rewarded differently, but it's a bet that organizational autonomy works better for complex situations such as the reward and performance management system. On the other side, if the organization is not willing to provide this autonomy, and to be honest, most of organizations are not, then what you need to do is create, include this, this area in your transformation program. You cannot leave this just to HR, and this is one of the pitfalls that we see in some of the organizational changes that we're doing. So okay, conversation. Whenever the conversation, incentive discussion comes up, some will say, this is HR thing. We should not touch it, right? But it doesn't work like this. Of course, HR should be involved. Of course HR should lead the discussion, but everyone should be involved. And there are many reasons for this. Reward system for technology people is pretty different from the reward system for business people or for sales people, right? Sales people incentives are really, really crucial. So if you're if you're creating cross functional teams, how including all these three areas? How do you combine them and create team objectives? Right? It's not hard, and it's not something that any one area can do by themselves. So it's really important, as with every big transformation effort, to have a lot of to have the important opinions in the room, to have cross functional team that will drive the change, that will create guidelines while providing some autonomy in the teams and the product units. One example I have is the one I mentioned before. So there was a company decision to switch the 2080 rule. So 20% team performance, 80% 80% individual performance, to a 5050, and then later to a 2080, and that was, that was a company wide decision that had a very positive, positive influence on the rhythm of the speed of the change. Yeah,
Dave West 33:19
I it, I think your guidance around, including HR, including business management, including, you know, sort of like technical management, I think including those groups and making them part of the change is, is crucial. I also think another thing that I've seen, and I'd love your perspective on it, and I could talk for for hours on this with you, but is that one of the as a Scrum Master, I if I was in that role, and oh my gosh, you really don't want me as your scrum master, but, but if I was in that role, thing I heard from listening to other Scrum Masters is I would try to, not necessarily make things transparent for the team, but at least transparent for me, understand
Dimitris Dimitrelos 34:12
why people What? What? What
Dave West 34:17
the rub, the incentive rub is going against them and making them do silly things. When it does make them do silly things. Because, you know, looking at that, and I'm being using incentive in a very broad way now, but looking at the things sort of into almost interchanging it with motivation which is which is incorrect, I know, but, but ultimately, they're very tightly coupled, but by understanding how the dynamics of your team and the motivators and the and how incentives play and and I your point about hygiene factors, you know, there's you can have things that you think, Oh, we'll get, let's increase everybody's salary. It it won't actually motivate people. So it'll make people happy for a bit, but it doesn't actually ultimately change behavior. But if you reduce people's salaries, that really does change people's behavior. So I'm trying to understand that, and as a scrum master, trying to at least get a visual, trying to put something together in your head around that, I think is is is crucial, because then you might have had to change it, but at least you could understand it. And some of it is just reframing. Can really help helping somebody who thinks that that isn't you know that they need to be the hero. Well, actually, you don't, and these are the reasons why, and this is how this will help your career even more than being a hero, you know? And I think, I think it's, I think there's that element as well, when you're in an organization where, yes, you're trying to influence change on this sort of, like broad winning coalition of HR, business leadership, technical leadership, etc, but actually, on the day to day, is, is having that understanding and that transparency? It's super important, right?
Dimitris Dimitrelos 36:11
Absolutely, absolutely. I remember a time when there was one of the teams I was coaching had this, this person that had the hero mentality? What it turned out, after a few sessions with a with a scrum master, after a few one on ones, is that what this person craved for was recognition from the team and the teams around them. So when we installed the system, a kudos system, that a very easy thing on Slack, that someone just, you know, say thank you to anyone, this person would consistently show up on the top of the list of people getting the most kudos, and he was really happy with that, and he he channeled his energy into helping others so he could get more kudos. And that's a perfectly healthy behavior, right? Yeah, instead of trying to do everything by yourself, channeling your expertise and your knowledge into helping others. Yeah,
Dave West 37:24
and that could have been blown up horribly if you know, 80% of his salary was to become a hero, you know. So I get it. That's the reason why it's holistic. Dimitri, thank you so much for spending the time today talking about this. It's super, super interesting. All right, we're coming to the end. So what's the one thing you want to share with our audience? What's the one like if you do nothing else after this podcast you should do? What would be that one thing do you think? And I know I put you on the spot a little bit, but what would be that one thing,
Dimitris Dimitrelos 38:05
I would say that you cannot have a well functioning product, operating model. You cannot, you cannot have a good, successful journey towards autonomy and product teams, if you do not take into account into account the way people are getting their goals set or set their goals, if you do not take into account the way the people are incentivized and get rewarded for their performance. It's really crucial. Some organizations think this is, you know, HR stuff, and they shouldn't be. They shouldn't get involved with this. But we've seen that a lot of behaviors, a lot of resistance to any change that organization might want to go through, comes from these areas. So if you do not incentivize a software engineer to have a really stake, a real stake, on the success of the product, then they will only care about the quality of the code and nothing more. So just a closing remark is a suggestion and advice to organizations thinking about transitioning to product operating model. It's not only about organizational design, it's also about performance management. 100% I
Dave West 39:55
100% agree that was the reason why, I mean from CO. Conversations like you and I have had in the past, and from the conversations of organizations doing a palm, that was the message I heard over and over again. You can implement a palm, one product in a sort of pilot environment without thinking about these things, because you pick the people that don't necessarily care. They're like the crazies. But if you want to scale it and you want to actually drive long term systemic improvement and product alignment and ultimately value, you are not going to go anywhere if you don't think about performance management. Absolutely, the teams so
Dimitris Dimitrelos 40:42
Dimitri, thank you.
Dave West 40:45
Thank you for spending the time today. I really enjoyed it. I'm sure our listeners did, and thank you for listening listeners to today's scrum.org, community podcast. We heard the lovely Dimitri Demetrios, PST and business agility lead for Accenture in the fantastic country, Greece, which all of us would love to visit now revisiting now, talk a little bit about incentives and his experiences, and the message, he said was, they're there. Worry about them. Think holistically. Think about how performance management and HR systems like that can undermine any change initiative. Be careful when you're dealing with human beings, and each of them is different, and ultimately things incentives can undermine and demotivate more so than perhaps they can motivate, which is always worrying as well. If you liked what you heard today, please subscribe, share with friends, and of course, come back, listen to some more. I'm lucky enough to have a variety of guests talking about everything in the area of professional Scrum, product thinking and of course, agile. Thank you, everybody and Scrum on you.
Transcribed by https://otter.ai