AI and the workforce: Beyond efficiency to real value creation

Transcript


Laura Burger: Welcome to Pragmatism in Practice, a podcast from Thoughtworks where we share stories of practical approaches to becoming a modern digital business. As organizations accelerate in their adoption of AI, one thing becomes clear, success isn't just about tools or algorithms, it's about people. How do we equip individuals, align teams, reshape roles, and build organizations that can learn and evolve in an AI-enabled world?

I'm Laura Burger, and today we're bringing together two voices at the intersection of talent and AI, the people and culture side, and the technology and transformation side. I'm joined by Joanna Parke, Chief Talent Officer at Thoughtworks, and Rachel Laycock, Chief Technology Officer at Thoughtworks. Welcome, Joanna and Rachel.

[00:00:47] Joanna Parke: Thanks for having us, and very excited to be here today. My name is Joanna. I'm the Chief Talent Officer at Thoughtworks. I have been with the company for 22 years. I started as a software developer, and I've played lots of different roles over the years, including leading our North America business and leading talent for the last eight years.

[00:01:07] Rachel Laycock: Hi, everyone. I'm Rachel Laycock, and happy to be here again on the podcast. I have been at Thoughtworks for just over 15 years, which I can't believe. I have played many different technical leadership roles across Thoughtworks. I've led our modernization platform and cloud service line. I've been a technology lead across North America. Then, for the last at least two and a half years, I have been the Chief Technology Officer for Thoughtworks, which has probably been some of the most disruptive times in technology.

[00:01:40] Laura: AI is moving faster than anything most organizations have experienced before. From where you sit, how would you describe this moment for talent and work? Maybe we can even talk about the leadership aspect of that.

[00:01:54] Joanna: I would say this moment is one of the biggest disruptions that I've seen in my career. I think it's in the very early days, and we're just beginning to understand what it means, especially what it means for the world of work and talent, and technology. Then, in terms of leadership, I think what we see is a lot of leaders really struggling with what this means for their organization, how can they drive adoption, and what benefits will they get from the new technologies.

We're going to dive into this more, but I think our view is that it's much more than just individual adoption of technology and that leaders really need to think about broad impacts to the teams and the full organization in terms of how work gets done.

[00:02:45] Rachel: Yes. I think the thing I would add to that is, unlike disruptions that we've had in the past, let's say digital transformation was a big disruption and a big change in our industry. We knew what the end state was that we were working towards. I think what's different about what's happening now is no one quite knows what the future is going to look like in terms of how we build software, how we run systems, how we're operating systems.

Therefore, given we don't really know what it's going to look like, we also don't know exactly what the talents landscape looks like, which makes it hard for leaders to navigate. Some of the stuff we want to share today is how we've been navigating that, and based on our learnings, what are our hypothesis of the stuff that's changing?

[00:03:32] Laura: There's a lot of leaders that are very excited about what AI can mean for their workforce. Maybe you can talk a little bit too, because there's a lot of uncertainty. What does that mean relative to some of the biggest misconceptions that we're seeing?

[00:03:46] Rachel: The biggest misconception, I think, is this whole AI is going to steal your job, which I believe is somewhat related to the conflation in the industry of, "Oh, I'm laying off all these people because of AI," and I just don't buy that. I actually think that companies are laying off people for more economic reasons around their business, and that's impacting everybody. We know we're in a hard place when it comes to economically and the workforce in general.

Those things get conflated, and then people have a lot of fear around AI. The reality is for people that are adopting it now, it's making them more effective, maybe in some cases, on an individual basis, more efficient. We'll talk a bit more about why that's such a problematic thing to measure, especially at scale. I think that misconception is creating more resistance in the workforce than is really necessary, and I don't think it's really true. I don't think it's true in the short term.

Obviously, it's very hard to predict the future right now. I'm saying that as a CTO, and I think most CTOs would agree with me. It's hard to look beyond the next 18 months, and usually we're looking three years out. Because of that, we don't know exactly how jobs are going to look like in the future. Most people that are adopting these tools it's making them more effective. They're finding better ways of working, interesting things that the Gen AI can do, and things that it can't do, like pushing it to its edge.

