#0054 - Sandy Mamoli - building great teams

Foreign.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

I am Sandy Mamoudi.

Hi Sandy. Thanks for coming on. So we want to talk about creating great teams with you today. Why don't we start by getting you to tell the listeners who you are and what your background is?

Sure. I am currently in my third career. I started out as a professional athlete and then at the tender Age of 30 I needed to grow up, went to uni and got a master's degree in artificial intelligence, which threw me into becoming a software developer, which I did for a few years. And then I moved to New Zealand from Scandinavia and having been working in agile way for several years at the time already, I decided I would not give up this way of working and started coaching agile teams in New Zealand. And I've done that for about 15 years now.

What was so good about Agile ways of working that you didn't want to give it up?

I did not really have lots of experience with Waterfall moving to New Zealand and I joined the first company here and I was in shock and I was in shock about how much people would tell other people what to do. I was in shock about this whole idea of change requests, about how little I got to talk to a customer and how I actually had to work without a team. I had just to do my part and then hand it over to someone else. So it felt really intuitively absolutely wrong to me. And that's when I decided I do not want to work this way. This is bizarre.

Yeah, I think that's common for a lot of us who've worked in a good agile team that we just never want to go back because everything's so much worse after that.

Completely agree with you. Once you have really experienced it and you can't explain it, once you have experienced it, you are chasing this feeling of being part of this amazing team for the mixed up your life.

So you wrote a book called Creating Great Teams and I'm wondering if we can start by asking you what is the problem? What do we see typically in teams? Are most teams not performing and what are the main reasons why?

That is an incredibly big question. My background is professional team sports, so I have experienced what it's like to be in a high performing team and I've experienced how magic happens when people really collaborate and then chasing this feeling in software development teams. And some of them are absolutely amazing. But then there are things that I will be missing which are teams stuck in a system where they are being taught what to do teams that do not have a compelling shared purpose of goal. So everyone just focuses on the part that they want to do and don't really care about what other people do. If you take Daniel Pink's Autonomy, Mastery and purpose, I see problems with purpose. People don't really know why they're on the team and what the whole goal is. I don't see that many problems with mastery people actually quite good. But I do see a huge problem with autonomy and to me, allowing people to choose the team they work in and creating the team the way they want it is the ultimate autonomy and also the ultimate way create a team that performs well.

So is this similar to the five dysfunctions of a team?

Similar to that. And I do love that book and I think Pentralencione is a genius and I found this book really helpful because there's research behind what makes team perform and what a well performing team looks like and what the conditions are to make a team perform well. I think it starts with can you actually be a team if you have 18 people and they don't have all the skills they need, they don't have a compelling purpose, a team is too big or people are on more than one team, then I think you will struggle. In order to have a team trust each other, you need to have the condition and the environment where you can make that happen. Meaning a small team with a shared purpose.

We see teams being put together by their managers and that makes them a team somehow. Whereas actually that doesn't mean they're a team. They don't have a shared purpose. They may not be doing the same work. They may not have picked each other as teammates. They may not actually want to work together and therefore they're starting from a horrible position because somebody's put a box around them and put the word team on it. Where none of the team behaviors have been thought about or done right at the beginning.

Yes, absolutely. And it's what the is the derby calls the you and you method of selecting a team. It's just based on who happens to be free and available. We take those people and throw them in a very regard. You are a team now without giving them a purpose, giving them support. And I find very often that goes totally wrong. And just to add to that, there's a lot of focus on psychological safety and I love that. But I also think there's a lot of misunderstanding around psychological safety because it doesn't mean that we're all super nice to each other and feel comfortable all the time. So one of the main dysfunctions I see is that people don't reach the stage where they can hold each other accountable, where they can give each other direct feedback of this is what I need from you or you are not doing as you said you're going to do. Those are conversations that need to be safe to have had. And that is what I think we need to remember psychological safety really means.

Lanciani talks about absence of trust as being the foundational thing, but then the next thing up is fear of conflict and artificial harmony. I've had that experience with a team that was made up about 50% of people from a service provider that were in a developing country.

They would not say anything in retrospectives or stand ups or make any suggestions. We knew that they were having serious problems because they weren't producing anything. And we'd say, are you having any problems? And the most senior person would just say, no, no problem. So we couldn't get anywhere with them because they were afraid of conflict, afraid of raising issues with this. Have you had that experience?

