Shoaib Ahmed was our special guest.
His Twitter: @prince2msp
His LinkedIn.
Transcript
[Yegor] Everybody hello, this is Shift-M podcast episode 33 with a special guest Shoaib Ahmed. Let me give the microphone to him and ask him to introduce himself.
[Shoaib] Hello. I’m Shoaib Ahmed, I’m the practice manager at Eagle Technology Group in New Zealand. I’m based at Wellington looking after our regional services business. It’s a multidisciplinary IT team, it comprises service delivery managers, project managers, active software engineers and a whole bunch of others working on a special niche industry. Other than that let’s get the talk going and if there is more interest we’ll talk more about myself but I’m sure we’ll talk more about the topic itself.
[Yegor] Sure. So you’re like practically working in IT projects or you consult them?
[Shoaib] It’s a bit of both. So I have some in the team that do consulting work which is more working with the customer advising them, but I have others in the team that actually will implement IT projects themselves.
[Yegor] Okay, that’s great, because the topic for discussion today is metrics, if you don’t mind, that’s the very interesting problem, we haven’t had a chance to discuss it so far in previous podcasts. But in my experience they really matter, but in the industry I quite often hear the opinion that metrics don’t really matter, that we don’t need to collect numbers, that something else is more important, so what’s your take on that? Do we need numbers or not? [Shoaib] I think there’s a bit of truth to both, projects by nature are risky business. So if it wasn’t risky and people wouldn’t actually be running projects right. So there is a need to collate and communicate what the risk is and how you address risk and all of that and there needs to be a common language for people to deal and have that conversation. So for that metrics are very useful. What sometimes isn’t so useful is just doing metrics for the sake of it because somebody else is running some sort of metric and we’re doing the same. That doesn’t really serve any purpose at all. The other area is probably… in some areas metrics can’t actually give you an appropriate number anyway. For example what’s the label or our motivation and how stressed people are and all those kind of things. You can’t really have metrics around that. So some of the metrics will tell you a good story. Other metrics will certainly tell you wrong things. So you have to run by metrics but also you have to have other methods that can actually tell you the full story.
[Yegor] But in your projects, in the last, probably in the recent projects have been worked in, did you collect metrics? Did you manage by numbers or not? And if you did then for example what kind of metrics did you use? [Shoaib] So there are two approaches that we size. For example I’ll give a very quick outline of what the professional services business looks like. So we have long sales cycle, so we don’t actually have a product as such. So it is more consulting project than activity. Sales cycle is quite long. The way that we would make more money or less money is by having people busy, right? So that’s the any way for us to make money. So utilization is effective for us people are more utilized - we are more profitable, they are less utilized - we are less profitable. So that’s what metrics is as we look towards that. And in order to achieve the most utilization, what we try to do is to have what we call annuity revenue which kind of gives us revenue every month VSS extra project group which can be variable depending on the sales cycle. So those are the two main categories of metrics that we try and capture is how much of our business is in measure, that’s guaranteeing review every month. This is how much can be variable, which you’re going to sell this month. So those are the two main categories of metrics that we run.
[Yegor] But you don’t measure how effectively those people are utilizing, you just measure the amount of time they spend, but you don’t know what exactly they do inside those time frames.
[Shoaib] We do, well, some of the metrics will tell that story, others probably won’t, the kind of metric that are difficult to maintains for example where you have a fixed price, where at least if it is any better compared to more. Whereas utilization is sometimes more effective if people out down metrics to be rewarded. So trying to come up with metrics that tell stories across different contracting charts sometimes can be difficult. So we do try both ways but I wouldn’t necessarily say we are successful in getting the full story on the way.
[Yegor] And do you see any problems with the people who are being used as the source for the metrics collection process or it’s…
[Shoaib] The most common challenges always people logging the autonomy in the correct manner, so big if the discipline gets harder and harder to get right. And you have to be consistent. The other challenge we find is we try to daily interest people working with you on. So we are actually running as close to real time for decision making and making choices in terms of we are to focus and we are not to focus. But that seems to be human nature sometimes gets in the way it is. It is quite challenging.
[Yegor] And how do you deal with that, with those challenges. So if people, because in my experience, I’ve seen it a few times, many times actually in my projects, that when you start collecting metrics, when you start asking people what were you doing or what’s the progress, you know how far you are and all different sides of information, they sometimes resist and say that we are not robots, we’re not know cogs in a big engine, we’re not supposed to be measured like machines. It’s more complicated process, so just stop collecting metrics. That’s what I’ve seen
[Shoaib] Yeah. I think there are some challenges in terms of how you measure how much work have you done or how far through the work you are. Especially something like software development item where you could have a problem you could be coming for the whole time up to the same effect. When what you’ve done is half of the work and you had one problem and then for days you’ve actually not been in progress. So, for a project manager that might not have come from an IT background that seems very incongruous as to how could you make such quick progress and then suddenly no progress for periods of time so it is more sort of getting that understanding to not just the technical stuff but also the people that are actually asking the metrics to be collected. So for example we tend to try and hire project managers and service delivery managers that come from the IT background, so I used to be a software developer long time ago. So a lot of that we try and convince them it is all the betterment in terms of whether we need more resources, less resources or people who get stressed if there isn’t enough resources, so we have and we use this as a metric to say how many [inaudible voice] should we have for the period of work and the amount of work that we have done. So we try and sell off on the fact that there is actually some outcome for the area as well. That seems to work actually, not always.
[Yegor] So you’re saying that, if I understood it right, so you’re saying that we have to somehow demonstrate to people the benefit of being measured somehow. And that’s how we buy their interests.
[Shoaib] Yeah. Ultimately people like that, so it doesn’t really matter who you’re addressing, whether it’s the executives or is it a VP of products or services or the IT staff themselves and so that those things that are of their own benefit. So as long as you can show some benefit to the people that you want something to improve, I think they are more likely to indulge and try and accommodate.
[Yegor] And very often, again another problem I’ve been facing is that it’s really hard to make metrics accurate when we are talking about, you know, metrics coming from people and they complain - teams and developers, programmers, they complain about that inaccuracy and they say that it’s better to not have any metrics. Instead of having metrics which give you false information.
[Shoaib] I think that’s always going to be the challenge. What we try to do is we try to have very few categories that you can choose from. So we will record the project people are working on the top of activity which will be typically be on the two or three different options. So the more options you give, the more there is room for interpretation and it doesn’t issue to lead to an accurate analysis. So what we’re finding is it true to measure in cost areas rather than try to be very specific because at that point sometimes was I doing analysis or was I doing troubleshooting, was I doing this or was I doing that, it becomes too hard to kind of get in accurately and a team of 40 people people who analyze it differently and you get a different result. So we have some, say it’s phases of projects and we just get people to log those phases. So log pre-sales, analysis, design, implementation and price projects. So we tried to limit to those options. I know probably later on we’ll see if we can make a little bit more granular than that. But at this stage we’re not actually trying to capture to the Nth degree.
[Yegor] Interesting. And as a programmer in the past, you said you were a programmer. Do you think it’s possible to measure the performance of a programmer in some numbers? [Shoaib] No, I don’t think so. I think what you can measure is you can measure your overall organization or your overall team because there is some level of normality across a larger team and that’s any developer could be 4-5 up to 10 times more productive than another developer who’s just an average developer and the output that you get from one to another could be extremely different. So I don’t think metrics are necessarily good, you give results of individual measurements. It’s a bit of measurement of that team as a whole as opposed to individuals because any metrics are usually defined or designed to conform to the normal curve and people that really scale always fall out of no curve and you don’t really want to be measuring those against that you know pretty well.
[Yegor] But if we don’t measure that, how we do we know who is a good programmer and who’s a bad programmer?
[Shoaib] So I tend to not utilize the metrics to measure the individual people because it’s into difficulty with the actual asset in terms of the output that you get from someone it’s like saying developer what he can build that in five hours, a normal developer may take 20 hours. Was it far more valuable to me than those 20 hours? It’s debatable. So rather than that what I tend to say is overall the team as a whole, how much work are they doing across the total effort that they’re putting in and how much of that is productive. So that’s what I’m looking at instead of trying to measure individuals using metrics, I found that to be very hard and not very productive actually.
[Yegor] It’s not very productive because it’s offensive or because it’s inaccurate? So what is the real problem why it’s not productive? What do you think?
[Shoaib] It doesn’t get the full story. It’s basically the situation. So the example of the really outstanding developer working part is somebody else with intermediaries and the productivity is totally different. You probably get the same outcome out of that. So how do you for a range of abilities come up with a trait, it distinguishes for each individual scenario. Metrics as a whole are designed to look across to what are the individuals doing. That’s what I find magicks don’t do very well.
[Yegor] Yeah but if we don’t give the full picture like I said which I totally agree that with just one metric we cannot completely describe the quality of a programmer. But isn’t it better to at least give a part of the picture instead of giving no picture at all?
[Shoaib] Now we tend to give some pictures. It’s very difficult to describe visibly. So we do have utilization targets for some of the senior consultants and programmers, same with junior programmers.. And the reason we’re trying to do that is for example the senior guys we want to be mentoring some of the intermediate opportunity stuff so we don’t want them to be getting fully chargeable work all the time because for a team as a whole it is more beneficial for a senior guy to spend maybe half a day with three intermediate programmers and all three of them kind of improving it is far more efficient than the senior guy might be developing for another few hours of the chargeable work. So with that in mind what we try to measure is how much time are they getting to mentor, how much time they’re actually using what they heard in mentorships, because these metrics that give those guys huge job satisfaction and that tends to work out quite well because they’re in a team since some of the other guys coming across and improving to be output as well. So while we’re not necessarily saying that you produce 20 twenty hours and you got us x amount of dollars, we are measuring other things, for example how many hours of mentoring did you do. Because that’s a key output that we need from some of the guys. So our team as a whole kind of improves. So they might say some metrics they do [inaudible voice]
[Yegor] So it looks like if I’m a developer and I joined the team I will have the numbers in front of me saying that good developers and this team, they spend let’s say 10 hours a month for mentoring and I realize for myself that if I spent 10 hours and I’ll be put on the good developers board.
[Shoaib] Yeah, and not only that. So this is the senior developers, all the outstanding developers. It is a silly expectation that they do spend that amount of time because with technical stuff sometimes what happens is guy is really taking the profession. Sometimes they aren’t as good necessarily trying to bring people up to this standard, they enjoy solving difficult problems and they don’t necessarily enjoy the interaction with others to try and pass on that knowledge. So this is more of a setting and expectation from management to the team as a whole and behavior that we want to say “Yes it’s great that you did top”, utilize targets, but for the various roles we actually have some indication that you can actually contribute in different ways rather than just a number of how many dollars you bring.
[Yegor] I’m just trying to understand, is it a good thing that we don’t have these metrics and we don’t measure because we can give the full picture, or it’s a problem for us and we just cannot solve it. And that’s why we don’t give the full picture. So what’s your take on that?. Do we need to work on your team for example? Does it need to work on finding the way to actually collect the metrics and give people the full picture. Or you just say that it’s not possible and we don’t want to do that. We want to keep people in this not in the dark but without the footage.
[Shoaib] So I can’t tell that for every organization, but our organization for example. I think the amount of effort it will take to establish the full story is probably not going to reward us all the outcomes that we want from the team. So one of the papers of the metrics is to measure, the other papers of the metrics is to drive the behavior and what drives it. We want to drive some behavior so we will share those kinds of metrics. For example how much collaboration is happening across teams, how much time are they with us or teams, how much the others should make those kinds of metrics we all share. We will also share with them in terms of what their actual or billable or utilization metrics were, in terms of making a judgment of… So your result is 80 out of 100 individual scoring, we teach to not do, because that I feel that we haven’t quite got to that stage. We might or might not as we make these improvements but at this stage I see us so far away from solving that, we’re trying to come up with a ranking system that will tell us more in the future.
[Yegor] I agree because you know what I’ve been experiencing in many situations is that people, especially senior developers who are really ambitious and trying to be professional, they don’t want to see themselves not ranked at all, they do work for recognition a lot. They only work for money. They work for respect. They work for appreciation. They need to see they want to see themselves as being the best developers of the team. So when the team tells them that you know guys, we’re all equal here, we’re all the same, you and this guy who just joined us three days ago. We’re all the same we’re getting the same appreciation. I think that senior people will not like that, they will try to quit.
[Shoaib] I agree. So basically there is a cost to the senior developer always wanting to work on technical items and not sharing their knowledge with the team. There’s a huge post to that. Let’s say the developer moves on and chooses to go somewhere else, he leaves a huge amount of intellectual property with that one [inaudible voice]. So the behaviour that we are trying to drive is that the recognition comes from the fact that we are actually asking surely to be ranked as the God that does the most amount of work or the most amount of whatever that takes you to the recognition. The recognition in fact is more how much can you bring others through and how does your mentor, how you improve. I agree that that’s a key part of the metrics, that we share with them, how much are they contributing, it’s when that actually becomes kind of a.. you can have like all tribes of people that are competing against each other to give it up as opposed to just one person being the outstanding one. We’re trying to kind of drive back a couple in that sense. So it’s been a bit of a trial. We’ve been running that for about seven-eight months. I think the team as a whole is in benefit, but well, we’re probably not doing exactly what you’re saying. And so having individuals showing that I individually show this. We do measure that, but we don’t have something to share with.
[Yegor] So you do have this information for the management player, but you don’t make it visible for the entire team, right? Because you know I’ve heard stories about software companies, I think a year ago or so, some of them were saying that they made even the salaries of programmers publicly visible, not only for the people inside the team, but also for everybody in the market. So you just know if you’re a programmer, you just joined the team and you know exactly how much who’s getting and you know the reason for that, that person is maybe working here for three years that’s why the salary is 20 percent higher than mine and this one knows like three languages programming languages instead of comparing to me knowing just one. And that’s why she’s getting 20 percent more and sort of that. So what do you think about that approach making completely visible the entire situation to encourage people to grow?
[Shoaib] Yeah. In New Zealand, we have a charge with some of the employment laws, sharing people’s salaries for a public knowledge, other than specific rules, for example executor’s. And you know it’s pretty bit about law. But what the teams will know is the salary [inaudible voice]. So no. Now that will be, for example, each of the bank will be somewhere around the difference of the Continuum 3000, and they are roughly aware of where others are based and their job title. And as people will know that their salary will be between x and y but they will certainly know exactly what was wrong.
[Yegor] You’re staying a bit far from the microphone, can you please move back. Now it sounds better. Yeah, I also have the same feeling actually because it’s making this completely public salaries may create more negative things than positive. So maybe that’s a little bit too far. But like I said you know the senior guys you know programmers are always interested to be recognized and maybe junior people may actually want to become senior and they know exactly what it gives to them, and they know exactly what’s not.
[Shoaib] I agree in terms of publishing everyone’s individual salary. I think that creates more problems and so that’s my point of view. But for consistency people do want to be recognized. And so the labels do reflect salary band associated with it so that is probably as close to knowing what others get paid, we can come to within the legal framework and also kind of without creating more trouble than it’s worth.
[Yegor] You know in one project I was working and we were discussing our progress on these you know daily meetups again in terms of numbers. So our project manager, I guess it was Scrum master, I don’t remember, that person was actually presenting some numbers to us like every day literally and showing how far we are. And there was in my experience, that was quite helpful because we knew that there is some timeline and the timeline we know exactly what the position is. And it was productive. But that person always complained that it took so much time for him to collect that information, it was you know it was a complicated process, and then eventually he stopped doing that. So what do you think? What’s your take about the balance between the amount of time we spend on collecting metrics and the benefits we’re getting from them?
[Shoaib] There is different benefits to collecting metrics because the last thing you want to do is run blind. And the team itself would want to know whether they actually make progress, if progress isn’t missing. They can review if necessary move to a different approach or whatever is necessary. The key here is a lot of people seem to do it manually but there are plenty of tools out there depending on how you run your teams to the tools that will make life a lot easier and a lot of these will integrate with very CRM systems and different management systems and all those kinds of things. So if people put in the effort to actually find the right kind of tools for that particular way that they would wish to run their projects. A lot of the effort in terms of getting the metrics. A lot of people have the same problems and lot of people have some sort of solution to that, it’s just a matter of finding the right solution for the kind of why one would want to run the projects. There are plenty of solutions out there and just the key is to pick the right one for that particular team.
[Yegor] Yeah I agree. And do you know what’s the term called KPI? Like key performance indicators, which people are using to manage and I’ve heard the term called management by objectives. I think it’s related to this. So when people know exactly what is expected, what numbers were expecting to gain, to achieve, and then they just go for it and they get some recognition, some reward when they achieve that. So what do you think about this approach? Is it a good idea?
[Shoaib] My personal finding is key performance indicators that indicate individual achievements drives one kind of behavior and key performance indicators that focus on the same outcome as a whole. That drives a slightly different kind of behavior. So I think KPIs are an excellent way to recognize and basically part of for example an Arrow organization, their salary contains salary part of it and the bonus part which is actually based on group performance. So, and we have some KPI in terms of percentage contribution, profitability and a few other things. So as long as the KPI is because KPI will drive people’s individual behavior, because people want to achieve inherently, as long as they KPI are actually focusing on a team target it is actually quite a valuable way to reward teams. But people will naturally compete. So the organization’s goal is not to necessarily have individual teams compete, but the overall organization to make the most benefit. As long as the KPI are directed towards that I think it’s pretty good.
[Yegor] And you think that the competition inside the organization is bad thing?
[Shoaib] Competition when only one individual is competing against everybody that’s a bad thing. But probably the teams within themselves to compete is not necessarily as bad, well slightly doesn’t necessarily equate but I’ve found this through personal experience, I’ve found that we are rewarding only individuals. That becomes difficult working situation.
[Yegor] Let me get an example: in one team I was a few years ago I was suggesting this model which was never accepted but the model was sounded like that - we collect metrics about individual somehow we measure for example the amount of contribution, you made the amount of features you introduced the amount of what you fixed. There are some numbers. And then by the end of the month we would draw a list of people of everybody in the team and we have numbers in front of each of them, and we know who is the best or who’s the worst, and then by the result of these so-called competition we increased the salary of the best person and we fired the least productive person. So what do you think about that approach? A little bit extreme but it is fair right. I mean why do we need to keep the least performing person in the team and why can’t we reward the best one?
[Shoaib] I feel that way what you get into a situation with really difficult problems. Anyone that has a solution is going to keep it to themselves. Where is the behavior that you want to share the share the actual knowledge or learning gain. So competing against teams is basically, I find from personal experience having that model, getting better results than individuals necessarily competing against each other, because they will compete with their own immediate people as well as they may compete against the other developer and hiding knowledge from them. The some of the team is actually at least half the individuals competing against each other within the team.
[Yegor] That only will happen if it will be possible to hide that knowledge, right? So if we if we somehow organize the work so that the people will have their individual tasks or their individual job pieces which they need to do, then they don’t need to. Well, of course you will say that everybody needs to share some knowledge, right, and we need to have an answer information. But still if we if it’s possible to somehow organize the work of the team that everybody’s working on their individual piece all the time, then we can potentially measure the overall result of every single programmer, and we somehow can say who is the good one who’s the bad one.
[Shoaib] But I find that that is not actually in theory that might be doable, but I find that in practice you can’t really isolate tasks enough, and less experienced people will listen to more experienced people. But you can’t hire everybody at some level. And the reality is you have a workforce or a set of developers that are at various levels of experience and expertise. But I have talent to go far beyond what the current progress is. The companies that will make real progress or who do better. How how you bring those people across to and how fast you bring those people to more knowledge and better outcomes. So with that in mind, if people are trying to compete just individually, in my experience I’ve not seen as good a result. I’ve worked in those sort of organizations with the most for example support tickets that you closed got some sort of recognition, but people go looking for the easiest tickets to solve, because complexity isn’t necessarily as easy to measure. But you don’t necessarily want everybody trying for the easiest ticket, you want the people to be looking to solve the more challenging problems. So individual behaviors get driven differently. If you reward any individual success.
[Yegor] I totally agree with that about the complexity you mentioned. Absolutely. It’s difficult or sometimes maybe even impossible to make those work pieces equally or fairly measured before they go to people. But my point and my question is maybe it’s not impossible at all. I mean maybe it’s not impossible. Absolutely. Maybe it is possible, it was just a problem of our teams, of our managers, that they cannot organize the work of the team, the structure of the team, so that the metrics war, so that it’s possible to actually you know to discharge the least performing person fairly. And that’s why, because the management is not so strong, not so smart. That’s why the management says “You know what guys, there are no metrics, because metrics are bad. We’re not going to measure you, we’re not going to ask him, we’re not going to evaluate your results, because evaluation is bad”. But maybe in reality it’s not bad. Maybe it’s good, but we cannot do it. It’s just technically difficult for us and the management is not smart enough to do that. That’s why they say “No, no, that’s bad”. Do you think so?
[Shoaib] Even the top developers of all the top technical people that you work with, if let’s say say it’s a team of six developers to distribute a package of work between the six of them that are of equal complexity and equal amount of work. I think it is very theoretical. I don’t think it’s even possible to distribute them evenly, regardless of what kind of problem solving, so I don’t think we should try and devise metrics because the effort to try and come up with a metric isn’t necessarily going to give us reward for the effort that we spend to try and develop them. But I think there are plenty of other ways of isolating who is non-performing guy but because when people are working with others, there are different ways of isolating non-contributing members and teams of low utilization, time taken to complete tasks, all those kind of things. There are some metrics that can be used to show troublesome people.
[Yegor] Okay, the practical example. You know the team I was suggesting to use a very silly metric which is lines of code written. We all know that this is the metric which doesn’t really demonstrate the productivity of a programmer because you can write the same code with just less lines of code and there will be a better code, if you use less lines. But still if you take a team of let’s say 20 people and you measure the amount of code they contributed to the source code repository over a month, and then you draw a table of everybody and then you see the numbers then it is very likely in my experience, that the person who stays at the bottom of the table is the last is the least productive person. It is just you know it is just a fact not a fact but this is just my observation that if you contribute the least amount of code to the source code repository most likely you are the laziest guys and that guy in the team and most likely that person deserves to be all deserve some disciplinary actions. Don’t you think that it’s just you know honest observation over months of course over one day that will be silly to say that, because maybe in just just one day that person was doing something else just thinking, planning, you know drawing diagrams, being at the meetings. But if you look at the long perspective like a month maybe it’s three months of more than even three months. That person was at least contributing programmer and most likely that person deserves some penalties.
[Shoaib] So that is a shame that you are expecting everyone to do an equal amount of work. So this is an area that I talked about with some of the senior guys. I actually want them to do list work and mentor some of the other people. So in that case if I actually receive my idea while working the way I want the team to work, then some of those top guys will actually end up having least lines of code which isn’t the reality at the moment because the amount of staffing dictates that some of the top guys are actually making more charge warehouse than I’d like them to work. So metrics is suffering a little bit at demand. But in my ideal way of working those guys would actually have the least amount of code they’ve done. So I don’t necessarily think that that ship will hold water as the metric that we can use to isolate least performing individuals in the team. But there needs to be several complementary indicators that will actually oscillate in the [inaudible voice].
[Yegor] We can calibrate them then. We can calibrate them and say “You were saying that for example 10 hours a month is supposed to be spending on mentoring.” Ok, we can calibrate that and say that the one person has 160 hours a month and another one has 150. Because 10 hours we deduct for mentoring. And then we get the results of the lines of code and calibrate them by you know this degrading coefficient. Maybe that’s a solution. But still all you may say that if people know about this metric and about this measuring system they will try to create as many lines of code as they can just in order to stay away from this bottom part of the table and that will generate a more verbose and that’s why less quality code, right?
[Shoaib] I think any measurement that you’d put on drives a certain behavior. I think that people know that they get measured on, they will make sure that they put in lines of code or rather than making functions out of things, doing the same thing three times or something like that. So you need other ways of trying to claim metrics.
[Yegor] Another example which is not about programmers but about testing, we had a group of testers in one project and they were all supposed to find bugs to find problems in the code and in the product and we wanted them to find as many problems as possible. So we wanted them to actually test and break the product, and then we suggested to measure the output of those guys by the number of bugs they find. So the tester who finds the biggest amount of bugs is most likely the best tester, and the one who finds the least amount of bugs is most probably the least effective tester. And the results were in a few months of measuring, that some of them were finding 20-30 times more than others. So there was a huge difference between numbers of the best testers and the worst testers, that was my experience.
[Shoaib] I think there are definitely some metrics we can use to isolate that, intent to lines of code, I don’t actually consider that in the past specifically because of my apprehension that you know not very nice coding behavior, but it isn’t to say that that isn’t certainly a bad thing. Sometimes these can be measured by management and not necessarily shared and used this as a solent metric for management to just keep an eye on underperforming staff, I certainly see that that could be very useful.
[Yegor] And in both cases, in both of these examples they give you I had a huge resistance from the team, people were not liking those metrics at all that’s why I started this podcast with asking you about your experience with people you know resisting or welcoming the message. Because my experience is that initially when you start suggesting metrics in the team then everybody, well most of the programmers and testers and everybody, they will tell you that the negative part of this process will outweigh the positive. One of them is likely to win them the further you move, the more you progress the more accurate you metrics are, the more people start to appreciate them and like them.
[Shoaib] I have found resistance to the highest when you’re measuring individually and I have found behaviors to control the most difficult as also when you measure individually, I have found that people are far more willing to entertain and also partake and metrics, when it’s for example a team where they can feel like they’re part of a tribe, or they’re part of a team, that is competing against others or that also drives the behavior that they see one of their teammates falling behind or not putting in the right sort of behaviors, they will individually challenge them and the teams will self correct but quite often are found not to match difficulty trying to implement the tricks in team environments but intervening individually has been troublesome, and I’ve seen plenty of resistance from sites. And it’s not unusual for my experience.
[Yegor] So, if I hear it correctly, so you’re saying that it’s better to make the competition a team the team vs person to person in the organization.
[Shoaib] Yeah.
[Yegor] And in that case let’s extend my example, let’s say we have two teams of taskers and then we calculate how many bugs one team finds in the month and then how many bugs in the second team find in a month, and then we compare those two numbers and then we reward somehow the team who wins, there will be product, you’re saying, right?
[Shoaib] Yup. I think that will be and in that scenario what you also get is let’s say people that are weaker within the teams, some of the guys will actually try and bring them up and what’s happening. How can we help them if that can’t drives the kind of behavior that you want. So you get some knowledge transfer out of necessity within the teams, because teams are trying to compete and kind of bring weaker along with them. That seems to be a bit more of the kind of approach that I like.
[Yegor] And that sounds like a benchmarking to me. More like, you know, comparing our numbers with the numbers across the organization. So let’s say we have like 10 different teams and then maybe instead of competing against them, we just know where we are on the total scale, so we know that our performance is like 4.2 while the average performance in the team is 4.7 so that we’re behind and we need to catch up somehow.
[Shoaib] And also ranking the team seems to be less of an issue than ranking individuals. So people will compete to be the best team and that’s the kind of recognition as well, so some of the top guys will take huge pleasure in the team being the one. So they cannot keep that kind of reward for recognition, but at the same time the organization gets the kind of behavior it wants out of the team. So that’s probably the best balance between reward and recognition.
[Yegor] Well sounds like we’re found a solution in this podcast. I’m just trying to summarize, so instead of making this gamification process as you know personal, we instead move it one level up to the level of the teams and then it becomes interesting and productive. Correct?
[Shoaib] That’s kind of my summary and kind of the what I’m finding that is working well, I’m sure different environments will have slight differences but that seems to be what’s working well.
[Yegor] Okay, that sounds good. I’m satisfied with this conclusion and I have no more questions for you.
[Shoaib] It was great talking to you.
[Yegor] Yeah, absolutely, me too, I really enjoyed it and thanks for participation.
[Shoaib] Awesome.
[Yegor] Have a good day.
[Shoaib] Thank you.
