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

Transcript

Marc:
Let’s segway into a different topic. You started actually talking about it already a little bit with your quality controller coming in and having a slightly different agenda to what the team is trying to achieve that they’re interacting with. So one of your blog posts that fascinated me was you wrote about governance based on the talk that you gave. And so everybody has experienced this, you talk to governance people, and they will tell you about how governance is supposed to be enabling and supporting et cetera. And then you talk to the people who have to comply with governance, and they just see it as restrictive and making the spaces smaller in which they can operate it, et cetera. So complexity science will basically say this is because there’s two types of constraints. Well, there’s more than two types, but there’s two classical type of constraints. We’re experienced in this field, which… so complexity talks about governing constraints, which are there to stabilize the system. And then we have enabling constraints which are allowed, as opposed to enable novelty and innovation and emergence, et cetera. And they constantly have to balanced within an organization. So you said that in the blog post something about API as a strategy to deal with change. And so in the play with governance, how does that work? What is API as a strategy for change? What is the thought behind this? And then what is the role of governance to make that happen rather than to kill it off?
Matthew:
Okay. So in regards to APIs as a strategy for change. When we take a complex monolith and we decompose it into pieces, in theory, we have a greater ability for teams to deliver and, and give them more autonomy. So, if I’m writing to an interface, I can subsequently continue to iterate on my performance and my security and my so on and so forth. Knowing that that interface will subsequently stay relatively stable. And because I’m interfacing with other things through a well understood and stable contract, I can have a reduced communication overhead between the subsequent teams. They should be able to, continue to do what they do on their localized API, knowing that the subsequent product or experience or service that picks this up is going to be stable.
So rather than having systems that did that old quarterly release cycle, where everything is deployed all at once, and the big bang subsequently breaks things because it wasn’t tested all uniform and so on and so forth. By pursuing an API strategy, we can get greater agility through this decomposition, like people are able to run faster without subsequently having to deal with other people. So as far as APIs go, that’s subsequently how we can facilitate change. If, for example, if our cyber group comes in and says, ‘Okay, well, we need to adopt a uniform identity management model.’ In theory, those individual teams can pick that up as they need to, and their backlog. And we can roll that out and subsequently have peace and harmony at the end of it. And, you know, five o’clock beers. Now, as far as how does governance tie into that?
The first thing that I ask whenever I go into a company and they say they have some kind of governance, I am much less interested in the static artifacts that are present, like their style guides or their requirement stock, or even their templates. The first thing that I’m interested in is what is your process to change? Every corporation, every company is in the midst of constant and ongoing change. Their expertise of their teams are changing. The makeup of those teams is changing. The marketplace is changing. Their strategy is changing and their governance needs to ensure that it’s delivering the outcomes that’s needed by the company. And because those outcomes are always constantly changing, I wanna see how they facilitate that change. Yes. At some point it’s gonna be manifest in these artifacts, the processes and the tools and the standards. But do you have a group that only meets once a year and subsequently like tosses out a standards doc that is not read by anybody?
Or do you have a community of practice that’s coming together? And once a week, or every other week is constantly assessing. Are you driving the desired behaviors? Is there a problem? Is there a friction? Do we need to modify things? Do we need to change things? How has that changed performed? Is it one benevolent dictator? Is it a democracy? And we go, you know, consensus, how are these processes facilitated within your organization to ensure that whatever outcomes you’re driving with that API program are the right ones. All too often I see companies, they realize they have a problem. They produce way too many APIs, and they’re all inconsistent. People, managers try and build new experiences. They try and build products on them. And it’s like having a Lego brick and a tinker toy and a wood block. And they’re having to do way too much a bandaging of these things together. They just, they simply don’t integrate like they should. And so then subsequently, ‘Hey, we’re going to create a center of an enablement or a center of excellence. That’s gonna make all these things consistent and it’s gonna fix the problem.’
And one of the first actions of that group is, ‘Hey, we need to deliver something. Let’s go to Netflix. Let’s go to Twilio. Let’s go to Stripe. Let’s go to one of the other well known API companies, and we’re gonna take their entire standard stock. And we’re gonna say, everybody has to do it this way right now.’ And at that point it’s a lost cause because they have a complex environment with people doing behaviors that have already been done. Obviously some of those behaviors aren’t good. There’s some inconsistencies that are leading to this lack of integration, but by borrowing somebody else’s artifact that was created in a completely different context, and by requiring all of it at once, what you’ve most likely led to happen… Even among people that are highly motivated and want to do a best faith effort, they’re gonna look at that and they’re gonna be like, ‘Yeah. Cool, bro. That’s not for me.’ And so one of the things that I really emphasize when going into these environments and talking with governance, one I talked about, ‘Show me your change process.’ Like even before we talk about the individual artifacts and the standards, how do you change? ‘Cause you’re gonna have to change. You’re gonna learn new stuff. You’re gonna have to change. And two, let’s start with the most impactful single thing that we need to drive better behaviors in one particular organization that was health routes. They didn’t have health routes for their APIs. And so subsequently they had no awareness of the operational health at the most simple level of whether things were up or down. So before we adopt Netflix’s API standards, let’s just start with, everybody needs to have a health route. If you are going to have an internally consumable API, you have to have a subsequent health route that we’re going to monitor and we’re gonna put on a dashboard.
Okay. So how do we make that real? What is our process for ratifying that, how, what is our language? Are we gonna capture that in an architectural decision record? Are we gonna communicate that out? How are we gonna grandfather the stuff that’s already out there. So even with that one simple seemingly inconsequential thing, we’re already having to find all this nuance and understand how do we make this real? And what I often tell folks is to do that for the uncontroversial stuff first, because you’re gonna have a ton of stuff you need to figure out: your communication plan, your enforcement plan, your reporting plan, all of that needs to be included, but you gotta do it for the uncontroversial stuff. Because when you do get into the weeds on contentious stuff, that’s not when you want be figuring out how you’re gonna roll that change out or how you’re gonna grandfather the existing stuff. So that’s a very long-winded answer, but APIs enable change within organizations, but they have to be accompanied by a governance group that is enabling change and reacting to the environment and driving the desired behaviors. If that governance group is static, that’s when you start getting into that bureaucratic top-down weirdness of, ‘Well, what do you mean I need to do these seven odd things and at the end I need to sacrifice a virginal chicken. Like this makes no sense. How is this related to the outcomes I’m trying to drive right now?’
Marc:
I totally agree with what you say. So the curiosity that I have is, in my experience, traditional governments bodies within organization are not equipped to do this mostly because they’re actually too small. So as I listened to you, what I heard you saying is actually there need to be a fair amount of conversation going on. The bigger the organization, the more fragmented that conversation might become. So I experienced one positive example in my consulting time. And essentially what we did there was we turned the problem around. So traditionally your model is you have a governance group, they have some quality standards that they’re governing and everybody has to come to them. So they become the bottleneck. That’s how you end up with your culture to release this, basically, ‘cause that’s the capacity they have to consume the tests, et cetera they need.
And so the way we turned it around was, well, what you learn is that the teams that have to jump through these governance hoops, they actually start to develop expertise about the governance standards, et cetera. So you actually have people within these teams that are governance experts who are just not recognized as that. So what we did was we turned it around and said, ‘Okay, they become part of the governance group in a sense of how are we driving change from a governance perspective.’ So we have conversations with these experts and let them consult. And how could we embed the next quality team, et cetera. So governance becomes a service almost like you have a service design or UX or et cetera, that teams can consume. And you use these expertises that are already exist in your organization to create the capacity to do that. So you start recognizing it and acknowledging people’s expertise, which previously you didn’t. So these were often BAs or technical architects or et cetera, and they were not recognized for governance expertise. So you just turn this around. But first of all, this can be a very lengthy process. So it took a couple of years in that organization. And then secondly, also when there was a little restructuring of that organization, the relevant people to keep it alive were removed and it died. So very fragile. So do you have any experience where this is done well and how it has been made sustainable?
Matthew:
Right. So like what you’re talking about is very much the, the concept of rather than having power over the governance group, having power over people, you’re talking about power with or power to. And in the organization, one of the examples within capital One is we only really got traction when our governance group stopped being power over and started being power with the lines of business that we were talking with. And we had the exact same issues: turnover among these federated individuals who were more than happy to help us out and work with us and recognized it as part of their job function. They’d leave for other companies or they’d get a different role or opportunity. And then therefore we had to go find somebody else. And so for us, it was absolutely instrumental that at the same time, we’re revisiting our standards and our processes and making sure that they were aligned with outcomes.
We were also grooming and raising our next generation of federated folks. So it was a self-replicating type of activity. So we didn’t have a single point of failure in the for example financial services line of business, when that one person left. We had a training operation that was about building community, bringing people into the fold, getting their activities, recognize their formal job description. It wasn’t just side of desk work, formal job description, making sure that we had the performance reporting back to their managers, letting their managers know, and their peers know how effective they were. Within any company there’s currency that can be expended. In capital one, there was formalized mechanisms for recognition and, you know, providing those on a regular basis. Like, ‘Hey, that person, they’re doing awesome. They helped us out. We have metrics to show what a positive influence they are within their organization.’
And then we subsequently would know that not only did that person now have currency that could be spent during their performance conversations, like, ‘Hey, check it out, I’m doing really well.’ But then their managers got a clearer sense of what good behavior looked like in the organization. And the managers then subsequently would help spread that out to their other folks. Like, ‘Hey, you know, I’m not getting this kind of feedback for other people. Maybe you should start doing this thing that this person was.’ So as part of the power with and power to activities, I had time set aside, like I needed to go and I needed to perform these kind of grooming opportunities, help build and sustain the community with the kind of performance, and making sure that that work was flowing through our already established mechanisms for rewarding performance and rewarding and acknowledging good behavior.
Kristof:
Okay, so, it’s a little bit of a segway but I want to continue the exploration of this topic. Before you mentioned coherence, and I’ve been spending a lot of time thinking about coherence. I’ve been talking to people about coherence, and often people get back to me like, ‘I don’t really get what you are talking about.’ So, I would love to hear your definition of coherence, and then immediately connected to that, what are the methods that we can use to help create coherence. We’ve already talked about governance as one tool for helping coherence to emerge, but do you know about other aspects that could be used to facilitate coherence?
Matthew:
Right. So I have a, a blog post from a while ago where I explained coherence with salt and pepper shakers. So there’s two concepts, there’s consistency and there’s coherence of an interface design. And so I had a picture of a salt and pepper shaker where perhaps you had a salt shaker and a pepper grinder. And I said, okay, in this example, you have an inconsistent interface for how you apply these things. There is coherence, you still are applying salt and pepper on your food to, you know, to season to taste. But there’s an inconsistency with the actual implementation of these things. And then I then presented there’s spray-on salt, I guess, for people that really want that beach smell. It is a product, it does exist, but then there was also pepper spray.
So showing these two, a picture of these two things, I would say, okay, the interface is now consistent. They’re both sprays, but you have an incoherent usage. You do not wanna use the salt spray and the pepper spray together. That is not a good experience. So it’s a simplistic analogy, but that’s how I explain the difference between consistency and cohesion. Cohesion goes back to, you could have inconsistent interfaces, the salt shaker and the pepper grinder, but they’re still cohesive because you use them together to achieve something. So going to the next part of your question about, what are other ways of doing it? Obviously I’m a big believer in governance because that’s what I help implement within companies. But I also think there’s a fair number of companies that lack a clear vision for what they’re trying to accomplish in their companies.
When it comes to their digital transformation and digital efforts, they perhaps have the equivalent of an airport advertising campaign. Let’s all be digital because that’s kind of in the air and they know that that’s something they should be doing. But what does that practically mean to teams, to people in the trenches? They don’t know. I oftentimes will press this point with people. Are we talking about digitization? Or are we talking about digital transformation? And if I see those blank looks, I’m very quick to explain, well, digitization is doing what you’re already doing more efficiently through the use of software. Completely valid. Lots of people are doing that, good for you. But when we talk about transformation, what we’re talking about is new ways of delivering value. So if I go into a company and they’re dead set on transformation, but they haven’t changed their business structure, they haven’t changed their people, they haven’t changed their processes? Now I’m skeptical. Now I’m like, ‘Hmm, okay. Something is not going to work. You’re, you’re keeping everything the same, but expecting a different result. We have a problem here. We have a mismatch.’ So the vision setting the statements, the articulation of what that is, and then connecting it to the actual job functions of the people. Like for me, that’s another area where it’s lacking, a lot of times. We need to have a north star. We need to have a vision, but then we need to go to the next step level. And everybody needs to understand how their job then connects to delivery on that vision. And then just general communication. The result of a lot of this activity, we talked about APIs and how, you know, you set aside these boundaries and then people can be autonomous within the boundaries. And that allows them to deliver a lot of work. Well then subsequently, we still need that coordinating function.
And in some organizations, you have a very strong product org that is able to reach across and put Humpty Dumpty’s pieces back together. Again, that’s awesome. Sometimes that’s a really capable engineering manager who can look across that environment and recognize how these things need to roll up into the value generating proposition for the company. Sometimes there still are enterprise architects who can see that larger picture, but regardless of job function, like what is that thing that provides the alignment and the cohesion between the pieces being created, who is monitoring all of these things and breaking down the silos? That is an incredibly important thing. And going into these companies, sometimes that needs to be established.