Oh yeah, totally had that experience. I used to work with Sony Ericsson in Copenhagen, Amsterdam, Stockholm, and a team in India and we had exactly the same experience. People go, production is down. And everyone would go, I didn't touch anything, I didn't do it, didn't do anything. We can see the commit log that you were doing something over there, like didn't do anything. Whereas all us Europeans were going, I did something over there. It could be related to this, it could be me and just a fault finding to fix something. And our reaction was anger, why are you doing this? What is wrong with you? Until we learn to have empathy. And what we learned was that for us it was entirely safe to go, hey, I just brought production down, I'm sorry and help and bring it back up. Whereas for the person who worked for major service provider in India, they got fired if they publicly admitted to a mistake that had severe consequences. So I've learned to have a lot of empathy with people not admitting mistakes if they are in a very different context. It took a really long time and repeated experience of no punishment for mistakes to build a team out of people. Whether that's a safe, that is not there.

So the previous podcast we did, we talked about this idea of working with people outside your organization to get some work done. And one of the key themes that came out of that was this idea of a shared goal, that if the people are working for a different organization, they are typically incented by that organization's Goals which may or may not be aligned with your team's goals. And that makes it really difficult because they have two masters, they have the goal of the team you're working with to try and get something done.

And.

And then they have the goal of their organization, which typically is around money. Have you ever seen a solution to it? Is there a way of breaching that gap between two sets of goals you're striving for? And they may be at conflict.

Several things that pop to mind. And the first one is that it is not just in outsourced teams. I've also seen that in local organizations, people are on an agile team, but at the same time say their test manager is interfering to write test place in a particular way. If the conflict is that people will always go for what is best for themselves, to retain their job, to get their bonus, to advance in their careers. And I have never seen how that can work to have such conflicting goals. Have you ever seen a solution to that while keeping the conflicting goals?

No. Sometimes the fact that there's conflicting goals gets hidden and we get lip service. It looks like we have a shared goal, but the behavior becomes different. So it's subversive, which I think's worse than being upfront. Unless we go to that shared goal, we end up not having a team. We have two teams and then we deal with it as a handoff problem, which I don't like. But if we say they're working in a handoff situation, at least that way we can focus on the handoffs. We know that's the area of constraint, so let's just focus on that, not worry about actually having a single goal.

I have seen a solution. By redesigning the engagement as the client, you can bring the supplier staff into your team as capped time and materials and make them team members and treat them as part of your team. So then service provider meets their goal of revenue and you are able to get them to focus on your goal, whatever that is. But there still can be severe problems with trust and refusing to discuss issues even in that situation, fear of conflict still, lack of commitment, avoidance of accountability and so on.

I completely agree. I'm currently working in a context where there are two teams that are a mix of client and vendor. That's working really great. There is trust, there is a shared goal, and there is commitment. What it did need though, was that someone took away the conflicted goals.

Yeah. What does a great team look and feel like in your experience?

Great question. There are so many things around that. So first of all they enjoy working with each other, they bounce off each other, they are feeling safe with each other, they respect each other, they all want to work together. Doesn't mean they need to be friends, but they need to want to work together. There is banter, there's constructive criticism, there is constructive feedback and there is no sugar coating or politeness. It's people who are honest, frank, direct with each other and they have clarity and also desire to reach a goal together so they can overcome any differences they might have because a shared goal is simply more important.

How do we measure that though? Because that sounds like a set of value judgments from an expert. I've been in one, this is like one I've seen before. But are there ways of measuring it?

There's no one absolute way of measuring and I thought what we can do is triangulate to an idea of how a team is doing. And I quite like Amy Edmondson's psychological safety assessment. I like team health checks that are not just around process but about how they feel they work as a team. I also like comparison between teams. If I compare it to being an athlete, in order to get inspired and see what is possible, I need to see what other people do. I need to see other teams and think, wow, they're performing really well. Those are the things they do. And sometimes I need to realize I'm great here. We have some shortcomings over there and just knowing where you stand can be super useful to compare without judging. We go around and visit other companies, we have lean coffees with people who come from other teams and we ask them questions to get comparison, see where we stand and what we can learn from others. And I don't think there's anything bad realizing that hey, we are an intermediate team and pro teams are over there and here's a list of things that we could learn.

