Oct 19, 2022
In this episode, we discuss with Dawn Ahukanna (Design Principal and Front-End Architect at IBM) why it is essential to acknowledge the whole spectrum instead of the pieces and how it can help if one keeps in mind the end and works backwards. Dawn also mentions how one can make an effective change.
Hosts are Kristof Van Tomme (CEO & Co-founder, Pronovix), and Marc Burgauer (Principal Consultant and Co-founder at Contextualise).
Also available on Anchor and Google
Transcript
Kristof:
So welcome to the API resilience podcast. Today we have Dawn Ahukanna who is a computational designer. Computational designers - if you don't know what that means, or if you can't imagine it - are creative people that apply their mastery and knowledge of how people, software, hardware, data, network, and systems all interact as one system. She works as a design leader in IBM systems business unit, and she helps clients in partnership with business partners to simplify IT management and operations using preventive maintenance, analytics, and insights. Dawn has been a guest previously, at the Deliberate Complexity conference series and she had a lot of really interesting things to say about APIs and how that all works together. And just looking at this introduction and her job description, this is gonna be an amazing conversation. I'm very much looking forward to it. Welcome Dawn.
Dawn:
Thank you for having me.
Kristof:
Thank you very much for taking the job description for the conference so serious and really like thinking about this whole, you know, APIs as membrane interface, like really thinking about that. We were talking about it with Marc, that you were one of the speakers who really thought it through and who really brought a presentation that was up to the conference.
Dawn:
I grapple with this all the time. And I think, one of the reasons why I have the role that I have is standing at the intersection. Sometimes I feel like I'm standing and stride and strong, and sometimes I feel like I'm almost doing the splits just to try and keep one foot in each area. And I thought it was a really interesting topic because APIs are a conversation that I have with designers, with product managers, with executives, and depending on who I'm talking to, they're talking about either using them, making them go away because they're a problem, updating them, refining them. “How do I manage and make a business out of this API?” And then keep three versions and get all my customers updated from API version one to three, when the customers on one are very happy and need to do what they need it to do. So where do you do the point of abstraction? Do you fake and strangle version one, move it to three, but everybody still thinks that they're on version one or do you keep the two and keep all the complexity on the internal or do you just make it go away and sell something else? So what I wanted to do and I get accused of being theoretical and in my head a lot was making sure we talked about the theory and then proposed and shared an empirical example of how I apply what I'm thinking about, because I think it's important to make things tangible and as a designer and also as the storyteller. I think that when you're talking about something that is like headache, inducing, the complex, making people laugh, keeping things light and having a conversation helps you kind of get through that. So I guess it's a gift that I have that I'm always finding connections and analogies and just the positions with things. So I brought all of that and it was an interesting topic. It's not something I always get to talk about. So I really appreciate you guys giving me the space to run with it.
Kristof:
What I thought was really interesting was this, it was almost like layering additional information or additional constraints on top of the information. And how that makes the API or the information that is flowing through the API accessible for additional people. And it's something that, so I've been talking to customers about APIs as… Well, we do developer portals. So I normally talk about developer portals as interfaces for the interfaces and that's not just APIs. There are also other interfaces. And this also spectrum, we were talking earlier about spectrums before start recording that it's not, there's this interface spectrum of very abstract, which are APIs all the way through full applications, but it's a spectrum. It's not either apps or APIs. A whole bunch of stuff in between.
Dawn:
Exactly. And it's because those things have value. If someone's going to put their hand in their pocket and give me money, then part of my response is like, “okay, how much do you want to give me?” Go and figure out how to make that thing and get that thing is enough either of a pain or is enough of a desire for someone to say, "I will part with this amount, if you can get me X". The gauntlet has been thrown down. That's the challenge. How do you figure out how to make X? And like you said Kristof, is everything from the physical, hardware box where that thing is running all the way to the device that's in their pocket. And they don't even care where the server is. "I just want this thing to happen." Right? That's the spectrum we're talking about. And it's literally running up and down that ladder and figuring out how you make levels of abstraction that are useful, desirable and valuable.
Kristof:
Yeah. And then also, how do you, how do you sell that to your management?
Dawn:
If somebody, again, slams 1 million, 2 million, 5 million on the table, then usually they're like, "go and build that."
Kristof:
That's okay. Yes. What we often encounter is that people say things like, "oh yeah, we're gonna do APIs." And that's it. It's like it's its own category. It's its own thing. And we're doing APIs now. I did a webinar just now and somebody asked, "Yeah, but we want to do API first in our organization." And I was like, "yeah, but be very careful" because you're just look like too many organizations stare themselves blinds on this strategy. Like we are going to do APIs instead of "what is the interface that we need for this job and how our people are going to interact with and how are we going to...?" Have you seen, maybe in your work a way to communicate the spectrum rather than the slices?
Dawn:
Well, one of the lessons that I've learned - and I just to remind everybody, I was a research scientist, developer and technical architect for a very long time and right now I design experiences - so I'm closer to the human than I am to the technology. And that's because all the variation is in the 9 billion different humans that we have, and we have to cater for. And that's also where the fun and the challenge is. So starting with the premise, "we're going to be API first" tells me that somebody, and I'm not joking when I say this, somebody put a check in front of you and said, "build this and I will pay you." Now, if someone didn't do that, then you have to look at the whole spectrum. And this is something I know as much as people either venerate or denigrate Apple, this is what they've done. They've never been first at anything, but when they come in, they don't do, "we'll just take this slice." They take the entire house, kitchen, sink, everything and give you a whole solution. I'm not crazy about how everything is prepackaged and you can't repair and all of that, but that's a conversation for a different time, but they've really focused on the experience that you take something of theirs, and it just works. I'm talking to you guys, we're all geeks here, protocols, video Codec, all of that stuff. I was up to my elbows in, when I was using Windows and Linux. I have no idea. I have a complete consumer experience most of the time, unless I'm developing on my mind, I have no idea how to figure out or even run the functions. And you know what? I really don't care. I open it, I turn it on. I type, it works. That is the level of interaction and interface that I care about at that point. Sometimes I do want to go deeper, but not all the time. And the analogy I give to my colleagues is the difference between if you wanted to play a song. People want to play music. You have three controls minimum on, off. Sorry. Turn the thing on, start and stop. What my colleagues and I do is that we give you a 50 lever, 100 knob mixing desk and tell you to look yourself out, mix anything you want. “I don't want to mix. I just want to play that song at a particular volume and enjoy myself and have an experience. I do not want to mix it. I don't want to do post production. I don't want to do any of those things.” And, so, when I talk about the spectrum of the API, Kristof, that is the analogy that I usually use. I literally pull up a mixing desk unless people was like, "what is that? Why are you showing me that?" I said, "that is what you're suggesting that you are going to build and give to someone." This is what they want. So you do need the mix, the mixing desk. Yes, absolutely sits underneath all of those three controls. But did they ask for the mixing desk, or did they ask for their own button or play button to play the music?
Marc:
Or specific configuration of the mixing desk. Or we want to listen to voices. Can you just give us the right configuration for voice? We want to listen to orchestra music, please give us. I'm using Mac since '84. And one of the core arguments where I always said I'm using Mac is like, I don't have time to configure. So as you said, Apple always actually thought, "what are people actually gonna do with this thing?" But what other people forget that in 84? So at the very beginning of the journey of the Mac, one of the core things that they already had in mind “what is the developer experience?” more than anybody else. So, at the time, when I picked up a Mac, I was able to program a pet Commodore. I was able to program dBase on a CPA, what's it called? CPM. I knew all these worlds and how to live. And when the Mac came along and you got initial Pascal interface, it's like, "Hey, I could build applications in no time compared to any of the other ex-..." So developer experience was at their forefront. I think that's why swift came along. They remembered developer experience matters, and we lost that age and they tried to reintroduce it.
Dawn:
Well, this is the point to your point, Marc, that I make: developers are people. People sometimes talk about developers are swift there, this special robot that sits in the corner and just pop... They're people. I agree with you. And so to your point and to your question, Kristof, my first analogy of this talk is mixing desk versus three buttons. Which one? And the people that I'm talking to don't even know that what I'm showing they're already upset with me, "what the hell is that?" That's the mixing desk that you are suggesting you want to give to people and you don't even know what it is. How are you going to make sure that that's the right thing for your audience?
Kristof:
But what are the slices? Because it feels that there's slices of abstraction, that there's certain useful slices of abstraction in there.
Dawn:
So I think that a lesson and a place to look is if you look at consumer electronics, let's take cameras for example. Now I have to confess, I was one of those people who said, "who the hell was ever going to use a camera on this device?" And I'm holding a mobile, a smartphone. So I have to admit, I didn't have the foresight to see the potential for that, but you've got everything from even before we had smartphone cameras, you had point and shoot instant cameras, Polaroids, where you could get your things straight away. You had a variation where you had some level of control that you are comfortable with all the way through to SLRs, to professional, where you had every knob under the sun. The upper limit - I remember talking to a guy who worked for Nikon - the upper limit was the dexterity and how many fingers that you had. If you put more, that couldn't be held or controlled, or in particular configuration and they spent time and studied this. They worked that out. So to your question about "what are the abstractions, what's the environment? What are the factors?” Is it the fact that you can only have 10 fingers looking at, you know, holding that thing? Is it how heavy it is and what physically people can carry? Is it the environment that it's gonna operate in? So you have to look at, and I'm gonna be a designer here where we say “step back and look at the wider environment. What system does that abstraction belong to and what is its function and how is it gonna operate?" That gives you a good idea. And then you still have to iterate through and eliminate all the variations that nobody wants to hit the one or two or three that are the money shot. My second thing, and people have heard me talking about this, Jabe Bloom, who I know has been on your podcast, talks about having either a really powerful magnet to attract and extract the needle that's in the haystack, or you go haystack diving, which means you're going to spend a lot of time looking at straw before you find the needle that you were looking for. And some people settle for a very strong piece of straw or say, “okay, that's the needle.” So the answer is, it depends, but I think there is an operating theory. If you start with the end in mind and work backwards, it's 10 times faster than just trying to eliminate all your possibilities.
Kristof:
Well, it's like one thing that I've seen. I dunno if it applies to your context because I suspect that you're very much in a B2B context, like where you're. But most of the time. We have got some customers that are providing tools for building digital experiences, also to SMEs. So there's the enterprise customers, and they've got money for custom integrations for diving the haystack, but then they have a bunch of SMEs and they don't have money for developers. They just want a needle.
Dawn:
They do, but they're very clear and specific about “How?”, “Where?”, “What?” they want. What is the value? So if anything, it's more important to talk to them, to figure out what configuration of their 10 fingers is the thing that they're going to spend money on. Otherwise, the challenge always with the space that I work in, which like you said, is business to business is, from a retail aspect: I call it stack it high, sell it cheap. There's enough that if you sell enough of it, there's enough demand. You sell enough of it, you make a lot of money, but it's a very narrow area. If you're looking at small businesses, the variety is huge and no one solution is going to address all of them. So you have to be satisfied with the long tail business. There might be one or two things. Yes, they're gonna make you a lot of money, but where you're going to actually make most of your money is the variation and being able to be flexible enough, to be variable enough that most people use it. And what Apple has been able to do is hit both of those regions. You do not have 3 billion, 4 billion people using a device without figuring out how to accommodate all of that variation.
Kristof:
Yeah. It's interesting because I think that this is the, so the API landscape as like the interface layer, it feels that it needs to go a little bit less abstract for really becoming mainstream.
Dawn:
Well, I think that, the thing that APIs, where they add value is there's always a level of exploration and discovery, and you need handholding and user interfaces of whatever interfaces for that. Once you've figured out what your flow or your system, or wherever it's done, and you just want the thing automated, or, you know, you just want to automate it and forget it. That is the beauty of APIs. Because then I don't want to sit and press a button 12 times, when I could just send something off and it would do it 12 times and it would be confirmed and done. So guess where the automation is the long tail, but everybody's focused on "oh, the first experience" the, you know, it's like the in cinema. They get ratings on the first week or two weeks that they're in the cinema. I've always thought that that's crazy because people don't only watch a movie in the first two weeks, they watch it all the year round, and you're still making your money. But again, it's really respecting, back to the conversation we had about time opening your aperture for time, where your definition of success isn't the first two weeks that something comes out. The definition of success is the first year, the first two years, the first three years, because it might take that long to reach the level of people to make the sort of money that you would want to make in order to be successful. But on the flip side, you need to keep the lights on long enough to be around for year one, year two, year three. So there's always a tension. I think so. I think that looking for instant or easy solutions is long gone. Tech is not the challenge. It's people. And they're not predictable or programmable or any of those things.
Marc:
So there's an interesting challenge that I experience a lot in opening the aperture for time. And so, just gonna give an example of how I experienced that very often. So while back I worked with a team that was building mobile apps for a company. And, so all that measuring was always like, when they wanted to try to assess a new feature, they were always measuring. So how does it do the first two, three weeks that we, so that's what everybody out there eyeballs on it. And other than that, came along with just asked a silly question and said, "do you have any data about usage of your features that are old?" Like "how many of the features that are in your app? Are you measuring?" And I know we were actually usually lose interest after two, three weeks. So they started measuring this and started realizing, “Hey, two thirds of the features are hardly ever used.” So we're carrying these arounds, but we're constantly praising these as big successes because in the first two, three weeks that were used. And that's often how I experience when I use the phone: there's a new feature, I'll try it. And I realize, I don't really need, and I stop using it. So this goes hand in hand with the second problem that we're all the time experiencing in IT: we try to address it with DevOps and even though we're making inroads, it doesn't go away. Is that actually the cost of operating software always outstrips the cost of developing by a long shot. So when you go into especially difficult transformations, everybody's focusing like, "how do we make development faster?" Nobody looks at the Ops guys. So you have this faster and faster release, new features and blah, blah, blah, which somebody has to operate. Somebody has to keep the servers up or whether they're cloud or real or whatever, you have to make sure the capacity to actually operate this stuff is still there. But in manage. So when I then talk to managers and I try to explain these two problems to them, there are some that get it, but they will usually be coming to me and say, "yeah, but I'm not measured on that. I have this list roadmap given by my boss and I need to do all of these things. And whether I do well or not is like the month, the monthly meeting after the release is when I show them the stats. And those stats have to look good. And if they look good, bingo. We all get promotion. And we've been seen as the great team, et cetera. And if the stats don't look good, then that's failure." And what happens three months later? Nobody cares. So what you're saying, when you say we have to keep the ap-, we have to opening up the aperture of time is we have to actually start to see what we're building with APIs, et cetera, is impacting the ecosphere in which we're operating. So the environment, et cetera. But what we experience in the organization is there's a lot of drivers that actually constantly try to close this aperture. So how do you manage, how do you get that people to accept that or to start to see the benefit of that?
Dawn:
I have two strategies, approaches when I observe what you just said Marc. First of all, some research in order to validate the human aspect of it, and what's the value without that and I really don't have a leg to stand on and it's my opinion versus somebody else's. And then the one that you guys are all familiar with is “the internet is wrong.” You put out a provocation that is just so wrong that people are like, "no, stop, hell no, it's this." But what happens then is because that is coming from almost an uninhibited place, you get the real motivation. If it is actually that people have decided that their motivation is going to be that they have to hit this target in order to get some specific goal. That is just the reality of that situation. So I either have to comply with that go over under round or through if that is not what I align with, or I say, "I'm not doing it," that you'd always have the option to do that. So the one is the provocation, the second one, and this is one of the reasons why people always ask me, "why are you a designer and a technologist?" I don't have to beg anyone to make a vision that I see. I can do that myself. So you are there talking about short term, "this is what's gonna happen." And I can put in front of the same audience that we're trying to convince or make a decision information that says, "if you make this thing, wait three months or six months, and you make something like this. Touch it, play with it, feel it, experience it. Then which one is better? A: One for you as an individual, in terms of the experience, and Two: as a company. Where are we gonna make more money?" Yes, you have the measure, but nobody, like you said, Marc, is using it after two weeks. Or if you make this thing and I'm putting my neck on the block here and so people have to be able to feel and touch and it's one of the reasons why I've always kept involved in technology is to A: be able to speak the language. But also if I have to create the experience and show what it's gonna look like rather than talk about it. So those are my two approaches to that challenge because people can't do what they can't see. Once you've seen it, you can't unsee it. And if they still make the decision that, "yes, it's a short term thing." then there's obviously, there's a whole bunch of things that are going on that are not necessarily in my control. And I spend the fine time if I can figuring out what that is. It's not the technology, that's the problem. It's not the market. It's something else that's going on.
Kristof:
I think there's, so one thing is like the relationship between the features and the product, but then there's also between the product and the product suite, like, especially in the API landscape. This happens a lot that is just, well, this API first strategy comes to this result. I don't know if this is happening in your context, but it's just, everybody should be building stuff and then we just publish it and there's a whole bunch of stuff. And it's so the same, the same dynamic that we just talked about, where we're just adding features and the nursing features that nobody's using anymore. The same things are also happening with the interfaces that we're producing and there's no overview of what we are actually trying to do here with this whole program.
Dawn:
Well, there's a conversation... That's why I'm saying, Kristof, you must have been eavesdropping on my conversation. I was talking to a general manager Monday or Tuesday of this week. And one of the very things we were talking about is the thing with the suite. Everybody always thinks about office as an example, because it can relate. And then I mentioned, and I said, “by the way, it's not just creating the suite once. You have to keep doing it, because there is a drift, an expectation drift.” There's actually a theory by, it's called the Kano Model. And the ironic thing is that a lot of UX models and patterns have been developed by economists. I don't know what the correlation is there. So Kano Japanese economist and he focused on customer satisfaction and quality. He has the traditional four by four, but his four by four is three dimensional. It's not just one dimension. So on the horizontal you have - I'm trying to remember now - I think it's quality on the X and then on the Y it's satisfaction. So obviously you want to be in the top right quadrant, but there's a kicker. The first left quadrant where you have high satisfaction and low quality is actually called "excitement generators." Or as everybody calls it "low hanging fruit." Create a lot of excitement, your two weeks Marc, that you were talking about: "lot of excitement. Yay, I've gonna go and check it out!" And then "is that it?" The benefit with that part of the quadrant is that it doesn't require a lot of investment to get a lot of interest and therefore make a lot of short term money, but it's not sustainable. Then you have “performance enhancements,” which is linear. You invest, you get the payout, you know, people keep finding quality and kids going up. And then the last one is "basic expectations." People don't tell you that they want those things, but they will sack you, if you don't have them. So you can only do a bad job there. And the kicker is that those excitement generators become performance enhancements and then become basic expectations, they're expected. So that's what happens over time. That means you have to keep adding to your excitement generators and degrading them to performance enhancers, and then making those performance enhances basic and either improving them or cutting them off. So that is a model that I talk to a lot of my designers, product managers, and business people about. It's not a one and done, it's a whole ecosystem network pipeline. All these things are connected and you have to keep iterating and doing it. And we were talking about the suite. So the problem with the suite is that the suite is those three things from the Kano Model. So what in the suite is an excitement generator, almost like a, you know, get your foot traffic in like a mall. What are the things that make you your main money and what are the things that you need to be cutting off to Marc's point? Some of those things, they gotta go. They're no longer useful. And if once you have an ecosystem, which is what a suite is, you have to design it and you have to create it in that way. Otherwise you will learn, you know, the market will teach you lessons the hard way.
Kristof:
I see different aspects of it. I think on the outside, when companies are providing external facing interfaces, that I think there's more understanding there about this cleaning stuff up. But on the inside it's a mess. It's an absolute mess.
Dawn:
Yeah, because it's invisible. It's not seen. So unless, another thing we were talking about, Marc was how things happen, but because of the limitations of our senses, we only know that it's happened after the fact, because we can see the impact. APIs to some extent are like that because you don't see them once they're operating. You only see after the fact that it's a "mess" because there's a bottleneck. And all of a sudden the whole system collapses, because there's so much load or there's so many demands that it can't, but this built up over time. Who was watching that? Nobody. So the thing, and that's why one of the things that I say is when you make an abstraction, what is the value. Who is paying for it? Because somebody has to pay for it to be made. Somebody has to be able to maintain it. Somebody has to create it. If those things are not taken care of, then why do you even have that abstraction? Back to your point, yeah, we're gonna be API first. Where's the value in that, to your target audience if your target audience is never going to use that API, understand it, be familiar with it? Another example I said was the Codec. I only learnt them because I had to, I wasn't interested in H 6, 2.4 or whatever the latest ones were, but I couldn't achieve what I wanted to do without doing that. Was it of value to me? No.
Marc:
So another aspect. If you say is internal messes is also… so how do we incur debt? Whether it's technical debt or organizational debt. So things are drifting. I'm going here with Jabe Bloom's, I'm not sure he would say all of his ideas, but he has a nice articulation where essentially says, the core reason we're experiencing deficits to, or here's how we would like the state to be, here's the real state of things. Not so nice because things aren't static, so never mind about, we take shortcuts here and there, but we're aware of them, but the real problem is actually the things drift. So your environment changes. Hence even if you develop something for a past state of the environment perfectly, now you have a deficit. But a lot of this is also due to organizational attention. So how much attention can we spend on keeping things orderly, et cetera. So then if we look at people who try to show benefit for money spent, so you go a bit further up on the chain, maintenance never comes up in those equations. The cost of maintenance, et cetera. They might become interesting at some point when the cost-cutter comes around and suddenly says, "why are we spending this amount on maintenance of this or that?" But usually by that time, it's already a bit late, in terms of, you know, making things tidy again, we're already in the big ball of mud dimension, whether it's technical or organizationally. So you can explain a lot of this with Conway's law, but as recent conversations have been going also on Twitter, et cetera, is we actually start to see, okay, so the communication structure also, actually just an outcome of other things, like, for example, budgeting. And so it's very interesting that you keep pointing out, "who's paying for this and what do they want to get for it?" And so Jabe's, the economies place that we discussed right now is exactly the point he makes: it says four things like an API, which is different than from looking after infrastructure and is different than from actually being focused on user value. You have a different economy. And unless you can actually talk about this in an economic sense differently, you will end up with a mess. So the way out is actually to say "how are we-?" It's not just who's spending and what they want for it, but also "how are we spending the money?" And most organizations still live in the bimodal world. So they say, even though we are applying product thinking. So what product do people want to do? Or we are operating in the old IT operational world where say, "oh, we have to constrain resources because they're finite. And we don't want to overload our systems." Whereas actually API is a different economy. It's so, as it says, things gain with value. So API gains in value, the more it's used. It becomes more valuable to the organization. It becomes more valuable to the people who benefit from it at the user end, the more it's used, which is a different economy from the other two.
Dawn:
Yeah. So this lines up what you triggered in my mind, Marc, is literally what bumped into my head was the Worldly map. Genesis, and I'm not remember the second one product. What is it?
Kristof:
Custom build.
Dawn:
Yes. Product and then commodity, right? As you move towards the commodity, commodity is where APIs live. That is predominantly where they should live, because that is fully automated, contained package set, forget forgotten. Product still needs a level of, that's the mixing desk. If you like, to some extent the three buttons are at the end, the custom built that is your audio file with his copper wires and tune speaker and all the rest of it, and then Genesis your inventor. So you think about those, that lines up with what we are talking about, value and economies. So, saying you're going to go API first when you've just observed something and trying to prove and make it true is totally wrongheaded. You haven't proven the case. You haven't proven the value. You haven't even got enough people signed up to say "yes, I would use that." So whenever I hear someone say, “yeah, we're gonna go API first.” The first thing I hadn't thought about it that way until you said what you said about Jabe's three economies. But the first thing I'm looking for is "what are you commodifying?" If you're not commodifying, then, because there you're talking about scale as well. So there's enough that you don't want an individual to keep repeating. I said, made the example of the 12 buttons. If I don't even have to press a button at all, I would prefer it. I don't want to even have to think about that because that's not valuable to me in terms of my time or what I want to do. The problem sometimes that I get is I'm having the same conversation I'm having with you, but people are like, "yeah, but show it to me. Are you saying you can't do it?" No. I'm saying it's the wrong thing in the first place, but you then have to have the alternative. Otherwise it looks like you don't know how to do it. You're just, you know, saying that they have a silly idea because it's ego or whatever. So you do have to have, again, like I said, step back, bigger picture. What is your API providing and what system is it gonna operate in? Is it genius, custom product or commodity?
Marc:
Okay. I have really advantage in most engagements that I'm working, I'm coming in under the guys of Agile. I often don't need to have to have exactly that conversation I can mitigate by then just to saying, "well, what do you need most? What do you need first?" Okay. Well, the other things that we know you want them, but so ruthless prioritization often actually sharpens the mind. You don't force them to make a “yes or no” choice, you just make a “now or later” choice, which they often find a lot easier. So, if you, I know you want this all singing, all dancing, mixing deck, but what do you need tomorrow? They will say three buttons please.
Dawn:
Correct. So, again, you made me think of something where, when I was a consultant, a lot of the times going into clients and we had this standing joke, "did you give them opiates, ibuprofen, or, and usually pain relief?" They are in such a dire situation that the first thing that they need is just to literally, you know, stop the pain. Because also if somebody's in pain, you cannot have a logical conversation. They're not thinking about anything else other than they need the pain to stop. Once you've got that relief almost in the euphoria of the relief, then you have that conversation about the wider being, because they're literally like, "yeah, yeah, yeah, whatever. I'm so happy that I no longer have pain relief. I'll give you a blank check" and then you almost have that cycle. So, again, as a consultant, I would go for the gnarliest, horriblest, painful problem, because off the back of that, then usually you could then have that. Because one you've built credibility to you taken actually given them relief and value and people are when the opposite of that kind of pain is euphoria. People are euphoric, they're usually a lot more conducive to having those kinds of conversations.
Marc:
But there's also my experience: the people in organizations as a consultant, that's somebody coming outside and help those who have the gnarliest problems are also the most neglected one. So you are actually gonna have on a people level, actually, usually the best time with them. Yes, their problems are horrendous, but they've been neglected, so somebody comes and say, "yeah, tell me, talk to me about your problem." They can finally articulate and somebody's listening, et cetera. Then you give them a bit of pain relief. You already have a good relationship then that's partially also why good things happen. I have advocated this for years now that if you try to do change in an organization. There's two mistakes that people always make. So first one is, give me all your best people. So the problem with the best people is that they're the best in the current environment. I have absolutely no interest to really change the ecosystem because they know how to be successful. And they're resistant to say, "Hey, why should I change that?" And then have to learn how to be successful again. But then the other thing is also, they go for low hanging fruit. I say, “okay, how can we prove the point most quickly?” And you absolutely learn. So, especially if you use both approaches, you'll learn absolutely nothing. What you actually see is that whatever transition model you're using, they're gonna use all the labels and all the illustrations, but they're gonna do things the way they always have done that.
Dawn:
Absolutely. Because that works for them.
Marc:
But also, so I usually say, “where does it hurt the most? Who has nobody talked to?” et cetera, you go work with them. First of all, you're gonna learn all the problems, all the dysfunctions in the organization have artifacts on display. So as you tackle them, you can literally actually show the rest of the organization, how you undo some of these dysfunctions. But as I said, also, they're not best people are of not the best people because they're working in areas where it's really hard. That doesn't mean they're less smart than the best people or less ambitious about any of these things. It's just, usually they work in an area that people don't pay attention to. And because they're not paying attention to it's hard. So transition should really be bottom up, which also goes very well with complexity theory. So find really who keeps the lights on is always one of my good questions. Not who is your glamor, blah, blah, blah, who keeps the lights on. Where are the people who come in when things go really badly? But then also, yeah, don't try to do something quickly. Try to undo something that's really hard and gnarly as you say.
Dawn:
You are in the “basic expectations” quarter right there.
Marc:
That's why you learn the most.
Dawn:
Yeah. And I think that you made a point, instead of the change, the effective change should be made bottom up one step at a time. That's what it takes. It's like changing any habit. You just have to keep doing what you need to do, but you also have to create the environment for that. And that's why it's always important to have the management executive, whatever sponsorship, because that gives you the runway. If you don't have that, then you're literally flying off a cliff with no safety net. So it's always, I think a balance and the people who I've seen do it well have created the environment for fostering that change by giving permission and then getting the people ready to take advantage of it. And those two things have to line up and they don't always, again, is getting the time aperture right for that interaction. You can't have everybody for a year go through change management training and not do any change at the end of that year, everybody is trained and has forgotten it and there's been no impact at all, no value for that investment. So it's working out how to do that almost in an iterative cycle.
Kristof:
Talking about consulting and like approaches in how to help people see the light, one of the questions that we've been asking - I think all of our guests, but not sure, I think or almost all of our guests - is do you talk about complexity to the people that you know, to your management and to your colleagues? Or, well, first, do you talk about complexity directly or is that a difficult thing? And if it's a difficult thing, have you found a way to communicate about complexity that makes it easier to get people around to thinking in a more complex, aware way about the world.
Dawn:
So rule number one: don't talk about something. The fastest way to get an executive to tell you, "get out my office" is talk about something and define it. They've probably seen it already and they're trying to figure out how to fix it. Designers have a saying "show, don't tell" this is where I would prototype something. Which would either be such a bad job provocation people like, "look, sit down, let me tell you how this should be done and I will show you, so you get that" or it starts a conversation. "Oh, I'd never thought of that particular angle. Well, if you do that, then what, and then what, and then what?" And it is complexity, but it has to be pragmatic at that point. Then after the fact and most people never remember what it's called anyway, I might come back and say, "oh, by the way, this is an aspect of complexity" and they don't care. It's no value to them. The thing I shared, for example, with the APIs was feedback and lessons from trying to talk about APIs as semi membrane and people like, "What, what? You send me, send me... What are you talking about?" But showing: "oh, so you do the controller here and then this allows only permission of this to hear. Oh, okay. I get that. Then what has this got to do with membranes?" Forget about the membranes. This is what I was talking about. And then you have a partnership and a conversation. One manager of mine said to me, I was particularly upset, cause I thought about this thing, I'd read it up and I'd even written a white paper and it got completely shut down. She pulled me aside and she said, "people don't care about how the sausage is made. Cook the sausage, give them the sausage and they want to taste it and enjoy it." I was like, okay. So that's a lesson that I've taken. So in general, I don't lead with that. I will mention it at some point when it's been effective and there is success that people can look at cuz then they have a positive example to say, "oh, so that was the complexity thing that Dawn was witching on about," but okay, great. But it's working for me. I'm good. But I tend to say? No. Applied practical, then you can talk about whatever theory you wanna talk about.
Kristof:
I think it's a shared experience with all our guests that it's just really hard and that people just don't want to engage with it. The difficulty is that you almost have to reduce the problem into like already a specific incarnation or specific solution for them to engage. And then the real lesson is lost because the real lesson is that it's a super imposition of multiple things that are interconnected.
Dawn:
I don't think Kristof, that the lesson is lost if you do it only once. If you apply it in different circumstances, then people get interested and curious. It's like: "how are you able to do whatever?" and then you explain, “okay, stop talking. You're talking about the complexity thing again.” Okay, fine. “You're doing what you're doing. Just show me” and what it's not that they're not interested, but it took me years to build the mental model. I didn't come, you know, turn up one day and all of a sudden I had the ability. It was trial and error, trial and error, feedback, trial and error trying this and eventually it's like, "okay, I finally figured the pathway through to get to the intersection." I always think about this, like a set, but instead of a three then set, it's a 16 then three dimension, like three dimensional chess. And you're trying to figure out how to get from one end of the most, to the other as quickly as possible. It takes practice and eventually you can look at it and say, “okay, I've done that before.” So I know exactly I could turn here. Here's like people who solve a Rubik's cube in seven seconds behind their back. I mean, that's just ridiculous to me, but they practice enough, they have the mental model of that thing and they can do it in seven seconds. You can mix it up, however you want, they literally turn it around, look at it. I've seen people do it behind their backs. It's solved it's so it's that sort of mental development. And that just takes time. So repetition, I think is important and by having a name for it, and you keep reinforcing that eventually people will get it
