Making Change Stick with Neil Vass

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast.

Today, I'm sitting down with Neil Vass. Neil was a recent QCon speaker at QCon London and is based in the UK, and today I'm sitting down in Australia. Neil, welcome. Thanks for taking the time to talk to us.

Neil Vass: No problem. Thanks for having me on the show.

Shane Hastie: My normal starting question is who's Neil?

Introductions [01:16]

Neil Vass: I've worked in tech for 18+ years, I think. I'm scared to go back and count exactly. I was a software developer for quite a long time and then gradually moved into, partly because nobody else was doing it, things like delivery management, the product side, the why are we doing this anyway, and moving towards talking to stakeholders about do you know what you actually want? That would help. And can these teams work together well?

I've worked at Tessella, which was a tiny company that nobody's probably heard of, but worked with all huge big conglomerates and different companies around the world doing such scientific research things, so working for AstraZeneca, Unilever or other people about what supports their scientific research was quite an interesting topic to work on. After that, it was the BBC, which is British Broadcasting Corporation, which is probably famous around the world for spinoff services like Dr. Who and stuff, and for the last six or so years I've been at the Co-op, which is 65,000 people, 180 years old, and has lots of different businesses about food stores, funerals, insurance and all sorts. I'm an engineering manager now, which means I line-manage engineers, I make sure we've got the right people and skills on teams and help talk to teams about improving how are they working and what would we like to get better at next.

Apart from work, I'm from Scotland, originally, which is in the north of the UK. I moved to Manchester for University a scary amount of time ago, so I've actually been in Manchester longer than I was ever in Scotland, which was an odd landmark to pass. But I think I've kept my accent, and I hope people can understand Scottish okay. I live in Manchester, which is quite a big city, and I've got a wife, two kids, a dog, and a sourdough starter is the latest addition to the family.

Shane Hastie: Nurture the sourdough starter. A good sourdough is a wonderful thing. Your QCon talk was Making Change Stick: Lessons Learned From Helping Teams Improve at the Co-op. Why do we need a talk on making change stick? Don't we just tell people to do things and they do it?

Changes imposed without communicating the why [03:20]

Neil Vass: That's a really, really good question and is something I touched on in my talk. I think, if you get into the right position of authority, you can probably make people do all kinds of things, but you can't make anyone care, and you can't make them find it useful. I think where we fall down loads of times is we say the standard is this, and it could be anything from you have to do sprint planning, you have to do retrospectives, you have to show me the evidence you've done them. Honestly, if you're not getting anything out of them, you either need to change how you're doing them or you need to stop.

I think huge amounts of waste are generated in the industry by all kinds of things that we say people need to do, but I want you to care about it, I want you to find it useful and I want you to experiment with it. If it's not quite fitting for you, why not? What's going on? I think in the Agile world, we've realized like in software, Agile and DevOps and Lean and people-focused approaches are the right way to do it. That works better, and we've made a caricature of the old style, the waterfall project management.

But one thing that's interesting about that is there are some good ideas in how waterfall works, like make sure you've thought about your risks, make sure you've planned things upfront and you know what your unknowns are, but that easily morphs into getting through stage gates by weight of documents. If you've got six kilos of risks here, you must be on it. Or everyone knows that that plan's nonsense, but we've submitted it, so we have to say we're sticking to it. If we're not doing waterfall well, what makes us think we'll do Agile any better? So, you can easily slip into the same kind of you're doing the outward signs of what's useful and it's just not. Get curious about things, work out what practices could help solve your problems.

Making change stick [04:54]

My last topic about why making it stick is important, I said in my talk there's multiple talks you could give about who am I to give people advice anyway? Did they actually want your help? Help would be useful if you're helping multiple teams, and you're not there every day to say, "Not quite like that. It's this." There's loads of things there. But the particular challenge I was looking at, and I think it was interesting for me to reflect at, and I've heard other people struggle with, is where somebody's had a challenge, you've talked through what might help, you've helped them implement it, and they're like, "That's great."