I think if we can move away from this idea of it's going to steal our job because it's not in the short term, I don't know what will happen in the long term, but it's not in the short term. I think we'll get less resistance for people adopting it. Then, when you've got more widespread adoption, that's where you start to push the edge of what the technology can do. Then people can innovate not just on their individual work, but how they work as teams and also how organizations work.

[00:05:37] Joanna: I just want to add to that, I was reading some research the other day where they did a deep dive into all of the job losses over the last year. Their conclusion was that less than 1% of job losses were actually due to work being automated or replaced by AI technology. It's certainly overblown. Rachel's right, it's two things happening at the same time that are being conflated. The other thing I wanted to add about misconceptions, and I think we hear this one a lot, which is that we don't need junior talent, that we don't need junior developers.

What we're finding when we talk to teams is that the magic is really happening where you have a great balance and a team between people earlier in their career and more experienced technologists. From the junior people coming into Thoughtworks, in particular, we see a lot of just being open-minded. These people are, if we can call them, AI native. They're learning how to use these tools and technologies from the get-go. They have a lot of passion and curiosity about how work can be done. They don't have a lot of, let's say historical baggage about how things used to be done.

That being said, they're lacking the experience, the hard-earned experience of having learned how to develop technology. We can call it the hard way. They really need the benefit of that experience from more senior technologists who can teach them what good looks like, how to think critically about the output of AI, how to develop good technology practices, which are still more important than ever.

[00:07:19] Laura: Both of you have recently authored articles around this topic, and there's that central tension around the AI benefits only matter at the organizational level. Maybe you can talk about that too, when we're thinking about the organizational level, the team level, the individual level. What's your perspective on that? Rachel, maybe you can talk a little bit to start.

[00:07:38] Rachel: Yes, it's interesting. When I think these tools first came out, and I think the early adoption of a lot of these tools was in the software delivery space and then creating new software. There was early claims that, "Oh, this is going to make you 50% faster," which is very challenging for any technology leader when the business is like, "Cool, you guys then 50% cheaper now," and it turned out that wasn't really true. In fact, we did many tests, we were pretty early adopters on these kinds of coding tools is that the best case at the time, on an individual level, it was like could be 13% more efficient. There was tons and tons of caveats around that.

That's just a software developer. The software teams are made up of developers and QAs and PAs and project managers, and product owners. It's a team sport. One bit of efficiency on one person doesn't necessarily mean that the whole team is more effective because in reality, if I can build software faster, then the amount of code reviews that needs to happen is speeding up, the amount of tests, and QA process. You're just creating a bottleneck somewhere else. We realized that really early on and said, "Well, okay, how do we start reducing some of these other bottlenecks?"

Then you're just playing whack-a-mole against a process. We were like, "Let's take a step back. How do we approach this when we're helping clients look at how can they be more effective in the software delivery cycle today?" We use a very well-known technique called value stream mapping, where you look at I want to get this value into production. From inception of idea into the thing is in the customer's hands and what are all the challenges in our current ways of working, which is usually cross team and we identify the waste in the system.

It's a very classic lean management approach. It's very old. It's been out a long time. That helps you then look at not just an individual or our team, but start to look organizationally at what you can do. Now, when you layer Gen AI coding tools onto that or other tools or Gen AI in general or large language models, at least in this context, think about it as a tool that can make people more effective. You can look at that whole value stream and go, "Hey, let's try this use case and see if we can put Gen AI into that use case and make that use case more effective."

From the perspective of getting value from idea into production, or change from change needed, issue in production into production. That's more of an organizational view than an individual view. An individual level, like as I said, even if you get one person to be more efficient, more effective, what does that mean in the context of the entire team and the entire organization? It starts that 50%. If you can even achieve that, that number gets smaller and smaller and smaller when you start to think at scale. That's the approach we've been taking.

