.jpg)
The Agile Within
Providing agile insights into human values and behaviors through genuine connections.
The Agile Within
Reeling from Rewrites? with Richard Lawrence
Software rewrites promise exciting technological advancements but frequently become risky, budget-draining quagmires. Why do these projects fail so consistently, and what can we do differently?
Richard Lawrence, founder of Humanizing Work, joins us to unpack the hidden complexities and psychological pitfalls lurking beneath seemingly straightforward rewrites.
We explore why the common directive to "just do what the old system does" is a dangerous trap, overlooking crucial hidden requirements, workarounds, and integrations that have developed over years. Richard introduces the "strangler approach"—a method that uses existing systems as scaffolding while gradually building new capabilities, allowing teams to deliver immediate value rather than delaying benefits until a complete replacement.
Next we examine user psychology, revealing why technical arguments for rewrites ("outdated technology," "unsupported platforms") fall flat with actual users. "That's your problem, not mine," reflects the realistic user perspective Richard articulates. Instead, we explore human-centered strategies that recognize users care about job performance, not technical implementation details.
Perhaps most valuably, Richard shares his "complexity-aware planning" framework, combining strategic exploration, active experimentation, and analytical planning to manage rewrite risks. We also tackle the difficult question of what to do when legacy customers no longer fit your product direction, offering alternatives to the blunt instrument of "firing customers" that build goodwill while still allowing strategic evolution.
Ready to transform how you approach your next system rewrite? This episode provides practical wisdom that could save your team months of frustration and your company millions in wasted effort.
Book a FREE 30 minute call with Richard:
https://www.humanizingwork.com/contact/
Connect with Richard on LinkedIn:
linkedin.com/in/richardslawrence
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Welcome to the Agile Within.
Speaker 1:I am your host, Mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Attention, Scrum Masters and Agile enthusiasts, Are you ready to level up your skills and connect with the best in the industry? Well, the Online Scrum Master Summit is your chance to hear from world-class Agile experts, gain real-world insights and explore the latest trends shaping the future of Agile. Best of all, it's 100% free and completely online. Happening from June 17th through the 19th, this event brings together thousands of like-minded professionals for engaging talks, interactive sessions and hands-on workshops. Don't miss this opportunity to sharpen your skills and expand your network. Sign up now at onlinescrummastersummitcom. And now on to the show. I hope everybody is having an absolutely fantastic day out there today.
Speaker 1:Welcome back to the Agile Within. I am your host, Mark Metz. I have a guest today and his name is Richard Lawrence. Richard, welcome to the show. Great to be here, Mark. So Richard lives in Hotchkiss, Colorado, and I want to know, Richard, if I were coming to Hotchkiss, Colorado, for a day, and I'd never been there before, what's one thing that you would say that I couldn't miss doing?
Speaker 2:We would love to have you in Hotchkiss, colorado. It's a part of Colorado almost nobody's heard of and if you were coming out here for a perfect day here you would do three things Actually. We're in Western Colorado, in the North Fork Valley, and if I were coming out here for a perfect day, I'd go in the morning to Black Canyon of the Gunnison National Park, which is about a half hour from here and is spectacular mini Grand Canyon sort of situation. Then spend the rest of the day visiting our wineries and tasting wine and eating delicious local food, and then in the afternoon get out on the Gunnison River for some gold medal fly fishing. Oh wow, you have to come in the summer, because this is nobody comes here between November and April. May to October is tourist season here and it's gorgeous.
Speaker 1:I assume that's very similar to Denver. Most people come and travel to Denver, unless you're going to go, I guess, a little bit further west over to Vail places like that to go skiing.
Speaker 2:Yep, and we're over in between Aspen and Telluride. If people are coming here in the winter, they're going kind of away from here towards one of the ski areas, but in the summer this is the place to go.
Speaker 1:Well, Richard is a product and leadership coach. He's also the founder of Humanizing Work. I am a huge fan of Humanizing Work and very much look up to Richard, and he's been very valuable to me over my journeys. So, Richard, you and I were talking. We had an interesting topic and that was a question Reeling from rewrites. What are we?
Speaker 2:talking about when we use the term rewrites yeah, when you mentioned that you were wrestling with a rewrite project in your recent career, and rewrites for me signals there's an existing system that people are using. Rewrites for me signals there's an existing system that people are using and somebody has decided that it needs to start over from scratch, probably on some new technology. It's going to be better this time. Maybe the old technology is not supported anymore. Maybe somebody wants to move from an in-house hosted solution to a cloud solution. There's any number of reasons. Sometimes it's just resume driven. Somebody wants a new technology on their resume and they're tired of working with the old system so they want to make a new one. But there's all sorts of classic problems with rewrites and, I think, some sneaky reasons why they end up failing over and over again.
Speaker 1:It's a very exciting venture to move into. There's lots of newness to be had talking about new technologies that you can take advantage of, like you say, could be a resume builder. But generally engineers software engineers they like problems and they like to solve things. And the software that we use to write software, the tools we have. You know, that's almost like a mechanic getting some sort of a new tool to work with or getting to work with the latest and greatest engine. It's like boy. I just can't wait to get in there and figure out how it's built and be able to customize it. But pretty soon that luster starts wearing off in the realization that this is a cool thing but there is a business to be run. People are waiting for us to build this, to use this application, and sometimes there's a timetable that's included in this. Like you mentioned, maybe the technology is so old that it's going to become unsupported very soon. If you have an issue with the software that isn't supported, well, you may be out of luck to go back to the vendor who developed those tools to try to help you with that. So I want to just run this situation by you, because I've gone through this several times in my career.
Speaker 1:But in looking back, there were times where we did want to do this rewrite because we did want to use the latest technology. One of the things that drove this particular instance was just what we said. The software was written on very old technology. It was client server based. It had to be installed at the client side and be served from there. It wasn't web based, but it was very feature rich, extremely feature rich, customized so much that the customers had exactly what they wanted in the application, right? Well, we had to do something about that. So the gravy train came to an end and we needed to develop some new software based on the old software. So it seems easy on the surface, right? You don't even need to build requirements. It's just like build this, just do what the old system does.
Speaker 1:That's right, yep. If you have any questions, just go see what it did reluctant to adopt the new software until it had all the bells and whistles that they had come used to using, because they had procedures built based off of those and in ways that they worked until everything was baked in, they didn't have any incentive to to use the new software. Talk to us about how you combat that yeah, I.
Speaker 2:I assume from the outset that they have good reasons they don't want to switch. The current system is serving them well enough and it it feels like it won't benefit them to switch to the new one. So what some organizations try to do is we're just going to mandate it, we're going to make them switch and we don't have a change management issue, because people have to use the system. But of course they'll find ways to avoid it and use the old system or use Excel or use sticky notes or whatever they can do to work around the thing. So it's still the same kind of problem even a startup has. We need to figure out how to make something that fits our market and meets their needs our market and meets their needs. And I think the just do what the old system does and then you can ship. It is a trap because one, you rarely know everything the old system does because people have integrated with it. They've worked around the bugs in the system that you don't even know are there, but they've made their processes and integrations work with that. Two, there's almost always something else people think of along the way that they wish they had. You know now that we're rebuilding it. Let's solve this problem that's always been bothering us. Let's add this new capability. And three you don't know about the way the new technology is going to intersect with all these old behaviors and that's going to cause some emergent requirements there.
Speaker 2:So instead of starting from the just make it do what it did before, I recommend starting from what's a thing that our users don't like about the current system right now, or what's a thing that's hard for them to do in their work that we wish they could do. So I'm looking for a new capability rather than re-implementing the things that work best already. Let's start with something new that introduces some new value for our customers. And then I recommend taking what Martin Fowler has famously called the strangler approach, which is where you use the existing system as scaffolding for the new system. So you build that new capability.
Speaker 2:Maybe there's some report that you would like to have in the new, rewritten system that's not in the existing system. Could we build that report in a modern, feature-rich kind of way, integrating with the old data? So it's a new thing integrated with the old thing, and then you slowly grow the new thing until it replaces and kind of strangles the existing system in place, instead of having this big switch from the old system to the new system once everything is done. You have a new system providing value right away and then covering more and more things. But the only way you're going to get people to adopt that is if it actually does something new or better than the old system. So we've got to work out from new value instead of just the table stakes stuff first. So I would let the existing system work where it works best, replace those things last.
Speaker 1:I mean honestly, if I'm a user, I'm being very transparent here. If I'm hearing reasons like, oh, the technology's old, it's not going to be supported anymore, I'm just gonna be like that's your problem.
Speaker 2:Yeah, that was exactly what I thought. Not my problem, not my problem. Yet it may become my problem and I can think about that, but I just want to do my job Well. I'm successful when I do my own thing, that I care about, and I tell product people all the time Nobody wants your software, nobody wants your product, no matter how great your product is.
Speaker 2:They want what they want and they may be willing to enlist the help of your product to get what they want. But we got to start from what they actually want. And especially in the case of a business critical internal system, like we're usually talking about with rewrites, of a business-critical internal system, like we're usually talking about with rewrites, the things people want is not the system. They want to be good at their job. They want to accomplish meaningful outcomes. They want other people to perceive them as competent and if we throw a new, partially featured system at them that they don't know very well, they're going to get worse on all of those fronts. We need to think about how to make them feel more awesome and effective in their job, and you're going to do that by giving them new capabilities that they appreciate first, rather than making their life worse first, and the promise that it'll get better someday, or better for you because you can keep supporting it.
Speaker 1:So it's interesting many times, when we do talk about rewrites, they're not approached in a at least in my experience they're not approached in a very agile manner. It's like you're replacing the old system with the new system and you do some months or years of work and at some point you have this cutoff line where we're going to stop using the old system as of this day and then we're going to start using the system as of you know after that. But there are ways that you can leverage, just kind of shave little pieces off to be able to still leverage the old system but then build pieces of the new system together so that they work with the old system. And yes, I know from an engineering perspective, a lot of times, well, the old system is crap. I didn't build it, some dummy built it. We don't want to interface with that because it's wasted time, right. But from the user's perspective it's much less risky to go that route, right.
Speaker 2:It's actually much less risky for the developer to, even if they don't see it, I think this system is crap. I'm going to replace it in less time, less budget, with this new technology that I think is going to be awesome, while dealing with all those hidden and changing requirements in the existing system. That is a perfect recipe for writing the next legacy system. You're going to want to rewrite or somebody else is going to want to rewrite, so we're way better off making something that has value from the beginning, and I guess another thing we should talk about here is uh, I think we we can give the impression that we have to go all the way over to, uh, kind of the most extreme agile approach with something like this, where we're constantly shipping new features and putting them in production, and I think there's certainly advantages to that. You're going to get better quality feedback. You're going to get value faster.
Speaker 2:Like all the standard agile stuff, I came up with extreme programming. It's the wrong way to say that. I came up in the days of extreme programming. That was like my first introduction to this agile stuff. I didn't make up extreme programming, but extreme programming was the part of the agile community that I came up in, and so I totally get the frequent iterations, frequent delivery, all of that. But I understand that in some of the environments that we work with clients in, they have, for example, regulatory reasons that make it really hard to do incremental delivery, or they're shipping hardware and software together, and so when you think about rewriting something, you're not really changing it in place, you're manufacturing a new thing that's going to replace the old thing, and so in those cases we'd often get pushback we can't really deliver incrementally. It might be able to build it incrementally. We can't deliver that way, and so we've shifted how we talk about this with clients who are going to get some value from larger plans, maybe even larger releases, for reasons that make sense in their environment, and now we talk more about complexity aware planning than agile planning, and what I mean by that is that there's really three different kinds of planning that need to happen.
Speaker 2:In any large initiative, whether it's a rewrite or a large new product, there's strategic planning let's figure out if we should even do this thing and what the problem is that we're trying to solve and that can happen with people in a room having some conversations. It can happen with some of the lean startup style experiments, a lot of the upstream things to figure out. If there's even a problem worth solving here, then there's what we call active planning, and this is the part that big traditional organizations often skip over, which is you've got complexity in something like a rewrite or a large new product. You have those things that you don't know. You don't know how are our customers going to behave with this. What are those hidden requirements and integrations in the existing system and the new technology really do all of these things that they're promising us that it can do in this particular problem space? You don't know those things. You don't even know all the questions to ask about it and you can't analyze your way out of that kind of complex problem. So you need to do what we've come to call active planning, which is take a piece of it, find something that will allow you to probe and explore that core complexity, which usually means build something. So take that new thing, take that challenging integration, narrow it down and build a slice of that. Get some people using it, if you can, and start seeing what happens.
Speaker 2:Agile people would just think of that as delivery. That's just us doing our thing In organizations that really value planning. We've had to frame that as that's still a planning activity. It's just an active planning activity. It's like Pixar doing lots of iterations to figure out a story before they go into the expensive animation, or an architect making models of a building before they commit to construction drawings. It's planning, but it's active and experimental kind of planning. So we're building a thing as part of planning and then you can shift into the analytical kind of traditional project management style planning if you need to.
Speaker 2:Now that we've resolved that core complexity, let's think about all the different variations we need to handle here and make that larger plan, do our larger estimates and budgets and figure out if we actually can afford to rewrite this thing. And then you can start executing and you can do that iteratively in an agile way and you can merge together some of that analytical planning and incremental delivery. But I think the real missing piece for a lot of these things is that active planning. So when we're looking at a rewrite, I would say let's figure out the places where this could blow up on us.
Speaker 2:What's most complex about this thing? It's going to be new capabilities. It's going to be those tricky existing business capabilities that integrate with different things that are critical to our business functioning. There's going to be some slice of that we may want to experiment with. There's probably some things around the new technology and its capabilities and I'd run a few experiments around that first and then decide should we do a bigger plan here and estimate with a little more knowledge from those experiments and at that point you could you try to do that earlier. It's not going to go well.
Speaker 1:I'm saying this tongue in cheek so people can't see me out there and see the smirk on my face. But when these complexities come up, have you ever heard a developer say, oh, yes, that is, that is a challenge, but there's this framework that just solves that inherently that problem. So we don't have to worry about that. We just have to implement this new. We've never worked with it before, but from what I've read, yeah, it resolves all of your issues and it might you can buy your way out of complexity Because things are not always inherently complex.
Speaker 2:Sometimes it's the problem plus you that makes it complex. Like if you call a plumber to deal with some mysterious water thing happening in your house, it's probably highly complex to you if you have no plumbing experience and that plumber may walk in and say, oh yeah, I've seen this before, I've got a part out in my truck. Let me put that together and solve that problem for you. So there are some kinds of problems you can buy your way out of. Maybe there is a framework that has already solved a technically complex piece of this. But you know the kind of complexity you can't buy your way out of.
Speaker 2:It's the humankind. How are people going to interact with this system? Then the future preferences and behaviors of humans is a major source of complexity in software systems. So yeah, you can buy yourself out of some of the implementation and technology complexity. Maybe I'd still want to run an experiment on that framework and how it solves a hard part of that problem. Um, but I would not assume that I could buy myself out of the problem of complexity altogether. And rewrites are so tricky because they look complicated and predictable on the surface. Just do the thing that already exists and they end up being this perfect storm of complexity when you get all the new things together.
Speaker 1:So my experience has been. So you did a good job of qualifying that. So if you are going to adopt some new technology, make a prototype, make sure it's going to do what you think, and maybe even go a step further would be my advice, because I've seen one too many times that suggestion come in and developer is all jazzed up about putting it in and then three months later it's like oh, we didn't realize this gets to how you design that prototype or probe, where most of the time, that developer who's excited about that technology is designing an experiment to confirm what they already believe.
Speaker 2:Confirmation bias is at play here. So I'm I'm going to build the thing that seems easy and straightforward and I'm going to pick the case where I'm confident this thing will work. See, it works. That thing. You run into a few months later where you change your mind about how well it works. That's the thing we actually need to test. So if you're designing a probe for this sort of thing, you want to falsify your hypothesis, or at least set out to falsify your hypothesis, not validate it. So I would ask if I think this thing will solve all my problems, how would I discover as quickly as possible that I'm wrong about that? Well, I probably should go after this part of the system where the documentation is weakest or where we understand how this framework will apply as little as we do anywhere. Let's take a small piece of that and run a probe there, and if we can make it work in that difficult context, then it's probably going to work in all the easier cases. But you don't start by doing the prototype on the easy case.
Speaker 1:Cost analysis is another thing that I've been bitten. Before you run this prototype it's very small. You implement this for one use case and guess what? It's great, and then, when you decide to scale up, you didn't realize what the cost is going to be. And when I talk about cost, I'm talking monetary cost of what it's going to be. And, holy cow, we're going to end up spending more on this tool than we're charging for the software. Yep, we're gonna have to kill this. We have to go another route. And so you've just ended up wasting cycles, building a prototype, implementing it, only to find out that it's way outside of your outside of your price range.
Speaker 2:I think team members often have a limited mental model for how cost works in a project. Like, how much time is it going to take me in my role to create this code and that's, that's the cost. But that may only be a small part of the total cost. Like, how difficult is it to test this thing I'm creating and how difficult and expensive is it to run this thing at the scale we're actually going to need to run it? This is a big one.
Speaker 2:When you're going out to a cloud solution versus a hosted solution. Suddenly I'm paying all of these fees that go up as I increase usage on this thing and the developers often not thinking about all of those total cost of ownership sort of costs. They're just thinking about how quick is it going to be for me to build this thing. And that suggests when you're thinking about what's the complexity here as we consider a solution, you need a sufficiently cross-functional team to represent those different perspectives and think about what is the entire cost, what is the entire experience of complexity from here to however long we want this thing to live and provide benefit for people, and the thing that's more expensive now may actually be cheaper in the long run.
Speaker 1:So one of the parts that developers are in. And again, I've said this numerous times on this show I was a former developer, I consider myself an engineer and a developer, so I lumped myself into this class of people or this group of people.
Speaker 1:But another trap to fall into is the way that the data is stored is crap. Yeah, it's very hard to deal with and we're just going to come up with a totally new data structure and it's going to be so much better. It's going to be easier to query. Reports are going to be a flash. It's going to be so much better. It's going to be easier to query Reports are going to be a flash. It's going to be so much faster.
Speaker 1:Oh wait, all these existing customers we got to like get them over to the new system. How are we going to? Oh, my goodness, it's going to take a lot of time and effort, and you know, when you're talking legacy systems, sometimes the data is not very clean. You got what you got, and so I had actually talked to somebody who did a very novel approach, and what he did was he said we're going to refactor the database later. We're actually going to keep the database where it is and we're going to interface with that so we have zero conversion to deal with and that brings customers online on a snap, and then we can work on refactoring later. And yes, that's going to cause some other problems, it's going to cause things to break, but we can do that after the customers are already online. Talk to me about, maybe, what you think about that approach if you've ever used it before, and just your general experience with the conversion effort.
Speaker 2:Yeah, I have used that approach before and I've done it with a facade on the old data structures so that the new system gets to use the new data structures as far as it's concerned and you have a facade over the old ones, which could be in the application layer, could be in the database layer as views or something, depending on your technology, and I'm far enough away from actual development these days. That that's as far as I would go down that path. But thinking about a kind of translation layer so that the new system doesn't directly have to know about the old structure, you've put it at the boundary, only the knowledge about that, so that you can replace it with an adapter to a new structure over time and slowly refactor that. And that would actually be refactoring. And again to bring up Martin Fowler, that definition of refactoring is changing the implementation of the system without changing the behavior. So you're improving the design in place while the system continues to function. So that's a nice way to do that. So the system does what it needs to do. You can test it. You can even have tests that run against both the old and the new system in an automated way to validate that the new one actually works the way the old one did, and as you change the data structure behind it, those tests continue to run and give you confidence about how it's working. So that can be a nice way to do it.
Speaker 2:The other approach that I've used in the past is segmenting your customers and peeling off segments of customers and their data incrementally and ideally starting with the ones that have the least data, so often going after newer ones so you don't have to move as much as fast. And two going with the ones that will benefit the most from the new capabilities that you're building in this rewritten and probably extended system. So they're the people who most want to move. And then, after they prove out the issues, if you start with the early adopters the ones who actually want to use the new system they're going to be a little more forgiving about the ways the new system doesn't work just like the old system, or doesn't work perfectly yet, so they can help you work out some of those issues that snuck into production before you bring over the majority or the laggards, to use the more term for that and they're less forgiving about the ways that the new system doesn't work, so that also solves a change management problem for you.
Speaker 1:So I'm going to bring up something that I can already feel. Just before asking this question, I already had a lump in my throat. My stomach starts getting a little bit of a pit in it, because I'm just a generally caring and empathetic person. I hear your show is a safe place though.
Speaker 1:It is a safe place, richard, and you're a safe one to share with one to share with. So you have these customers that are longstanding customers with you and they've been with you, let's say, from the beginning of the company. But you do need to reimagine your software and one of the things that I notice is this isn't a family, it is a business and in some cases the new system just isn't a good fit for those old partners that you had and it's just going to cause so much effort to be able to please them that doesn't align with the rest of your customer base and again this causes I just I can't say enough about how much I cringe, but the term firing a customer comes up and sometimes they're just not a good fit and that's very uncomfortable to do. But you just have to do what's best for your company and for the customers that you serve as a whole and not get dragged down by a single customer. It's a hard call to make.
Speaker 2:And I think that's true, especially if you have a strategic reason for doing that. I think we're moving into a new market segment. One that I've seen with some of our customers is industries where there's consolidation and, like you may have previously served small businesses and now there's small businesses getting acquired or merging together and becoming more enterprisey midsize or large businesses and you may want to follow that market up in your product and at some point you're putting enough focus into doing that thing. Well, that meeting the quirky needs of the small businesses is expensive for you and you're probably not serving them as well as you used to, so you could keep wrestling with that and not doing things very well for them, but that's probably not going to serve anybody well. So you're at a fork in the road where either you make a strategic decision to actually invest in that other segment and do it really well and differentiate there, or you decide that's not where we're going. I probably should help those customers find a solution that's more suitable for them and I say it that way deliberately, that's not a euphemism for help them find another place to go. Meaning cut them off and leave them hanging would feel like it's done in service of them and wouldn't have the bad feeling in my gut that you're describing, Mark, would be.
Speaker 2:Let me think about a few options that would be better for them now, because there's probably somebody else in the market who took advantage of us moving up market to go after those customers that aren't being served as well.
Speaker 2:Is it possible for me to put a little bit of investment in, maybe an export tool that lets them get their data into a form that could be imported into that competitor's tool? Now the CFO might say you know we're not going to make any money off of that. Well, maybe not, but we are going to probably build loyalty so our former customers won't hate us and talk bad about us. And if consolidation is a trend in that industry, some of those former customers who leave now may be our future customers when they end our strategy to serve that larger market. And we're just getting some future buyers there by treating our past customers well who may become our future customers again. So I think that's a, I guess, human-centric, strategic way to do that sort of thing Not just firing them but helping them find a better solution than we're being for them and thinking about doing that in a way that proves goodwill and a potential future customer relationship.
Speaker 1:I love that and it's not software related. But I'll tell you where my soft spot comes from. This is that I grew up in a very rural, small community. Like most of the grocery store chains that are going around, they get taken up by, get bought the only grocery store that was in the hometown that I grew up in. Well, the company got sold and they were going into a bigger market and the bigger market was like yeah, that's small potatoes, we're not going to go to a small little city.
Speaker 1:So what did the people in the community what options would they have Drive 45 minutes to get groceries. You know that's not a very good option. So they at least did work to keep the grocery store open until one of those smaller chains was able to have a deal to come in and replace them, and that's just a very human way. I mean, I just like to think that's the right way to treat people and I just think things come around and if you treat people like dirt or like you're just using them for I don't know, it comes around to bite you some way or some form. I'm not saying karma is necessarily real, but I just like doing the right thing and so in that particular instance.
Speaker 2:That's what really stands out to me is just doing the right thing for people, yeah, and I think if you're creative, doing the right thing and doing the thing that's good for your business are rarely actually in conflict, because business is fundamentally human relationships. So you can't really give up on good relationships for very long before that is going to prevent you from having a good business.
Speaker 2:So a human centric approach to business. If, again, if you're creative and you find things that create flywheels for impact like you're having more and more positive impact on people and flywheels for your business model we're having more and more business, whatever our business model is and yet you do the work to think about both those things Well, they're more often than not actually going to align. Doing the right thing for people causes people to want to exchange money for whatever product or service you provide, and if it feels like those things are in conflict, something is broken in your business model and it's not going to last anyway.
Speaker 1:So, as we're coming up on a close to our episode, I want to share one one story with you, richard. So I was, I was working at a company and I was in a management and it was a software management role and it just started. In the company there was a single developer who developed this utility software that the company used as part of their broader package, and he was just releasing it when I first came on board and was asking him questions and he said well, yeah, I had to refactor our old software so it would do these new things and we're going to release it next month, but I'm going to need to rewrite it again. Wait, what? I'm sorry, I must have misunderstood you. You said you're going to have to rewrite it again, and so that is an example of and it was a fun tool.
Speaker 1:And you know, we just had to have a heart to heart conversation and I just had to say you know, if that's the way you like to work, that sounds like something you need to go off on your own to build. If you want to build tools from the ground up, we just don't. We've got more important things to deal with than building. Building these low level tools, uh, that you want to build so it. It just doesn't sound like a good, a good match. That was a hard conversation to have. He ultimately left the company but yeah, so that's, uh, I guess, uh, uh, maybe an atypical example of of rewrites. And have you ever come across somebody who said they were rewriting something? Before they released it, they said they needed to rewrite it again.
Speaker 2:Um, I somebody who said they were rewriting something before they released it. They said they needed to rewrite it again. I don't know that I have. I may have felt that myself. I'm about to ship this and I see all the problems with it.
Speaker 2:I think there's thinking about that story that you told. I see two psychological angles at play there that actually might have made it possible for him to be a good long-term contributor on your team. So not to rethink your management there in hindsight. But the two things that came to mind for me one is there's a cognitive bias angle here where our brains have these shortcuts that keep us alive but sometimes mislead us, and one of those is something called the curse of knowledge, which is once you learn something, it becomes obvious to you and just gets integrated into how you think about the world At scale. We call this common sense, all those things. They're so obvious to me. I assume everybody else knows this and I don't realize. I don't remember that I learned those things at some point. And when you project curse of knowledge backwards in time, you get hindsight bias, and I think for developers this often shows up as well. Knowing what I know now, I'm going to get it right next time. Not realizing next time is going to have its own complexities and something new will emerge and I'll get it wrong. But you forget that you're never going to plan this perfectly. It wasn't. I should have planned better and then I would have got it right. As things emerge and change, and unless you acknowledge that and work in a different way, you're going to keep creating that system that you want to rewrite. So that's one angle.
Speaker 2:The other angle that came to mind for me is the research on motivation. Motivation research, among other things, has shown that the two of the major human motivators are purpose. We want our work to are purpose, we want our work to matter and play. We want our work to be interesting and engaging, to do a sense that I'm good at what I'm doing. I'm growing in what I'm doing.
Speaker 2:One study showed that the play motivator is three times stronger than the purpose motivator, meaning you have to have a really, really compelling and clear purpose to overcome the desire just to fiddle with things and enjoy the technical challenge and feel good at what you do.
Speaker 2:A lot of developers are so disconnected from a compelling purpose that they find the meaning and engagement in their work from the technology, and I suspect that's true here and I suspect that's true here. There there may not have been a strong enough connection to why being done with this thing and moving on to something else had a strong impact on the business and on other people, and so it was just I. My work has meaning because I get to play with cool things and make the most brilliant technical solution. Sometimes you can resolve that by increasing the connection to purpose and you find that people are more willing to do things that maybe aren't as shiny and new and interesting from a technical perspective but have deeper meaning to them. That purpose motivator can overcome the play motivator. So I wonder if one or both of those might have created some more options for that developer to find more ways to contribute that were good for him and good for the company.
Speaker 1:Do you have a DeLorean, a flux capacitor, and I always forget. Is it plutonium or uranium? One of the two, I can't remember.
Speaker 2:I know, as long as you get up to 88 miles per hour, it's going to go well. And yeah, you can go out and redo that hour. It's going to go well. And, yeah, you can go out and redo that Well. Maybe somebody listening is in a similar situation and can think about it differently.
Speaker 1:There you go, Richard. I really appreciate you coming on the show. This has been absolutely fabulous. I love this conversation. If our listeners out there want to get in touch with you, what's the best way for them to do that?
Speaker 2:The best way to connect with me is through our company website, humanizingworkcom. If you want to reach out to me directly, it's richard at humanizingworkcom and I'm on LinkedIn as well, but you can also just go to the contact page on our website and currently it's possible to book some time with me and or my co-founder, peter Green, if you want to talk about how we can help your organization get better at leadership, product management or collaboration and at this point there hasn't been an overwhelming demand for that. I think most people assume that everybody else is taking our time, so until that becomes a problem, it's actually really easy to get some time with us and talk through what's going on in your organization, and we love having those conversations. Humanizingworkcom, slash contact and reach out and we'll be in touch.
Speaker 1:And you said that first call is free. It is, yeah, so how do you go wrong with that? Free everybody.
Speaker 2:There goes my calendar, yeah.
Speaker 1:All right, richard, I really appreciate you taking your time to come on the show. It's been absolutely fantastic. Love your work, love your content. Let's do this again sometime. I'd love to. It was great talking with you.
Speaker 2:Mark, Thanks for having me on.
Speaker 1:All right, everybody that brings it into another episode of the Agile Within. We'll see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.
