Navigating the messy middle: A guide to real product organization transformation

Transcript

Stuart Hobbs: Welcome to Pragmatism in Practice, a podcast from Thoughtworks, where we share stories of practical approaches to becoming a modern digital business. I'm your host, Stuart Hobbs. We've all seen the headlines about agile transformations or becoming a product-led company. Leaders invest millions, change the org charts and adopt the lingo. Yet often the results just don't follow. The reality is transformation isn't a simple switch from project to product. It can sometimes be a messy, non-linear journey where success is defined not by how much you ship, but by the tangible business value you actually deliver.
 

Today, we're going to unpack that journey, the platforms, the pitfalls and the practical steps to get real results. Joining me today are two fantastic guests. First, John Cutler, Head of Product at Dotwork and author of the popular Substack, The Beautiful Mess, and Ivana Ciric, Product Principal here at Thoughtworks. Welcome to you both. Lovely. John, let's kick things off with yourself. You're going to be a familiar voice to many of our listeners through your writing, but for those who might not know your work, would you mind introducing yourself? Tell us a little bit about what you're currently doing at Dotwork.
 

John Cutler: I'm a product manager and I've dabbled in UX, and then I have a habit of writing. It was about 10 years ago that I started sharing thoughts. Since then, I think I've written almost a thousand blog posts. It was really fortuitous because I never thought much of it, but it's opened up all these amazing doors, both career-wise, getting to work at certain places because of the writing, but also the opportunity to interact with so many teams around the world as a little bit of an almost organizational psychotherapist in a sense, because I don't do the structured engagements like you all do at Thoughtworks.

It's more, product leaders will reach out to me and plumb my brain about things, or I'll do a workshop for a team, or I'll do a coaching session with different people around the world. Very rarely have I done that in an official capacity. I've been working full-time at companies either as a product evangelist or as a product manager or UX, or currently Head of Product at Dotwork.
 

Specifically, Dotwork helps you model your organization for strategy, model the org chart, think about the flow of value in your company goals. There is some element of strategic portfolio management, but we can talk about what that actually means in a product-centric org. I'm not sure it means the same thing as it does in a company that focuses more on programs or projects, but the cool thing about the current role is it's taken it even to another level. In addition to just talking to people about how their companies work, I spend half my day actually modeling out how they work and getting into the details, specific meetings, specific rituals, specific ideas.

For my own personal journey, this has been great. It's taking it up even another level in terms of being in the hive mind. Now I'm literally in the hive mind of these companies. It's been fun.

Stuart: Wonderful. Thanks, John. Ivana, I know that you work very closely with our clients on their transformation journeys. Would you mind sharing a little bit more about your background and what your role as a product principal here at Thoughtworks entails?

Ivana Ciric: Absolutely. I'm also a product manager, currently in our customer experience product and design practice. Part of that role is-- the majority is working directly with our clients, not only on transformation journeys, but on their product development journeys. Part of my role is working directly with these customers, typically on a much longer timeframe, so a year, two years, three years, and the rest of it is innovating on our practice.

Of course, along with that goes the typical agile transformation, product transformation, we're talking AI transformation now, looking at how does our own practice need to evolve to better serve our clients, to reflect the reality and really the messiness of how product really gets built?

Stuart: Wonderful. Thank you. Let's get into the meat of it. John, I wanted to direct the first question to you. Now, you often refer to product development as a beautiful mess, the name of your Substack. Why do so many leaders try to fix this mess with rigid frameworks? In your view, why does that usually fail?

John: I think it's fairly human. Look, it's New Year's right now. It's January 21st, we all try to fix our mess, our own personal life mess, [chuckles] with rigid frameworks in some sense, like the latest resolution we have or the latest fix we have. I think that this is a natural tendency we all have to look for a simple answer to these problems that we have.

I'd add that there's a great quote by a researcher whose name is Cat Hicks. I go back to this quote all the time, even in The Beautiful Mess and different articles. I've probably quoted this a bunch of times now, 8 or 10 times. Cat says something like, "Instead of trying to make all the complex messiness go away, why don't we help foster environments where it's easy to tackle complex problems that we're working on?"