[00:10:33] Joanna: Yes. I just want to add on to that. I think it's very natural that many organizations, including Thoughtworks, really started at the individual level. These are new tools and technologies, and there's a lot we don't know about them yet. For organizations, getting the tools into the hands of their people and encouraging a culture of experimentation and continuous learning is so important. You start doing that, and you get people to really explore what's possible.

Then, the next phase that needs to come is this more-- I don't want to call it top down, but more broad organizational view that needs to happen to say, "Okay, what are we learning? Where are we seeing the benefits? Where does it work well? Where does it not work well?" There certainly are places where it does not work well. Then, as Rachel talked about, what is the value we create for customers, and how can we do that in a different way, maybe a better, faster way to really unlock value?

I think because of the macroeconomic environment over the last few years, and the fact that these tools are not inexpensive it's natural that a lot of the focus has been on cost savings and productivity, leading to cost savings. I think what will be really impactful is the organizations that start to shift that view to value creation. We can tell from many, many historical technology innovations that ultimately is what will happen, and that the winners out of this transformation will be those that figure out how to leverage the technology for growth and for creating more value.

[00:12:14] Laura: I would add on to that. I've been speaking to a lot of different technology leaders across many different industries, and they're saying, those productivity metrics, those efficiencies, they're not being realized. I guess for many of the reasons I just described, just because you do something in the small doesn't mean you actually can see that at scale. Where they're actually seeing value of GenAI, the tools and the models is improving of effectiveness of their employees, which is a little less easy to measure than efficiency.

That leads into what Joanna is talking about. When you think about effectiveness, it's usually around how can I do my job better, do more, and that's more in the growth mindset, value creation mindset. If that shift is happening in technology leaders, then I think that shift is going to start happening across the industry, and we're going to move away from just the pure productivity metrics.

As Joanna said, it's the economic pressure that's creating that. Nearly every technology leader I've spoken to said, "I'm not getting extra budget to invest in AI." Their initial hope was, well, hopefully that this creates an efficiency that I can then use to invest back in AI, and that's not happening. We have to take more of the value creation approach to it and look at what metrics we can set around that.

[00:13:33] Laura: Joanna, I want to pick up on to something you were talking about with that healthy balance and that top-down, or I should say bottom-up, top-down approach when we're looking at that. Maybe you can talk a little bit about how that would look and how we want to best balance that for success, because we want to give people that freedom. There's also that balance between the freedom to create and the governance and the structure, and how do you really meet in the middle? Maybe you can talk a little bit about that.

[00:14:02] Joanna: Organizations truly do transform from the activity that's happening on the ground. It's a great place to start, and getting people excited about and bought into the possibilities and really taking ownership over their own learning journey and their team, and how it's evolving. It's really hard for individuals or even teams to be able to see the big picture. That's where I think senior leadership needs to come in and really think about the organization, how they create value for customers.

What are the organizational opportunities? Devise a strategy or an approach on what are the most critical business challenges that we want to capture opportunities around. It's then marrying the two, as you said, Laura, and figuring out how do we crowdsource from employees, all of the ideas that they have, all of the innovation that's potentially coming out of their experiments. Figure out how to channel them into those important business use cases. Then, thinking about organizational structure, how work gets done, how teams are organized.

A lot of the organizational structure builds up over time, and it's a really difficult task to unpack or untangle and think about a different way of work getting done. I think we're seeing from our teams that the way teams are interacting with each other is changing a lot because of this. Having that end-to-end view is really important. It's only the senior leadership that has that really big picture view of the entire organization.

[00:15:51] Laura: At this pace of change, obviously, careers, skill sets, career paths are changing. Any thoughts around how that's going to evolve and what we're going to see, maybe even more near-term because of that?

[00:16:04] Laura: Yes, I can share some of my thoughts. I've been heavily focused on the software delivery lifecycle, how we build software, how we operate it, how we run it, how we modernize it. How people are working starts to give you some idea of what roles could start to look like in the future. This is just in this context, I think every function will have to look at that, how things are being used, and then take that step back and think about how could this progress?

