Using Behaviour Stories to Manage Cultural Debt

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down, across 12 time zones, with Ahmad Fahmy. Ahmad, welcome. Thank you for taking the time to talk to us today.

Ahmad Fahmy: My pleasure. Thank you for making the time.

Shane Hastie: You've been a contributor to InfoQ a few times but we figured out this is the first time we've actually spoken in-person. So, really good to see you for a change. So, you and I know each other, but tell me a little bit about your background.

Introductions [00:47]

Ahmad Fahmy: So I was a developer in the late '90s during the pre-dot.com bubble bursting, and was developing for about a decade, and then generally followed the normal development path as the industry was moving to outsourcing. I became a project manager, a program manager basically in the bank I was in at the time, trying to be a director, effectively.

And the path was one where development was a commodity. It was a commodity you want to move away from technology as soon as possible. This is before the software-craftsmanship movement and Uncle Bob and all that kind of stuff.

So I became a project manager, program manager. By around 2006, 2007 I was running strategic projects in a large bank in the UK. And at that point there was a major inflection point where it was discovered that most major projects were failing.

And so, we shifted to this thing called Agile, and then started this massive transformation at that time around 2007, 2008. And then from there I really fell in love with this idea of organizational change and continuous improvement and the entire culture that was Agile, and made me quit the bank. I started doing it independently for about the past decade. So that's me in a nutshell.

Shane Hastie: Agile has become the thing everyone loves to hate at the moment.

Ahmad Fahmy: Yes, exactly.

Shane Hastie: What's happened?

Adopting agile ways of working are fundamentally about culture change [02:14]

Ahmad Fahmy: To me, it's almost intellectually lazy to just hate Agile, how Agile sucks, Agile doesn't work. What sucks and what doesn't work and what's incredibly difficult is changing the culture of an organization, or even changing the culture of a family or yourself, or changing your behaviours. It's incredibly, incredibly difficult.

So this idea of Agile doesn't work, Agile sucks, no. What doesn't work and what's incredibly hard is to change the culture of an organization. And so, I have a problem with this whole just blaming Agile or blaming a particular framework.

We're in the business of culture change, and I don't think there's anything more difficult to do in an organization. And so, there's parts of Agile that I don't like, like they're overloading it with some practices and moving away from, like Alistair Cockburn calls it, the Heart of Agile.

I do agree there's parts that I personally don't like, and the overloading I don't like, but just blaming everything on Agile is, as I said, to me, an intellectually lazy exercise.

Shane Hastie: So culture change is hard, organization change is hard, people change is hard. Why is it necessary?

Changing culture is like creating an ecosystem [03:18]

Ahmad Fahmy: The analogy I like to give or the way I think about why it's necessary is that, I don't know if you've ever owned a saltwater fish tank, it was a hobby of mine for many years, and this is how I think about all of this.

If you want a saltwater fish tank and you want to have the most rare anemones or specific fish to thrive, clams and things like that, you have to manage one thing above all else, you have to manage the one thing you don't see, which is the actual water itself.

If the water is not balanced and managed almost perfectly, the fish will die, or specifically, your most beautiful fish will die. And what will remain are your super-resilient fish that no matter what happens, they're not going to die. And to me, organizations are almost the same thing.

You need to manage the one thing you don't see, which is the culture, or your best talent will leave, and you'll lose the inherent beauty, the ability to create beautiful things. And so, to me, if you don't manage the culture very carefully, it's almost like not managing the water of a saltwater fish tank. Only the crap will remain, basically...

And it's a lot like the story that's permeating everything right now, Boeing, is the perfect example. Boeing had this wonderful culture, and it was subsumed by another culture when they merged. And they had this culture of real radical transparency.

And one of the major leaders at the time decades ago believed in transparency so much and say, "If you're not transparent, if you do not tell me early and often what's going on, then..." I think he said, "I'll rip your head off and I'll crap down your throat."

Maybe that's not too much psychological safety there, but he was so insistent on this culture of radical transparency and research and development. And then they merged with a company whose culture was effectively all about the bottom line and all about stock buybacks and pushing the stock price further and further.