I agree 100% with that perspective. I have a background in music and toured with bands. The creative process is messy. It doesn't matter whether it's in music or it's in industry building things that you've never built before. It is a collaborative and messy thing.

One thing I would add, though, is that we only have so much capacity to handle that cognitive load. If you look at Matt Skelton or the Team Topologies stuff, that goes for leadership as well, that goes for everyone. There is this constant push and pull between making the organization legible enough at different levels to even rationalize about what's going on and then being able to get into all the details, the fun mess, in the place.

It's not about either on one end, simplifying your whole org, although everyone seems to want that, and it's not, on the other end, meaning that everyone, every point of the day, is getting bombarded by the mess. [chuckles] It's about shaping the environment so that you can do The Beautiful Mess type stuff, more of that and less of the high cognitive load, soul-sucking, brain-draining mess that sometimes happens.

That's what I love about this problem. It's not as simple as either embrace uncertainty. You hear people talk about, "Embrace uncertainty," and then they'll say, "You just need to visualize the work." It sounds like you're not embracing uncertainty, you just want to visualize the work, you just need to adopt this framework. Even people who say, "No frameworks, you just need to say there's no frameworks," that's still a framework. It's a framework of no frameworks. [chuckles]

We all have this pull to want to simplify the problem and come up with a magic framework. I love the fact that it just doesn't work, yet it's the best we've got as humans. We have to play around with these tendencies of wanting to simplify things and then embrace the reality of things. That's why I think it's a beautiful mess, but I think for a lot of people who've had to dig their head into all the stuff that's going on in their organization, it probably feels like an overwhelming mess.

Stuart: I was going to say it's probably easier to look at from the outside in than being part of that mess so to speak. Ivana, it would be fantastic to get your perspective here and also the Thoughtworks' perspective. I know that you work on a number of transformations and advise a lot of our clients in this area. It would be fantastic to get your view on how our clients are dealing with this.

Ivana: So many different thoughts. First, it's very easy, like you said, to come in from the outside and go, "This looks wrong. That looks wrong. That looks wrong. It would just be so easy if you did it this way." Then when you start working with somebody, whether it's a client, whether you're a brand new person to the company and you start getting into that mess and you start pulling apart the layers of, "Why are things a certain way? Why are they a certain way for a specific audience? Why do people want to change at all?" then you realize that it isn't as simple and there are things that you can do to improve the situation depending on what your goals are.

At times, people don't really know why they're changing in the first place. Very, very often, companies model themselves after a successful company or a company they think is successful. "I want to be the next Amazon," or, "I want to work like Meta because I love their products or I love their business results." Then we start saying, "Amazon has PR FAQs. Let's just adopt this one practice, get everybody to write PR FAQs and then we'll be good to go." It's this behavioral aspect and this structural aspect of transformation that I will say most clients who come to us, they get it. They're just not sure where to start. They still have this idea that there's a perfect approach or this one great way to do it. The consulting industry in general has been guilty of selling frameworks and selling simplified ways of doing things.

I know from my perspective, whenever I join a client, the first thing we do is, we discover what their problems are, what their goals are. We work together to shape what that transformation looks like, so that it's less of the "Here is an approach." We do try to have some structure. We also try to understand why we're going somewhere, how we're going to get there in broad strokes, and then incrementally move towards an ideal state that isn't modeled after anybody else, but does take best practices from experience.

Stuart: Wonderful. Thank you. John, with yourself, to talking about some of the traps that leaders often fall into. On a recent podcast, I know that you were speaking about the trap of false dichotomies, specifically the idea that either you need great people or great processes, and that somehow you have to choose between them. Do you see leaders falling into this particular trap? Are there any other big myths that very often derail them before they even start this process?

John: One specific trap, and I'm guilty of this, I think, again, humans are guilty of this. I don't think the Tim Ferriss podcast would be as popular as it is if we weren't a little bit guilty to this. It's very rational to say, "I want to achieve the results that X company has, therefore, I must act and behave like that company behaves." That makes sense. "I want to be a hyper-organized person, and I listen to Tim Ferriss, and then it said that I've just read the tips and tricks of highly successful people, and then I'm going to do that thing." You must behave like the people that you emulate and that you want the same results as them.