One example that we're seeing is is the art of greenfield creation of code is going to be more and more automated. This field of spec-driven development is rising around that where the developer or the product person spends more time focused on the initial specification in order to get a great result in terms of what's generated. The stuff that gets generated is not only the code, it's the unit tests around that. The whole greenfield, like creation from zero to one of applications, I think, is massively disrupted.

Then, if you just think about, as I said earlier, what would a team look like ordinarily. A standard development team might have two pairs or two developers and a QA and a BA, and a product manager, and potentially those QA, BA, and product manager might go across several teams, but that's your standard setup for a development team. There are tweaks around the edges, but if we're saying a developer is writing the spec and then everything else is getting generated, then who's their pair, and is that necessary?

Then we need somebody who knows the business requirements. Now that could be a BA, could be a product manager, whatever the role is in that organization. That's kind of it. That's a totally different setup. Now, immediately, that leads to the problem of, okay, if we only need a very senior engineer and we need a senior, pretty technical product owner, A, what does everyone else do? B, how do we grow those people? Because you don't just come out of university as a senior-level engineer.

The skills that you learn, which is currently all the hard way and all manual, we do pairing at Thoughtworks, where people sit side by side. We also work on lots of different projects. That speeds up people's learning because not only did I sat with somebody working through a problem, learning different ways of doing things and approaching a problem. They're also learning lots of different cross-functional concerns, potentially different industries, seeing things go into production, seeing what goes wrong when things go in production.

That's basically how we all learn. The professionalization of our industries is kind of low if you compare us to real engineering industries, or architecture, or even the medical field; it's much more structured. There's an expectation of you having certain levels of learning before you can do certain things. That makes me think that, okay, we're going to have to nurture these people right from university all the way up to this senior level. I think we have to take a step back, break down what it is we actually learn.

That leads me into essentially an apprenticeship model or a professionalization of our industry. I was just talking about building software. We haven't even talked about modifying it and running it. In the future, there's going to be lots of agents doing things. We're already seeing that happen from an operational perspective. There's an issue in production. Oh, it's a pretty simple fix. The agent figures it out and fixes it. Then, some developer reviews it and says, "Yes, that's good. Let's go." That's totally different to the manual approach that we've done in the past.

You're going to have these very much smaller teams covering much larger pieces of software or much larger systems. They're just not going to have the depth and the understanding of those systems. What they need to have is the depth and understanding of what could go wrong, what's good answers to things that go wrong. Those are all architectural and engineering concerns around software, which just it changes the field.

I think then that pair in my mind, and this is me hypothesizing, is that, you've got a senior engineer plus their apprentice, and then you've got a senior technical product owner or a product owner, and their apprentice. That's a theory I have that we'll be testing out at Thoughtworks. I don't think it's far off from what other people have talked to me about, because otherwise we're just going to have a massive dearth of these.

Everybody wants these senior engineers, and that's great, but there's not going to be enough of them to go around, and these senior engineers what they're skilled at it's not very well written down. It's not like you can say like, "Rachel's a level seven," and so on. It's assumed I know all these things. We're not at that stage at the industry, but I could see us going there.

[00:20:50] Joanna: The peer programming, what's really interesting, when I talk to our teams, there's this idea of, "Isn't the AI tool your pair?" Really, what they're finding is you obviously need that human discernment to look critically at what the output is. What they're doing, especially when you have a pair of maybe a more senior and a more junior person is, rather than the pair necessarily spending all of their time handcrafting code, the pairing is used to teach people how to use these tools properly.

The topic of the pairing is maybe changing or evolving, or the discussion that's happening. Certainly, there's still the notion of how should we approach this problem. How should we solve this problem? What should we do next? That leads to really high quality we know from pair programming history. A couple more things I wanted to add, since you asked about career paths. I think one interesting pattern that I'm seeing, again, when I'm talking to our teams, if we go way back when Rachel and I entered the workforce of software developers, we were what we called full-stack developers.

You could be a full-stack developer because the stack was infinitely less complex than it is now. Then, as technology evolved, it became almost impossible because the full landscape of technology was so big that you couldn't be an expert in all areas of it. I was speaking to one developer who shared a story with me that he really viewed himself as more of a backend developer expert, but with the augmentation of these tools, he said, "I can be really proficient now in front-end development because it can fill in some of the knowledge gaps I have about the stack."