You come back a couple of months later, and maybe the same people, maybe a few people have changed on the team, or maybe it's the exact same one, were saying, "I'm struggling with this." I said, "That sounds like the same challenge. What about that thing you started doing that fixed it?" "Oh, we've kind of stopped." Often, it's vague. What was the reason? Has the kind of work changed or is the person who was driving it gone, or did it just fall out of the habit?

Sometimes, you think, "I've helped you. I've gone and helped you. I've gone and helped you," and I look back at the first one, and they're like, "Ah, I've made no progress at all." If it was just a me thing, I'd worry about it myself, but it's something I hear lots of people talk about. It's something I see other people struggle with too, and the teams, themselves, are sometimes at a bit of loss to, "We've solved this once. Why am I fighting the same fire again?" I thought that'd be an interesting focus to put on as I looked through my career at the Co-op.

Shane Hastie: What are some of the reasons that this does happen? Because I agree, I've seen this pattern, and it's a common pattern across many, many organizations and many teams, and I would say, it's not restricted to large companies. It's large, small, intermediate, so what's happening there?

Solving the same problem over and over again [06:28]

Neil Vass: It's an interesting one. I'm not sure I've got the full story of it. You could either let it depress you or let it give you some strength is that people who really know what they're doing, like industry luminaries, struggle with it just the same. I had an example of Henrik Kniberg, who first popularized the Spotify model and a lot of other things, he wrote a really interesting book called Lean from the Trenches, which is a detailed case study about how they made Lean thinking and Kanban work for them, and it talks about the people, the managers, the stakeholders, what do they work out and what's doing. At the end of the book, you're like, "This lot know it. They really understood what wasn't working for them before and what works for them now. They've cracked it. That's good, that's how you solve things."

Then in his follow-up presentation, once he'd moved to Spotify, he's got a slide in there about a train just going off the rails over a cliff, and this was the story of the very next project by the very same group of people, all the same stakeholders and bosses and everybody forgetting everything they'd learned. It was like, "We've talked about this. What's wrong?" You could think, "Well, nobody can make change stick," but I'd prefer to think it's just hard. It's not that I'm not good enough, we're not thinking about things enough, or where I work isn't right, it's something we all struggle with.

One of the reasons for it, I think, if you want to check you're still doing something, it's easier, it takes less energy to make sure the outward signs are still there rather than think about, "What were we doing this for, and are we still getting that, and what problem was it trying to solve for us, and do we still have that problem?" The things can shift without realizing.

One pattern I saw as I looked to helping multiple teams at the Co-Op was we'd put in place, "Here's how you kick off a team. Here's how you should set up your goals. Here's the things to think about and team charter and things like that." But over the course of just a couple of years, we'd moved in the part of the organization I was in, from everything was discovery or a very early stage, "We're just prototyping," or, "Things are new, and we're working it out." You can see the problem and you can see a sort of end stage. We'd shifted without really noticing it across multiple teams to almost everything was a long-running live service, which means you're now looking to incrementally improve rather than have focused, "This is a new thing." You've got teams that have been around for a long time, and even if the same people are on them, you've kind of forgotten some of the reasons you talked about. It seems we've said this stuff, we've talked about what was useful and why we're adding things, feels like boring or unnecessary or patronizing to repeat it.

I think people don't realize, and the number of times I have learned this lesson and then had to repeat it to myself, because it didn't quite stick, is that thing about being a broken record about when you are bored of talking about a thing, people are just about starting to listen. I think that works with ourselves as well. Outward signs might persist, and as people get busy, you only do that outward thing or you let things drop altogether. I suppose the last one is when we think about improvement, often what we think about is what can it add, what new process or technique or habit is going to do it? Before you know it, the whole week's absolutely full of all the wise and wonderful things that you're doing to help yourself that we're not getting any work done anymore.

Shane Hastie: One of the things that certainly I've seen is you're right, we'll bring in a new process, we'll bring in a new thing that we want to do because there is value in it, and time gets full. We do get busy. How do we choose what we stop doing?

