Show me your change process! Conversation with Matthew Reinbold - part 1

 

Transcript

Kristof:

I’d like to welcome Matthew Reinbold who works for Concentrics catalyst API practice group which is a consultancy that provides consultation services worldwide to help build mature and sustainable API programs. Matthew, you are the digital engagement leads specialized in API governance and social technical systems and API program design. So we’re really excited to have you on the podcast because you have some of the magic terms in there. And I also kind of understood that you even have a book coming about complexity. So welcome Matthew, thank you for joining us on the podcast.

 

Matthew:

Well, thanks for having me. Just to flesh out the background a little bit more. I’ve been doing web technology for the last 20 years and, and caught the mobile bug. Back before the iPhone, I got involved with APIs when it was a matter of trying to get the data to these little compact flip devices that we all had started doing APIs. There came up as a developer and through a number of different roles, increasingly got higher and higher in the hierarchy. So rather than managing just a single API, then it was a suite of APIs. And then it was a division of APIs. And during the course of that growth, I found myself in a position where I was managing the API governance for multiple fortune 500 companies. And it was at that point, that things switched. It was now suddenly less about the technology and more about these vague abstract forces that seemed to be buffering our initiatives.

 

And at first I couldn’t quite get my hands around it, what’s going on? Why isn’t my perfect solution “Perfect”? In air quotes here for the audio audience. Why, why isn’t my technically sound solution, my rational argument, why isn’t that enough to cut through and help me have success in these complex ecosystems that I was finding myself in. So that’s how I started down the path of thinking about complexity and these ecosystems that whether we acknowledge them or whether they’re still kind of these vague forces that, that shift around in enterprise environments. Like how do we, how do those things affect the success of our projects? And so, you know, through a variety of different experiences and efforts, I was stumbling around kind of piecing this together and then hit upon this large body of work that already exists. Thinking about complexity and social systems, socio-technical systems. And that’s been something that lately I’ve been very passionate about bringing not only to my own work, but then the solutions and consultations that I offer to customers, how to manage these large ecosystems and how to navigate these difficult things. So subsequently that’s also the, the topic of the book, like how to make progress in these complex environments, how to make change stick.

 

Kristof:

So one of my pet peeves is that complexity, because like in the software world, we look at complexity as something kind of bad or something that we’re trying to get rid of. Because complexity has a bad rep in in the software world. Well, one of the key understandings for me was that coming from this complexity literature is that, ‘Oh, actually complexity is a good thing.’ As long as you can contain it and not have its blow up in your face. It’s the thing that actually makes living systems work.

 

Matthew:

It’s dependent on the context, right? I mean, I don’t think you’d want your airplane flight to suddenly start exhibiting emergent properties. Right. Let’s define a couple things just to make sure everybody’s on the same page, because I don’t know the audience, if they’re familiar with this. For the longest time software development has been complicated. There’s no getting around it. These are interesting new ways of developing things and it’s complicated and it can be very hard. So running a marathon, even though it’s one step in front of another, it’s very straightforward, what you need to do. It’s still hard. So this is not a slight on complicated systems, but complicated systems essentially are well understood. There is one cause and effect. There’s one thing after another, if you do this thing, it always ends up the same way.

 

Complex systems, however, are the sum of the interactions. And those interactions are unpredictable. The more complex the system, the more likely you’re going to have an unpredictable result at the end of it. So even though you may be putting in the same inputs into that system, you may be getting different results. So when I talk about these things… you know, in the US, we had the stock market crash that turned out to be the result of the complex interactions between automated stock trading bots. Like every single one of those things was doing exactly what it was programmed to do. It wasn’t a bug in the system per se. It wasn’t debugging a complicated system. It was the emergent properties of all these things playing together in the interactions, which subsequently wiped like 3 trillion dollars in the course of a half hour off the stock market. So to your point, there’s some very exciting things that can happen with emergent properties. And we can develop software that can create new products and services and experiences through the reduction that we see in like APIs and microservices and distributed systems and so on and so forth. But there are certain systems where you still want to have a complicated, not a complex system where you have to have the same outcome every single time. Those probably need to be complicated systems.

 

Kristof:

And I definitely don’t disagree. Oh well, that’s a double negation. So I agree with that. I believe that it’s the humans that are anyway going to be complex in your system. So, and every single system we build there’s humans, at least interacting as a user, but also building these systems. So whatever software we put out is always going to be interacting with a complex world. And because of that, you know, we’re gonna get complexity no matter what we do. And then I think it’s about figuring out where do you want the complexity to happen? And at some level there’s always complexity happening. You know, if you zoom in enough, you’ll find it somewhere. You just want to put it in the right pocket so that it doesn’t start crashing your plane, or something else, or crash the stock exchange.

 

Matthew:

Right. Absolutely.

 

Kristof:

Marc, what are you pondering about?

 

Marc:

So I’m a bit curious about, well, there’s two things you said already that I would like to dig a bit deeper, but let’s start with one. So one, there’s this thing that you said about, how do you actually apply the understanding of complexity? When we’re working with customers, and so most customers that we’re engaging with will not have any understanding or not that level of understanding of complexity. Often, as you say, we have to start by actually defining what we mean by it when we even talk about it, because they’re not familiar with these distinctions. But also then especially if they’re company leaders or execs or so then they’re often really focused about the negative sides of complexity. As in, ‘We did all these lovely plans and they didn’t happen and why did they not happen?

 

And it couldn’t possibly be because our plan was wrong.’ So in my experience, this is always a difficulty almost to the extent that I often wish I could avoid working with people who have not already accepted complexity as part of the world, the way we obviously have. So how do you make this palatable? How do you open them up that they’re at least willing to entertain the consequences of complexity and rather than just seeing it as something that has to be removed or reduced, the way also that they see it as an opportunity. So do you have any recipes or insights on how to do that?

 

Matthew:

Yeah, the first thing when exposed to a new environment or a new company, I don’t go in talking about complexity. Like it’s always started with, ‘What are you trying to do? How do you deliver value? What is valuable to you and what have you tried thus far?’ I think that’s the biggest thing, setting it in terms of how they characterize the problem and what they’ve tried to solve, how they’ve tried to solve it. And so then taking that and saying, ‘Okay, now I see that, yes, you’ve gotten everybody aligned and you’re all producing lots of microservices. Oh my gosh, every time we turn over another rock, there’s another microservice! You’ve been very efficient in incentivizing your company to do that. And now low and behold, nobody knows exactly what is going on. And everything is a murder mystery, whenever there’s a bug, because they have to call in Everybody, because everything has this loose coupling to everything else.’

 

And so then at that point it’s like, ‘Okay, now let’s actually talk about the incentive systems and the way that the environment is prompting your behavior and whether that is actually efficiently driving those outcomes that you’re trying to achieve. Yes, from a technical standpoint, from maybe the CTO standpoint, creating a lot of microservices was a signifier or an example of how they could drive the organization forward. But ultimately that’s not a business outcome. Then this is where the language is very… you have to tread carefully because you don’t want to contradict the people that have brought you in. You don’t want to say, ‘Yeah, that plan was kind of dumb and you’ve incentivized the wrong behaviors.’ However, like working together, it’s like, ‘Okay, everything needs to track back to the business outcomes. So you’ve wanted to do something with your digital transformation here.’ ‘It wasn’t to create a bunch of these little fragmented pieces, which subsequently have introduced a lot of organizational overhead, operational overhead that now subsequently you can’t ship, like you thought you would. Let’s get back to what you were trying to do. Okay. This was part of a digitization effort to make things more efficient or maybe it’s about resourcing or maybe it’s about something else. There was business value. Let’s track that back at that.’

 

So yes, in my mind, I’ve got a complexity lens that I’m looking at things and using it to debug where things have broken down, but for the business I’m talking about value and ultimately the ends that they’re trying to achieve and subtly, like poking at what they might have told themselves as far as what they thought their goals were, and whether that was actually valuable to the business or not. So sometimes those microservices that they created do have some kind of business value, but more often than not this grand strategic plan that happened turns into a bunch of soundbites and little short snippets that through time, get warped, get misunderstood, get devalued and, and therefore then we we’ve got a problem because now our environment is prompting behaviors that actually don’t achieve that original vision. Did that answer your question?

 

Marc:

It was a good start, and resonates with me initially. Yes. You, at least initially, you do not use the complexity language. You use the value language, et cetera.

 

So it’s my experience that the only way you can actually start opening up the complexity topic is if you can point at something where you can demonstrate they already are facing complexity. So as you said, for example, having your microservices becoming a ball of mud, so to speak, that starts to have agencies on its own that you didn’t anticipate, and that is undesirable, et cetera. If they have enough technical understanding, you can take ‘em down that route and start talking about complexity.

 