I think we're also seeing the lines between roles are blurring. You can create a decent user interface, you can create the business requirements, and you can use it to generate test data. I think we're coming full circle from a full-stack or very generalist approach. We weren't very specialized as an industry for a while, and I think we're coming back full circle to more of that generalist view.

[00:23:13] Laura: Let's shift gears a little bit and talk about earlier, we hosted the internal AI for software development festival. What surprised you by that? That was obviously a really big undertaking, tremendous effort. Some really good outputs, I think, from that.

[00:23:30] Joanna: I think maybe before Rachel answers that, I'd like to just share a little bit about the origin of the festival. I was having a conversation with some of our senior technologists, and I was really trying to understand this world is changing so fast. Every day, there's new tools, new models coming out, and how are you staying on top of it? One of the things they shared was we have something in the talent space called the 70:20:10 model.

It's a well-known model about how people learn, and it's basically 70% of your learning happens on the job, 20% of it happens through social interactions, and only 10% through formal learning. They really reference this notion that because things are moving so fast, they have to rely on their network to really share and understand. Whether that's people they follow on social media or things they read, or just spending time with other senior technologists talking about what they're doing, the experimentation.

The idea for the festival was really born out of this concept of social learning, which is something that's very near and dear to us at Thoughtworks. We talk a lot about our culture of cultivation, which to us means that everyone is both a student and a teacher always. The intent of the festival was to hear from Thoughtworkers what they were doing, whether that was in their client projects or in their side projects, and really share with each other so that we could accelerate learning.

[00:25:04] Rachel: To answer your question directly, Laura, what surprised us, we had a lot of hopes the energy that the festival would generate. I was just surprised about how much energy it generated. At the end of the day, outside of what's happening with AI, it's all doom and gloom and not great news. As an industry perspective, as we stated earlier, lots of layoffs across the globe. I was worried that people would be like, "Yes, that's nice, but I've just got to get on with my day job. I got to get my head down."

What I realized, and I guess it's true, we proved it is as much as we as leaders can say, this is important, it's really when people hear from their peers and other people they respect that they pay a lot more attention. I have experience with this recently because, on the back of the festival, we've been doing more of this internal sharing of finding out what projects are doing interesting things and then asking them to share with a wider group.

Those are way more well attended, people are way more interested than what me and Joanna might say, and other leaders will say, it is what it is, but we're okay with it. Once they see their peers and folks like them doing the work, using these tools, what results that they're getting, and what's working and what's not, it encourages people to really use these things. We had an uptick in people requesting the training courses that we'd built.

We have a bunch of different chat groups around one that's just in AI, one that's around AI-assisted software delivery in this space. Lots more people joining that. That's a buzz every day. That's actually my starting point in the morning. I'm like, "Okay, what's been happening in that chat space?" Because that's usually where all the links to all the articles and everything is happening.

It's not just a random article or something that appeared in your inbox, which you don't know if it's just marketing for some product. It's people that they respect or that they think is interesting stuff to follow. The energy that that created, which, as I said, we've been building on. Then we're actually planning to do another festival early in the new year as well. That was probably one of the most impactful things we did.

[00:27:23] Laura: Well, it's a lot of community-based learning. When you think about just having the tool or having the training versus learning together, and I think that's such a strength here, is that community-based learning. Great. You talked a little bit about too, how you were spending time learning about the projects.

I know you've had some focus groups with our technologists. Were there any moments that have come out of that? Like you had said, we see a lot of strength and progress when we're speaking with our technologists and spending that time. Was there anything interesting that came out of those focus groups?

[00:27:58] Joanna: Yes, loads. Over the last few weeks, I've been doing some focus groups with Thoughtworkers from around the globe. I've talked to people in Brazil, Spain, the UK, India, and it's super interesting to hear different perspectives from people in different regions. I think a few takeaways I have. One that's very clear, comes out loud and clear in the conversations, is that good programming practices, whether you want to call that extreme programming, that those practices are more important than ever.