Change involves stopping doing things, not just adding new elements [09:47]

Neil Vass: That's a good one. One exercise I've used on one team I got into a good habit, it was a quarterly what have we achieved, what have we done, what did we try that didn't work? But also a good layout like make a mock-up of your team's calendar on the wall and a mock-up of your team's Kanban board or whatever you use, things that you recognize. We used color-coded Post-Its. I think we had yellow ones to explain what's this for? That was interesting, because if you think your stand-up is to update your scrum master on what you've done yesterday, that's a good chance for somebody else in the team to say, "That's not really what they're meant to do. Can we use something else if we don't need updating?" So the yellow, here's what this is for. Some reds, like this is confusing or not working or needs to change, and the green Post-Its for, "I like this. This is valuable and still helping us." You can choose different colors because it's hard to find the right Post-Its.

But that has sparked some really useful and interesting conversations, especially when you see big clusters of confusion about what we're meant to be getting out of something. Also, having everything up there at once does make you wonder about efficiencies. Do you have a separate time when you check in on whether your deadlines or your objectives and key results or whatever your measuring progress, is there a separate regular meeting about that? Is that something that should come up naturally as you're talking at stand-up or some other time? Could that fit in somewhere else, and do you feel you know it? Is there anything that quite often what we don't flip between is there's some habit that needs embedded, something that's new and a bit confusing for us, so we need to talk about it regularly. Can that just turn into an information radiator? Can that be somewhere that would prompt and just have a chat about ad hoc as needed, but we're still getting the value out of it? I think that helps.

The last bit is probably what do we value and what we put in place for a good reason that's holding us back? A phrase that I really like is organizational scar tissue. When something goes wrong, we have to protect ourselves against that. It grows over it, and before you know it, this is where the well-meaning origin of all the, if you've gotten to change approval boards and stuff with an enormous checklist, and it's like, "And have you thought of this and have you checked that?" It's because one time somebody hadn't checked the DNS settings, so now everyone's got to write a whole sheet about what they've done with DNS. Actually, that was something we didn't have the eye on one time. We know it now. Can that go, because everything you add will have some impact on something else you can't do, so talking about what's valuable and what matters to you.

A nice other bit of focus there on what can we add and what can we do? Your reflex is to keep things, because it keeps us safe when we do things. But keeping in mind things like the accelerate metrics, I've always built and talked to teams about that being important. We value being able to release and if we want to release again and again frequently and be confident it's not right, that's something we value. Now, you've got this fabulous book with thousands of different companies backing up your story. If we value that, what are we doing that harps that? Because anything that slows you down from able to release, being able to roll back confidently from maybe able to just, "I've got an idea now that's out there." If something's impacting that, it really has to justify itself and carry its weight, and if it doesn't, be prepared to take it away or simplify.

Shane Hastie: Removing the friction, challenging those ceremonies, practices, that takes a bit of courage.

The dangers of artificial harmony [12:59]

Neil Vass: Absolutely. I think in lots of teams, you get stuck in that artificial harmony where we're all too polite to each other, and often, it's some dedicated person's role on the team who has designed the current setup. If somebody's put in these ceremonies, if somebody's put in this way of working, and I say, "I don't think it's valuable anymore," it's not me saying, "I don't think you're valuable, you do the wrong thing." So absolutely, probably job number one on your team is to get to a position where it's fine to talk about anything. If people actually genuinely believe you know where they're coming from, you value and respect their skills and abilities, you like someone and think they should stay on the team, if that's all off the table and taken for granted and just understood, you can have much shorter and easier conversations, because, "Yes, then I know all this. Can I talk about changing this, because I don't think it's working for us anymore?"

You're right. I've seen lots of teams where bringing it up takes weeks of thinking about, "How could I even mention it," and awkward dancing around the issue to the point where nobody's really sure what you've even said. Getting to a point where you can just talk to each other is really important on the team.