I often see two events happen that made the team form and start to get that team behavior and one of those is some form of existential threat and the team then gel to fend that threat off and I start seeing some good team behaviour. The other one is that sense of competition against other teams. Sometimes done well. It's a polite, friendly competition, sometimes not so well. But again, that sense of competition seems to make the team form and gel together a lot faster than if neither of those events happen. Is that what you've seen?

Absolutely. Especially friendly competition done well. It can be inspiring and it can be helpful for performance and it can be absolutely enjoyable.

I wonder though, can you have a really good team if everybody is a novice but they have all of the other characteristics, they have the behaviour, but they don't have the skills, I think absolutely not.

If you don't have the skills, there's no process, there's no behavior, there's no team spirit that can completely eliminate that problem. If you have the behaviors, over time it will make it possible to learn. So over time it will be possible to succeed. I have seen this really amazing thing at a Wellington company named Snapper where they said, we have got a very young team. Nobody knows anything about services design. In fact, nobody in the company knows very much. The five of you, you got two weeks, go away as a team, learn anything you can about service design, report back. So that would be a team with the behaviors, currently lacking some skills, being sent out to acquire the skills. They are a good team and I think they will become a great team skills wise. Are they going to perform on day one? No, but after a while they will and they do and they did.

What about the opposite scenario? Then you've got a team of individual experts who don't have those behaviors, they don't trust each other, they have fear of conflict and so on. Can they be a high performing team?

So Barry, you mean a team of talented assholes, right?

Yes.

Yeah. Thank you.

Competing with each other.

I think we've all experienced that. And I was so glad when Bob Sutton wrote his book called the novel Asshole Role because I've always had this feeling that doesn't pay off to have a toxic person on the team. We should stop catering to the diva. It's a really bad idea. And when his book came out that showed the cost of one toxic person on a team and that our intuition was right. Don't cater to the asshole hero.

How do you deal with that? So when I start working with a new team, I have a conversation with the leader of the team and also the team themselves to say, look, you've been put in this place where you're going to try and adopt an agile way of working. Often the team have been told they're going to go through this change. They haven't self selected for it to happen. And so the conversation I have with them is, look, at some stage you may decide this isn't right for you. Give it time, give it a go. But if you decide you don't actually want to work this way, then the organization has an obligation to help you find something that fits the way you want to work. And that's okay. What I could say is you're Going to vote yourself off the island and that's okay. Right? You don't have to work this way. It's your choice about your life. But the opposite one is where you have that talented asshole that really the team starting to feel that the person is toxic and they're not helping the team become a team. Have you seen what's the ways you've seen the team or the leadership deal with that problem? What's a successful and respectful way of dealing with that effectively voting them off the island?

Yeah, I think the talented asshole is not always a personality problem. That those are behaviors and I wouldn't put my hand up to sometimes have, sometimes have I been that asshole. Don't know how talented. But I've definitely behaved in a way that was not good for a team and that was because I didn't see it. I didn't. I lacked perspective in some situations. I had a knee jerk reaction. And so this is behavior, not personality in my case I hope.

And behavior can be changed. So we can work on changing behavior. We can. I usually start out gently because it's harder to come back if you start out hard and then pull back. But I start out gently. If that doesn't work I will go harder and harder. And also having conflict, having a hard conversation, I mean also have other people have heart conversations with them to make them understand. And after a while if nothing has worked and the person really does not work want to work in this way that is okay. And as you see I like your way of doing this. Hey, do you want to vote yourself off the island? Absolutely. I've also removed people by telling people management like this is your pilot agile team. You have this person, they are toxic. If you want this to succeed, you're going to remove that person. And that has sometimes ended really well. The person got removed. The person ended up on some other waterfall project. Basically had to go back to the old world. Came back three months later and credit to them and went wow, I'd forgotten what it's like. Can I come back? Because I think this could actually be way better. And that guy has been in an agile role for 14 years now and also never wants to go back. So I think there is sometimes a behavior that is different from the personality and people change their behaviors in a team.