I heard a lot of these tools; if you attempt to do something that's too complex, you're likely to get back garbage. One of the longstanding good practices in software development is that you tackle the smallest possible thing next, and you build quality software one small piece at a time. Some of that comes from test-driven development. You write a test for a small piece of functionality, and then you write the code to make it pass.

They're finding that that approach really helps them get the most out of these tools. It's also instilling, again, in the more junior technologists these good practices. Pair programming, test and development, they are finding to be more important than ever. The other thing that is interesting, particularly when I talk to the senior technologists, is just the impact to their role. Rachel talked a lot earlier about prompt engineering, and I think what we're seeing is that a senior engineer role is moving from more of a builder role to more of an orchestrator and an integrator.

What I found is different people have different opinions about this shift. Some are more excited about it than others. I would say some developers really get their fulfillment and satisfaction from the process of handcrafting code. They are not excited about the fact that they are now spending more time on prompt engineering, and then a bunch of time on code reviews to look at the quality. Then there are others who, they more get their fulfillment from seeing their ideas come to life, and so any speed or augmentation that they're getting, they're super excited about.

As we think about the future of talent and career paths and roles, I think it's something important for leaders to recognize is that different people are welcoming them at different levels. We really have to help people through the change management of how they get satisfaction and fulfillment from the craft and find a way to really engage and motivate people in that process.

[00:30:52] Laura: Lots of change obviously happening. I think there's a lot to manage too when you think about employees and cognitive load, moving at pace. Even Rachel, I think I've heard you talk about before, thinking about the thing and not the hours, the bolts, and how we really solve for that and move at pace, but be very focused at times. It's going to be a different type of probably workforce workplace. Maybe you can offer a little guidance when it comes to that. How we're working through that today, and where you've got some general opinions on that.

[00:31:28] Rachel: I think it's an interesting word because a lot of it does come down to change and change management. I think traditionally when we think about change, we're like, people, process, and technology, but that's in a world where we know what the output is going to be. As Joanna was saying earlier, when we built our program-- I don't know what we call it actually now, I think about it. We knew that we had to shift, and we needed to do something in AI. We intentionally said AI-first software to really push the edge of it.

We looked at not just the people, the process, the tech, but also what are competitors doing? What are the tools and technology? How's that changing? What's our core differentiator? What is our business model? We looked at everything and then run it all in parallel as a change program with what I call a strategic learning cycle. Not different functions running off in different directions and doing things. It was a program we put together intentionally, forced everybody to cross-collaborate. I know you were both part of it, so you know what it felt like.

I described it as organized chaos, which I think is a good thing. Lots of learnings. Then at least once a quarter we were like, what did we learn and what are we pivoting on right across the articles that we put out in the industry, across how our talent changes, across how we work changes, across how we go to market, everything. These things all influenced each other. I think that that was tricky to do, but it was so important to take that approach because otherwise you're implementing change in a silo in a place where everything is changing around you. There's no clear end state.

We're not going from A to B, and then this is the change program. We're going from A, unknown B, begin change. It's totally different way of thinking about it. What we were able to do is learn things along the way. Like I talked earlier about, at the start we were like, "Oh no, this is creating a bottleneck here. How do we make sure it's not just developers doing these tools? Oh, if we take a step back, how does it look at the whole process? Oh, let's break apart the stuff that's greenfield from brownfield because that's really different."

When I say brownfield, I mean editing existing software and then the whole legacy modernization, or I've got a mainframe, or I've got some really old system. That's a whole different thing. We broke things apart and then brought them back together. When we put articles out in the world, we saw what the feedback was and we connected to the industry to see what they were doing. It was this constantly evolving and moving space. The festival and other things we were doing is really just trying to take Thoughtworkers on the journey of like, "I don't actually have the answer."