And effectively, what you have right now is, the net result of that is not just the loss of profitability, it's actually loss of life. And so, to me, there's nothing more important for a leader to do than match culture. It's not something I... I don't say this, great leaders say this.

It's one of the things that I find, especially with this whole push to quarterly returns, quarterly returns, quarterly returns, leadership is managing that above all else, and not managing culture.

Shane Hastie: If I'm not an executive leader, if I'm a team lead, an architect, somebody in the technical space, how do I contribute to culture?

How can a team leader contribute to culture? [05:58]

Ahmad Fahmy: That's a great question, because the way I think about it, and none of this stuff is exact science, but for example, I'm American, America has a culture, this macro culture, but then, if you go to New Jersey and California, they have separate cultures, and even within New Jersey and California, if you go to certain cities, they have their own cultures.

And so yes, there is a culture for an organization, especially these large multinational organizations. And then, those should not be ignored. That cannot be ignored. But I do believe that there's micro cultures as well between teams, between divisions.

And so, I think even within a team, and a team leader can create a culture for that particular team that's far more superior than the culture of, say, an adjacent team. So to me it's a false dichotomy that only the Steve Job’s and only the Elon Musk’s and only these organizational leaders can change the culture. I believe that there's micro cultures that can be changed.

And you'll see it. I'll work on some transformations and the organization will have 15 teams, and people will say, "I want to work for that team, I want work in that team," because that particular team has a specific culture.

Shane Hastie: So what makes this culture?

Culture is the behaviours that are accepted in a group [07:11]

Ahmad Fahmy: First we have to, I guess, define culture because it's one of those words, like love, that mean nothing and mean everything. And so, of course, there's the standard definitions of culture by PhDs. And I'm not a PhD, I'm a practitioner. I have my definition of culture.

And to me that's the codified behaviours of the organization. It's the behaviours that have become accepted over time. And I subdivide those into adaptive and maladaptive, and these are not my terms, these are B.J. Fogg's terms, but adaptive and maladaptive behaviours.

And the things that I focus is on the maladaptive, or you can call them toxic or cultural debt, or whatever term you want to use, but those are my focus is the maladaptive behaviours. And where they come from, in my opinion, they come from times of stress.

So, when an organization is stressed, even when a person is stressed, I mean, think about it, if a person is stressed, that's when the bad behaviours come out, that's when the donuts, the cigarettes, or whatever, the yelling, that comes in times of stress. When those triggers routines, they become codified within the organization and generally accepted, that's when they become part of the culture.

Shane Hastie: How do I influence this?

Ahmad Fahmy: That's the question. Okay, so there are those that believe that the only way to influence culture is to change the structure of an organization. Culture follows structure. And by those I mean, Peter Drucker, amongst others, this is an established idea that in order to change culture you must change structure.

But I don't believe that. I think that's a false dichotomy, if I don't change structure, then I cannot influence culture. I think there's also ways of changing culture at the micro level, almost like borrowing from Toyota Kata or Lean, this idea of continuous improvement.

Now, I think you can continuously improve or even have marginal gains on the cultural front. So I think that it's not just you have to change structure, I think you can change culture at the grassroots level as well. At least that's my cognitive bias.

Shane Hastie: This leads me to behaviour stories. Tell me about behaviour stories, what are they?

Ahmad Fahmy: Well, they're BS, for short, you know?

Behaviour Stories as a tool for culture change [09:31]

I guess the best way to explain behaviour stories is with a story. It begs to be told as a story. And the context in which behaviour stories was born was, a large financial services company that's been through multiple Agile transformations, and that particular division of your organization was really fractured.

And by “fractured” I mean the business and the people who want things and the people who deliver things were basically no longer talking, in a sense, actually so much so that the business side was looking to circumvent the technology side and actually go out with outside vendors. So, there was a lot of damage to the trust between both of them.

And one of the things, when they asked me for help, was, "Please don't bring any of the Agile crap." And to them, they almost had triggers. Like, if you took out a post-it note or mentioned T-shirts or things like that, you might trigger a bad response.

So, what they asked me was, "We've tried the Agile stuff, it's not working for us. And where we are now is that, you know, we're really fractured between the business and technology," or, "... between the product side and the delivery side." And so that's the context in which I was engaged.

