You don't need more code. You need more business impact. | Thoughtworks' Chris Westerhold

26:54And everybody's heard of Conway's Law before. But when, you know, you go in and talk to somebody, it's like, yeah, you've built all of this stuff around the way you operate. And that's not really good for you. And in that, that back to that example I was giving, that's how their organization was set up. And so that's how they were building software. And, you know, you have to rethink some of those things if you're going to be able to really move the needle. So let's talk a little bit about actually moving the needle. Now, we've kind of broken down waste sources of it, ways that it impacts process and tooling within an organization.

27:31And, you know, some people look to things like automation to solve waste. Maybe if you can find ways to deploy faster or reduce cycle time, they kind of view those as like the solution to reducing waste within their organization. But often many teams just need a little bit better alignment and a little bit less sprawl. Like, you know, whether that is process sprawl, like you described earlier or some sort of tooling sprawl, given all of this, how do you identify work that actually matters in this environment where you may have lots of sources of waste that you don't fully understand yet? I always take these types of questions and go back to organizational goals.

28:09And I know that feels like a big step for a lot, but like you hear, you hear lots of people talk about like OKRs and these other things, but like what are the goals you're actually trying to solve as an organization? And, you know, when you think of like young startups, they don't have a lot of money and they want to go really fast. And so you're totally fine with accumulating a lot of tech debt because, you know, you're going to have to replatform this thing once you get your series B or something like that. And that's OK. But then as you mature, you know, less concerned about going super duper fast, you probably have a little bit more money so you can be a little bit more focused on quality.

28:50or maybe you're trying to completely transform your business. Like what are the things that actually matter to you as an organization? And I see a lot of engineering teams really struggle because they don't have a North Star. Like, how do I identify the things that matter? I need to know what our goals are. What are we trying to accomplish as an organization? And then that's going to help me identify the right things to do because you can automate all kinds of stuff. But if you're going to replatform or do some other stuff, you know, maybe next year, it would be silly to spend your time on some of that.

29:29And so to me, not having that alignment, you can just see this rippling effect across an organization, especially as that organization gets larger. I've talked to some orgs that have 5, 10, 15 ,000 developers. And I would bet that if you went up to the average person there and asked them, like, what, like, your work you do every day, how do you think that actually impacts the business? And a lot of them would probably say it doesn't, which is, which is, has its own set of problems. But I've been there. Yeah. I mean, we all have, right? But if you, if you don't have that, like, how are you going to identify the stuff that matters?

30:07you can't really yeah i'm thinking back to when i was in platform engineering at a very massive company and and uh the latest to hot technology comes out and the ceo says we all have to do this thing now and it's like but i work on platforms that don't touch that so like what does that mean for me and you know i think the the second bit around some of that is like you'll hear a lot of engineering leaders say and focus around just productivity productivity productivity productivity and you know the there has been a severe focus on the need for faster typers when i think i mean we're going to talk about ai in a little bit but like that's been like the focus is like oh well we need people to actually write more code and i would say the answer to that like i think that's a false premise you don't necessarily need more code what you need is more impact to your business because like the the value of a line of code is essentially dropped to almost zero at this point with a lot of the other tools and everything that's out there but you know understanding what are you trying to do why are you trying to do it what's the waste that's in your way and you know like i think we all have been on some kind of platform team at some point in our life but you know what maybe abstract away that complexity is the best thing that you can do to let your developers focus on the things that matter.

31:32Like you talked about the unknown unknowns. Like, yeah, you should be, like if it's a known known or kind of a known unknown, great, automation paths for that, bring in your AI tools to help with it and then allow your really expensive engineers to go focus on the things that actually matter, not on things that have been well-sorted inside of your organization and then let other things focus on that. I think another interesting kind of misconception or misunderstanding is that like developers don't like to talk and they do. They'll talk your ear off. All you have to do is just come to them with good intentions and ask them interesting questions and they'll talk your ear off and they'll tell you where all the problems are.