Yeah, I think so too. I think that some people are just assholes. You've got narcissistic control freaks and people with personality problems. But a lot of people just are not aware of the impact on others. And if you can point it out to them and most importantly explain a better approach then I think that's quite helpful. About 25 years ago, I got quite a lot of criticism as a young project manager about my approach because I was very task oriented, very goal oriented, very hard working and driven. And I was like that with other people too. And I got given some pretty harsh feedback. But the problem was that I wasn't given any solutions. I was just given, you should have better relationships with people. You need to get on better with people. And that's not helpful at all. It's one thing to point out the problems, but I think with giving feedback you need to be clear and specific and don't make it about their personality, make it about their behavior. That's my feelings. What are your thoughts on how to give good feedback to people in those situations?

I think what you just said is brilliant. It's the differentiate between the behavior and the person, give feedback on the behavior and tell them what would be useful instead. And not just go, hey, you should build relationships, but those are the things you do. This is the impact and how about you do this other thing instead? And I really don't believe in the whole like shit sandwich and wrapping feedback and how to deliver it. What I think is important is that pick the right time and the right person. Ask if you can give feedback, but make sure you get the chance at some point and then be honest, be upfront.

One of the things I found right at the beginning of my journey was we lost this idea of pastoral care. Techniques I found really useful was doing the team charter using a technique called this person, that person. So two parts of a page or a Miro board and writing down the behaviors that they would like to see in the team. So we call that this person and all of the behaviors that they wouldn't like to see and we call that that person. So, you know the typical turning up late, talking over top of people, those kind of things. And what I found is by having that available for the team, they could point to those behaviors and have a polite conversation with somebody saying, hey, you're being that person and they're not the person. Effectively, I learned by mistake to do that early. So one of the teams, we didn't do that. And then when the problem happened, we then had to do the this person, that person exercise. But it was very clear why we were doing it right. And then it became personal because we really were doing it because a person was behaving in a way the team didn't like. And so it was so obvious. So I've learned to do that exercise early and the team forming process and then they can use it. But coming back to that pastoral care, do you find that a lot of the teams start off on their agile journey and then they get into almost factory behavior and it's all around the tasks and the work to be done because often the problems are generated outside of the team. They have something going on in their life that's causing them a problem and then we see that behavior come into their work. So have you seen that loss of pastoral care of the people as part of this agile adoption?

I think actually the other way around I have seen more pastoral care, especially in the last three years. I'm currently working on a talk that's leadership with empathy. I talk to leaders and how they have experienced the last years in terms of pastoral care. And one of the things they said was that people have become more fragile, people are more in need of pastoral care. Someone has compared it a bit with people treating their employer like their 1950s husband, providing financial security, providing emotional security, providing wellness and providing a social life. So I think the last three years have seen a lot more pastoral care and I think that is really, really, really good. And in some cases we might even be overdoing it, or maybe it's just we also need to make sure that our leaders have some pastoral care and we have some empathy with them.

I wanted to ask you about what you would do with some other common types of individual performance issues. So another common one I see is the charming slacker. So this is the person in the group that everybody likes but never gets anything done and spending all of their time talking to other people and is focused on people, not the task. What do you do in that situation?

It's such a common type, the laser slacker, charming, pretending to work, but actually just not doing anything. I think they're really hard to deal with because other people like them, Many other people don't see the problem. And if it has an impact on the team, I will have that conversation without trying to recruit other team members to gang up on that person. Because I think that is fair having that conversation. And sometimes I just sacrifice a little bit of team performance if the damage of kicking that person out ultimately will be greater than that hit on team performance. Because sometimes I think that lazy slacker has other qualities where they're immensely important for the team and just keeping the spirit up, directing the team and making a huge difference for team cohesion. So I'm trying to find a Balance between when it's damaging to have a deep weight on a team versus is this really deep weight or is it just people who have different qualities?

We've been talking about individuals and what you might do as a manager. But whose responsibility is it? Is it really the manager's responsibility? What about the team members themselves?

I would say any good team would regulate most of that behavior and have that conversation with each other. That is what a team that is driven, that has psychological safety would do. And personally I hate this other person is not performing or this other person is doing something I don't like. I need to escalate it to my manager. And when people come to me with that, the first thing is, okay, what have you tried to solve this? Have you taught the person? I think going outside the team is the last resort.

You've written quite a lot about teams taking control of their own structure and destiny, haven't you? So team self selection and so on because it's not very common.