Shane Hastie: These are, I want to say, skills, competencies that we don't teach engineers at school.

People skills are vital for success, however they are not taught in engineering programs [14:16]

Neil Vass: I think that's really true, and I've got lots of empathy for it, because I remember learning engineering myself when you're first at school or early in your career, there's so much to know just about the tech side. How does the internet work, and how do all the things I talk to as well as the language and frameworks I'm learning. It's a big job, so I'm definitely not saying you need to learn it all at once, but I think the value of it can make so much of your job easier. If you've got any good ideas about getting work done, having a satisfying job, getting people to listen to your ideas and stuff, knowing about this people side is at least as valuable knowing about the tech.

Something else that I like to stress to people is lots of it's super easy. If you've not thought about it before, how can I bring this up delicately? How can I negotiate between us agreements in a team without insulting or upsetting and still get my point across? If you've never worked on that before, there's lots of, "You can just do this and do this." It's like a magic trick. Sometimes, you think, "Surely what I need to know is the latest frameworks, the latest hard technology stuff." That's good, but these are valued just as much, they'll help you in your career just as much, so put some focus on them too.

Shane Hastie: What are these people skills? I don't like to use the term soft skills because they're often harder to build than some of the technical skills.

"Soft" skills are actually really hard [15:37]

Neil Vass: Absolutely. You can think of it like if you're doing all the tests, you hate those flaky ones that you might do the same thing multiple times. You keep running it, and sometimes it passes and sometimes it doesn't. That's a problem in tech, but that's how people work, so I can see the challenge of trying to get that right. Some things that have really helped me, there's a Camille Fournier book about The Manager's Path that talks really clearly about the progression.

If you were to go from just out of school, beginning programmer all the way up to a CTO or even higher, they talk about what changes at each stage and what you should be thinking about and probably earlier than you think. It's not like I'm a line manager now or I'm a head of engineering or something, and now I need to know some people stuff. It's on a team, day-to-day, negotiating with your peers and stuff like that where you can develop it. But there's some really good chapters in there saying things like, "It's at this point you realize that what got you here isn't the skills you need anymore." That shift as you get more senior is important.

Other things have helped when you're struggling with something in particular, there's loads of books and podcasts and topics to look into, so there's not one manual for how people work. But something that really opened my eyes about what was going on with lots of people is a negotiation book called Getting to Yes, so that's William Ury and some other people. This gets taught and lots of universities and stuff. I'd never heard of it. What I liked about that was as for negotiating, you want this and I want that, and we often think of that as I'm trying to buy a used car off you. I'd like you to lower the price. Negotiating is all the time. When we've got different ideas about how to approach something, how are we going to proceed? So that is pretty much most human interactions.

Even knowing that negotiation was a topic that I should be looking at was a light bulb for me, and what I loved about that was there's loads in there that I recognized from speaking to people, but I'd learned it as I think this individual needs that, you need to have prepared the ground, you need to have talked through this, you need to show you've heard them. Or sometimes, it's that department, like marketing people think like this. With this book, some of the tricks I'd done already, I realized that's how people work. "Oh, this is valuable. This is spectacularly useful everywhere," and there was lots of good things in there that just work in day-to-day conversations.

One thing that stuck out for me as just an example of something I'd never thought about before, and I've thought about probably every conversation since, sometimes it feels like if you think we should do one thing, and I don't think we should do that, it feels like we should use our time together to lay out my case, to talk about what's going on. But what that often feels like is we've got nothing in common. 100% of our talk is about us disagreeing, so this person doesn't get it. But quite often, both of us agree. You take it for granted and you've never considered, both of us want this product to be a success. Both of us think that do not on the web is the right thing, both of us, all kinds of stuff. There's a huge vast wave of stuff that we agree on, and it's on this little point we want to see how we can make our shared endeavour work.