32:18You just have to ask. and when you start to think about that type of thinking and that kind of continuous improvement that goes along with this different set of metrics, you now all of a sudden are doing things that are kind of twofold. If you have a good understanding of where you're going in as an organization and you're listening to your developer community to say, hey, tell me where the problems are. Where is the crossroads of those two things that can have a good impact towards your organization, positively impact your development community. Study after study says that happy developers are going to be more productive.

32:55They're going to write better code, all of those bits. And all of a sudden you've made everyone happier and a rising tide lifts all boats. But if you're like a lot of those kinds of things take a serious level of leadership and organizational alignment to make that happen. Yeah. Yeah. So do you have any examples of an organization that starts to think about, wants to think about things the way that you are describing, but maybe instead of actually improving productivity, they're actually like adding to the complexity of their environment. Yeah. I see this quite literally all the time. And this is the, like as technologists, and I kind of already mentioned this, like we kind of fall in love with technology.

33:39and if you're just constantly thinking about bringing in new tech, bringing in this other stuff, and you're making your environment more complex. I met with a client yesterday, and we were talking about CICD. How do you kind of modernize your CICD platform? And I asked him a question. I was like, well, what platform do you use right now? What's the thing that you're really kind of focused on? And he's like, oh, well, some teams use Azure DevOps. Some teams are using Bitfucket Python. lines other people are using team city octopus deploy jenkins github actions the answer is yes yes and i was like i was like did you just list a did you just google like give me 10 like cicd like he's like oh no yeah no i mean this is just kind of what we're doing and i'm like well of course you have a problem i mean it's about 2 000 developers which is big but not that big and you know so you have you now have this landscape of complexity that is hard enough for the people on those teams to be able to understand but now you've made like you have a high level of fragmentation inside of your organization you've made it difficult for internal engineers to move from one team to another team and you've now essentially kind of crippled yourself when it comes to being able to be nimble enough to go after the things that matter to the organization.

35:06I actually want to touch on something, you know, you mentioned like asking developers to figure out what would actually benefit their lives, but I wonder how do you balance this? Like, uh, you know, I always think if you ask a room full of developers, like if you ask 10 developers, what's your favorite CICD tool? There's a good chance you're going to get 10 different answers probably 12 you know you have 12 actually right so how do you balance this like well the developers want all of the greatest technologies and they just want to adopt what they think is really cool versus like we as an organization need to make sure that we are following best practices we're standardizing things we have like happy paths that are easy to follow along with like how do you balance those two things yeah that's a really great question but I have to give two answers to it.

35:51And so I'll have to caveat a little bit. So you want to think about your early adopters. So like, who are the people that are on the forefront of things? And you can see this a lot in the AI space right now. Like, oh, well, do you want to use Cursor, Windsurf, or any number of other things that pop up seemingly every day? There is a number of people-ish, 10 %-ish, that are going to want to just run around and use all of that stuff and just geek out on it, spend all night, fiddle around with it and find the best way to do it. Like a lot of organizations try to rope those people in. It's like, no, no, no, no, you can't do that.

36:28It's like, well, no, even hold on a second. Like those are people that are going to validate all this stuff for you. Then there's this middle majority that are just like, tell me what to do and I'll do it. Like if you want to buy cursor, great, I'll use cursor. You want to do VS code, fine, I'll do VS code. Just give me an easy path to get my job done. I am technologically literate, but I just, I don't care. Like there's not enough of a reason to care. And so I think in the best organizations, you have a process that can say, let these like cutting edge, bleeding edge people go do that analysis, but then gather that feedback from them and say, Hey, I saw you were fiddling around with Sonnet and, you know, Claude Code.