Just specifically in this product operating model thing, this is a highly context-free model. When Marty Cagan wrote this Transformed, it's very much like the classic business book of, find 30 companies that were successful or find a high end of people, and extract out patterns that are so non-controversial, so standard that you persuade yourself that you understand the world, because whenever you look at a successful company, you can bend your thinking and to be able to say, "They obviously fit this particular pattern."

We're really hardwired to do this kind of thing. We love these books. We love these books because we nod the whole time, because it's specifically designed to make you nod the whole time. That's the tradition of these business books.

If you look at the companies that are called out in these books, they themselves have gone through massive changes and pendulum swings over the years, from highly centralized to highly decentralized, to multi-product, to platform, to focusing a lot on the end-to-end experience, but then realizing that that's actually pretty painful from an organizational overhead standpoint, from, "Platforms are going to solve all our problems," to, "That's okay if 10 different teams evolve the same platform." From microservices to, "Oh, we're back to the monolith again, back to microservice."

The companies that are called out in these books, they themselves have gone back and forth and have evolved into what they are today. Back to the trap, and then I'm curious with Ivana what their take is on this, is that the trap is looking and saying, "If we just emulate what that company is right now, we're going to achieve the same results." It just doesn't work like that, because to emulate those companies, by the time you become what they were a year ago, they've already changed, [chuckles] to do that.

It's the mistake we make in our personal life to look at the behaviors of where we want to go and think, "If we just walk the walk, talk the talk, that's how we're going to get the results," and then not peeling away a couple of layers below that, to think about the underlying dynamics that allow people to adapt and emerge and find their way of doing things.

One very specific example, at Dotwork, we deal with a lot of people who have a lot of passion for the way their company works.

For example, one person will say, "We love to write it down and we love to document it." We've written the book. There's an 80-page "How we work," book internally, and there's been a lot of love and passion that's gone into writing that book and keep it up to date. You can have a company that could care less about writing anything down. They love that it's emergent. They love that it's culturally transmitted. They don't like writing it down because they feel that writing it down takes the soul away from the practice. Same results, massively different approach to getting there, to getting the end result of success. If you copied either one, you'd probably find that it's not for you. That's an example.

Stuart: Ivana, I know that here at Thoughtworks, we've got a history more of aligning with principles, rather than prescribed methodologies. It would be lovely to get your thoughts. When you go to a client, What's the number one smoking gun that is telling you that they're stuck in project mode, even if they're claiming to be an agile organization?

Ivana: There are some great companies that I've seen from the inside work in a very project-oriented way. Not only are successful companies different, but within a large company, you will have different subcultures. Again, we can use Amazon. There are so many different teams and subcultures within Amazon and any of the clients that I work with. You have the folks who are very passionate about whatever is written. Maybe we have a set of values, maybe we have a set of artifacts that we use, and people use them, but then, what about all those shadow artifacts that are created when these main ones don't work?

Like you said, John, there's very human aspect of dealing with this mess in different ways that work for different groups and different people. When we do enter our client, one of the things we do is we don't try for this big bang approach of transformation of anything, really, of any kind of implementation. Again, there are times when you cannot release incrementally, but when we try to approach what we are doing from a pilot perspective, we can focus on what the real problems are in the space that we're working with and we can find a solution. I would say solution makes it feel like there is an end state when it evolves.

We will find the next step on this journey together and move towards it. Some people will go faster and some people will go slower. Then if we have this small group of people first, you can focus on them a little bit better, and they will learn whether they are detractors or whether they're really passionate about this change. Either way, they may change their mind, but they become your champions. You don't have to push as much if you are really seeing results. Folks will tend to go out and spread the word.

Then there's this other aspect of the exclusivity of doing something in a small group. All of these skunkworks and innovation teams, they're really exciting and everyone wants to be part of them. You start to develop along the way that change really happens rather than trying to think about, "What's the perfect messaging? What's the perfect process?"

I do work with a client right now who's in the middle of this transformation from a very traditional, agile mindset, behaviors, processes to a more product-oriented approach. Even within that company, there are different teams that are approaching it slightly differently based on their business, based on the expertise they have, sometimes based on the partner they've hired, because everybody brings in that unique perspective.