And similar to my other patterns, necessity's the mother of invention. And so, when I was given those constraints, and so that the standard playbooks are not going to work, what I came up with was this idea that, I did this introspective and asked a bunch of people in the organization what happened.

And a lot of, well-meaning coaches, and I would do this myself in the past, they came in with a bunch of practices, a lot of really good practices, and they inflicted them on the organization. And whether it's scrum or elements of large scale scrum or technical practices and things barred from XP and MOP programming, and all of these patterns, they brought them into the organization, all of which are good, and I endorse all of them.

But what one person said was, "We're suffering from post-transformation stress-disorder." And so, when I started thinking about it, the sheer amount of practices that were introduced into this organization, what really were they doing was, they were changing behaviour.

So if you think about the scrum as a pattern language with a set of practices, and you add on top of it 15 other practices, you are targeting so much behaviour change, and so it was too much for the organization to absorb.

And so I started thinking, before engaging with this client, if what we're trying to do is change behaviour, and what these patterns do are change behaviour, how do you know which behaviours you should actually change? How do you target specific behaviours, or should you just come in with a whole menu of things that are just good standard practices?

Without a sense of urgency and purpose, change doesn't happen [12:07]

And so, this was the context to which I went to this client. So I brought them together, and I actually called the workshop the BS Workshop, because they don't want any of that Agile BS. I called it the BS Workshop. And what I did was, I'm a firm believer that without a sense of urgency and purpose, change doesn't happen.

And it's not just my belief. The standard change models all start with creating urgency and purpose. And so, either there's an external sense of urgency, you're going to go out of business, similar to Elon Musk and Tesla or Steve Jobs in the late '90s, either there's an extrinsic sense of urgency, or an intrinsic sense of urgency and purpose.

This is what I feel is missing from most Agile transformations, there isn't a sense of urgency. "We need to move to Agile because we need to move to Agile. We need to move to Six Sigma, we need to move to TQM without a sense of urgency and purpose."

And so that became the first step, because that to me underpins all change. Like Lewin says, "You have to unfreeze the organization before you can create an establishment of norm." So before even behaviour stories, before even culture, I need to manufacture a sense of purpose. That's step one, manufacturing a sense of purpose.

And so, I said we're going to create a goal for the organization that's within three to six months away. So, it has to be close. No three-year strategic, nothing, none of that kind of stuff, I want a goal that's three months from now. And I don't want to stretch objective. If you've run a 5K, your goal should be to 10K, not a 100-miler.

And the last part was, the goal must be constrained. So to me it was the secret sauce. And the way I explained it in the workshop was, constraint means, what are you not willing to sacrifice to meet this particular goal? So, an example could be, well, we're not willing to hire new people, we're not willing to sacrifice quality, we're not willing to impact the specific delivery.

So, what are the constraints for this goal? And I added another dimension where I was like, "It must deliver something the business cares about." I think it has to be an execution goal, because that, ultimately, is what the business wants. Business doesn't care about story points. So, business wants execution, wants stuff delivered.

And so, that was the first step, create this activation energy. And what I found was, actually creating a goal that technology and business both care about, is easier said than done because technology generally has its own agenda, you know, migration to this platform, to this new data center.

It has its own agenda, and the business have their own agenda. There's a tension between both things. So aligning on a goal was easier said than done. It actually took me about three to four hours. But after that goal was created, because of the three dimensions; constraint, achievable, near-term, I call it the CAN goal, what I discovered as a coach over years, if you just label something, it gives it a lot more gravitas.

CAN Goals: Constrained, achievable, near-term. [15:01]

I said, "You've heard of SMART goals, this is a CAN goal, all right? Constrained, achievable, near-term." But that's not behaviour stories. That was, all I'm trying to do there is start rebuilding trust, talk about a delivery in the language of the business, and create that activation energy to create change or unfreeze the organization. That was step one.

The structure of Behaviour Stories: In order to meet the goal, X group or person has to stop doing Y behaviour [15:19]