37:09What'd you think? And as you start to gather that information, you can now take those learnings and apply that to the middle majority and say, great, we've built a really great platform for you. We have some custom IDE plugins. You know, we've determined based on all of this feedback that VS Code and whatever, whatever is fine. And so that's the way that you can keep essentially both of those camps of folks happy. Like that works really well when it comes to those types of tool where you run into problems are like CICD pipelines and like more kind of core fundamental things where it's like, hey, I can't have you just running and going and trying every random pipeline tool under the sun because that brings in cost and complexity and things that are a little harder to unwind than, you know, using J unit or whatever.

38:04Right. You're rightfully calling out that it's less about allowing all these bespoke developer experiences pop up within your organization that's only going to make it harder to exchange knowledge. That's not the same as people who are pioneering or early adopting with tools and experimenting with them and figuring out things that are going to work for your org before anyone in the world knows if they're going to work for anyone. Those are two different levels of choosing your lane, having your favorites, figuring things out. Because those early adopter folks, they might feel strongly identified with a few of the things they're picking up.

38:39But they're not like, oh, I'm JUnit or bust, like what you just rightfully called out, right? If you're in an organization that has that kind of sprawl, there's a lot of opportunities to simplify, I think, the platform. And that actually really flows well into another thing we want to talk about with you, which is about having the right strategy to make those organization-wide engineering changes, make those platform engineering upgrades that are actually going to make an impact and not slow people down or cause a revolt, right? This is what everyone's afraid about when you make massive change for developers.

39:11And right now, you know, AI is being used pretty interchangeably as like an ultimate developer productivity accelerant and unlock. But without platform engineering and a coherent strategy, that's ultimately chaos and it's expensive chaos at that, right? You know, all these queries are costing somebody money. And Chris, you've said that companies need to rethink their systems and their platforms before bringing in new stuff to actually help them. And how do you think that actually looks like in practice and how can a team really start? Yeah, that's there's a lot there. I always like to, just as a general principle, optimize for laziness.

39:53The best developer is a lazy developer. I don't want to do that again. It wasn't fun the first time. I don't want to do it again. Give them a path to be able to do that. And I think a good platform and a good platform strategy enables some of those things where you have these kind of golden paths that allow people to be able to do things easily, but it's flexible enough for you to be able to say, Hey, here's how you can modify this to make it work for you. Here's how this kind of like centralized ownership or centralized controls, but federated ownership. Like I'm just providing you with a core and allowing you to be able to go from that.

40:33Like that's one way, like, you know, the, I always liked, uh, I always kind of bounded autonomy is another thing that I try to talk about of like, you know, Hey, well, there has to be a box. I can only support so many tools and so many tools, so many things. And so now this is how we're going to, you know, provide these sets of tools out from a platform perspective. They're going to be well curated. They're going to be easy to use. They're going to, you know, kind of hook into all of the things that you would expect them to do. And the vast majority of people are going to be okay with that. And you're going to get a lot of unlock from a productivity perspective by providing people with this kind of set of tooling.

41:21You know, the way that you kind of described the question, like a lot of people do feel like if they tell people they can't do something, it's just going to erupt in chaos. Like I, but I don't think that's necessarily true. If you invoke like the EAs of old of like ivory tower, like, you know, you shall not pass kind of stuff. Like, yeah, you're going to get some really bad reactions. But when I think of good developer experience, good platform engineering and kind of like just a really good metrics to strategy overall, like you have to do it with your community, not to your community. And so if you build that culture that says, hey, you know, I would love to have every tool under the sun.

42:05I can't. I'm sorry. I know you're a huge fan of Go, but we're a Java shop. Like, I just can't have five random services written in this thing. I get it. It's a cool language. There's nothing I can do about it. And if you have a, you know, an open set of conversations about those kinds of things, and you have a process where people submit stuff and you, you really build that community and go back to like the, you know, dissent, but agree, like kind of a thing where it's like, yep, I get it. don't agree with you, but I'm going to accept it and move on. That is the, the cultural impact that you have to have around all of this stuff or everything just falls flat.