The premise is that people do the best work if they can choose who they work with and what they work on. If you choose a team that has a particular purpose, you can choose into that purpose and you can take responsibility to make sure that you all have the skills that are necessary and that you actually want to work together. I find that people get this right because they are the ones who have the information about what they want to do and who they want to work with.

Should you choose your own manager?

I actually think so. I don't think it is always possible in all organisations. I was hesitating because I need to define what the role of the manager is first. If the manager is the person who takes care of you, both pastoral care and also helps you making career decisions, who coaches you or you can bounce off ideas, then I think absolutely, it's like choosing your coach. You should choose your own manager.

And do sports teams choose their own captains?

Some of them, but no, they don't. But you do choose a coach because you have several elite offers and you go, what's the coach where I can learn the most? You choose because that coach is coaching this particular team and that coach is world class. So I can learn a lot. So in a way, yes.

So originally my thoughts always were don't break the team up. So team form, they get a way of working, they get to a level of velocity that is reasonable and they just get good at delivering. And we break them up at the risk of breaking that behaviour and that pattern and that success. But then over time the Team gets stale, they get into a factory behaviour and it's not enjoyable for them. Have you found that breaking and reforming of teams is beneficial or is it better to keep them together?

I think giving them a choice is good. What I find in any software development team if they don't get new impulses they get stale and performance stagnates. Getting new impulses doesn't have to mean you tear it all apart and totally different people are now working on this thing. I usually have a self selection event. People choose a team and then repeat that every six to nine months and I've never ever seen that everyone has left a team and is off to do something else. If that happens there's a different problem than something you what to look into. But in general most people stay for a long time on the team they want to be in and some other people move around. So what you get is relatively stable team with a few changes swaps and that I find is not the tearing apart and it gives enough impulse for the teams not become stale.

When I think about self selection I think about that horrible process when you're at school and and you're not the most athletic and so you never pick first. I don't think I was ever picked last but I wasn't near the top of the middle and so that for me self selection you always worry about the mates selecting themselves. So what is the process for self selection that makes it safe or what are the anti patterns that we should make sure we don't do when we're enabling a team to self select?

The poor kid and school yard is not being picked is exactly the first fear that pops into absolutely everyone's mind and what I can tell you is it doesn't happen. It can't happen because the process doesn't allow for it. You are not being picked. You pick your team. You walk up to an empty team shell and put your photo there. I would like to work there so it's no one approaching you going hey Shane, do you want to work with us? It's the other way around and so that doesn't happen, they're not picked up. Then you have people who might still absolutely hate it or who are totally new, they're on day one in their company or day five so they have no idea what to choose. So usually also have an area where people have the opportunity to opt out and have a signal hey, can someone please approach me? And that works well. Most people just decide where they want to go, put that photo there and most of Them stay where they chose to be. There's some compromise, but they make compromise with each other. There's no picking.

What happens if everybody wants to be on the sexy digital team that's building their new thing, the new product, and they don't have budget for that.

There's a huge assumption right there that everybody wants to work on the new thing, the new product. That's what I would want to do, what you want to do. Maybe Shane too. But it has always been so surprising to me. There have always been teams that I would find super non interesting that was a pure projection. Just because I find something interesting or not interesting, totally different for different people. So never happened to me that there was a team that didn't get picked or that everyone picked the same team.

But what happens if the team can only have four, six people and they have nine people who want to be on the team?

That is a constraint you want to make clear up front. And I once made the mistake of not making that clear up front that it was only budget for four people on a team. In retrospect, what we should have done is just for that team, only four people are needed. Maybe you've got seven people who are really interested and that's when you have facilitators in the room to help people have a conversation. Instead of this team, how about that team? What about if you move over there? Then the whole thing could maybe work. What other solutions are there? Because a self selection is not just about me, me, me, me, me. This is where I want to be. Instead of managers deciding who is going where, we trust people to come up with a good solution for the entire organization or whatever the scope of the self selection is. So we trust you to make this work. Not everyone will get their first choice of team, but I find when people compromise and don't end up in the first or second choice of team, they have agreed to it or at least they know why it is happening. So they actually behave like responsible adults 90% of the time.

Do you find that it works better when there is already that trust in place? So would you apply self selection right at the beginning of a new team who haven't changed the way they work, haven't built that team trust? Is that a dangerous time to experiment with it?