The other part of that was sometimes it feels like you don't want to give somebody's arguments too much credit, because if I thoroughly understand where you're coming from and I don't think that's the way we should approach it, if I understand it and talk it through your reasoning, does that mean I have to agree with you, and that's not the truth. I can completely, thoroughly see where you're coming from and still disagree about what the next step is. More than that, for a lot of people, if I'm saying you're wrong, what a lot of people think is, "He's not understood me. He doesn't see where I'm coming from. I have to explain it again." Instead of listening to your side of it, they're thinking about how to reframe their argument and waiting for their turn to go again.

Instead, if I can reframe your argument, repeat it almost better than you can, the benefits and the reasons why it's valuable, that can often be the first time somebody relaxes and thinks, "This is someone who gets it, and he says we should do something different." That's just such an unlock bar for negotiating with people in all kinds of situations.

Shane Hastie: So this people stuff, you've got 18 years experience, you've moved into that leadership management role. What are some of the key skills or pieces of advice that you would give somebody who's wanting to step into a technical leadership stance or space?

Advice for new leaders [19:51]

Neil Vass: Oh, that's a good question. You're probably doing a lot of good stuff already. If you're a human navigating the world, like anything I've mentioned here, you've done versions of already anytime that you've not just said okay and got on with a task you're handed, or anytime you've not just been suggesting things, and everyone goes and does it, you've had to negotiate what's going on here. It's not just that negotiation, it's the whole how does this team fit together, what skills and abilities do we have or need, and how can we help build them? Thinking about what you've done already is useful and what areas have you sort of enjoyed or found success with? That can give you areas to lean on and think about doing more of.

Another important shift, I think, that really helped me to think about leadership is your job on a team is to maximize the output and the capability of that team, so you're trying to make your team understand what kind of work is valuable, to understand the impact of the work, and to get work out of it. Quite often, I thought of myself as, "It comes in, there's different cogs here, and my cog is spinning really fast," and you definitely know that that is not how the overall machine takes in more work and puts out the other side. What can you do, what can you suggest to improve the capability of the whole team? The kind of suggestions that come up with there is if there is somebody who knows lots of tech skills and knows all our systems and how they interact with each other, there's so much work that will come in that says it's faster if this person does it. But that's not true if 90% of our work goes in your queue for that one person.

Suggesting ways we can do that and things we've done there before is if work comes in, and this person's going to be 10 times faster than anybody else, they are not allowed to touch it. Someone else has to pick that up. This person could be there and watch. Do not touch the keyboard until you get to a point where it feels like more and more of a work. It's not an automatic send it to that person. There's that and other concrete examples about skills and abilities. If somebody's not doing this on your team, you can definitely suggest it in any team sessions or take people aside and talk about it and just say, "I'm interested in how do we help level up this whole team?"

That can be on lots of dimensions, so it could be how can we get more skills, more domain knowledge, how can we get more understanding of the impact? Did anything we released make any difference? Sometimes, people think they don't want to bore you with that, so just being an advocate for bringing that up in what little ways we could sprinkle it in just helps you and the people around you think more about the big picture. Our job here isn't just to churn through the tickets, it's to build all our skills, it's to understand the impact, it's to choose more sensible things to work on in future so we can do less and still get that business impact to meet user needs.

Shane Hastie: Your job isn't to identify the requirements, your job is to change the world. Love it. Neil, really interesting stuff. Some good solid advice there. If people want to continue the conversation, when do they find you?

Neil Vass: I'm still mourning the collapse of Twitter. I used to be on there all the time, but it's been a good few years. I've started my own blog at Neil-Vass.com, which is definitely where I'll write anything that comes into my head about this and many other topics. On there, it's got a list of LinkedIn and Mastodon and other social sites that I'm trying to do it, so absolutely leaving comments there or getting in touch on any social medias to ask anything or suggest anything that you think I should look into more, I'd love to hear about it.

Shane Hastie: We'll make sure that link is in the show notes. Neil, thank you so much for taking the time to talk to us today.

Neil Vass: It's been great. Thanks for having me.

Mentioned:

• Book: Lean from the Trenches
• Book: Getting to Yes
• Book: The Manager's Path