42:48And you end up with chaos of tools and things. And like, you know, there's no productivity and just everything is just a mess. In the end, engineering takes good leadership and there's no tool in the world. There's no AI that can come in. There's nothing that can replace that kind of a thing. Cause it's just not easy. And that's the, like, that's the stuff that you have to get there. And whether, you know, AI tools, platform tools, all of these things are going to help enable people be better, but you got to get the crap out of the way, the waste and friction. And that's done through leadership and through continuous improvement engine and rethinking about everything.

43:28So you're talking to a bunch of companies that, you know, I mean, every company we talk to is asking like a pretty consistent set of questions about AI and how it's affecting, you know, how How to adopt it, how to manage the impact, how to make sure it's responsible and all of that. So just from what you've seen in recent months working with various companies, what is the difference between a company that is doing a great job at incorporating AI into their workflows versus one that hasn't yet leveraged it or has tried to leverage it and failed in some way? Like, what do you think is the main difference?

44:00It is a difference between system thinking and tool thinking. If I've heard this once, I've heard it a million times. we've implemented Copilot or any other tool we've implemented Copilot, you know, last year and we've seen nothing. We've seen almost no impact at all. And can you come in and help us prove the impact? And I'm like, hold on a second. There's a couple of different problems here. One, like I can't, I can't prove something just because you want it to be proven. And you, you just, I know you've spent probably millions of dollars on this, but it doesn't mean that it's right. And, you know, this goes back to the kind of the fallacy that I talked about before of needing faster typers where, okay, if you're going to just bring in a code gen tool, that is predicated on the fact that I need a faster typer to create more code.

44:47And that's just not the case for people that are really doing really good things with AI right now. It's by rethinking value streams and systems to enable people to not only work better, but to get to better, higher quality output. Because if you look at the data, like especially some of the kind of initial data around things like Copilot, and this is not me pointing fingers at Copilot, it's just an easy, easy word to use. Like, yeah, that, you know, people leveraging Copilot and those types of tools, you're getting a lot higher level of bugs. You're getting higher code complexity. you're getting and you know i think one of the reasons for that is the fact that you're just saying hey give me this block of code and move on and you're not you're you're thinking about it as a one-way street in a lot of ways and this is where like the whole vibe coding thing has come from but like thinking about your ai is essentially like a coding companion like at thoughtworks we've always pushed pair programming and you can think a lot about an ai system as being a pair and treating the AI assistant that way.

45:52Hey, ask me questions about this particular set of code and not just, Hey, give me a block of code that does X, Y, or Z. And as you start to think about it that way, especially in like now this kind of agentic world that says like, great, well, this is an agent that I can talk to that can help me with infrastructure. This is one I can talk to about, about better pipelines or about whatever, or design, or, you know, and I can pull in all the context that I can think of from across the organization to say, hey, these are all of my design standards. These are all the ADRs around my design. Here is our kind of core infrastructure and all of these different bits around auth and auth Z.

46:31Now, all of a sudden you can start to have a much more targeted and interesting conversation to say, great, how do I solve this problem? Not how do you give me more blocks of code? Right. And it goes back to like the value of a block of like a line of code is essentially zero now because like I used to hire you because you knew Java. Now I need to hire you because you can solve a problem. And by redesigning these AI systems that can pair you across that for these different problems, that's where people are really starting to have success. Yeah, I think personally, you know, I've had the most success when I can break any challenge that I have down into a very fundamental component.

47:12Like, you know, I think really what it comes down to is having a good data set to feed into an AI model that is then makes decisions within a very specific criteria. Because you really think about LLMs, they're trained on lots of data, including bad data. So just because they know a lot doesn't mean they're always going to make the right decision. but because they were trained on bad data they're also very good at what you described with the pair programming where when you ask them to challenge your ideas they're much more capable of spotting where you're making bad decisions or or have bad ideas yeah and i think that approach a lot we've seen a lot of development teams have had success when they treat it more like a sparring partner rather than like something that just delivers volumes of code to them.