Kristof:
And then, it’s two thoughts. One, I am just taking Ruth Malan’s training course on architecture and all the good stuff. And one of the things that came up in our class is that building good software is about first forming a theory of the problem, and then also forming a theory of your solution. And then co-evolving them together as you learn more about the things you are doing. Creating a coherent API initiative is maybe having a theory about the platform that is going to enable you to create new business value. And then actually executing on that platform in the shape of APIs. So that was one thought, and then the other one was coherence and alignment. I don’t remember where I read it but I read it this week. Marc, you are amazing, you remeber everything you read, and then put the attributes… well, much better than me.
Marc:
When I the quote stuff, I remember where I read it.
Kristof:
I need to look it up, but it was an article in which it was explained that you can have coherence without alignment. And that in a top-down structured organization that’s the more traditional model, the default idea is that we have to get alignment. Everybody needs to believe the same story and we’re gonna force it down their throats so that we can get coherence. And this is the old way of getting to coherence. And it works, it’s kind of a struggle, maybe it doesn’t work. But there’s another way, that is a lot like jazz music, where you are doing a lot of things that you are describing, basically tending to the humans and making sure that they start believing similar stories and they start having identities that are congruent with each other. So that they can actually act in unison and have a coherent platform that then comes out at the end.
Matthew:
Yeah. The, the whole forcing it down their throat is not, not something that I established. You know, oftentimes I’ll be talking with leadership and we’ll be talking about the vision, but an aspect of that is how do we enable the co-creation. Maybe the executive leadership has some idea of where they want to drive things, but it’s not a matter of then subsequently military style, like dictating how the rank and file will march. It’s about, this is the vision where we’re gonna go now: subsequently, how are you going to play a part in that? How do we enable you to have an ability to co-create your subsequent part in that, that larger vision? And so I like your jazz metaphor. You know, there’s no single piece of sheet music that is dictating exactly how people are going to perform in that environment, but there’s still somebody who takes the initiative. You know, whether that’s the percussion or the lead, you know, saxophone or something like that, there is still somebody that sets the mood and the tenor and the tempo, and people then participate within that invisible structure, that invisible network.
Kristof:
I just looked it up, it was an article from Ben Mossior and Jabe Bloom, from a training they did together, this is from where I got the reference to this alignment versus coherence. I think it always comes down to be mindful of the humans.
Matthew:
Well, that seems to be a bit the tenor of this conversation now. So I think a lot of traditional views, or I don’t how traditional they are, because if you dig into the past, you find they’re not quite like that. So it might have been a second half of the 20th century view of organization became very technocratic, almost mechanistic and what we’re seeing now. So a lot of what you actually said is there need to be conversation. There need to be part participatory processes where, and it’s not just about getting buy-in from people, but it’s literally getting the views of people from various aspects of the organization together to get complex change happen. And so I don’t actually think this alignment by pushing it down their throats ever works. If it works, it works very short term but it’s very brittle because ultimately people don’t buy in. So you can short term create a bit of pressure that they just all feel they need to comply with, but they will as soon as possible, try to break out of it. And so the coherence actually comes exactly from, ‘Can we create conditions in which people can pursue their own goals while keeping the whole thing together and moving in a sensible direction?’
Well, and creating those identities just to kind of bring it back. Here in the US, you know, I think we probably dialed up individualism to 11. The idea that the individual is the sole important unit within a workplace. And so the idea of teams is kind of there, but the teams are really just there to facilitate the individual goals for as long as the individual is within the company. And then subsequently they either get promoted or they leave. I think in the US, the one thing that we do need to do a much better job about is creating that sense of we, rather than the sense of I and when I look at my European counterparts, I see that there’s not this need, people understand that there is value in a group dynamic and that they are, you know, there’s much more to a team than just who you report to. But in the US, I think we need to recapture some of that. We have way too many lone cowboys, and they’re almost always cowboys, very few cowgirls unfortunately, yeah we need to change that script as well. Way too many lone guns for hire and subsequently, we don’t have the opportunity to create this larger identity that’s trying to fulfill a purpose. It’s all about, you know, ‘What do I get out of it? And then if I don’t get what I’m looking for, I’m outta here in 8 to 16 months.’
Kristof:
And with the speed up of this churn in organizations, this is getting harder and harder because, you know, I’ve seen organizations where the longest tenure in the team was two years and I’m like, ‘What do you mean? Like after one year you’re finally starting to become productive.’ So by the time you’re leaving…
Marc:
There’s even philosophies now propagated that you should dissolve the team every two years. But that’s what I mean, if you go and dig into management theories. And so from, let’s say the first half part of the 20th century, then I think, again, that’s a pendulum. So between individualism and the collectivism, it’s interesting that you say the Europeans are better than the Americans because, okay. At least in the UK, what I see is suddenly all drive to oh, talent talent. So they want the lone guns to solve all the problems. And the idea of teams seems suddenly less attractive. That might be less the case. And I don’t know, Belgium, Germany, et cetera, but in the UK, they’re looking across the pond and saying, what has made American companies so successful and try to imitate that, they believe it’s individualism. But if you look at management history, so to speak, that seems to be a pendulum where we’re going back and forth between believing in geniuses and talent that come solve our problem. And then going back to, ‘You know, it’s actually teams that make change happen and innovation.’ And yeah, that’s interesting to see where it swings.
Matthew:
Yeah. I certainly hope it is a pendulum and we are moving back toward an idea that the sum is greater than the parts. I’ve seen effective teams. And I do know, I was talking about that model earlier about, teams being broken up and now suddenly the parts are not as effective as they were before. In my head, I wanna be on a team that is productive and has an identity of how they’re delivering things and that I feel like it’s a force multiplier for my impact and my work and my relevance for the most productive hours that I have every day. I certainly hope that the whole idea that we’re gonna have all these genius individuals and they may be jerks, but, you know, they’re very productive jerks for the nine months that they’re here. I hope that is an interesting footnote in our development history because ultimately the most rewarding times that I can think of wasn’t about the individual pieces of work, it wasn’t about the bullet point that I could put on LinkedIn. It was about the team that I worked with and my fond memories for what we were able to accomplish. So I sincerely hope that that’s the future of work and not the anything else.
Kristof:
I think that if you are embracing your diversity as an organization or diversity in general, you need time. Like to make diversity jam together or jazz together. And I just looked it up and the jazz reference came from Sonja Blignaut. She had an article about coherence and all that jazz. But you can’t drop a classic musician and drop them into a team into a jazz team and hope that they’re gonna be able to perform. They don’t have the context, they don’t understand. I don’t know if you can have just musicians just popping into each other’s shows. I think they probably need some time together just to get used to how they’re doing things. So yeah, I also hope so. I imagine that maybe this is a differentiator as a business. If you can, if you can create the setting where people don’t feel the need to just run off to the next career move that maybe this is the thing that can really set you apart because you can just have much better teams.
Matthew:
Well, we’re talking about emergence, emergent properties between people where you have individuals and that emergence doesn’t just naturally happen. You can’t shake your finger at somebody and say, ‘Okay, now show me some emergence.’ And especially your point about diversity is spot on. The reason that people are diverse is because they have different experiences, different backgrounds, different predilections, different preferences. It will take some time for individuals to figure out how do we interface with each other? How do we, you know, when he’s, you know, going back to the jazz metaphor, when he goes on a run, that’s gonna give me an opportunity in two bars to then subsequently come in and do my thing. It takes time to get that kind of familiarity and know how you can work with each other. So I’m still figuring out what are the formalized methods or activities, it’s more than a trust fall. We all know that, but what are those ways that we can get people comfortable creating that shared identity, creating that group sense and creating that ability for emergence to then subsequently start coming to the fore?
Marc:
Well, if you find it, you need to come back and tell us.
Kristof:
I believe that APIs are kind of like the nerve system for multicellular organisms and this is like a new layer of decoupled meaning creation or, this coherence thing is about… so I believe that if you don’t understand this, you can’t do well. Your ability to be successful at APIs will be limited because you don’t understand that you need to be looking for coherence. That it’s not just about building products, that’s the other thing people are like, ‘You know, API should be a product.’ ‘Okay, great. But, you know, that’s an outward facing thing. That’s not necessarily something you’re using to build other stuff on top.’ So if you’re building an internal API program, probably you need to manage it differently. You need to manage it for coherence rather than for variety or for product-market fit.
Matthew:
It was when I was reading, I forget the actual author, but I was reading about how they were saying that the power within the system is in the interactions. And for me, I had two thoughts. It was immediately, ‘APIs are the place where those interactions are happening,’ but then the second thought was, ‘Oh my gosh, it’s the interactions between the people as well.’ And, you know, we assume like all of this is programmatic that’s happening in there. No, these are lines of communication that are now being rewired within the organization that are subsequently like creating brand new interaction patterns. I was like, ‘Oh, that’s the thing.’
Kristof:
Exactly. And it’s not just taking a standard operation procedure and, ‘This is your manual.’ It’s about creating that freedom where people can do their adaptiveness, but then with a clear, nice structured set of constraints that enables them to be more productive and create better places to live and to work. Probably that’s also how we get teams to stay together longer, because it’s a better space for them that they’ve created for themselves. Right. We’ll see. Thank you very much for going with us through the rabbit hole.

You may also wish to listen to part 1.