There are many smoking guns, so to speak. I love the one where we go into a client and they give us a very detailed requirement doc or backlog, and then they say, "We want you to build this." Usually this doesn't happen anymore because during the process of deciding whether we're going to work together, we come to alignment on the how, and what is our approach? By the time that we actually sit down in a room and start plugging away at the problem, we already know that there are exceptions, but we don't want to plan two, three years in advance the exact steps that we are going to take.

Stuart: I'd be fascinated to dive into a little bit more about that journey that organizations take. John, I know that recently you mapped out the prototypical journey of organizational evolution, and you particularly warned your readers about linear maturity models. As you are speaking to teams that are navigating this journey, are there any particular stages or specific stages where you see them getting stuck or even sliding backwards, maybe more than anywhere else?

John: It's interesting. Writing that post, I kept reminding people it's not a maturity model. What I was trying to point out in that post was that the common dynamic is this idea of all the motions going on at once, and there being new ideas that get rejection and then get people interested. The idea of converging on mental models and then there's being divergent behavior and new mental models as the earlier adopters in the company, or trying to find out what's next, or success bringing the next problem, "Wow, we're really good at delivering. There's lots of flow."

I wrote recently on LinkedIn this idea that within a company, the concept of flow even changes as you deepen this journey that you're taking. At first, flow is flow of the work, and then someone raises their hand and says, "It can't just be linear. Do you mean flow of feedback?" They said, "Oh yes, flow of feedback." Then that becomes helpful until someone says, "Well, how about value?" Someone, "Oh, okay, flow of value. Okay, we've got to rethink our thing." Then someone says, " We're still throwing things over the wall. How do you get a network approach? How do you get flow not just as a linear thing, but as a tree or as a network?"

"Oh, it's value chains. It's flow across the value chains." Then they go deep into flow across the value chains and then someone says, "It's not just one value chain, is it?" There's horizontal elements across. There are some tree-like parts of it. There are some root-system-like parts of it, and there are some other types of graphs. This keeps evolving.

Now, the reason why it's important for me is that when you're trying to model this out or just come up with an ontology for a company that they can get started with, Dotwork, for example, I see this firsthand. I literally see, for example, it starts out where the company says, "We have a company strategy," and that gets broken down into projects, and then you build them. Then the next level from that is, "We get a company strategy, but let's just organize them into programs, and maybe we'll fund the programs," and then you've got the projects and then you deliver.

Then the next level for the company is, "There's still dependencies between them. What if our programs are more value-- Oh, let's call them value streams." Then you get the company strategy broken into value streams with projects inside of it and then you get teams.

Then the next phase of the company like, "Oh, these value streams aren't really, really aligned. They're still big projects. What about this emerging idea of the product operating model? Let's mash these ideas together." I see firsthand how there's no real world. Everyone says, "You'll map the real world in the company, and then you'll somehow get this truth about the organization," but the truth is that there's constant evolving of mental models in the company about where they're going. That's what I learned writing that particular post, that this has been an idea that's been percolating in my head, that it really is many things happening at the same time, all the time.

One pattern I've noticed is that generally, this is very simple, highly oversimplified, but top-down only change works in a crisis, but otherwise doesn't work if that's all you have. Bottom-up change with nothing else, unfortunately, doesn't work. Middle-out change from middle management is especially damaging. All the managers get burnt out. Nothing ever happens.

The one pattern I have seen is that the top-down air cover, not prescriptive for sustainable change in a non-crisis situation, is top-down air cover and signaling at the core level that something has changed in the company and a support from the bottom up. There needs to be support and signaling to the front lines that those new behaviors are okay and they're welcome to do that.

Someone could argue there, "What's the role of middle management in there?" I would say middle management is actually helping the signaling of leaders do what they need to do. They're playing a dual role, and they're helping the bottom-up effort as part of that.

That is the one pattern I've seen that there's a lot of failure modes in that, top-down, bottom-up, middle-out, and that one that does seem to produce generally better results. When the board talks to the CTO and they have a really hard conversation about what it will mean to change, and the core three or four sets of signaling goes on at that level that's backed by the financing of the company and the investment side of the company and the leadership side of the company at the board level, it does make a huge difference when that happens.