47:58Well, and it goes back to like, how are you improving now? Like your knowledge and also creating better output. What is the business value and the business impact that you're trying to get to? Great. You need high quality code that is going to solve a certain set of problems, not getting code out there fast. That'll solve some of those things. That's why I've had this personal kind of bad reaction to this focus on productivity where it's like, yes, we all want to go faster and do more, but labeling it developer productivity just seems like a really bad marketing campaign. Like what you want is better outcomes and, but you need good high quality code to be able to make that happen.

48:42And, you know, the, you know, kind of the explosion of these AI tools really can make people, you know, way faster, but you're only as good as a system in which you work. And so if you're going to, what's the Einstein quote? Like if you're going to judge a fish by its ability to climb a tree, it's always going to think it's stupid. And so like that kind of overlays into this, like if you're going to put somebody into this machine that just you're constantly running on this treadmill, that's a problem. And so how do you change that dynamic? That's that type of system type thinking that you have to bring in and remove that waste, remove that friction, and then enable people to actually get the job done.

49:23Right. It's like moving in like a different modality of being a knowledge worker. You're just working with the information that's going in and going out in different ways. What I find whenever I'm using these new agentic tools, whether it's to code or to design something, there's so many ways that you can use it, but ultimately I partner with it in order to create the artifacts that I need to have better outcomes. Instead of working with the LLM in a declarative or imperative way, like do this, make this, create this, interact with it in an interrogative way. And then as you and the LLM kind of crystallize that knowledge and get really firm and really crisp on what you need and what you're building, then actually what you need to create is a really good document to put that in for a future conversation to use.

50:11The business context and the impact that you're making, you're ultimately producing different artifacts of knowledge work. And that's like a whole different modality shift. And people can only work in that kind of environment when they have the right tools and ability to do so. and the like there's a bunch of different kind of paradigm shifts that are that are kind of coming along with that because like you you know we've we've long complained about documentation and the problems that come from that and you know there are really good you know kind of llms that can go and analyze your code and analyze these other things to come up with better information but you know as you're moving through like the sdlc life cycle now and as a developer that is you know creating code why are you not saving chat threads like hey this is the thing that actually used it to this was my logic that i was using to walk through it why you know now with as cheap as storage is and cheap as everything else is why would you not store some of that stuff instead of saying like hey like summarize this code for me and then dumbing that into confluence like that's not as it's useful for some but in this new context like who's going to go read that what you're going to want to do is just you know type in a question in an element it's going to go find it well in this new model you can start to save a lot of other sets of information that are going to help when it comes to solving those other problems and it's like hey i need to go change code well we've all been here it's like looking at a new set of code and you're like man who wrote this and then you go look at the commit message it was you and you're like no this doesn't make any sense at all.

51:51Like, what was I thinking back then? And I remember early in my career, I could remember every line of code I wrote, like everything that I changed, it was just, and then you get to a certain point, you're like, I can't remember any of it. And so you can, how do you start to think about saving out of this information to provide better kind of telemetry and observability to what happened for future you? To tie this back to something that we talked about sort of at the top of this episode is You mentioned that like 10 % of developers that are naturally going to want to go out and experiment with new technologies, be the ones that are on the cutting edge and bring back learnings.

52:28To me, when I hear that, I also get a little skeeved out because I start to think about shadow IT. And as somebody who used to run shadow IT, I can't condone the practice, but I understand why that sort of thing happens. so you know to me that kind of use one of the risks of like unstructured ai adoption what else are you seeing as like a risk to overall engineering effectiveness developer productivity developer experience however we want to use whatever phrase we want to use to describe this like if an organization doesn't have structure to the way they're rolling it out what are the risks that they're they're bringing into the company yeah that's a really great question and I actually started my career in shadow IT as well so like I fully understand and I also don't condone but you know one of the like I made a joke the other day about you know kind of LLMs are giving like shadow IT weapons of mass destruction because you can I mean I've done some stuff with like Microsoft Access and like like some like weird scripts that should have never been done but you've now given i imported as insecure dependency now you know it's right you've now given people essentially you know tools that can have really serious impact to an organization when it comes to security and everything else like if if everything is run in the cloud and you're now allowing shadow it essentially to run these things like you you have a whole nother layer of problems that you didn't have before and there needs to be a lot more governance from a platform perspective from a just quality and security perspective and like how do you you know i really think that is the it's stuff we've talked about for a long time but i think this is where we're going to be forced into this particular like kind of mindset of, I have to have essentially hard gates that stop something from moving into production because of the problems that can come from this.