Step two is where the behaviour stories came in, with the maladaptive behaviours or cultural debt, similar to technical debt, uncovering it. So, what I had them do is, at the risk of getting something thrown at me, this is when I brought out the post-it notes, and I said, "Here's the format for the behaviour story. In order to meet the goal, X group or person has to stop doing Y behaviour."

So, the format is simple. In order to meet the goal, X group or person has to stop doing Y behaviour. And now, I know there's not enough psychological safety for people to start saying, "Hey, in order for me to meet the goal, Shane has to stop doing this," right, because their bosses are in the room.

We're very far away from the psychological safety for people to actually say what they want. So, I create a box, and people could write and put stuff in the box, and just create some anonymity. And originally, people weren't writing, but once people started writing, there was this kind of FOMO that kicked in, everyone started writing.

I was like, "Oh, he or she are going complain about me, I'm going complain about them." And so, after, I don't know, 10, 15 minutes of people writing, I gave them a break, and then I clustered all of the behaviour stories. And there were dozens. There was a lot of behaviour stories, and some common themes which I clustered.

And then, brought them back from a break, and I said, "Okay, I want you all to read it." And I was like, "What's your feedback? Like, what do you think about..." This is a voyage of discovery for me. This whole entire thing was an experiment.

And one person at that point said, "This is our actual culture. Like, all these behaviour stories and all of these negative behaviours, that's actually the culture of our organization," or, "... our division within the organization." And so, I used the wisdom of crowds, and I asked them, "Which of these behaviour stories do you feel is the biggest blocker to meeting the goal?"

Everything was constantly tied back to the goal. And people dot-voted, dotmocracy, and they picked a certain amount. And I told them, "Look, ultimately, this is all BS." That's the first time I've mentioned the acronym, right? "This is all BS. These are all symptoms of a problem."

So the complaints, for example, and there were some biting ones, like, the business have to figure out what they want, in order for us to meet the goal, technologists must stop writing shitty code. People are, in some cases, very direct with their blame, even blaming certain executives, and things like that.

Sales needs to stop selling things that don't exist, or overselling, and all that kind of stuff. So I said, "Look, these are all symptoms. They exist, but they're all symptoms. It's like having lower back pain. The source of the lower back pain is generally not in the lower back."

It's like Russ Ackoff says, "Fundamental attribution error." It's, the source is somewhere else in the system. And so, the job now is to figure out if these are the symptoms, what's the root cause of the symptoms?

For example, one of the common behaviour stories was, "Management needs to stop having too many meetings. If you want us to meet the goals, stop having meetings all the time, stop asking us for status meetings."

Now, the solution for that, if you just solve that without understanding the underlying cause, it's like taking painkillers for your lower back, you don't solve anything. And so, I broke them up into certain groups and they did a root cause analysis on why those symptoms exist.

Finding the root cause of the behaviours [18:21]

And once they understood the underlying reason, really got to the aha moment, "This is why we have so many meetings," that there's no trust, and once they've really understood, then I tell them, "Now you have a complete behaviour story. You have a complete BS now," right?

Only now that we understand the symptom and the root cause, could we start thinking about patterns, applying certain patterns, or applying certain... Like, now you can say, "Oh, in this particular case we should experiment with pair programming, or we should experiment with a single-product owner."

But now you understood there's a symptom, an underlying cause, we understand the underlying cause, and now you can apply certain experiments to solve those behaviour stories. And that was the last step, come up with experiments, but you have to tie them to the underlying cause.

And that roughly was the workshop, plus some next steps. It was creating the activation energy using CAN goals, uncovering the behaviour stories, or the BS, and then applying patterns or experiments or tools to those actual underlying cause, which is exactly the opposite of what I used to do when I first became a coach.

I used to say, "Hey, there's all these great patterns and practices, and we should install them." And so, this was flipping that paradigm where it's almost like backing into the culture of the organization. And then, once you understand the maladaptive behaviours and where they come from, only then do you apply the patterns.

Shane Hastie: Great story. You said it took people a while to start writing those stories, and then clustered them. How did you make it safe to even have those conversations?

Making it safe to have hard conversations [19:58]