Stuart: Absolutely. Ivana, I'd love to get your perspective on that as well, also, to touch on something that you mentioned earlier, around not advocating a big bang approach. It'd be lovely if you could maybe explore a little bit about, "What's the alternative to the big bang approach, the thin slice approach?" It'd be great to get your thoughts on that.
 

Ivana: Oh, for sure. John, I was just nodding the whole time. A couple of things popped up in my head, the first being that quote that all models are false or bad, but some are useful, and this idea that the model is maybe even useful for a period of time, and then it has to evolve. That definitely resonates from the work that I've done back to big bang versus other models.

I don't know if you've heard or read the book Viral Change. It is one that I recommend to folks thinking about organizational change. As opposed to this big bang approach, more of a virus spreading through the organization. I think one thing that really helps when you do start with a small team is you don't have to have all of those agreements in place. You don't have to have the board agree, or the execs agree.

You can start, and it may be bottom-up, or it may be from the middle somewhere, but you can prove out the value of the results of whatever change that you're planning to make, and then you can say, "Look, I have a case." Folks will tend to either listen to the rationale or observe and say, "I like what these people are doing. Let me try it."

You can sometimes circumvent this political process and the way that things are done using a much smaller, more focused approach. You have more control in general of the people that are working on it. You can design your transformation experiments. We don't only experiment on the products that we've launched, but we should be experimenting internally with how we approach our structures and our culture.

John: One thing I like about that, too, is it's almost a precursor to what I talked about. It would be very difficult to go in front of the board and say, unless it was an existential crisis, "On a purely theoretical level, we think we need to adopt this." It'd be much easier to go into that situation and say, "We have been running some pilots around this and here's the early results around it."

I love the idea that it's never just one direction or one model, it's also, you can help make your case and prove things out in the real world with tangible examples. Anywhere near the front lines, you can do that. That's actually liberating for leaders.

When I talk to leaders recently, I try to remind them that I think that you often have a lot more influence locally than you imagine because of the structural natures of companies and how they're working. A lot of it is you have a lot more leeway locally than you think, and you may have a lot less leeway globally than you think. There's just the sheer inertia of the company at play, however, I like your point that you can leverage one for the other.

A leader said to me recently, "At the end of the day, I noticed no one really looks at the details of what we're doing. There's a corporate machinations of what we're doing that, at the end of the day, it's a budget, and it's a set of things, but I have a lot of more leeway than one would expect locally to do it, but then using that locally borne out example as the Trojan Horse into the more global change." I think that's a really interesting pattern.

Stuart: Fantastic. Thank you. I wanted to move on to another question that often comes up, and that's around industry fit. Obviously, many of our clients aren't in the software industry. They sell cars, flights, pharmaceuticals, or financial services.

From your experience, John, does transforming to a product-orientated operating model work for them and how? Ivana, it would be great also for you to jump in and give your perspective on this, as well, from the different industries of clients that you work with.

John: What's funny, when I was working at Amplitude, Amplitude sold to a lot of tech companies, and so we were very much in this idea of being product-led. What was funny about that was, as we started to go upmarket to car manufacturers and other folks, that messaging wasn't landing as well. They were like, "We are already the best in the world at producing a certain type of car." To say that we're not product-led is kind of funny. We're about as product-led as you can get, or if you're a LEGO, "We know how to make products, so don't lecture us on products."

One thing I started to say at that point is thinking of this idea of product centricity more as a tool chest. I started to say things like, "It's using design, data, technology to create sources of sustainable, differentiated growth for your company that benefits your community, your customers, your team, your investors, and everyone."

That opened up a lot in my mind where you're inside a big industrial place, and you've got this great toolkit that many people might not know about immediately, just like how a consumer good designer has a toolkit for making the best soap, or an insurance plan designer has the best toolkit for making hopefully beneficial insurance, especially here in the United States, for healthcare or any number of things.

You have a toolkit, and you're skilled in something that other people are not necessarily skilled in. When that clicks, something amazing happens with teams, which is, you can look at any non-digital product-selling company, and there's just opportunities everywhere to apply technology, data, design to improve things for the business. The angle I would say is I see these companies read this transform, and it's suddenly they say, "Oh, we've got 500 product teams," as if that's the end goal.