54:34Have a data breach from some random thing that got deployed into some random cluster in the cloud that cost you who knows how many millions of dollars. That's a problem you're only going to find once. And how do you stop that? You're going to have to have those layers into there or you're going to really, really struggle. I think the way you solve this, so like that was my doom and gloom version. But I think the way you actually solve this is by you have to kind of get rid of these groups. And like I understood why you had them before because you, you know, they were generally around analytics and reporting and some like really weird like little workflow tools.

55:17But if you're, if you can truly free up your really expensive engineer's time with, you know, this level of kind of AI and automation and everything else, give folks like that the ability to create proofs of concept that can truly show value and be able to now say, great, look at this thing. it's really you know it has these things it has this business value and then be able to pass that into your you know traditional it groups to get built i think there is a way of rethinking about how really technology works inside of an organization and you know everything down from from the way you prioritize projects and products and applications and do portfolio management, but even down to like, what does a tool like JIRA look like in the future?

56:19And do you need to follow those same kind of constructs that you've had over time? And because now, if it is truly that much easier and better to operate these things, which you should if you're building the right kind of systems, then great. Great. How do you enable the folks inside of your organization that know where the problems are? How do you enable them to fix it? And you don't want them to have to fix it on their own. So great. Give them an avenue in. Just like with the platforms like we talked about earlier with the, you know, dev tools. Great. It's the same thing. Right. It's like, hey, you can build a really cool POC and guess what?

56:53We can now take and translate that into something interesting. Before we wrap up, Chris, where can people go to learn more about your insight and connect with you? Yeah, you can find me on LinkedIn, ThoughtWorks.com, Carrier Pigeon, email, whatever you can find. I'd love to chat with you. I love to hear people's stories about what's working and what's not working inside of their organization. It's always something interesting and there's always really hard challenges to find. Things can get better. I always go back to the Chinese adage of when's the best time to plant a tree. The right answer is 25 years ago, the second best one's today.

57:33And so when I think about measurements, metrics, removing waste and friction, just be a little bit better tomorrow than you are today. And in two or three years, you're going to look back and go, wow, we've really made some progress. And we didn't do it through this big, messy kind of transformation. We just naturally, you know, made things a little bit better. And I think that's really the way that, you know, success is made. Ben and I completely agree and it's all about having that communication and in being able to understand like I can make an action right now so I should do it it's about doing the little things today that are going to make that huge impact for tomorrow and you know thanks so much for sharing your insights with us we also uh you know Ben and I and the Dev Interrupted team we we do also love to hear from folks about what they're doing inside of their own engineering teams if anything we've covered today is really kind of close to heart to you or fascinating or maybe you even have countering opinions, we would love to hear them.

58:24Please, you know, reach out to us. You can reach us many different ways, like on LinkedIn, maybe on Chris's, you know, maybe you can actually reach Chris by like Smokestack. I don't know. But if you actually managed to do that, let me know. And to you, our loyal listener, you know, you've made it this far. We've had a really nice conversation about how teams really work. So if you made it all the way to this point, you clearly loved what we chatted about. Please be sure to like the episode and be sure to tune into Substack, where every Tuesday we drop this episode along with engineering news. So if you're not reading that, you're only getting a tiny scoop of the story.

58:57So we'll see you next time and take care.