Actually it is easier for them to gel as a team because they've chosen to be here. They want to make this work. On an organizational level, I would be considerate of the culture. If you have a culture where people are open, get along well, it's a good culture, then yes, go and do it. And there is also other companies where I just would not do it because I know it would go wrong. I have seen companies where they did a self selection and afterwards management moved a few people around and that is actually worse than not just having honest management selection. Nothing bad about that.

I worked with a team where a few people were real experts and a large number of people were not very experienced. And it seemed to us that the best way to form teams was to put one expert as a leader of each team. I didn't necessarily have to have the people responsibilities, but have an expert in each team and then have the other skills around them. But if you ask them to self select, they might agree to do that. On the other hand, they might just want to work together, which wouldn't have been very good either. So I'm thinking for self selection to work, you'd probably want to put up a team model for each team to say we need people with skills in product analysis, design, build and test in each of these teams. So if we have all developers, that's not going to work. If we have all testers, it's not going to work. But if we have a model with spaces for pictures to go into, that might be a solution. Have you tried that?

Yes and no. I think having spots, one senior developer, two junior developers, one intermediate tester is something that blocks you and people from finding good solutions. It is already something that adds complexity to a process.

What I do find helpful is to have a constraint that you need to be able to deliver to purpose. You need to have the skills and not necessarily the roles. Because if we focus on skills, then we acknowledge that not every developer is the same as any other developer. So it's about people and their skills rather than people's roles and specialties having individual slots. But just going roughly those skills is more helpful than having predetermined slots in my experience.

Did you hear that, Murray? Yeah. Skills not roles, mate. Skills, not roles. So there's got to be some pre work then.

Right.

We have to actually have worked out what the goal of each team's going to be, what they're going to work on, what we're asking them to deliver. So they know then what skills they'll need to self form to make sure they can do their work and how.

Many people they can afford to have as well.

Yeah. So there has to be some knowing constraints. If we have a constraint that we can only afford five people in this team, we have to know the goal we would like them to achieve.

You wouldn't even be able to define whether it was successful or not because can those team deliver to purpose, yes or no? Don't know. Don't know what the purpose is. So absolutely. And there's a lot of work that goes into that preparation. One of the failure modes is when people just rock up and go how hard can it be? In roughly three teams, just put yourselves into something. There is, I find usually months of let's rethink what are the teams that we want? What is their purpose? Are there any other constraints around budget and whatever other constraints you might need? My recommendation is to have as few constraints as you possibly can so that you don't introduce more complexity and have a look solutions that people might come up with that you or I might not see.

I want to ask you about the bigger picture. So teams work within the system and they work within a hierarchy that is defined by managers. And I have gone in and coached teams using retrospectives and agile processes and I've helped them improve a lot. But they run into organizational blockers quite quickly. There's lots of different types. The test manager is very jealous about the testers, so he won't let them cooperate with the developers even if they're in the same team. There's a DevOps group who won't let anybody deploy anything. They're just the old ops and take months and want giant packages. And there's organizational process and structure issues which really limit how effective a team can do. So is it really all about the team or is it about the bigger picture? And then what do we do about that?

What I love about my job as an agilent coach is that one moment I've worked with the team and I'm deep in a detail there and then the next moment I'm talking to the test manager about not doing controlling all his tests. And then I am in a conversation with someone about the release process and five minutes later I am talking to the CEO. And I think spanning that spectrum is really important because if I'm honest about my job, what I really do is I go cool. You over here should talk to this person over there. Just broker those conversations because they're all those information silos with people with different perspectives and even the test manager who we perceive as controlling or the DevOps group that is not DevOps at all, making decisions they think the right thing for the company and making that's possible to understand different perspectives is the way I usually try to go. Sometimes I succeed and sometimes I fail.

All right, we better go to summaries. What do you think, Shane?

Before we do that, I got one question. It's around team compensation. So what have you seen? Have you seen any good ways that monetary compensation can become more team and goal focused rather than individuals?

I have a huge problem with performance bonuses unless it's some sort of profit share, because I don't think they actually motivate people and they create more damage than good. First of all, I hate bonuses. Why do we need to have them at all? Working in Europe, nobody had any bonus. We just got a salary. So it took a lot of this off the table. And then there's. How do you pay people? I wouldn't pay by performance. I would pay by skill. If you pay people by skill, you don't compete with each other. You acquire more skills and experience over time. And then if you do really want to have a variable part of people's income, I would go buy a profit share.