Look, if the SaaS companies that you're trying to model now are going to more platform-focused approach and are now getting rid of their GMs and not calling everything a product, it might be a good idea for you to reconsider just calling everything a product because everything is not a product. You've got a great product. You sell toys or something.

I think that there's a way to get beyond the hype and imagine you're going to copy the companies to think what we're really talking about is the essence. The essence is an amazing palette of skills, and opportunities, and problem-solving techniques that can be used to help companies become more successful and serve their customers. That's been the shift in my mind from product-led as a digital product first idea to more like, "I don't even care about the word 'product' much anymore. [chuckles] Just tell me how we're using these skills and organizing to produce value for the company, and we'll worry about the semantic debates about what a product is later."

Ivana: Absolutely. I think folks who are on teams where they interface with customers, where they build digital products, they do see some of the benefits of working in a different way, but it can be difficult, again, to influence more globally, in a sense. We definitely start with examining the industry, talking to the client about what their real problems are. When we're able to connect how we can actually influence their problem, that's what they really care about. I see a lot of folks in tech or who are advocating for a product operating model, but they can't connect it to what your customer wants to achieve. At that point, it's not going to get very far.

Stuart: I wanted to quickly move on to talking a little bit about looking to the future, but also looking at some of the resistance points as well, and particularly on the people side. John, I know that you've described product management as game design. If a product leader is changing the rules of the game, for example, maybe stopping detailed roadmaps, how should they handle the potential confusion and resistance that might come from other parts of the business here?

John: I think the crux of that thought experiment that I had, which is that every leader in some sense is designing a game, was to make leaders aware of their decisions. As a leader, you're designing a game whether you know it or not. Most people, the first thing they say is, "You mean incentives. You're designing the incentive game," because they think games equals incentives. I'm saying, "No. How about the experience of working in the company? How about the experience of discovery? How about the balancing difficulty with progress? How about giving people a tangible sense? How about the community or the social aspect of the game?" Then they start thinking about it.

I have a fun list, we can share it after this, of the hallmark of good game design. It's appropriately leveled, achievable goals, but hard. There's a social element to it, there's a magic to the experience that you're having. Then whenever I show that to leaders, they're like, "Oh, that is the job, isn't it? To be able to do it?"

Specifically to your question, the number one game that the product leader needs to figure out is the game with people they report to and the other stakeholders in the business. That's where the model design and the narrative design really is important, and guiding those leaders down a path. You might not be the game you decided you wanted to play. I wrote a playbook called the North Star Playbook. It's all about using the North Star metric. I was talking to leader, they loved that book. They love it. That's what they want to align all the stakeholders around.

Meanwhile, a design leader in the company is talking about customer journeys as a central underlying idea to think about how to think about value. Oh, my God. They're going on and on and on about this silly North Star framework and the inputs, why this is the right game, and how it balances all the incentives. Design leader, meanwhile, is knocking it out of the park in every single meeting because it's very relatable. Everyone can understand and wrap their head around the customer journey and everyone understands when customers are having problems in the customer journey. It's very salient.

It's a good game. It's a really good game. It's a good game to walk into your meeting with your stakeholders and say, "Let us realign around the customer journey, where the teams lined up--" Dotwork is actually really good at visualizing this, but it's like, "Where are teams lined up against the customer journey? Here's what's been different since last month." I was laughing because the leader was so bought into their own idea of the game that they thought that would bring their other peers along with them that this other person just-- the design leader just circumvented everything they were doing.

I said, "Well, the proof is in the pudding. The product market fit of the models you have internally and the narrative framings you have internally is a product." Every product leader owns a product which has game-like qualities, which are essentially the core set of models and value narratives that exist, how strategy relates to that, whether there's actual buy-in, and whether that model is a catalyst for action. That's what I was getting at with the game design part.

Stuart: Wonderful. We clearly have to talk about the future and AI. There is a fear that AI is just going to turn us into faster feature factories, generating lots of code at lightning speed. John, do you see this as a risk? Ivana, how do we ensure that AI helps us to build the right thing rather than just more things?

John: Ivana, you go first. I'm curious on the Thoughtworks perspective here.