But it sounded a little bit like you actually try to avoid it entirely? So keep them on the value language or are you actually trying to sort of…? So that’s what I do: I try to sort of entice them towards, ‘Hey, here’s your experience of a complexity. And let’s now talk about what’s the opportunity in it.’ So as Kristof said, so the way I look at the world is all the creativity comes actually from rubbing up against the complexity of the world. This is where the sparks come because it is unexpected. It is… You can’t anticipate it. It’s something novel that jumps into your field of vision, et cetera, that sparks ideas, et cetera. So I’m trying to coax them to the complexity view of the world, but often that can be a very tedious, long process.

 

Kristof:

I think the way that I started talking about it is that complexity is a source of value because complexity is something hard. And so if you can find an area in your industry where there’s complex behavior, or like the example I always use is a GPS routing, like, you know, the routes, the best route will take into accounts the complexity of the existing traffic. And so if you are really good at keeping up with that complexity, then you can do a much better service than anybody else. It’s basically, it’s a moat for your business, if you can deal with complexity in the right way. And then… but it’s a different type because I think you still, most of the time you’re bumping into the unwanted complexity of like, ‘Oh, this technological system suddenly has its own will and it’s doing stuff that I, that we don’t want, or we didn’t expect.’ Right. Have you had that conversation where it’s like ‘Well, let’s look at how this is going to actually make you un-copiable and stronger.’ Is that something that’s already ripe in the market or it’s still early?

 

Matthew:

Well, that’s something that, I mean, some people will want to entertain that, but in my experience many times I get the, ‘So what!? That’s a very interesting observation, Matthew, I have complexity. So what?’, And so what I’ve tended to do is steer people more toward the more tactile things. So getting really crisp on what actually are the behaviors that we are trying to drive going back to the microservice example. So obviously we’re not trying to drive a gajillion microservices and create a microservice death star that’s unmanageable. What kind of behaviors are we trying to drive? What was meant by that initial effort? ‘Well, okay. You know, what we’re trying to do is we’re trying to create sound boundaries. We’re trying to create that domain driven design.’ - ‘Okay. That’s great.’ I really like B.J. Fogg’s model here for behavioral design. He talks about three things being the basis of any kind of behavioral change within a group or a person. He talks about motivation. And usually that’s all we talk about when we talk about changing how people do things. We talk about motivation.

 

We assume it’s just a matter of, well, they just need to be more disciplined. Unfortunately, motivation is not the only thing. Two is ability, and sometimes this is addressed within organizations and they say, ‘Oh, well, we’ll just get some kind of online cloud learning platform. And that the ability will take care of itself. People will just spend time in their off hours and they’ll just learn how to do things.’ Which is a bad sentiment, but it also is still incomplete because we’ve had motivation and ability. And the third thing are the prompts, the environmental prompts to perform the activity. So most people are probably familiar with brushing their teeth before they go to bed. You know, that that action, going to bed, is a very strong prompt to perform an action. ‘I’m going to get ready for bed. And I’ve got this litany of things that I do before I go to bed. And one of those things is brushing the teeth,’ That may be at 9:00 PM. That may be at 11:00 PM, may be at 3:00 AM if I’ve had a really good night. But the fact is there’s a strong prompt in the environment that I’ve habitualized, and I do that thing. So taking that back to our microservice example, what kind of environmental prompts exist to get people to do that domain driven design? And so maybe there’s several different activities. Maybe there’s like events storming or the formalized DDD or bringing in a contract or whatever, but like, is there a prompt in the environment when starting a new project to do this thing, to define those boundaries and subsequently get a service that is logical and holistic and not just a bunch of fragmented pieces that subsequently the consumers don’t understand, but actually meaningful. So how do we design the process and procedures and subsequently then bring it back to the people so that we have the kind of desired behavior change.

 

So underneath this, we’re talking about complexity and how to change behaviors and stuff like that. But for the people that I’m talking with, for them this is actionable. This is a new project. This is, ‘I can put this person in charge of this. I have a path to making sense of things.’ And if I get the sense that, ‘Okay, you know, if they want to know the why, why are we going down this route? Why are we…?’ Well, okay, now we can start talking about complexity and like the interactions between all the things and the resulting hairball that subsequently we’re trying to unravel. But for the most part, people just want to ‘Let’s, let’s go, let’s go. What do we need to implement here? How can we start reporting out status? How can we start showing metrics that we’re making progress?’

 

Kristof:

I have a theory, but it’s basically a hypothesis and we need to see what happens. But I believe that in the next decades, complexity will become an integral part of, of successful businesses. That to be successful, you’ll have to have some smart way of constructing your complexity. That if you’re just going to try to build a complicated machine, you’re just not gonna be very successful. And I think that companies like the platform companies and the ecosystem builders, they’re already showing this. Actually APIs are very much a part of that because it’s a tool for building ecosystems and for building a much richer network of players that are interdependent, interconnected, adaptive to each other. Do you see this already playing out in the companies you’re interacting with, or are they already aware of this?

 

Matthew:

I see it as a pendulum and I will say that I can only speak for the US. But what I see is over the last 10-15 years, there has been a movement away from formalized organizational design, where there were people whose job it was to maintain some kind of holistic consistency or cohesion across the company. So I’m talking about job families like business analyst, enterprise architecture, there’s a few related ones.

 

Kristof:

Technical writers also?

 

Matthew:

To some sense perhaps technical writers. I could see technical writers certainly having that unique silo-spanning perspective on how things work because of their role of having to articulate how these things work in conjunction. But what I’ve seen in software shops in large enterprises is this–and I love developers, I came up a developer–but this deification of the developer as being the sole archetype of everything. So, you know, ops was incorporated into the developer’s role. And increasingly architecture was incorporated into the developer’s role. And those, those spanning functions, the things to provide coherence across boundaries slowly went away because it was assumed while we just give teams the ability to run autonomously as fast as possible, and will just make a lot of stuff. We’ll throw a lot of things at the wall and hope something sticks. And again, this is a very US, probably FANG, Silicon Valley type of perspective on how to run a dev shop.

 

But subsequently what we’re seeing now is companies getting in trouble because they have all of these very tiny fragmented pieces within their organization and an inability ‘cause they’ve lost the muscle, the muscle is atrophied. The inability to figure out how to put this back together. Nobody is minding the larger story across these siloed areas. And because nobody’s setting the vision and providing the alignment, then suddenly now we’re having localized optimizations. Like everybody needs stuff to do, and they want to have stuff to celebrate at the end of the quarter. And so like they’re making their own pieces run faster, but putting, putting that back together and things are awkward, things are, are weird. The interfaces aren’t, aren’t seamless. They don’t, they don’t feel well when they’re meshed together. So again, I’ll caveat that huge simplification and stereotyping here, but I do see that. And so as a pendulum, I do see us swinging back toward needing that coordinating function, having the people who are able to look across all of the works being produced and provide some kind of semblance of coordination across those pieces.

 

Marc:

Okay. So let’s get back to the second thing that you said early on that I would like to dig into a bit, that is complexity in connection with how to make change stick. How do the two connect or what has, what to do with the other in, in your experience and how, how do you make change stick?

 

Matthew:

So, I’m very interested in whenever there’s a new survey or a new article that talks about the failures of a new digital transformation effort, you know, and it depends on the source. Some will be like 75% of digital transformation efforts fail. Sometimes it’s as high as 90, but bottom line, you have these large efforts within companies that burn a tremendous amount of time and energy and money that don’t go anywhere, that fail in their primary goals. And so, is it because the people are just ill informed or not talented? I highly doubt that. Yeah, the percentage would not be that high if it was just a matter of people tilting at windmills. It really, to me speaks that we don’t understand the complex factors at play when we try to introduce this new digital transformation.

 

So I worked for a large financial services firm in the US called Capital One. And because of our success, my team’s success with the API program, I would get thrown into various meetings. You know, somebody was spinning up a new initiative and they, you know, just wanted to have some brainstorming. And I remember sitting in a meeting and what was being proposed, represented a significant change in the daily behaviors for developers. It was warranted. It had some good rationale behind it, but ultimately people were gonna have to change their habits in a big way. And so I’m politely listening and we get toward the end of the meeting and I, you know, said, ‘Hey, you know how are you going to roll this out? How are you going to facilitate the change in habits that are going to be necessary? Right now, people are doing ABC. You’re asking for 1, 2, 3.’ And I remember very distinctly the vice president kind of waved her hand and she, ‘Oh yeah, yeah. We’ll, we’ll do training, the training’s taken care of, don’t worry about it.’ And I was like,’ What are you talking about?!’ Like, if it was just a matter of providing information, just per a matter of providing training, like all new year’s resolutions would work, everybody would…, all diets would be okay. You know, like there are complex interactions that happen in the course of daily business: people, processes, technology. And this was just a complete afterthought. It was just assumed that we were gonna drop this in. Everybody’s gonna take it up and we can move on to the next thing after we claim success. And low and behold, you know, six months later, it was completely stimied. That hadn’t gone anywhere because they had completely misunderstood what it actually takes to get people to change what they’re doing. So I’ve got other stories along the same lines, but for me, that’s where it connects. Like if we’re gonna change the organization, it’s not enough to just drop a tool in, we can’t just parachute in a memo and expect things to change. We have to address how things are currently done and how we bring people along to that new vision, that new set of behaviors that we want to accomplish.

 