I would pay people by skill, but also by the market. So when I was setting salaries for 50 people, which I did at one point, I looked at salary surveys from large recruitment agencies and they basically tell you, a junior is in this range, a mid is in this range, the experts in this range. And then I just worked with my leaders to say, where is this person? Okay, they should be paid this because we don't want them to leave. And if they're being paid as the same as they would if they went out and looked at for a job, then that's going to take that off the table completely. And the cost of replacing people is huge. So why not?

And I think it's brilliant because what you're doing is you're adjusting continuously because the market changes and you don't want all the people who've joined earlier to leave because the market has taken off. So I think that's absolutely brilliant to revisit that.

What I found interestingly, Sandy, is that people who were quiet and bit insecure had lower salaries. In particular, women from developing countries.

In this particular company were being paid 25% less than they should have been because they never asked. And so they never got a raise because they worried. I felt that was very discriminatory and it kind of happened without anybody thinking about it.

I think you must be a really good leader. So good on you for doing that. It's something really hard in a team even to work with people and especially women from developing countries because very often their visa is tied to a job. So they're very scared that if they lose this job that changes their life entirely for us. We just walk away and find something else for them. It upgrades their entire family so their stakes are so much higher and I understand why they then go by don't rock the boat, don't ask for a raise and also within a team don't speak up. And that can actually be really detrimental for team performance. And I very often have to say I struggle with that. Getting people out of the shell because it's good for the team while also acknowledging and understanding that they understand that the behavior of just doing as you're told to do is not the road to success.

Yeah, we also had the reverse where there was loud extroverted men who made friends with the senior executives who were getting paid a lot more than they should. I put a stop to that as well which wasn't as popular. Let's go to summary. Shane, what he got.

Alrighty. So what are the problems with teams that we should worry about? So teams that are told what to do been given a set of tasks and told to just do the tasks. Teams that don't have shared goals, that's a recurring theme from every guest we've had for a long time is focus on that shared goal. That's probably the most critical thing to getting a team to work and performing. And then also when people, individuals are focused on there but then handing off and they don't care about that end to end delivery or that goal being achieved, we've got a bunch of problems. I like the fact that you couldn't quantify what a great team looks like because I can't either. I resonate with that. Right. When you see joy in the way they're working, when you see respect across the team members, when you hear and feel that buzz of them working. Those ones I recognize and the one that I didn't thought about is constructive feedback. When you see the team giving each other constructive feedback, that's good. So I think it's one of those things that after you've done worked with a couple of teams you can feel the switch. One team I did work with, they started out doing an NPS score with the team and that was actually one of their feedback loops. It was still a qualitative one but I thought that was a good technique. Interested in that you've seen an increase in pastoral care over the last three years. Maybe that's the whole Covid remote working. We're starting to care about that because we can't assume it's happening anymore because we can't see. Sit in the room and watch people. I like the idea that good teams regulate themselves, right? So set the team up for success and get the hell out of dodge and just be there if they need you, they'll come and tell you.

Right?

If you're available, don't try and regulate themselves. The self select. So that key message of team members put their faces in the team they want to be in. So they're self selecting, which makes sense because that's the term not being selected. And then the second one is what that override. If you're going to empower them to self select, they self select. If you have a constraint, bring it up front and tell them what the constraint is and they'll work within that constraint. But the idea being as few constraints as possible because it makes it less complex. So really only part the constraints you really care about and then let the team get on with it. So yeah, that's mine. What do you got, Murray?

Yeah. Probably the biggest problem I've seen with teams lately is fear of conflict because I've been working with some offshore teams. But fear of conflict and artificial harmony is a very serious problem that causes poor results, poor performance of a team. I'm still not sure how to get over that. Even try and have conversations with people, leaders and so on. Didn't work, so I'll keep working on that one. I agree with you on what does a great team feel like? You can feel it hard to measure. I think NPS might be a good idea, but apart from that, a good team just performs the kicking goals and they work really well together and they're continually improving, which is another important sign for me. I think too often managers look to the team as the issue and you can help teams get a lot better. But very often it's the system they're in and the organization they're in that becomes the limiting factor. And often managers will ask me to come in and help them get their team to improve the way that they're working. And I do that and then find actually it's the manager themselves or their peers who are causing a lot of the problems that we see in the team. So I think we need to do a lot of work with that as well. I also like being a agile coach for the same reason as you, Sandy and I get to work on all of these things. I think we're in the business of organizational change, really working from the team level up. And yeah, I very much agree on outcomes and outcome focus, goals and purpose. It's very important. I would like to explore the area of selecting your own manager. I haven't seen people do it but I'm quite interested in experimenting with it. Any last thoughts from you Sandy?