Ivana: [laughs] I think we're here because initially, when we didn't really understand AI capabilities, the promise was we'll build the same thing, but cheaper and faster. That's very attractive, but as AI solutions started to hit production, we started to see what some of the quality risks or privacy or ethical risks could be. Then we went from over-enthusiasm to pragmatism in trying to build in a new way rather than simply falling back on the same old measures of success.

When we're talking about developer experience, our engineers are coding and they code X% of the time. If we introduce a coding assistant, A, what's the impact, not just on efficiency? Step back and first figure out what we're measuring because there's always some kind of countermeasure that gets impacted by what we're doing.

Then look at, is the bottleneck really coding or is it something else? Are our best engineers spending most of their time in meetings? How do we solve that problem? AI/works, our new agentic development platform, came from this new way of thinking. Going back to what does it even mean to develop products? How do we do it? Where does that point to AI and the use of AI to do something, to improve something? It doesn't only have to be efficiency.

I'm working on that right now. We're looking at the entire set of activities that we do, and they're not linear. I am pretty sure people are sick of me saying that. "Why can't we just put it on a slide? It's a single slide with lots of circles. It looks great, and we can measure it individually."

Just being mindful that there is an entire system around some of the activities that you do, and trying to measure it in a way that's appropriate and more holistic than simply, "We're going to do everything faster."

John: I couldn't agree more. I think one benefit of AI and the discussions people are having is it's forcing people to really think about cognition and think about what it means to create and what it means to sense-make together. I'm trying to be really optimistic that the desire for quick, near-term benefits will be offset by the thoughtful attention to cognition and how it works to do great things.

I say I'm optimistic because as a species, or at least in the last 300 years, since the industrial revolution, we haven't shown a great track record at balancing near-term gains versus long-term things. That's my hope, and maybe some really bad things need to happen for us to get to the better discussion and the good discussion that we need to have.

Specifically, I was chatting with the team, and it was interesting because I showed them a very simple model. I said, "There's things you're doing which are contextful, and things you're doing that are context-free." I use a Cynefin framework, whatever. There's things that are simple and plain, and there's things that are complicated and complex.

Now let's talk through the cognition that's going on for different things you're doing at different squares. We've got six squares. There's things that are context-full and highly complex. It's beyond even a dynamic optimization problem. You've got multiple frames to consider. You're jumping back and forth between different perspectives.

I know a great researcher. Her name is Anthea, and she works in Australia. She's researching how to use AI to help as a cognitive aid for jumping between mental models. That's the correct application of AI for that square.

Then another example, context full but actually very simple, is you're in a meeting, and you're taking notes, and you might be making a couple of remarks of the dynamics in the room. It's contextual because the context surrounding that meeting is important. In isolation, it won't be very helpful, but that's the thing you do out of college if you were working in a company, is like, "Oh, they'll take notes." You're learning how to do that.

Now, the challenge is to get to that upper right, it really helps to have done that work earlier in your career, really helps to sitting there taking notes and doing the work. That activity is a very different application of AI. AI needs to understand the context, but the sheer idea of summarizing text for different audiences, that's really the thing. It's not just taking notes. It's actually, could you write three versions of the notes, one for the executive summary, one for the details of the people, and then capture the action items? AI is very good at that, even though it's a context-full activity.

Now, you go to context-free in the upper-- As you start to move up, the complicated problems are physics. Physics, there are laws that are essentially context-free in the sense that they apply their root problems to do that. AI has a certain brute force approach to solving those particular things, but they're fundamentally context-free.

Anyway. The point is not the model I'm talking about. It's more like, the positive thing that was happening is that people then started talking about cognition, and they started talking about what they're doing to solve the problems that they have. You see this with the product development life cycle. The actual act of synthesis from a UX research angle is a pretty contextual activity, but there are some nuts and bolts, "Dot your i's cross your t's," aspects of it, quote the quote, put them into rough themes so I can review them.

I think I'd leave people with that thought that maybe the opportunity is thinking about thinking and cognitive architecture, and that's going to be the big-- The people who understand that-- and unfortunately, a lot of them got laid off to save money, but the people who do know about that, the people who understand anthropology and sociology and different models, and can jump between those frames and understand cognitive architecture, I think that is the hidden opportunity in all this, is that if we can embrace that, we can start building tools that really benefit humans in great ways, if we can get there.
 