Ahmad Fahmy: To get them writing was easy because they were not writing it and putting it on the board, they were writing it and putting it into a box. And that anonymity, and once people started writing, other people started writing. Had I said, "Okay, write it and put it directly onto the board," I think people would've not felt safe, already because the room, there was already factions in the room.

The technology was sitting in the room, the business was sitting on the other side, there was some senior leaders in the room. Anonymity is what made people feel safe to write. But even then, they didn't write right away. It was only when some people appeared to start to scribble that other people started writing, because it's like, "My voice is not going to be heard."

And you do need some great facilitation, because when people started to feel like there's some finger-pointing, what I said was, "Look, these stories all exist. What we're just doing is actually just surfacing them and looking at them. It's not like we're inventing this here. These stories exist."

And stories is the currency of an organization. Stories are so powerful. They're more powerful than data, in my opinion. And the stories that the organization tells itself and tells new joiners, and all of that kind of stuff, are incredibly powerful, and generally not even talked about.

And so you constantly hear, great leaders are great storytellers. That's all true, but there are nightmare stories that are told quietly throughout the organization. And that's what I told.

I was like, "These are stories that are told and mentioned and taught to new joiners, and people talk about them, and all that. We're just actually surfacing them now to do something about them."

So yes, there's a lot of framing you have to do to remind people why we're doing this. And mentioning to people that, "Is this the culture in which you want to spend the next 10 years in," or like I mentioned the water before, "Is this the water that can nurture new talent?" And so, short answer is facilitation and constant reframing.

Shane Hastie: And in the digging down to the root cause, so you gave the example of too many meetings and figuring out it's because of a lack of trust, how did the groups get down to that? At this point, were they still in their silos or did you bring them into cross-functional-

Ahmad Fahmy: Oh, no, at this point we had three behaviour stories we were tackling, and I created basically three teams that had all developers, management, and product folks within each team. And so they were, I won't call them cross-functional, but cross-organizational groups, and exploring why this stuff happened.

And the teams, one of them was really interesting because what they learned was that it was inversely proportional to trust. The less they trusted the teams the more meetings they created, the more meetings they created the less the teams had time and more context switching and preparing decks and all of this kind of stuff.

And what I taught them, and I think the easiest tool, is Five Whys. It's the most intuitive. Constantly ask why, constantly ask why. And ultimately, the why was that the teams did not feel comfortable, safe to tell people bad news. So, if they didn't feel safe to say the bad news, then they would just wait and just not deliver.

So there's this delayed fear, "So we're not going to deliver." And so for management also being pressured by product was, "Okay, then we need more status reports." Even the daily stand-ups became a status report. And so then the question was how do we create the psychological safety to where the teams would surface almost immediately when there was a problem?

So that then became like, okay, what's the useful experiment to create that? Now we talk about tools and patterns and processes and things like that.

Shane Hastie: As you say, that's the inverse of most organizational transformations, whether it's Agile, Digital, or whatever language you want to use. The most common pattern is, come in, impose a new set of practices, and the consultant goes out with a check, "I've done my job."

Inverting the traditional transform approach [24:00]

Ahmad Fahmy: Yes, and I was guilty of that too. I had my favorite things, and I was like, "Every organization needs to be doing TDD, every organization needs to be doing spec by example, every organization needs to be doing this good stuff." And the reality is, no, not every organization has to be doing TDD and not every organization used to be doing SBE.

And it's like Kent Beck, I love the story, he was like, he went to Facebook, and I hope I'm telling this story well, I heard it on a podcast, and he went to Facebook and he was like, "They're not using any of my XP things." Yet, they're one of the most successful technology companies.

Not everyone has to use specific patterns. As a coach, I was a shu or ha level coach at that point where “thou shall follow the rules”. You must follow this organizational diet. And so I'm guilty of the same thing.

Shane Hastie: Ahmad, really good story. There's some quite inspirational stuff, in fact. If people want to find out more, where do they find you and where can they find out about behaviour stories?

Ahmad Fahmy: Best place is my website, you'll find out about me, and there's a bunch of resources around behaviour stories.

Shane Hastie: Wonderful. Thank you so much for taking the time to talk to us today.

Ahmad Fahmy: It's really my pleasure.

Mentioned

• Ahmad Fahmy on LinkedIn