Writing down oh, need to try out selecting your manager and I wonder if I can engineer that because I have a company that's going to have new managers and I am one day I'm to rock up and go hey, how about we let people choose their managers? Thanks for the inspiration. I'm off trying to convince people to do that.

My experience is that managers are highly variable. Maybe one third are great, one third are bureaucrats who don't make any difference one way or another and one third actually make it much harder for the team to perform well and the people who know that best are the team.

So that would be an interesting experiment.

Yep. And the same goes for Angela Coaches. There are people where you go like you're absolutely amazing. I can learn so much to your average to oh my God. God what the hell are you doing?

Yeah, particularly the people who have only experienced water scrum fall in like banks and consulting companies and then they come in and they're rigidly setting that up everywhere they go.

Yeah, I was going to ask is that happening in Australia too? I don't know if you are cliche but what I see in New Zealand is actually just agile by numbers and it's pretty shit but it's in those larger enterprises and it's the same network that move from one enterprise to the next and when they join they introduced the same shitty agile everywhere. I call it the McKinsey Agile. Is that happening in Australia too?

Yes. BCG and McKinsey are going around to all of the big companies saying we can help you cut your costs substantially by implementing Agile because when teams are self managing you don't need as many managers. So we'll just set a target of firing 25% of managers. We're going to implement the Spotify model and Safe spot a safe and we'll do some packs, we'll do some big bag change. Pay us the $50 million and see you later. There's a lot of money to be made. I just recently lost an opportunity to help people because I said there's better ways of doing things than safe and they were absolutely shocked.

Yep. It has become synonymous with agile. It's what people think agile is. My friend Tony uses the word quarterfall and I think that's totally what's happening. We now have okrs and three months plans and those three Months are waterfalls.

Yeah, they are. And they've fixed scope too, despite what everybody says. So yeah, it's a real shame. A lot of it is just due to inexperience. SAFE is gigantic and it takes quite a long time to understand what's going on and what the issues are with us and new people to Agile see it and think, oh, this solves everything. Great, let's just do it by the book.

The New Zealand government now, right. If you haven't paid the SAFE masters to get their certification, you're less likely to get work in New Zealand government because they've all decided to drink the Kool Aid and go down the safe path. One of the things that's come a realization doing the podcast is organizations started after 2000 typically don't have the large hierarchies. Typically they're still building their ways of working organizations before 2000, but they're based on old ways of working and to change those organisations is incredibly difficult. We will get success with teams because we will typically get a team bubble where that team is empowered to change the way they work. Then once we get outside the team and we start to move it through the organization, then we hit the wall. Then we hit that hierarchy and that manager versus leader behavior. I think it's hard to change those large old organizations.

What they're doing, I think Shane, is they're changing agile to become bureaucratic and suit their existing way of doing things. Agile silos because we like silos. Agile hierarchy because we like hierarchy. Thousands of rules and processes because that's what we like.

Yep. And SAFE is a methodology and some leaders like methodologies because they believe it gives them safety. Hence the name.

Yep. And it's a brilliant name. It's an absolutely brilliant marketing name and you need to have a deep understanding of agile to see what's wrong with it because every single ingredient there is. Oh, that's a good thing. Oh, that's a good thing. Oh yeah, that's also a good thing. But it's only if you take all those things together you'll realize what has been built. But you need to understand agile before you can see that.

Yeah, well, it's like a pattern library, but it's all focused around three month program increments and tons and tons of rules from above. All right, thank you very much for coming on, Sandy. That's interesting. I learned something about self selection. I'm going to try it when I can. So much appreciated.

Thank you so much for having me. That was fun.

That was the no nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help building great teams that create high value digital products and services, contact Murray at Evolve. That's evolve with a zero. Thank you for listening.

Sam.