The first question of, am I getting fired because of AI? My answer right now is no. I can't tell you about that in three to five years. We'll all see, but I want you to come on this journey. The other thing is, I'm not doing this to you. It's not leadership saying you all must change. It's like the industry is changing around us, and come on the journey, because coming on the journey will actually help you get a lot of the learnings of what does the future look like. Then, to Joanna's point, that's where people started to go like, "I like crafting software. I don't know if this is where I want to go."

It's like, well, it's better that you figure that out sooner rather than later. I think the big part is being open about the change that we're all going through and trying to take people as much as possible on the journey with you, and not being siloed off in different functions. Everybody trying to do things their own way. That's why I called it organized chaos, because there was still some of that. I like the idea of a thousand flowers blooming, but then we come back together, and we're like, "Which of the three to five flowers are we actually going to put some energy into that we think are going to grow into a really nice garden?"

We did a lot of that. Then, as we go into 2026, we've really identified where are some of our big blind spots. Where are some of the big open questions that still need figuring out? That's either a real constraint that's going to be ongoing or an opportunity for us to innovate in the various parts of our business. That's really how we've approached it. Then when I talk to other organizations that have also been fairly I guess ahead in terms of their own transformation around this, it's quite similar hands actually.

[00:36:04] Laura: Great. 12 months from now, what's one thing you would love to see organizations stop doing, and then one that you would like to see them start doing as a result of this when we're talking about AI and talent?

[00:36:19] Joanna: I'd love to see organizations start reinvesting in junior talent. I think it is an existential threat, as Rachel said, which is, if we overly focus on experienced engineers, we'll find ourselves with no experienced engineers in a few years. I also think that organizations underestimate the importance of the energy, passion, and curiosity that people early in their careers bring. That's my start doing.

In terms of stop doing, I really think we have to shift from the obsessive focus on cost savings and turn our energy to value creation. It's, again, understandable why we've been there in terms of the macroeconomic growth, but it's easy to fall into the efficiency trap and not achieve true productivity gains and true gains in value creation. I think the organizations that are able to make that shift are the ones that are going to emerge as the leaders in the future.

[00:37:21] Rachel: I think, and this is related to the start doing, take that step back and think about, given the power of this, how does it impact my X value stream within my business? How could that change my organization, and how do I start down that path? Because I think that's a very different approach to incrementally using a tool or this is better or this is better, because they have to start using the tools just so people can start using it in anger and see what's good and what's not. Then take the time to take a step back and look across your whole organization for those value creation opportunities. As I said, we didn't rehearse this, but we have [inaudible 00:38:04].

[00:38:05] Joanna: Great minds.

[00:38:06] Laura: Yes. Any other parting thoughts today that we haven't covered?

[00:38:12] Joanna: It's been a great discussion. I think what's exciting about this time in the industry is that it is changing and evolving so fast. We just need to approach it with curiosity and understanding of how we can really engage everyone in the organization to go on the journey. I'm excited to see how it evolves over the next three to five years.

[00:38:38] Rachel: I do have a parting thought now.

[00:38:39] Laura: You do.

[00:38:40] Rachel: You inspired-- [laughter] I say this a lot, but I think it's important to reiterate. Just because you can't see those immediate cost savings or whatever the initial early thoughts were, don't sit and wait, because we don't know the end state, but waiting is not a good strategy. Starting, whether it's as an individual, learning them, whether it's as a team, seeing how you can work together more effectively, whether it's as an organization thinking about how can you create value with these things.

Yes, lots of those use cases and proofs of concept will amount to nothing. That's the idea with experimentation, is that you learn stuff and you move on, and even if that learning is not the greatest idea, but waiting to see what are the killer use cases and who's going to disrupt your industry, not a good idea. I think organizations have to figure out how to get started and take their organizations on the journey.

[00:39:39] Laura: That's great. Perfect. Well, thanks so much for joining us for this episode of Pragmatism in Practice.

[00:39:46] Rachel: Thank you.

[00:39:46] Joanna: Thank you.

[00:39:48] Laura: If you'd like to listen to similar podcasts, please visit us at thoughtworks.com/podcasts. Or if you enjoyed the show, let us know. Share a post on LinkedIn or X and tag Thoughtworks.