Stuart: Look, before we wrap up this episode, one final quick question for you both. Ivana, I know earlier you had a book that you mentioned. Do you have any books or newsletters, or other resources other than The Beautiful Mess Substack, of course, that you might recommend to our listeners to learn more about this area and get more insight?
 

Ivanna: The Viral Change book, at least from a transformation perspective, and we'll link it in the episode, it has a really well thought-out approach to change, and to something that you mentioned earlier, John. It talks about the role of management in change and what middle managers or leaders can do versus what some of the people actually championing the change can do. From a change management of transformation perspective, that's the one I would recommend. Anyone who's writing about thinking and writing about thinking from the system's perspective and taking a holistic approach, I would definitely recommend.

John: I don't know. I just opened up my Kindle reader. I've found The Skill Code to be really, really helpful back into that line of thinking about thinking. It's by Matt Beane. That's been really helpful thinking about how learning will happen around AI. It's depressing, but also empowering the Four Thousand Weeks book. I'm also a glutton for some of these self-help books.

There is an April Dunford book called Sales Pitch that I really liked. I always think that the people in our business, we get so deep into thinking about thinking or whatever, that sometimes we forget just what makes a good pitch. April Dunford has this great idea of helping the buyers buy versus the sellers sell, and has a great analogy that she uses about her experiences buying toilets and how she ultimately bought a toilet from the store that helped her buy toilets, as opposed to just talking about features.

That hit with me a lot because I am someone who cares a lot about education and being consultative and helping. I've always felt a little bit dirty about sales, and this helped me see that I could merge like, "Oh, helping. I'm actually helping the buyer buy versus the seller sell, myself sell." That was pretty good. Context Changes Everything, which is really-- you're going to take a couple of tries to get through it, maybe don't recommend it for easy reading, by Alicia Juarrero, but that's all about constraints and context and how that matters. I think those are the last couple of ones.

Ivana: I'll just add what you said about Sales Pitch, which is on my list, but I haven't finished. Bob Moesta's Demand-Side Sales is what-- it sounds like it is a very similar theme. If you feel icky about sales, what about thinking from your customer's perspective, who really want to buy at a particular point in time and they want to solve a problem? How can you help them go through that process?

John: It's also deep in Dotwork. Now, I'm Head of Product, and I'm involved somewhat in sales of this company, and it is very interesting. It overlaps the idea of model building and the game design stuff that we said too, where in April's example, she says, "You're trying to buy a toilet, one person just points at all the features."

Then she walked into a store and said, "Look, I know you've never thought about it this way, but fundamentally buying a toilet is really three or four questions. Let me give you a mental model. It's the number of times you're going to flush the toilet. It's whether you care or not about the aesthetics of the toilet, and then any constraints you have in your house about the organization of the bathroom when doing your things."

When you hear that, you're like, "Oh, thank goodness. This was so overwhelming. I never thought about it that way." They're like, "Is this toilet going to be flushed 20,000 times in its lifespan, or 300?" You care about how it looks. I think that way too, when we talk about when people feel icky about frameworks and models. We have the same thing at Dotwork. Now I walk into meetings as like, "I know you think buying these types of tools is about the visualizations offered in the tool, but let me help you. Let me help you buy and share my expertise. It's really about its capabilities of modeling how you work and adapt, and the ability to collect the data cleanly and effectively, which is often hard and then presenting the decision support that leaders need. Let me shift how you're thinking."

That's just an example from the book. I love it. Any person in a consulting or salesy type role can benefit from April's simple book. It's very accessible.

Stuart: Well, I'm certainly grabbing my Kindle, and I'm going to be giving those a go later on today.

John: Start with that one, not the Context is Everything, because then you'll go down a rabbit hole you might not come back from, which is okay.

Stuart: Indeed. Of course, listeners, please don't forget to check out The Beautiful Mess on Substack for more of John's insights. John, Ivana, thank you both for the time today in joining this episode. Dear, listener, thank you so much to you for joining us for this episode of Pragmatism in Practice. If you'd like to listen to similar podcasts, please visit us at thoughtworks.com/podcasts. If you enjoyed the show, do help to spread the word by rating us on your preferred podcast platform. I look forward to seeing you next time. Thank you.