April 16, 2025 • 41 mins
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
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Welcome to the Agile Within.
I am your host, Mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Attention, Scrum Masters andAgile enthusiasts, Are you ready
to level up your skills andconnect with the best in the
industry?
Well, the Online Scrum MasterSummit is your chance to hear
(00:51):
from world-class Agile experts,gain real-world insights and
explore the latest trendsshaping the future of Agile.
Best of all, it's 100% free andcompletely online.
Happening from June 17ththrough the 19th, this event
brings together thousands oflike-minded professionals for
(01:13):
engaging talks, interactivesessions and hands-on workshops.
Don't miss this opportunity tosharpen your skills and expand
your network.
Sign up now atonlinescrummastersummitcom.
And now on to the show.
I hope everybody is having anabsolutely fantastic day out
(01:34):
there today.
Welcome back to the Agile Within.
I am your host, Mark Metz.
I have a guest today and hisname 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 toHotchkiss, Colorado, for a day,
and I'd never been there before,what's one thing that you would
(01:55):
say that I couldn't miss doing?
Speaker 2 (01:57):
We would love to have you in Hotchkiss, colorado.
It's a part of Colorado almostnobody's heard of and if you
were coming out here for aperfect day here you would do
three things Actually.
We're in Western Colorado, inthe North Fork Valley, and if I
were coming out here for aperfect day, I'd go in the
morning to Black Canyon of theGunnison National Park, which is
(02:17):
about a half hour from here andis spectacular mini Grand
Canyon sort of situation.
Then spend the rest of the dayvisiting our wineries and
tasting wine and eatingdelicious local food, and then
in the afternoon get out on theGunnison River for some gold
medal fly fishing.
Oh wow, you have to come in thesummer, because this is nobody
(02:37):
comes here between November andApril.
May to October is touristseason here and it's gorgeous.
Speaker 1 (02:45):
I assume that's very similar to Denver.
Most people come and travel toDenver, unless you're going to
go, I guess, a little bitfurther west over to Vail places
like that to go skiing.
Speaker 2 (03:01):
Yep, and we're over in between Aspen and Telluride.
If people are coming here inthe winter, they're going kind
of away from here towards one ofthe ski areas, but in the
summer this is the place to go.
Speaker 1 (03:07):
Well, Richard is a product and leadership coach.
He's also the founder ofHumanizing Work.
I am a huge fan of HumanizingWork and very much look up to
Richard, and he's been veryvaluable to me over my journeys.
So, Richard, you and I weretalking.
We had an interesting topic andthat was a question Reeling
(03:32):
from rewrites.
What are we?
Speaker 2 (03:33):
talking about when we use the term rewrites yeah,
when you mentioned that you werewrestling with a rewrite
project in your recent career,and rewrites for me signals
there's an existing system thatpeople are using.
Rewrites for me signals there'san existing system that people
are using and somebody hasdecided that it needs to start
over from scratch, probably onsome new technology.
It's going to be better thistime.
Maybe the old technology is notsupported anymore.
(03:55):
Maybe somebody wants to movefrom an in-house hosted solution
to a cloud solution.
There's any number of reasons.
Sometimes it's just resumedriven.
Somebody wants a new technologyon their resume and they're
tired of working with the oldsystem so they want to make a
new one.
But there's all sorts ofclassic problems with rewrites
and, I think, some sneakyreasons why they end up failing
(04:18):
over and over again.
Speaker 1 (04:20):
It's a very exciting venture to move into.
There's lots of newness to behad talking about new
technologies that you can takeadvantage of, like you say,
could be a resume builder.
But generally engineerssoftware engineers they like
problems and they like to solvethings.
And the software that we use towrite software, the tools we
(04:42):
have.
You know, that's almost like amechanic getting some sort of a
new tool to work with or gettingto work with the latest and
greatest engine.
It's like boy.
I just can't wait to get inthere and figure out how it's
built and be able to customizeit.
But pretty soon that lusterstarts wearing off in the
realization that this is a coolthing but there is a business to
(05:03):
be run.
People are waiting for us tobuild this, to use this
application, and sometimesthere's a timetable that's
included in this.
Like you mentioned, maybe thetechnology is so old that it's
going to become unsupported verysoon.
If you have an issue with thesoftware that isn't supported,
well, you may be out of luck togo back to the vendor who
(05:25):
developed those tools to try tohelp you with that.
So I want to just run thissituation by you, because I've
gone through this several timesin my career.
But in looking back, there weretimes where we did want to do
this rewrite because we did wantto use the latest technology.
One of the things that drovethis particular instance was
(05:49):
just what we said.
The software was written onvery old technology.
It was client server based.
It had to be installed at theclient side and be served from
there.
It wasn't web based, but it wasvery feature rich, extremely
feature rich, customized so muchthat the customers had exactly
(06:11):
what they wanted in theapplication, right?
Well, we had to do somethingabout that.
So the gravy train came to anend and we needed to develop
some new software based on theold software.
So it seems easy on the surface, right?
You don't even need to buildrequirements.
It's just like build this, justdo what the old system does.
(06:31):
That's right, yep.
If you have any questions, justgo see what it did reluctant to
adopt the new software until ithad all the bells and whistles
that they had come used to using, because they had procedures
built based off of those and inways that they worked until
(06:53):
everything was baked in, theydidn't have any incentive to to
use the new software.
Talk to us about how you combatthat yeah, I.
Speaker 2 (07:02):
I assume from the outset that they have good
reasons they don't want toswitch.
The current system is servingthem well enough and it it feels
like it won't benefit them toswitch to the new one.
So what some organizations tryto do is we're just going to
mandate it, we're going to makethem switch and we don't have a
change management issue, becausepeople have to use the system.
(07:24):
But of course they'll find waysto avoid it and use the old
system or use Excel or usesticky notes or whatever they
can do to work around the thing.
So it's still the same kind ofproblem even a startup has.
We need to figure out how tomake something that fits our
market and meets their needs ourmarket and meets their needs.
(07:47):
And I think the just do whatthe old system does and then you
can ship.
It is a trap because one, yourarely know everything the old
system does because people haveintegrated with it.
They've worked around the bugsin the system that you don't
even know are there, but they'vemade their processes and
integrations work with that.
Two, there's almost alwayssomething else people think of
along the way that they wishthey had.
(08:07):
You know now that we'rerebuilding it.
Let's solve this problem that'salways been bothering us.
Let's add this new capability.
And three you don't know aboutthe way the new technology is
going to intersect with allthese old behaviors and that's
going to cause some emergentrequirements there.
So instead of starting from thejust make it do what it did
before, I recommend startingfrom what's a thing that our
(08:32):
users don't like about thecurrent system right now, or
what's a thing that's hard forthem to do in their work that we
wish they could do.
So I'm looking for a newcapability rather than
re-implementing the things thatwork best already.
Let's start with something newthat introduces some new value
for our customers.
And then I recommend takingwhat Martin Fowler has famously
(08:56):
called the strangler approach,which is where you use the
existing system as scaffoldingfor the new system.
So you build that newcapability.
Maybe there's some report thatyou would like to have in the
new, rewritten system that's notin the existing system.
Could we build that report in amodern, feature-rich kind of
(09:17):
way, integrating with the olddata?
So it's a new thing integratedwith the old thing, and then you
slowly grow the new thing untilit replaces and kind of
strangles the existing system inplace, instead of having this
big switch from the old systemto the new system once
everything is done.
You have a new system providingvalue right away and then
(09:40):
covering more and more things.
But the only way you're goingto get people to adopt that is
if it actually does somethingnew or better than the old
system.
So we've got to work out fromnew value instead of just the
table stakes stuff first.
So I would let the existingsystem work where it works best,
replace those things last.
Speaker 1 (09:57):
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 (10:09):
Yeah, that was exactly what I thought.
Not my problem, not my problem.
Yet it may become my problemand I can think about that, but
I just want to do my job Well.
I'm successful when I do my ownthing, that I care about, and I
tell product people all thetime Nobody wants your software,
nobody wants your product, nomatter how great your product is
(10:30):
.
They want what they want andthey may be willing to enlist
the help of your product to getwhat they want.
But we got to start from whatthey actually want.
And especially in the case of abusiness critical internal
system, like we're usuallytalking about with rewrites, of
a business-critical internalsystem, like we're usually
talking about with rewrites, thethings people want is not the
(10:52):
system.
They want to be good at theirjob.
They want to accomplishmeaningful outcomes.
They want other people toperceive them as competent and
if we throw a new, partiallyfeatured 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 tomake them feel more awesome and
effective in their job, andyou're going to do that by
giving them new capabilitiesthat they appreciate first,
(11:13):
rather than making their lifeworse first, and the promise
that it'll get better someday,or better for you because you
can keep supporting it.
Speaker 1 (11:21):
So it's interesting many times, when we do talk
about rewrites, they're notapproached in a at least in my
experience they're notapproached in a very agile
manner.
It's like you're replacing theold system with the new system
and you do some months or yearsof work and at some point you
have this cutoff line wherewe're going to stop using the
old system as of this day andthen we're going to start using
(11:43):
the system as of you know afterthat.
But there are ways that you canleverage, just kind of shave
little pieces off to be able tostill leverage the old system
but then build pieces of the newsystem together so that they
work with the old system.
And yes, I know from anengineering perspective, a lot
(12:04):
of times, well, the old systemis crap.
I didn't build it, some dummybuilt it.
We don't want to interface withthat because it's wasted time,
right.
But from the user's perspectiveit's much less risky to go that
route, right.
Speaker 2 (12:20):
It's actually much less risky for the developer to,
even if they don't see it, Ithink this system is crap.
I'm going to replace it in lesstime, less budget, with this
new technology that I think isgoing to be awesome, while
dealing with all those hiddenand changing requirements in the
existing system.
That is a perfect recipe forwriting the next legacy system.
(12:43):
You're going to want to rewriteor somebody else is going to
want to rewrite, so we're waybetter off making something that
has value from the beginning,and I guess another thing we
should talk about here is uh, Ithink we we can give the
impression that we have to goall the way over to, uh, kind of
(13:04):
the most extreme agile approachwith something like this, where
we're constantly shipping newfeatures and putting them in
production, and I think there'scertainly advantages to that.
You're going to get betterquality feedback.
You're going to get valuefaster.
Like all the standard agilestuff, I came up with extreme
programming.
It's the wrong way to say that.
I came up in the days ofextreme programming.
(13:25):
That was like my firstintroduction to this agile stuff
.
I didn't make up extremeprogramming, but extreme
programming was the part of theagile community that I came up
in, and so I totally get thefrequent iterations, frequent
delivery, all of that.
But I understand that in someof the environments that we work
(13:45):
with clients in, they have, forexample, regulatory reasons
that make it really hard to doincremental delivery, or they're
shipping hardware and softwaretogether, and so when you think
about rewriting something,you're not really changing it in
place, you're manufacturing anew thing that's going to
replace the old thing, and so inthose cases we'd often get
(14:06):
pushback we can't really deliverincrementally.
It might be able to build itincrementally.
We can't deliver that way, andso we've shifted how we talk
about this with clients who aregoing to get some value from
larger plans, maybe even largerreleases, for reasons that make
sense in their environment, andnow we talk more about
(14:29):
complexity aware planning thanagile planning, and what I mean
by that is that there's reallythree different kinds of
planning that need to happen.
In any large initiative, whetherit's a rewrite or a large new
product, there's strategicplanning let's figure out if we
(14:50):
should even do this thing andwhat the problem is that we're
trying to solve and that canhappen with people in a room
having some conversations.
It can happen with some of thelean startup style experiments,
a lot of the upstream things tofigure out.
If there's even a problem worthsolving here, then there's what
we call active planning, andthis is the part that big
(15:13):
traditional organizations oftenskip over, which is you've got
complexity in something like arewrite or a large new product.
You have those things that youdon't know.
You don't know how are ourcustomers going to behave with
this.
What are those hiddenrequirements and integrations in
the existing system and the newtechnology really do all of
(15:34):
these things that they'repromising us that it can do in
this particular problem space?
You don't know those things.
You don't even know all thequestions to ask about it and
you can't analyze your way outof that kind of complex problem.
So you need to do what we'vecome to call active planning,
which is take a piece of it,find something that will allow
(15:55):
you to probe and explore thatcore complexity, which usually
means build something.
So take that new thing, takethat challenging integration,
narrow it down and build a sliceof that.
Get some people using it, ifyou can, and start seeing what
happens.
Agile people would just think ofthat as delivery.
That's just us doing our thingIn organizations that really
(16:15):
value planning.
We've had to frame that asthat's still a planning activity
.
It's just an active planningactivity.
It's like Pixar doing lots ofiterations to figure out a story
before they go into theexpensive animation, or an
architect making models of abuilding before they commit to
construction drawings.
It's planning, but it's activeand experimental kind of
(16:38):
planning.
So we're building a thing aspart of planning and then you
can shift into the analyticalkind of traditional project
management style planning if youneed to.
Now that we've resolved thatcore complexity, let's think
about all the differentvariations we need to handle
here and make that larger plan,do our larger estimates and
budgets and figure out if weactually can afford to rewrite
(16:59):
this thing.
And then you can startexecuting and you can do that
iteratively in an agile way andyou can merge together some of
that analytical planning andincremental delivery.
But I think the real missingpiece for a lot of these things
is that active planning.
So when we're looking at arewrite, I would say let's
figure out the places where thiscould blow up on us.
(17:20):
What's most complex about thisthing?
It's going to be newcapabilities.
It's going to be those trickyexisting business capabilities
that integrate with differentthings that are critical to our
business functioning.
There's going to be some sliceof that we may want to
experiment with.
There's probably some thingsaround the new technology and
its capabilities and I'd run afew experiments around that
first and then decide should wedo a bigger plan here and
(17:44):
estimate with a little moreknowledge from those experiments
and at that point you could youtry to do that earlier.
It's not going to go well.
Speaker 1 (17:53):
I'm saying this tongue in cheek so people can't
see me out there and see thesmirk on my face.
But when these complexitiescome up, have you ever heard a
developer say, oh, yes, that is,that is a challenge, but
there's this framework that justsolves that inherently that
problem.
So we don't have to worry aboutthat.
We just have to implement thisnew.
(18:13):
We've never worked with itbefore, but from what I've read,
yeah, it resolves all of yourissues and it might you can buy
your way out of complexityBecause things are not always
inherently complex.
Speaker 2 (18:27):
Sometimes it's the problem plus you that makes it
complex.
Like if you call a plumber todeal with some mysterious water
thing happening in your house,it's probably highly complex to
you if you have no plumbingexperience and that plumber may
walk in and say, oh yeah, I'veseen this before, I've got a
part out in my truck.
Let me put that together andsolve that problem for you.
(18:48):
So there are some kinds ofproblems you can buy your way
out of.
Maybe there is a framework thathas already solved a
technically complex piece ofthis.
But you know the kind ofcomplexity you can't buy your
way out of.
It's the humankind.
How are people going tointeract with this system?
Then the future preferences andbehaviors of humans is a major
(19:11):
source of complexity in softwaresystems.
So yeah, you can buy yourselfout of some of the
implementation and technologycomplexity.
Maybe I'd still want to run anexperiment on that framework and
how it solves a hard part ofthat problem.
Um, but I would not assume thatI could buy myself out of the
problem of complexity altogether.
And rewrites are so trickybecause they look complicated
(19:33):
and predictable on the surface.
Just do the thing that alreadyexists and they end up being
this perfect storm of complexitywhen you get all the new things
together.
Speaker 1 (19:44):
So my experience has been.
So you did a good job ofqualifying that.
So if you are going to adoptsome new technology, make a
prototype, make sure it's goingto do what you think, and maybe
even go a step further would bemy advice, because I've seen one
too many times that suggestioncome in and developer is all
(20:04):
jazzed up about putting it inand then three months later it's
like oh, we didn't realize thisgets to how you design that
prototype or probe, where mostof the time, that developer
who's excited about thattechnology is designing an
experiment to confirm what theyalready believe.
Speaker 2 (20:22):
Confirmation bias is at play here.
So I'm I'm going to build thething that seems easy and
straightforward and I'm going topick the case where I'm
confident this thing will work.
See, it works.
That thing.
You run into a few months laterwhere you change your mind
about how well it works.
That's the thing we actuallyneed to test.
So if you're designing a probefor this sort of thing, you want
(20:42):
to falsify your hypothesis, orat least set out to falsify your
hypothesis, not validate it.
So I would ask if I think thisthing will solve all my problems
, how would I discover asquickly as possible that I'm
wrong about that?
Well, I probably should goafter this part of the system
where the documentation isweakest or where we understand
(21:03):
how this framework will apply aslittle as we do anywhere.
Let's take a small piece ofthat and run a probe there, and
if we can make it work in thatdifficult context, then it's
probably going to work in allthe easier cases.
But you don't start by doingthe prototype on the easy case.
Speaker 1 (21:21):
Cost analysis is another thing that I've been
bitten.
Before you run this prototypeit's very small.
You implement this for one usecase and guess what?
It's great, and then, when youdecide to scale up, you didn't
realize what the cost is goingto be.
And when I talk about cost, I'mtalking monetary cost of what
(21:41):
it's going to be.
And, holy cow, we're going toend up spending more on this
tool than we're charging for thesoftware.
Yep, we're gonna have to killthis.
We have to go another route.
And so you've just ended upwasting cycles, building a
prototype, implementing it, onlyto find out that it's way
outside of your outside of yourprice range.
Speaker 2 (22:00):
I think team members often have a limited mental
model for how cost works in aproject.
Like, how much time is it goingto take me in my role to create
this code and that's, that'sthe cost.
But that may only be a smallpart of the total cost.
Like, how difficult is it totest this thing I'm creating and
how difficult and expensive isit to run this thing at the
(22:23):
scale we're actually going toneed to run it?
This is a big one.
When you're going out to a cloudsolution versus a hosted
solution.
Suddenly I'm paying all ofthese fees that go up as I
increase usage on this thing andthe developers often not
thinking about all of thosetotal cost of ownership sort of
costs.
They're just thinking about howquick is it going to be for me
(22:45):
to build this thing.
And that suggests when you'rethinking about what's the
complexity here as we consider asolution, you need a
sufficiently cross-functionalteam to represent those
different perspectives and thinkabout what is the entire cost,
what is the entire experience ofcomplexity from here to however
(23:06):
long we want this thing to liveand provide benefit for people,
and the thing that's moreexpensive now may actually be
cheaper in the long run.
Speaker 1 (23:13):
So one of the parts that developers are in.
And again, I've said thisnumerous times on this show I
was a former developer, Iconsider myself an engineer and
a developer, so I lumped myselfinto this class of people or
this group of people.
But another trap to fall into isthe way that the data is stored
(23:34):
is crap.
Yeah, it's very hard to dealwith and we're just going to
come up with a totally new datastructure and it's going to be
so much better.
It's going to be easier toquery.
Reports are going to be a flash.
It's going to be so much better.
It's going to be easier toquery Reports are going to be a
flash.
It's going to be so much faster.
Oh wait, all these existingcustomers we got to like get
them over to the new system.
(23:54):
How are we going to?
Oh, my goodness, it's going totake a lot of time and effort,
and you know, when you'retalking legacy systems,
sometimes the data is not veryclean.
You got what you got, and so Ihad actually talked to somebody
who did a very novel approach,and what he did was he said
(24:16):
we're going to refactor thedatabase later.
We're actually going to keepthe database where it is and
we're going to interface withthat so we have zero conversion
to deal with and that bringscustomers online on a snap, and
then we can work on refactoringlater.
And yes, that's going to causesome other problems, it's going
to cause things to break, but wecan do that after the customers
(24:37):
are already online.
Talk to me about, maybe, whatyou think about that approach if
you've ever used it before, andjust your general experience
with the conversion effort.
Speaker 2 (24:47):
Yeah, I have used that approach before and I've
done it with a facade on the olddata structures so that the new
system gets to use the new datastructures as far as it's
concerned and you have a facadeover the old ones, which could
be in the application layer,could be in the database layer
as views or something, dependingon your technology, and I'm far
(25:11):
enough away from actualdevelopment these days.
That that's as far as I wouldgo down that path.
But thinking about a kind oftranslation layer so that the
new system doesn't directly haveto know about the old structure
, you've put it at the boundary,only the knowledge about that,
so that you can replace it withan adapter to a new structure
(25:33):
over time and slowly refactorthat.
And that would actually berefactoring.
And again to bring up MartinFowler, that definition of
refactoring is changing theimplementation of the system
without changing the behavior.
So you're improving the designin place while the system
continues to function.
So that's a nice way to do that.
So the system does what itneeds to do.
(25:55):
You can test it.
You can even have tests thatrun against both the old and the
new system in an automated wayto validate that the new one
actually works the way the oldone did, and as you change the
data structure behind it, thosetests continue to run and give
you confidence about how it'sworking.
So that can be a nice way to doit.
The other approach that I'veused in the past is segmenting
(26:19):
your customers and peeling offsegments of customers and their
data incrementally and ideallystarting with the ones that have
the least data, so often goingafter newer ones so you don't
have to move as much as fast.
And two going with the onesthat will benefit the most from
the new capabilities that you'rebuilding in this rewritten and
(26:43):
probably extended system.
So they're the people who mostwant to move.
And then, after they prove outthe issues, if you start with
the early adopters the ones whoactually want to use the new
system they're going to be alittle more forgiving about the
ways the new system doesn't workjust like the old system, or
doesn't work perfectly yet, sothey can help you work out some
(27:04):
of those issues that snuck intoproduction before you bring over
the majority or the laggards,to use the more term for that
and they're less forgiving aboutthe ways that the new system
doesn't work, so that alsosolves a change management
problem for you.
Speaker 1 (27:25):
So I'm going to bring up something that I can already
feel.
Just before asking thisquestion, I already had a lump
in my throat.
My stomach starts getting alittle bit of a pit in it,
because I'm just a generallycaring and empathetic person.
I hear your show is a safeplace though.
It is a safe place, richard, andyou're a safe one to share with
one to share with.
(27:45):
So you have these customersthat are longstanding customers
with you and they've been withyou, let's say, from the
beginning of the company.
But you do need to reimagineyour software and one of the
things that I notice is thisisn't a family, it is a business
and in some cases the newsystem just isn't a good fit for
(28:07):
those old partners that you hadand it's just going to cause so
much effort to be able toplease them that doesn't align
with the rest of your customerbase and again this causes I
just I can't say enough abouthow much I cringe, but the term
firing a customer comes up andsometimes they're just not a
(28:28):
good fit and that's veryuncomfortable to do.
But you just have to do what'sbest for your company and for
the customers that you serve asa whole and not get dragged down
by a single customer.
It's a hard call to make.
Speaker 2 (28:43):
And I think that's true, especially if you have a
strategic reason for doing that.
I think we're moving into a newmarket segment.
One that I've seen with some ofour customers is industries
where there's consolidation and,like you may have previously
served small businesses and nowthere's small businesses getting
acquired or merging togetherand becoming more enterprisey
(29:06):
midsize or large businesses andyou may want to follow that
market up in your product and atsome point you're putting
enough focus into doing thatthing.
Well, that meeting the quirkyneeds of the small businesses is
expensive for you and you'reprobably not serving them as
well as you used to, so youcould keep wrestling with that
(29:27):
and not doing things very wellfor them, but that's probably
not going to serve anybody well.
So you're at a fork in the roadwhere either you make a
strategic decision to actuallyinvest in that other segment and
do it really well anddifferentiate there, or you
decide that's not where we'regoing.
I probably should help thosecustomers find a solution that's
(29:48):
more suitable for them and Isay it that way deliberately,
that's not a euphemism for helpthem find another place to go.
Meaning cut them off and leavethem hanging would feel like
it's done in service of them andwouldn't have the bad feeling
(30:11):
in my gut that you're describing, Mark, would be.
Let me think about a few optionsthat would be better for them
now, because there's probablysomebody else in the market who
took advantage of us moving upmarket to go after those
customers that aren't beingserved as well.
Is it possible for me to put alittle bit of investment in,
(30:31):
maybe an export tool that letsthem get their data into a form
that could be imported into thatcompetitor's tool?
Now the CFO might say you knowwe're not going to make any
money off of that.
Well, maybe not, but we aregoing to probably build loyalty
so our former customers won'thate us and talk bad about us.
And if consolidation is a trendin that industry, some of those
(30:55):
former customers who leave nowmay be our future customers when
they end our strategy to servethat larger market.
And we're just getting somefuture buyers there by treating
our past customers well who maybecome our future customers
(31:16):
again.
So I think that's a, I guess,human-centric, strategic way to
do that sort of thing Not justfiring them but helping them
find a better solution thanwe're being for them and
thinking about doing that in away that proves goodwill and a
potential future customerrelationship.
Speaker 1 (31:33):
I love that and it's not software related.
But I'll tell you where my softspot comes from.
This is that I grew up in avery rural, small community.
Like most of the grocery storechains that are going around,
they get taken up by, get boughtthe only grocery store that was
in the hometown that I grew upin.
(31:53):
Well, the company got sold andthey were going into a bigger
market and the bigger market waslike yeah, that's small
potatoes, we're not going to goto a small little city.
So what did the people in thecommunity what options would
they have Drive 45 minutes toget groceries.
You know that's not a very goodoption.
So they at least did work tokeep the grocery store open
(32:16):
until one of those smallerchains was able to have a deal
to come in and replace them, andthat's just a very human way.
I mean, I just like to thinkthat's the right way to treat
people and I just think thingscome around and if you treat
people like dirt or like you'rejust using them for I don't know
, it comes around to bite yousome way or some form.
(32:39):
I'm not saying karma isnecessarily real, but I just
like doing the right thing andso in that particular instance.
Speaker 2 (32:49):
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 anddoing the thing that's good for
your business are rarelyactually in conflict, because
business is fundamentally humanrelationships.
So you can't really give up ongood relationships for very long
before that is going to preventyou from having a good business
(33:12):
.
So a human centric approach tobusiness.
If, again, if you're creativeand you find things that create
flywheels for impact like you'rehaving more and more positive
impact on people and flywheelsfor your business model we're
having more and more business,whatever our business model is
and yet you do the work to thinkabout both those things Well,
they're more often than notactually going to align.
(33:34):
Doing the right thing forpeople causes people to want to
exchange money for whateverproduct or service you provide,
and if it feels like thosethings are in conflict,
something is broken in yourbusiness model and it's not
going to last anyway.
Speaker 1 (33:47):
So, as we're coming up on a close to our episode, I
want to share one one story withyou, richard.
So I was, I was working at acompany and I was in a
management and it was a softwaremanagement role and it just
started.
In the company there was asingle developer who developed
this utility software that thecompany used as part of their
broader package, and he was justreleasing it when I first came
(34:11):
on board and was asking himquestions and he said well, yeah
, I had to refactor our oldsoftware so it would do these
new things and we're going torelease it next month, but I'm
going to need to rewrite itagain.
Wait, what?
I'm sorry, I must havemisunderstood you.
You said you're going to haveto rewrite it again, and so that
(34:32):
is an example of and it was afun tool.
And you know, we just had tohave a heart to heart
(34:53):
conversation and I just had tosay you know, if that's the way
you like to work, that soundslike something you need to go
off on your own to build.
If you want to build tools fromthe ground up, we just don't.
We've got more important thingsto deal with than building.
Building these low level tools,uh, that you want to build so
it.
It just doesn't sound like agood, a good match.
(35:13):
That was a hard conversation tohave.
He ultimately left the companybut yeah, so that's, uh, I guess
, uh, uh, maybe an atypicalexample of of rewrites.
And have you ever come acrosssomebody who said they were
rewriting something?
Before they released it, theysaid they needed to rewrite it
again.
Speaker 2 (35:30):
Um, I somebody who said they were rewriting
something before they releasedit.
They said they needed torewrite it again.
I don't know that I have.
I may have felt that myself.
I'm about to ship this and Isee all the problems with it.
I think there's thinking aboutthat story that you told.
I see two psychological anglesat play there that actually
might have made it possible forhim to be a good long-term
contributor on your team.
So not to rethink yourmanagement there in hindsight.
(35:53):
But the two things that came tomind for me one is there's a
cognitive bias angle here whereour brains have these shortcuts
that keep us alive but sometimesmislead us, and one of those is
something called the curse ofknowledge, which is once you
learn something, it becomesobvious to you and just gets
integrated into how you thinkabout the world At scale.
(36:13):
We call this common sense, allthose things.
They're so obvious to me.
I assume everybody else knowsthis and I don't realize.
I don't remember that I learnedthose things at some point.
And when you project curse ofknowledge backwards in time, you
get hindsight bias, and I thinkfor developers this often shows
up as well.
Knowing what I know now, I'mgoing to get it right next time.
Not realizing next time isgoing to have its own
(36:36):
complexities and something newwill emerge and I'll get it
wrong.
But you forget that you'renever going to plan this
perfectly.
It wasn't.
I should have planned betterand 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 torewrite.
So that's one angle.
(36:57):
The other angle that came tomind for me is the research on
motivation.
Motivation research, amongother things, has shown that the
two of the major humanmotivators are purpose.
We want our work to are purpose, we want our work to matter and
play.
We want our work to beinteresting and engaging, to do
a sense that I'm good at whatI'm doing.
I'm growing in what I'm doing.
(37:18):
One study showed that the playmotivator is three times
stronger than the purposemotivator, meaning you have to
have a really, really compellingand clear purpose to overcome
the desire just to fiddle withthings and enjoy the technical
challenge and feel good at whatyou do.
A lot of developers are sodisconnected from a compelling
(37:39):
purpose that they find themeaning and engagement in their
work from the technology, and Isuspect that's true here and I
suspect that's true here.
There there may not have been astrong enough connection to why
being done with this thing andmoving on to something else had
a strong impact on the businessand on other people, and so it
was just I.
My work has meaning because Iget to play with cool things and
(38:02):
make the most brillianttechnical solution.
Sometimes you can resolve thatby increasing the connection to
purpose and you find that peopleare more willing to do things
that maybe aren't as shiny andnew and interesting from a
technical perspective but havedeeper meaning to them.
That purpose motivator canovercome the play motivator.
So I wonder if one or both ofthose might have created some
(38:25):
more options for that developerto find more ways to contribute
that were good for him and goodfor the company.
Speaker 1 (38:34):
Do you have a DeLorean, a flux capacitor, and
I always forget.
Is it plutonium or uranium?
One of the two, I can'tremember.
Speaker 2 (38:42):
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 andredo that hour.
It's going to go well.
And, yeah, you can go out andredo that Well.
Maybe somebody listening is ina similar situation and can
think about it differently.
Speaker 1 (38:55):
There you go, Richard .
I really appreciate you comingon the show.
This has been absolutelyfabulous.
I love this conversation.
If our listeners out there wantto get in touch with you,
what's the best way for them todo that?
Speaker 2 (39:07):
The best way to connect with me is through our
company website,humanizingworkcom.
If you want to reach out to medirectly, it's richard at
humanizingworkcom and I'm onLinkedIn as well, but you can
also just go to the contact pageon our website and currently
it's possible to book some timewith me and or my co-founder,
(39:29):
peter Green, if you want to talkabout how we can help your
organization get better atleadership, product management
or collaboration and at thispoint there hasn't been an
overwhelming demand for that.
I think most people assume thateverybody else is taking our
time, so until that becomes aproblem, it's actually really
(39:50):
easy to get some time with usand talk through what's going on
in your organization, and welove having those conversations.
Humanizingworkcom, slashcontact and reach out and we'll
be in touch.
Speaker 1 (40:00):
And you said that first call is free.
It is, yeah, so how do you gowrong with that?
Free everybody.
Speaker 2 (40:09):
There goes my calendar, yeah.
Speaker 1 (40:13):
All right, richard, I really appreciate you taking
your time to come on the show.
It's been absolutely fantastic.
Love your work, love yourcontent.
Let's do this again sometime.
I'd love to.
It was great talking with you.
Speaker 2 (40:24):
Mark, Thanks for having me on.
Speaker 1 (40:26):
All right, everybody that brings it into another
episode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the AgileWithin and please spread the
(40:58):
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Welcome to the Agile Within.
I am your host, Mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Attention, Scrum Masters andAgile enthusiasts, Are you ready
to level up your skills andconnect with the best in the
industry?
Well, the Online Scrum MasterSummit is your chance to hear
(00:51):
from world-class Agile experts,gain real-world insights and
explore the latest trendsshaping the future of Agile.
Best of all, it's 100% free andcompletely online.
Happening from June 17ththrough the 19th, this event
brings together thousands oflike-minded professionals for
(01:13):
engaging talks, interactivesessions and hands-on workshops.
Don't miss this opportunity tosharpen your skills and expand
your network.
Sign up now atonlinescrummastersummitcom.
And now on to the show.
I hope everybody is having anabsolutely fantastic day out
(01:34):
there today.
Welcome back to the Agile Within.
I am your host, Mark Metz.
I have a guest today and hisname 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 toHotchkiss, Colorado, for a day,
and I'd never been there before,what's one thing that you would
(01:55):
say that I couldn't miss doing?
Speaker 2 (01:57):
We would love to have you in Hotchkiss, colorado.
It's a part of Colorado almostnobody's heard of and if you
were coming out here for aperfect day here you would do
three things Actually.
We're in Western Colorado, inthe North Fork Valley, and if I
were coming out here for aperfect day, I'd go in the
morning to Black Canyon of theGunnison National Park, which is
(02:17):
about a half hour from here andis spectacular mini Grand
Canyon sort of situation.
Then spend the rest of the dayvisiting our wineries and
tasting wine and eatingdelicious local food, and then
in the afternoon get out on theGunnison River for some gold
medal fly fishing.
Oh wow, you have to come in thesummer, because this is nobody
(02:37):
comes here between November andApril.
May to October is touristseason here and it's gorgeous.
Speaker 1 (02:45):
I assume that's very similar to Denver.
Most people come and travel toDenver, unless you're going to
go, I guess, a little bitfurther west over to Vail places
like that to go skiing.
Speaker 2 (03:01):
Yep, and we're over in between Aspen and Telluride.
If people are coming here inthe winter, they're going kind
of away from here towards one ofthe ski areas, but in the
summer this is the place to go.
Speaker 1 (03:07):
Well, Richard is a product and leadership coach.
He's also the founder ofHumanizing Work.
I am a huge fan of HumanizingWork and very much look up to
Richard, and he's been veryvaluable to me over my journeys.
So, Richard, you and I weretalking.
We had an interesting topic andthat was a question Reeling
(03:32):
from rewrites.
What are we?
Speaker 2 (03:33):
talking about when we use the term rewrites yeah,
when you mentioned that you werewrestling with a rewrite
project in your recent career,and rewrites for me signals
there's an existing system thatpeople are using.
Rewrites for me signals there'san existing system that people
are using and somebody hasdecided that it needs to start
over from scratch, probably onsome new technology.
It's going to be better thistime.
Maybe the old technology is notsupported anymore.
(03:55):
Maybe somebody wants to movefrom an in-house hosted solution
to a cloud solution.
There's any number of reasons.
Sometimes it's just resumedriven.
Somebody wants a new technologyon their resume and they're
tired of working with the oldsystem so they want to make a
new one.
But there's all sorts ofclassic problems with rewrites
and, I think, some sneakyreasons why they end up failing
(04:18):
over and over again.
Speaker 1 (04:20):
It's a very exciting venture to move into.
There's lots of newness to behad talking about new
technologies that you can takeadvantage of, like you say,
could be a resume builder.
But generally engineerssoftware engineers they like
problems and they like to solvethings.
And the software that we use towrite software, the tools we
(04:42):
have.
You know, that's almost like amechanic getting some sort of a
new tool to work with or gettingto work with the latest and
greatest engine.
It's like boy.
I just can't wait to get inthere and figure out how it's
built and be able to customizeit.
But pretty soon that lusterstarts wearing off in the
realization that this is a coolthing but there is a business to
(05:03):
be run.
People are waiting for us tobuild this, to use this
application, and sometimesthere's a timetable that's
included in this.
Like you mentioned, maybe thetechnology is so old that it's
going to become unsupported verysoon.
If you have an issue with thesoftware that isn't supported,
well, you may be out of luck togo back to the vendor who
(05:25):
developed those tools to try tohelp you with that.
So I want to just run thissituation by you, because I've
gone through this several timesin my career.
But in looking back, there weretimes where we did want to do
this rewrite because we did wantto use the latest technology.
One of the things that drovethis particular instance was
(05:49):
just what we said.
The software was written onvery old technology.
It was client server based.
It had to be installed at theclient side and be served from
there.
It wasn't web based, but it wasvery feature rich, extremely
feature rich, customized so muchthat the customers had exactly
(06:11):
what they wanted in theapplication, right?
Well, we had to do somethingabout that.
So the gravy train came to anend and we needed to develop
some new software based on theold software.
So it seems easy on the surface, right?
You don't even need to buildrequirements.
It's just like build this, justdo what the old system does.
(06:31):
That's right, yep.
If you have any questions, justgo see what it did reluctant to
adopt the new software until ithad all the bells and whistles
that they had come used to using, because they had procedures
built based off of those and inways that they worked until
(06:53):
everything was baked in, theydidn't have any incentive to to
use the new software.
Talk to us about how you combatthat yeah, I.
Speaker 2 (07:02):
I assume from the outset that they have good
reasons they don't want toswitch.
The current system is servingthem well enough and it it feels
like it won't benefit them toswitch to the new one.
So what some organizations tryto do is we're just going to
mandate it, we're going to makethem switch and we don't have a
change management issue, becausepeople have to use the system.
(07:24):
But of course they'll find waysto avoid it and use the old
system or use Excel or usesticky notes or whatever they
can do to work around the thing.
So it's still the same kind ofproblem even a startup has.
We need to figure out how tomake something that fits our
market and meets their needs ourmarket and meets their needs.
(07:47):
And I think the just do whatthe old system does and then you
can ship.
It is a trap because one, yourarely know everything the old
system does because people haveintegrated with it.
They've worked around the bugsin the system that you don't
even know are there, but they'vemade their processes and
integrations work with that.
Two, there's almost alwayssomething else people think of
along the way that they wishthey had.
(08:07):
You know now that we'rerebuilding it.
Let's solve this problem that'salways been bothering us.
Let's add this new capability.
And three you don't know aboutthe way the new technology is
going to intersect with allthese old behaviors and that's
going to cause some emergentrequirements there.
So instead of starting from thejust make it do what it did
before, I recommend startingfrom what's a thing that our
(08:32):
users don't like about thecurrent system right now, or
what's a thing that's hard forthem to do in their work that we
wish they could do.
So I'm looking for a newcapability rather than
re-implementing the things thatwork best already.
Let's start with something newthat introduces some new value
for our customers.
And then I recommend takingwhat Martin Fowler has famously
(08:56):
called the strangler approach,which is where you use the
existing system as scaffoldingfor the new system.
So you build that newcapability.
Maybe there's some report thatyou would like to have in the
new, rewritten system that's notin the existing system.
Could we build that report in amodern, feature-rich kind of
(09:17):
way, integrating with the olddata?
So it's a new thing integratedwith the old thing, and then you
slowly grow the new thing untilit replaces and kind of
strangles the existing system inplace, instead of having this
big switch from the old systemto the new system once
everything is done.
You have a new system providingvalue right away and then
(09:40):
covering more and more things.
But the only way you're goingto get people to adopt that is
if it actually does somethingnew or better than the old
system.
So we've got to work out fromnew value instead of just the
table stakes stuff first.
So I would let the existingsystem work where it works best,
replace those things last.
Speaker 1 (09:57):
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 (10:09):
Yeah, that was exactly what I thought.
Not my problem, not my problem.
Yet it may become my problemand I can think about that, but
I just want to do my job Well.
I'm successful when I do my ownthing, that I care about, and I
tell product people all thetime Nobody wants your software,
nobody wants your product, nomatter how great your product is
(10:30):
.
They want what they want andthey may be willing to enlist
the help of your product to getwhat they want.
But we got to start from whatthey actually want.
And especially in the case of abusiness critical internal
system, like we're usuallytalking about with rewrites, of
a business-critical internalsystem, like we're usually
talking about with rewrites, thethings people want is not the
(10:52):
system.
They want to be good at theirjob.
They want to accomplishmeaningful outcomes.
They want other people toperceive them as competent and
if we throw a new, partiallyfeatured 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 tomake them feel more awesome and
effective in their job, andyou're going to do that by
giving them new capabilitiesthat they appreciate first,
(11:13):
rather than making their lifeworse first, and the promise
that it'll get better someday,or better for you because you
can keep supporting it.
Speaker 1 (11:21):
So it's interesting many times, when we do talk
about rewrites, they're notapproached in a at least in my
experience they're notapproached in a very agile
manner.
It's like you're replacing theold system with the new system
and you do some months or yearsof work and at some point you
have this cutoff line wherewe're going to stop using the
old system as of this day andthen we're going to start using
(11:43):
the system as of you know afterthat.
But there are ways that you canleverage, just kind of shave
little pieces off to be able tostill leverage the old system
but then build pieces of the newsystem together so that they
work with the old system.
And yes, I know from anengineering perspective, a lot
(12:04):
of times, well, the old systemis crap.
I didn't build it, some dummybuilt it.
We don't want to interface withthat because it's wasted time,
right.
But from the user's perspectiveit's much less risky to go that
route, right.
Speaker 2 (12:20):
It's actually much less risky for the developer to,
even if they don't see it, Ithink this system is crap.
I'm going to replace it in lesstime, less budget, with this
new technology that I think isgoing to be awesome, while
dealing with all those hiddenand changing requirements in the
existing system.
That is a perfect recipe forwriting the next legacy system.
(12:43):
You're going to want to rewriteor somebody else is going to
want to rewrite, so we're waybetter off making something that
has value from the beginning,and I guess another thing we
should talk about here is uh, Ithink we we can give the
impression that we have to goall the way over to, uh, kind of
(13:04):
the most extreme agile approachwith something like this, where
we're constantly shipping newfeatures and putting them in
production, and I think there'scertainly advantages to that.
You're going to get betterquality feedback.
You're going to get valuefaster.
Like all the standard agilestuff, I came up with extreme
programming.
It's the wrong way to say that.
I came up in the days ofextreme programming.
(13:25):
That was like my firstintroduction to this agile stuff
.
I didn't make up extremeprogramming, but extreme
programming was the part of theagile community that I came up
in, and so I totally get thefrequent iterations, frequent
delivery, all of that.
But I understand that in someof the environments that we work
(13:45):
with clients in, they have, forexample, regulatory reasons
that make it really hard to doincremental delivery, or they're
shipping hardware and softwaretogether, and so when you think
about rewriting something,you're not really changing it in
place, you're manufacturing anew thing that's going to
replace the old thing, and so inthose cases we'd often get
(14:06):
pushback we can't really deliverincrementally.
It might be able to build itincrementally.
We can't deliver that way, andso we've shifted how we talk
about this with clients who aregoing to get some value from
larger plans, maybe even largerreleases, for reasons that make
sense in their environment, andnow we talk more about
(14:29):
complexity aware planning thanagile planning, and what I mean
by that is that there's reallythree different kinds of
planning that need to happen.
In any large initiative, whetherit's a rewrite or a large new
product, there's strategicplanning let's figure out if we
(14:50):
should even do this thing andwhat the problem is that we're
trying to solve and that canhappen with people in a room
having some conversations.
It can happen with some of thelean startup style experiments,
a lot of the upstream things tofigure out.
If there's even a problem worthsolving here, then there's what
we call active planning, andthis is the part that big
(15:13):
traditional organizations oftenskip over, which is you've got
complexity in something like arewrite or a large new product.
You have those things that youdon't know.
You don't know how are ourcustomers going to behave with
this.
What are those hiddenrequirements and integrations in
the existing system and the newtechnology really do all of
(15:34):
these things that they'repromising us that it can do in
this particular problem space?
You don't know those things.
You don't even know all thequestions to ask about it and
you can't analyze your way outof that kind of complex problem.
So you need to do what we'vecome to call active planning,
which is take a piece of it,find something that will allow
(15:55):
you to probe and explore thatcore complexity, which usually
means build something.
So take that new thing, takethat challenging integration,
narrow it down and build a sliceof that.
Get some people using it, ifyou can, and start seeing what
happens.
Agile people would just think ofthat as delivery.
That's just us doing our thingIn organizations that really
(16:15):
value planning.
We've had to frame that asthat's still a planning activity
.
It's just an active planningactivity.
It's like Pixar doing lots ofiterations to figure out a story
before they go into theexpensive animation, or an
architect making models of abuilding before they commit to
construction drawings.
It's planning, but it's activeand experimental kind of
(16:38):
planning.
So we're building a thing aspart of planning and then you
can shift into the analyticalkind of traditional project
management style planning if youneed to.
Now that we've resolved thatcore complexity, let's think
about all the differentvariations we need to handle
here and make that larger plan,do our larger estimates and
budgets and figure out if weactually can afford to rewrite
(16:59):
this thing.
And then you can startexecuting and you can do that
iteratively in an agile way andyou can merge together some of
that analytical planning andincremental delivery.
But I think the real missingpiece for a lot of these things
is that active planning.
So when we're looking at arewrite, I would say let's
figure out the places where thiscould blow up on us.
(17:20):
What's most complex about thisthing?
It's going to be newcapabilities.
It's going to be those trickyexisting business capabilities
that integrate with differentthings that are critical to our
business functioning.
There's going to be some sliceof that we may want to
experiment with.
There's probably some thingsaround the new technology and
its capabilities and I'd run afew experiments around that
first and then decide should wedo a bigger plan here and
(17:44):
estimate with a little moreknowledge from those experiments
and at that point you could youtry to do that earlier.
It's not going to go well.
Speaker 1 (17:53):
I'm saying this tongue in cheek so people can't
see me out there and see thesmirk on my face.
But when these complexitiescome up, have you ever heard a
developer say, oh, yes, that is,that is a challenge, but
there's this framework that justsolves that inherently that
problem.
So we don't have to worry aboutthat.
We just have to implement thisnew.
(18:13):
We've never worked with itbefore, but from what I've read,
yeah, it resolves all of yourissues and it might you can buy
your way out of complexityBecause things are not always
inherently complex.
Speaker 2 (18:27):
Sometimes it's the problem plus you that makes it
complex.
Like if you call a plumber todeal with some mysterious water
thing happening in your house,it's probably highly complex to
you if you have no plumbingexperience and that plumber may
walk in and say, oh yeah, I'veseen this before, I've got a
part out in my truck.
Let me put that together andsolve that problem for you.
(18:48):
So there are some kinds ofproblems you can buy your way
out of.
Maybe there is a framework thathas already solved a
technically complex piece ofthis.
But you know the kind ofcomplexity you can't buy your
way out of.
It's the humankind.
How are people going tointeract with this system?
Then the future preferences andbehaviors of humans is a major
(19:11):
source of complexity in softwaresystems.
So yeah, you can buy yourselfout of some of the
implementation and technologycomplexity.
Maybe I'd still want to run anexperiment on that framework and
how it solves a hard part ofthat problem.
Um, but I would not assume thatI could buy myself out of the
problem of complexity altogether.
And rewrites are so trickybecause they look complicated
(19:33):
and predictable on the surface.
Just do the thing that alreadyexists and they end up being
this perfect storm of complexitywhen you get all the new things
together.
Speaker 1 (19:44):
So my experience has been.
So you did a good job ofqualifying that.
So if you are going to adoptsome new technology, make a
prototype, make sure it's goingto do what you think, and maybe
even go a step further would bemy advice, because I've seen one
too many times that suggestioncome in and developer is all
(20:04):
jazzed up about putting it inand then three months later it's
like oh, we didn't realize thisgets to how you design that
prototype or probe, where mostof the time, that developer
who's excited about thattechnology is designing an
experiment to confirm what theyalready believe.
Speaker 2 (20:22):
Confirmation bias is at play here.
So I'm I'm going to build thething that seems easy and
straightforward and I'm going topick the case where I'm
confident this thing will work.
See, it works.
That thing.
You run into a few months laterwhere you change your mind
about how well it works.
That's the thing we actuallyneed to test.
So if you're designing a probefor this sort of thing, you want
(20:42):
to falsify your hypothesis, orat least set out to falsify your
hypothesis, not validate it.
So I would ask if I think thisthing will solve all my problems
, how would I discover asquickly as possible that I'm
wrong about that?
Well, I probably should goafter this part of the system
where the documentation isweakest or where we understand
(21:03):
how this framework will apply aslittle as we do anywhere.
Let's take a small piece ofthat and run a probe there, and
if we can make it work in thatdifficult context, then it's
probably going to work in allthe easier cases.
But you don't start by doingthe prototype on the easy case.
Speaker 1 (21:21):
Cost analysis is another thing that I've been
bitten.
Before you run this prototypeit's very small.
You implement this for one usecase and guess what?
It's great, and then, when youdecide to scale up, you didn't
realize what the cost is goingto be.
And when I talk about cost, I'mtalking monetary cost of what
(21:41):
it's going to be.
And, holy cow, we're going toend up spending more on this
tool than we're charging for thesoftware.
Yep, we're gonna have to killthis.
We have to go another route.
And so you've just ended upwasting cycles, building a
prototype, implementing it, onlyto find out that it's way
outside of your outside of yourprice range.
Speaker 2 (22:00):
I think team members often have a limited mental
model for how cost works in aproject.
Like, how much time is it goingto take me in my role to create
this code and that's, that'sthe cost.
But that may only be a smallpart of the total cost.
Like, how difficult is it totest this thing I'm creating and
how difficult and expensive isit to run this thing at the
(22:23):
scale we're actually going toneed to run it?
This is a big one.
When you're going out to a cloudsolution versus a hosted
solution.
Suddenly I'm paying all ofthese fees that go up as I
increase usage on this thing andthe developers often not
thinking about all of thosetotal cost of ownership sort of
costs.
They're just thinking about howquick is it going to be for me
(22:45):
to build this thing.
And that suggests when you'rethinking about what's the
complexity here as we consider asolution, you need a
sufficiently cross-functionalteam to represent those
different perspectives and thinkabout what is the entire cost,
what is the entire experience ofcomplexity from here to however
(23:06):
long we want this thing to liveand provide benefit for people,
and the thing that's moreexpensive now may actually be
cheaper in the long run.
Speaker 1 (23:13):
So one of the parts that developers are in.
And again, I've said thisnumerous times on this show I
was a former developer, Iconsider myself an engineer and
a developer, so I lumped myselfinto this class of people or
this group of people.
But another trap to fall into isthe way that the data is stored
(23:34):
is crap.
Yeah, it's very hard to dealwith and we're just going to
come up with a totally new datastructure and it's going to be
so much better.
It's going to be easier toquery.
Reports are going to be a flash.
It's going to be so much better.
It's going to be easier toquery Reports are going to be a
flash.
It's going to be so much faster.
Oh wait, all these existingcustomers we got to like get
them over to the new system.
(23:54):
How are we going to?
Oh, my goodness, it's going totake a lot of time and effort,
and you know, when you'retalking legacy systems,
sometimes the data is not veryclean.
You got what you got, and so Ihad actually talked to somebody
who did a very novel approach,and what he did was he said
(24:16):
we're going to refactor thedatabase later.
We're actually going to keepthe database where it is and
we're going to interface withthat so we have zero conversion
to deal with and that bringscustomers online on a snap, and
then we can work on refactoringlater.
And yes, that's going to causesome other problems, it's going
to cause things to break, but wecan do that after the customers
(24:37):
are already online.
Talk to me about, maybe, whatyou think about that approach if
you've ever used it before, andjust your general experience
with the conversion effort.
Speaker 2 (24:47):
Yeah, I have used that approach before and I've
done it with a facade on the olddata structures so that the new
system gets to use the new datastructures as far as it's
concerned and you have a facadeover the old ones, which could
be in the application layer,could be in the database layer
as views or something, dependingon your technology, and I'm far
(25:11):
enough away from actualdevelopment these days.
That that's as far as I wouldgo down that path.
But thinking about a kind oftranslation layer so that the
new system doesn't directly haveto know about the old structure
, you've put it at the boundary,only the knowledge about that,
so that you can replace it withan adapter to a new structure
(25:33):
over time and slowly refactorthat.
And that would actually berefactoring.
And again to bring up MartinFowler, that definition of
refactoring is changing theimplementation of the system
without changing the behavior.
So you're improving the designin place while the system
continues to function.
So that's a nice way to do that.
So the system does what itneeds to do.
(25:55):
You can test it.
You can even have tests thatrun against both the old and the
new system in an automated wayto validate that the new one
actually works the way the oldone did, and as you change the
data structure behind it, thosetests continue to run and give
you confidence about how it'sworking.
So that can be a nice way to doit.
The other approach that I'veused in the past is segmenting
(26:19):
your customers and peeling offsegments of customers and their
data incrementally and ideallystarting with the ones that have
the least data, so often goingafter newer ones so you don't
have to move as much as fast.
And two going with the onesthat will benefit the most from
the new capabilities that you'rebuilding in this rewritten and
(26:43):
probably extended system.
So they're the people who mostwant to move.
And then, after they prove outthe issues, if you start with
the early adopters the ones whoactually want to use the new
system they're going to be alittle more forgiving about the
ways the new system doesn't workjust like the old system, or
doesn't work perfectly yet, sothey can help you work out some
(27:04):
of those issues that snuck intoproduction before you bring over
the majority or the laggards,to use the more term for that
and they're less forgiving aboutthe ways that the new system
doesn't work, so that alsosolves a change management
problem for you.
Speaker 1 (27:25):
So I'm going to bring up something that I can already
feel.
Just before asking thisquestion, I already had a lump
in my throat.
My stomach starts getting alittle bit of a pit in it,
because I'm just a generallycaring and empathetic person.
I hear your show is a safeplace though.
It is a safe place, richard, andyou're a safe one to share with
one to share with.
(27:45):
So you have these customersthat are longstanding customers
with you and they've been withyou, let's say, from the
beginning of the company.
But you do need to reimagineyour software and one of the
things that I notice is thisisn't a family, it is a business
and in some cases the newsystem just isn't a good fit for
(28:07):
those old partners that you hadand it's just going to cause so
much effort to be able toplease them that doesn't align
with the rest of your customerbase and again this causes I
just I can't say enough abouthow much I cringe, but the term
firing a customer comes up andsometimes they're just not a
(28:28):
good fit and that's veryuncomfortable to do.
But you just have to do what'sbest for your company and for
the customers that you serve asa whole and not get dragged down
by a single customer.
It's a hard call to make.
Speaker 2 (28:43):
And I think that's true, especially if you have a
strategic reason for doing that.
I think we're moving into a newmarket segment.
One that I've seen with some ofour customers is industries
where there's consolidation and,like you may have previously
served small businesses and nowthere's small businesses getting
acquired or merging togetherand becoming more enterprisey
(29:06):
midsize or large businesses andyou may want to follow that
market up in your product and atsome point you're putting
enough focus into doing thatthing.
Well, that meeting the quirkyneeds of the small businesses is
expensive for you and you'reprobably not serving them as
well as you used to, so youcould keep wrestling with that
(29:27):
and not doing things very wellfor them, but that's probably
not going to serve anybody well.
So you're at a fork in the roadwhere either you make a
strategic decision to actuallyinvest in that other segment and
do it really well anddifferentiate there, or you
decide that's not where we'regoing.
I probably should help thosecustomers find a solution that's
(29:48):
more suitable for them and Isay it that way deliberately,
that's not a euphemism for helpthem find another place to go.
Meaning cut them off and leavethem hanging would feel like
it's done in service of them andwouldn't have the bad feeling
(30:11):
in my gut that you're describing, Mark, would be.
Let me think about a few optionsthat would be better for them
now, because there's probablysomebody else in the market who
took advantage of us moving upmarket to go after those
customers that aren't beingserved as well.
Is it possible for me to put alittle bit of investment in,
(30:31):
maybe an export tool that letsthem get their data into a form
that could be imported into thatcompetitor's tool?
Now the CFO might say you knowwe're not going to make any
money off of that.
Well, maybe not, but we aregoing to probably build loyalty
so our former customers won'thate us and talk bad about us.
And if consolidation is a trendin that industry, some of those
(30:55):
former customers who leave nowmay be our future customers when
they end our strategy to servethat larger market.
And we're just getting somefuture buyers there by treating
our past customers well who maybecome our future customers
(31:16):
again.
So I think that's a, I guess,human-centric, strategic way to
do that sort of thing Not justfiring them but helping them
find a better solution thanwe're being for them and
thinking about doing that in away that proves goodwill and a
potential future customerrelationship.
Speaker 1 (31:33):
I love that and it's not software related.
But I'll tell you where my softspot comes from.
This is that I grew up in avery rural, small community.
Like most of the grocery storechains that are going around,
they get taken up by, get boughtthe only grocery store that was
in the hometown that I grew upin.
(31:53):
Well, the company got sold andthey were going into a bigger
market and the bigger market waslike yeah, that's small
potatoes, we're not going to goto a small little city.
So what did the people in thecommunity what options would
they have Drive 45 minutes toget groceries.
You know that's not a very goodoption.
So they at least did work tokeep the grocery store open
(32:16):
until one of those smallerchains was able to have a deal
to come in and replace them, andthat's just a very human way.
I mean, I just like to thinkthat's the right way to treat
people and I just think thingscome around and if you treat
people like dirt or like you'rejust using them for I don't know
, it comes around to bite yousome way or some form.
(32:39):
I'm not saying karma isnecessarily real, but I just
like doing the right thing andso in that particular instance.
Speaker 2 (32:49):
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 anddoing the thing that's good for
your business are rarelyactually in conflict, because
business is fundamentally humanrelationships.
So you can't really give up ongood relationships for very long
before that is going to preventyou from having a good business
(33:12):
.
So a human centric approach tobusiness.
If, again, if you're creativeand you find things that create
flywheels for impact like you'rehaving more and more positive
impact on people and flywheelsfor your business model we're
having more and more business,whatever our business model is
and yet you do the work to thinkabout both those things Well,
they're more often than notactually going to align.
(33:34):
Doing the right thing forpeople causes people to want to
exchange money for whateverproduct or service you provide,
and if it feels like thosethings are in conflict,
something is broken in yourbusiness model and it's not
going to last anyway.
Speaker 1 (33:47):
So, as we're coming up on a close to our episode, I
want to share one one story withyou, richard.
So I was, I was working at acompany and I was in a
management and it was a softwaremanagement role and it just
started.
In the company there was asingle developer who developed
this utility software that thecompany used as part of their
broader package, and he was justreleasing it when I first came
(34:11):
on board and was asking himquestions and he said well, yeah
, I had to refactor our oldsoftware so it would do these
new things and we're going torelease it next month, but I'm
going to need to rewrite itagain.
Wait, what?
I'm sorry, I must havemisunderstood you.
You said you're going to haveto rewrite it again, and so that
(34:32):
is an example of and it was afun tool.
And you know, we just had tohave a heart to heart
(34:53):
conversation and I just had tosay you know, if that's the way
you like to work, that soundslike something you need to go
off on your own to build.
If you want to build tools fromthe ground up, we just don't.
We've got more important thingsto deal with than building.
Building these low level tools,uh, that you want to build so
it.
It just doesn't sound like agood, a good match.
(35:13):
That was a hard conversation tohave.
He ultimately left the companybut yeah, so that's, uh, I guess
, uh, uh, maybe an atypicalexample of of rewrites.
And have you ever come acrosssomebody who said they were
rewriting something?
Before they released it, theysaid they needed to rewrite it
again.
Speaker 2 (35:30):
Um, I somebody who said they were rewriting
something before they releasedit.
They said they needed torewrite it again.
I don't know that I have.
I may have felt that myself.
I'm about to ship this and Isee all the problems with it.
I think there's thinking aboutthat story that you told.
I see two psychological anglesat play there that actually
might have made it possible forhim to be a good long-term
contributor on your team.
So not to rethink yourmanagement there in hindsight.
(35:53):
But the two things that came tomind for me one is there's a
cognitive bias angle here whereour brains have these shortcuts
that keep us alive but sometimesmislead us, and one of those is
something called the curse ofknowledge, which is once you
learn something, it becomesobvious to you and just gets
integrated into how you thinkabout the world At scale.
(36:13):
We call this common sense, allthose things.
They're so obvious to me.
I assume everybody else knowsthis and I don't realize.
I don't remember that I learnedthose things at some point.
And when you project curse ofknowledge backwards in time, you
get hindsight bias, and I thinkfor developers this often shows
up as well.
Knowing what I know now, I'mgoing to get it right next time.
Not realizing next time isgoing to have its own
(36:36):
complexities and something newwill emerge and I'll get it
wrong.
But you forget that you'renever going to plan this
perfectly.
It wasn't.
I should have planned betterand 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 torewrite.
So that's one angle.
(36:57):
The other angle that came tomind for me is the research on
motivation.
Motivation research, amongother things, has shown that the
two of the major humanmotivators are purpose.
We want our work to are purpose, we want our work to matter and
play.
We want our work to beinteresting and engaging, to do
a sense that I'm good at whatI'm doing.
I'm growing in what I'm doing.
(37:18):
One study showed that the playmotivator is three times
stronger than the purposemotivator, meaning you have to
have a really, really compellingand clear purpose to overcome
the desire just to fiddle withthings and enjoy the technical
challenge and feel good at whatyou do.
A lot of developers are sodisconnected from a compelling
(37:39):
purpose that they find themeaning and engagement in their
work from the technology, and Isuspect that's true here and I
suspect that's true here.
There there may not have been astrong enough connection to why
being done with this thing andmoving on to something else had
a strong impact on the businessand on other people, and so it
was just I.
My work has meaning because Iget to play with cool things and
(38:02):
make the most brillianttechnical solution.
Sometimes you can resolve thatby increasing the connection to
purpose and you find that peopleare more willing to do things
that maybe aren't as shiny andnew and interesting from a
technical perspective but havedeeper meaning to them.
That purpose motivator canovercome the play motivator.
So I wonder if one or both ofthose might have created some
(38:25):
more options for that developerto find more ways to contribute
that were good for him and goodfor the company.
Speaker 1 (38:34):
Do you have a DeLorean, a flux capacitor, and
I always forget.
Is it plutonium or uranium?
One of the two, I can'tremember.
Speaker 2 (38:42):
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 andredo that hour.
It's going to go well.
And, yeah, you can go out andredo that Well.
Maybe somebody listening is ina similar situation and can
think about it differently.
Speaker 1 (38:55):
There you go, Richard .
I really appreciate you comingon the show.
This has been absolutelyfabulous.
I love this conversation.
If our listeners out there wantto get in touch with you,
what's the best way for them todo that?
Speaker 2 (39:07):
The best way to connect with me is through our
company website,humanizingworkcom.
If you want to reach out to medirectly, it's richard at
humanizingworkcom and I'm onLinkedIn as well, but you can
also just go to the contact pageon our website and currently
it's possible to book some timewith me and or my co-founder,
(39:29):
peter Green, if you want to talkabout how we can help your
organization get better atleadership, product management
or collaboration and at thispoint there hasn't been an
overwhelming demand for that.
I think most people assume thateverybody else is taking our
time, so until that becomes aproblem, it's actually really
(39:50):
easy to get some time with usand talk through what's going on
in your organization, and welove having those conversations.
Humanizingworkcom, slashcontact and reach out and we'll
be in touch.
Speaker 1 (40:00):
And you said that first call is free.
It is, yeah, so how do you gowrong with that?
Free everybody.
Speaker 2 (40:09):
There goes my calendar, yeah.
Speaker 1 (40:13):
All right, richard, I really appreciate you taking
your time to come on the show.
It's been absolutely fantastic.
Love your work, love yourcontent.
Let's do this again sometime.
I'd love to.
It was great talking with you.
Speaker 2 (40:24):
Mark, Thanks for having me on.
Speaker 1 (40:26):
All right, everybody that brings it into another
episode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the AgileWithin and please spread the
(40:58):
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Popular Podcasts
Amy Robach & T.J. Holmes present: Aubrey O’Day, Covering the Diddy Trial
Introducing… Aubrey O’Day Diddy’s former protege, television personality, platinum selling music artist, Danity Kane alum Aubrey O’Day joins veteran journalists Amy Robach and TJ Holmes to provide a unique perspective on the trial that has captivated the attention of the nation. Join them throughout the trial as they discuss, debate, and dissect every detail, every aspect of the proceedings. Aubrey will offer her opinions and expertise, as only she is qualified to do given her first-hand knowledge. From her days on Making the Band, as she emerged as the breakout star, the truth of the situation would be the opposite of the glitz and glamour. Listen throughout every minute of the trial, for this exclusive coverage. Amy Robach and TJ Holmes present Aubrey O’Day, Covering the Diddy Trial, an iHeartRadio podcast.
Betrayal: Season 4
Karoline Borega married a man of honor – a respected Colorado Springs Police officer. She knew there would be sacrifices to accommodate her husband’s career. But she had no idea that he was using his badge to fool everyone. This season, we expose a man who swore two sacred oaths—one to his badge, one to his bride—and broke them both. We follow Karoline as she questions everything she thought she knew about her partner of over 20 years. And make sure to check out Seasons 1-3 of Betrayal, along with Betrayal Weekly Season 1.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.