Marc:

So how’d you do that?

 

Matthew:

Step one is about the stories, and I know as technologists, we’re… stories really can’t, I just list my pros and cons or, you know, Marc, you were talking about your background. Can I just do the Wardley map and put it out there? And everybody just accepts it as the way? And unfortunately it’s not so. I’ve got a post on my blog about what it takes to do stories, but the thing that I found, there’s like four or five different points. The thing that I found the most important is creating the new identity for the people in the story. It’s not enough to just say, ‘Hey, we’re gonna be a remote work organization from here on out,’ because that does not address the identity of the person who was the den mother, for example, or the the friendly boss that liked to walk the halls. What you’re proposing represents a loss of identity for that person. They’ve lost something in that move to remote work. And so therefore they are going to kick and scream and say, ‘No, we had the pandemic and therefore we need to go back to that thing where I identify, I had a role in that world and I want to get back to that role.’ So subsequently, you know, in providing that conversation and talking about changing behaviors, going into the complexity of it and saying, ‘Well, okay. Let’s talk about how you can still have that identity. What was it about that identity that was useful to you? Was it because you were engaging in interacting and getting the information that you felt like you needed day in and day out to perform your job that you haven’t had for the last two years? Is that what it is? Well, we can figure out the reshaping of that identity to still get you that information, to make you feel successful and useful.’

 

But just to say, ‘Okay, you know, here’s the memo, we’re all going remote work, everybody should comply. See you on Monday, online’ You know, that’s, that’s not good storytelling. I’m talking about going a level deeper. So, you know, talking about storytelling, rallying a team to support the effort and continuing to tell that story again and again throughout creating the kind of useful metrics to then subsequently show progress about those kind of things. All of those, it’s a set of engagements to look at the environment, understand the culture, understand the people and the complexity and how they interact and then be sensitive and give them an opportunity to be part of that change rather than having change thrust upon them.

 

Kristof:

I heard several words that, that are for me keystones for working with complex systems, one was Identity. One thing that I find fascinating is how individual identities and group identities work together, and how many identities can an individual have. Do you have your team identity? Do you have your personal identity? Do you have a company, a member of a company identity? How many can you hold in your head? Because I think there’s only a limited real estate for identity to some extent. Have you seen cases where you’ve also helped with the transition of group identity and… Or that was the storytelling that you were doing? How did you go about that?

 

Matthew:

So I’ll start with the story about how not to do it. One thing that I’ve seen in enterprise environments is where you identify a high performing team and you say, ‘Hey, congratulations, we’re gonna break you up now and move all your parts to other places.’ The idea being well, somehow this magical well-functioning unit is all made up of individual pieces. And if we just break them up and sprinkle the pieces across uniformly, these other groups will become high performing. And so obviously there’s a huge morale hit because these people probably liked working with each other and they are not nearly as efficient and performative in these other groups. And so there’s that group identity that you alluded to, that wasn’t addressed there. It was considered just, you know, they’re all replaceable cogs. ‘We’re gonna take the units and spread them out.’ That’s certainly not the way to do it. In that particular case, perhaps there’s not a role for that team anymore. And so going into that group and, and saying like, ‘What was it that you really valued about this?’ And then trying to bridge that with where they might be going. The practical reality is that sometimes a team needs to go away. Sometimes there is no longer a function for that team, but a successful manager will spend the time to actually know what the people are getting out of that group. And then making sure that that value is represented with where they’re going, as opposed to, ‘Well, I’m the boss. You just go where I say, you’re gonna go.’

 

Kristof:

So I’m hearing a lot of needs, like looking for the needs of the people and then making sure that those are answered.

 

Matthew:

Yeah. I mean, and well, and then going back to the identity, how do the people represent themselves? When I was running the API COE, we had to change the language that we used when we reviewed the open API descriptions that were submitted to us. At first, we had a development team that helped create this tool. So when teams were ready, they would create an open API document and they would submit it to the tool and we’d see it on our queue. And the API COE would go in and we’d, you know, work through the queue, very methodically. Okay, we’re going to meet with this team and we’re gonna talk about APIs and, and work through that. Well, the tool, as it was designed by this other entity, if we’d had problems with the design, we would click a button and the team would get a message saying ‘You’ve been rejected.’ Well, as you can imagine, highly paid professionals who are decades into their career–and we talked about that deification before–and have been told they’re so wonderful and so awesome and so critical to our ability to win. Being told that they’ve been rejected is not, not a good message. That is not a pill that they like to swallow. So we had to wholesale go through the tool and look at everywhere we had these interaction points with the people, and try and find language that aligned with how they saw themselves–highly trained technical professionals– and ease that interaction. We still had to have a back and forth. We still had to have a communication, but in clicking that button and trying to facilitate some kind of further evolution of the design, like we needed to say like, ‘Okay, you know, this is not a rejection.’ Like, ‘Hey, we see what you’re doing. We’d like to see if we can’t evolve this, if we can’t come to a better state, if we can’t…,’ You know, and so using language about iteration, which kind of ties back to their expectations on agile, using language about making things better, appealing to the craft of the whole thing that went down so much better than like, ‘You don’t know what you’re doing, get outta here.’

 

Kristof:

How do you balance between what could be seen as manipulation when you start massaging the message, and respecting dignity. Cause I think, yeah…

 

Matthew:

Yeah. This is a huge thing. Whenever I start talking about influence and prompts and behavior, I do see people start to contract, start to pull away like, ‘Ooh, this, this is Machiavellian. This is like, uh, I’m not, I’m not comfortable with this.’ And I guess the way I would respond to that is that these things happen whether or not you are engaging with them. If you are part of a large enterprise environment, there is a constant, ongoing shifting set of needs and concerns and outcomes. And you can either engage with that and try and create better outcomes for you and your team. Or you can completely ignore it and be a victim of that stuff that’s going on. And so when I talk about influence, obviously I very clearly say upfront, you cannot influence a behavior if somebody is opposed to it, like flat out. ‘You’re not going to trick somebody. Or if you do trick somebody that’s gonna happen once, and they’re never gonna trust you again, you have soiled that relationship and it’s done. Don’t burn that bridge.’

 

But when we talk about influence and I go back to the storytelling, part of the storytelling is not dropping into somebody and talking at them for the next 50 minutes, unlike this podcast. Sorry. It’s starting out finding out where their heads are at, what are they trying to accomplish? You know, if they’re trying to ship five APIs this year, but I’ve got a quality initiative, that’s probably gonna pump the brakes on it. I don’t just jump in and say, ‘Yeah, the thing that you’re hoping to deliver, that’s subsequently gonna get you the promotion? I’m gonna wave you off that.’ Like, that is not a good conversation. I need to start to talk to them about why they think that’s their objective, how they’re going to meet that. And then subsequently figure out how my narrative aligns with theirs, how we can co-design a story that gets them to where they need to be, but subsequently, also achieves my objectives. It’s these kind of engagements, these kind of conversations that I think we so sorely lack in the space. And you know, is that something that we’re just destined to not do? Like, you know, developers just can’t talk to each other. I don’t believe that at all.

 

Kristof:

But it’s not just developers. It’s everywhere. Like there’s this company and I’m forgetting their name right now, but they have a workshop called ‘Stop motivating your employees’ and the core idea is that as soon as you start, if you believe it’s your job to motivate your people, you basically believe that you’re gonna have to manipulate them. And you’re basically not treating them as adults anymore because now you’re treating them like, children. That’s like, ‘Oh, let’s do this shiny thing.’ And that’s both like, yes, you shouldn’t use sticks. That’s not a good idea, but also be careful with your carrots because your carrots are as manipulative as your sticks. And there’s a way of treating people with dignity, where you respect their existing identity and you show them like, what is the needs? That lets you to this identity that is a constraint that helps you to fulfill your role in your organization and how can you transform it so that you can stay who you are, but become useful again, in this new place that you have to go to. Well, this is the hard work and often it’s a lot of work. And that’s, you know, you can’t take shortcuts with these things.

 

Matthew:

Right. Yeah. I agree.

 

Further onto Show me your change process! Conversation with Matthew Reinbold - part 2