November 13, 2024 • 33 mins
Ever wondered how to navigate the chaos of a growing startup? Join my conversation with Tom Holt, principal consultant at Otterworks Consulting, as he reveals the secrets to transforming initial success into sustainable growth. Through Tom’s seasoned insights, discover the nuances of managing expanding teams and communication complexities, and learn how to maintain momentum with refined processes.
Communication can make or break a burgeoning team, and as lines multiply with growth, chaos often ensues. Our discussion dives into the evolution of communication and authority structures in agile environments, where clear empowerment is key. Embrace the wisdom of gradual process introduction to keep teams informed and efficient, sidestepping bottlenecks along the way. Leaders, it's time to trust your teams and distribute responsibilities to pave the way for seamless decision-making and effective scaling.
Creating a psychologically safe space is the bedrock of effective change management. Tom shares strategies for fostering trust through retrospectives, enabling teams to unearth valuable insights and drive continuous improvement. Learn about the power of focused goals over multitasking and why smaller, iterative approaches can lead to quicker value delivery and adaptability. Plus, get tips on meaningful documentation without the bloat, ensuring your processes add value and aren’t just noise. Engage with us for free consultations and start taming that chaos today!
Connect with Tom on LinkedIn:
https://www.linkedin.com/in/tomholtstl/
Discover Tom's company, Otter Works Consulting:
https://www.otterworksllc.com/
Contact Tom via Email:
Tom@OtterWorksLLC.com
When in St. Louis, Missouri visit Forest Park and City Museum:
https://en.wikipedia.org/wiki/Forest_Park_(St._Louis)
https://citymuseum.org/
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.
Mark (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.
Well, hey there.
Welcome to the Agile Within.
This is Mark Metz.
I hope everybody is having anabsolutely fantastic day out
there.
Today's episode from St Louis,missouri.
(00:49):
I have Tom Holt.
Tom, welcome to the podcast.
Thanks, glad to be here, reallyglad to have you.
I've spent some time in StLouis, but you're the guest, not
me, so I want to know if I hadnever been to St Louis before,
tom and I was coming for a day.
What's one thing that you wouldsay I couldn't miss doing?
Tom (01:12):
Well, I've heard some other people do this.
I'm going to cheat and give youtwo.
Go for it.
One thing that you can't missin St Louis is we have a park
called Forest Park.
It's actually bigger thanCentral Park and it is
surrounded by a whole bunch ofthings that are absolutely free
to go to.
So we have a science museum.
(01:34):
We have a zoo that is free.
We have an art museum that'sfree.
There's a Missouri historymuseum that's free, which may be
not quite as exciting as theother it depends on your bent.
So that's really cool ForestPark.
I would check that out.
The other is a place called CityMuseum, and City Museum is
nothing like what it sounds andit's extraordinarily hard to
(01:55):
describe found, found object artexhibition.
This is like an entire buildingthat is a found object art
installation that is designedfor children and people that can
still crawl on their knees,which I can't.
You can explore it.
There's tunnels.
(02:16):
There's an airplane fuselagethat's attached to the outside
that you can crawl through.
It is the most amazing thing.
I recommend everybody to gothere.
I've never seen anything likeit.
I've traveled all over theplace and I've never seen
anything even remotely like it,so I recommend that highly.
Mark (02:34):
That sounds awesome.
I'm going to get some linksfrom you so we can post it to
the listeners here.
If they're ever in the areathey can visit.
Well, thank you for that.
That's awesome, All right, Well, Tom is the principal
consultant at OtterworksConsulting and before that he
was the head of engineering at afew different startups, and
he's been in technology forthree decades now and counting.
(02:57):
And, Tom, the title for theepisode today is called Taming
the Chaos, and I want to ask youTaming the Chaos?
What's that all about?
Tom (03:07):
So for me, I've been in a lot of situations where I've
come into a startup that hasreached the point where they're
starting to have some success.
They're growing A lot of thethings that they did when they
were small, when they were two,three, four, five, 10 people are
just not working for themanymore and they've created some
(03:29):
people might call them ad hocprocesses.
I like to call them organicprocesses, because they grew up
over time and those organicprocesses are just not serving
them anymore and they'restarting to feel the pain of the
chaos that used to feed thembut now is starting to give them
(03:49):
some pain, right, somedifficulty, as they are
continuing to grow.
So they realize the phrase iswhat got you here won't get you
there.
They've realized that what gotthem here, to this place of
growth, is not going to scalepast where they are right now.
That's my thing is I like tohelp people tame that chaos and
(04:14):
kind of put it in a box andfigure out where to go from
there.
Mark (04:18):
Give us some examples.
What kind of chaos and whatkind of pain are we talking
about here?
Tom (04:24):
There's a lot of different research around this, but one of
the really simplest things andthis is I'll have to kind of
draw a picture for you, sincethis is audio only.
But if you think about when youfirst start off, you know you
might have like a very, verybeginning.
You might have a single techperson and a single other
founder, right, so somebodythat's kind of on the sales idea
(04:45):
side, and you've got somebodythat's kind of the
implementation side, and whenyou have that, the communication
between those two people isjust a single line of
communication.
And so you've got these ideasand they're bouncing off each
other and the person isgenerating code and they're
making things happen.
And then you get a third personin the mix.
(05:07):
Whoever that third person is,when that happens, you now have,
instead of one communicationline, you now have three
communication lines.
Between each of those threepeople there's a communication
line.
So you've got threecommunication lines.
When you add a fourth person,you now have seven communication
lines.
By the time you've got threecommunication lines.
When you add a fourth person,you now have seven communication
lines.
By the time you've gotten toeight, you've got 28 different
(05:30):
communication lines, and at somepoint that just becomes more
than you can handle.
So you need to start beingreally intentional about how you
communicate within that team,that team of eight.
Now, still, you can kind ofhandle it, because, just as a
human being, you've been througha lot of situations where
(05:51):
there's teams of people and youknow who's got what information
by the time you've gone pastthat though, once you get to
double that to 16 or to 32,those just natural ways of
communicating, interacting witheach other, no longer mirror
family relationships or anythingelse that you might have, or
(06:13):
school situations or anythingelse that you might've come up
with in the past, and so youreally need some more structure,
people that haven't experiencedthis or have grown up in this
situation, in this company orthis organization.
But it can cause some actualemotional distress.
I mean, I've been in situationswhere you know, hey, we're all
(06:49):
professionals, but somebodykicked a hole in the wall, right
, because they were angry aboutstuff that shouldn't make you
that angry, right, but it'sbecause you're passionate about
what you're doing.
Maybe you're in a meeting andthings aren't going and you
don't know who's got theauthority to make what decisions
.
Or you don't know, some pieceof information didn't make it to
you and it's just making it toyou now.
(07:10):
We see these kinds of things inall sizes of organizations, but
they really happen a lot inthis transition from small to
midsize.
Mark (07:20):
So communication is important, but you also have
that dynamic of who's in chargeRight and who's calling the
shots.
So when it's two people, likeyou say, you may have one person
that's responsible for sales sothey're interfacing with the
customers and you've got anotherperson that's handling the
implementation.
(07:40):
Maybe they're a technologistand they're handling all that
side.
Maybe they're a technologistand they're handling all that
side.
But as the company startsgrowing, it's hard for either
one of those people to have ahold of everything that's going
on there.
There has to be some pointwhere that starts breaking down.
And it's interesting to findwhere that point really is,
because when you bring otherpeople in, you want other
(08:03):
perspectives, you want diversityof opinion.
Maybe you have to ask theleaders that start are you
really?
Is that really what you'relooking for?
Tom (08:12):
Well, right, and some of the best leaders I've ever been
around and learned from will saythings like if I'm the smartest
person in the room, then I'vehired the wrong people, and so
there is that transition as well, right?
When it's just two of you, Imean, you're both, hopefully,
(08:33):
the smartest person in the room,at least in your realm, in your
area that you're dealing with.
Once you grow to a largerorganization, you're going to
have to give up pieces of theauthority around that expertise
to others.
For example, if you are the CEOof this startup and you've got
the CTO, let's say, let's justimagine that there's two people
(08:57):
and the CEO is doing themarketing, the sales and the
product management, and the CTOhas got a little bit of product
management, is doing all thetechnical aspect and maybe the
customer support as well.
At some point you, hopefully,are going to hire some people to
handle some of those things.
So let's say, you as the CTO,you go listen, doing the
(09:20):
customer support is great,because I get to hear directly
from the customers, but wereally need somebody to answer
the phone when I'm deep in themiddle of some technical flow,
right, so we hire somebody.
And if you don't trust thatperson.
If that person doesn't have theauthority to interact with the
customers and to makecommitments to the customers,
even on the basis of their role,then you're going to have a
(09:43):
problem and that problem is onlygoing to get worse as you go
forward.
So sitting up those kinds ofauthority structures is really
important Not that it has to behierarchical, but people need to
know what they are empowered todo, and that goes into every
aspect of the organization.
I kind of concentrate on thedev team and the people that are
(10:05):
creating the product.
They need to know what they areempowered to do.
This is a podcast that is theAgile Within.
That's about Agile, right?
So within Agile we say that theteam should be as much as
possible empowered to makedecisions that are within their
realm of expertise.
We shouldn't have thatauthority held above them.
(10:27):
But it really, if you thinkabout it, has to go through the
whole organization.
Mark (10:33):
So as the company grows, we need to add some structure,
and the purpose of the structureis so that people are informed,
communication lines are openbetween everyone and decisions
are efficiently made.
But you don't just go from noprocess to very heavy process,
(10:53):
from one day to the next.
Right, what does it look likein making that transition?
Tom (10:59):
That's an excellent question.
The first thing, the mostimportant thing that you want to
establish, is a phrase that weuse a lot, which is
psychological safety.
There needs to be psychologicalsafety within the team.
All the other things you mightgo ahead to do aren't going to
have the impact that you want ifthere's not trust between the
(11:21):
people that are trying to affectthis change and the people that
have to live with the changethat you're doing.
This is going to sound weird,but I start with a retrospective
.
I might start with multipleretrospectives, depending on how
large the team is or how manyteams there are.
There may be a retrospectivethat includes the dev leader and
(11:43):
other stakeholders within thecompany, because maybe they have
some insight into the ways thatthe development organization
has been running that affectthem, and so that's really good
information.
You want to understand that.
Also, within the devorganization, you might have,
let's say, you've got two teamsor three teams.
(12:03):
Now you might want to haveindividual retrospectives with
each of those teams.
So you want to dig into what isgoing well, because there's
probably some things that aregoing pretty well and you want
to understand this.
You don't want to run overthose things.
And then you want to see, okay,what's not going well.
And by not going well, you wantto dig down.
You know kind of the five whys.
(12:24):
It's like these tickets areshowing up, they're not fully
baked.
You're like, well, you want todig into that and understand,
okay, how does that affect whatwe're doing?
Why do you feel like theyshould be different?
And you dig into it.
You need to understand what'sgoing on.
I like to make those things asfun as possible.
Depending on the companyculture, the team that you're
(12:47):
dealing with.
I often will have them off-site.
It takes them out of thecontext of.
A lot of people are remote now,so that's that's a different
thing.
But honestly, if you couldbring them in person to do this,
that is very helpful.
Include some what I callserious fun, some games that
(13:08):
lighten the mood, that takepeople to.
That's just a prescription forany good retrospective.
But that's how I like to start.
And then, once thatretrospective is done, you
hopefully have a body ofknowledge that you have
(13:30):
collected.
Now where do you go from there?
I would pick elements out ofScrum right, just because A it's
really well-documented howScrum works and it's actually a
really simple, relativelylightweight process.
Depends on how far along thecompany is, whether I would
implement all of Scrum orwhether just pieces of it.
If I were going to implementjust pieces of it, I might not
(13:52):
always go in this order, but Iwould probably go with daily
stand-up.
First, always retrospective,because anytime you go into this
situation you want to becontinuously improving.
That's one of your mainmechanisms for continuous
improvement is to involve theteam in it.
The other thing that I want tomake sure any company that's
doing dev work uses is astack-ranked backlog, and that's
(14:14):
a commitment that thestakeholders through the product
owner, if you're using Scrum,or whoever managed that product
manager that's the commandmentthat they need to make to the
team is to give them a sense ofwhat's most important.
Because if you can't tell theteam what's most important, it
is really difficult for them tomake that decision on their own,
and what you're really doing isabdicating that decision to
(14:37):
them, that decision to them.
So I think this is somethingthat I've seen in almost every
company that's going throughthis.
It's like, oh my gosh, we gethalfway through this project and
then somebody comes on and theyinterrupt it.
It's like, well, that's becauseno one has forced them to have
the discipline of prioritizingtheir own inputs to this
situation.
So stack correct backlog putsto this situation.
(14:58):
So stack rank backlog.
And then finally, if all ofthat stuff is in place, then I
might go to a iteration-basedprocess, so a sprint-based
process.
I think those are reallyvaluable, but it's also a
constraint.
There's also a cost to doing asprint versus just a free flow
(15:19):
of work, and that cost is thefact that your work doesn't
necessarily fit into one week ortwo weeks or, god forbid, four
weeks.
However long your sprint is,there's going to be, there's
going to be.
You know, as you're putting therocks into the sprint, some of
the rocks are too big.
You can fall into the trap oflike, well, we'll just squeeze
(15:40):
it in, which is terrible becauseyou you know everybody tries to
do that and we all know howthat works.
Right, you end up not gettingthat last bit done.
Or you have to say we're goingto commit to less, in which case
you've lost some efficiencythat everybody hopes you could
regain, although it's absolutelybetter than trying to do more
than you're actually capable.
Mark (15:59):
You talked about scrum.
They're doing their daily Scrumsor their daily stand-ups,
they're having retrospectives,they have a backlog, but what
happens is it becomes a wishlist and people want to know.
You have all these differentstakeholders, and this is
especially for a startup whereyou're trying to start something
new, especially if you aretrying to retire a legacy
(16:22):
application and trying to createa new version of an updated
version of an application or asuite of applications that are
in the marketplace Everybody isclaiming for I need this, I need
this, I need this, and I'veseen the temptation is well,
we're just going to start allthese things so we can tell
everybody we're working on it,we're working on it, right?
(16:46):
And then people oh, okay, well,I'm happy, they're working on it
.
So what you're telling thatperson is that you're working on
it, and what they perceive itto mean is oh, that means you're
going to deliver it to me verysoon.
But what you're telling them iswe're working on it to get you
off my back, but we're alsoworking on 10 other things that
(17:07):
we're also telling nine otherpeople that we're working on it,
and pretty soon.
You're not making anybody happy, but you're pleasing them in
the short term.
You have to pay the piper atsome point.
Tom (17:18):
It's what I call a pretty lie.
I don't think when peoplesometimes it is intentional, but
I think most of the time whenthe people that say, yeah, we
can work on that as well, I meanthey do it with the best of
intentions.
Wow, yeah, that does soundimportant.
Okay, we'll get started on thattoo.
I mean, the problem is thatfocus is incredibly important.
(17:40):
Okay, we'll get started on thattoo.
I mean, the problem is thatfocus is incredibly important.
There's a lot of research that'sbeen done that shows that the
more that you interrupt someone,the absolute less you will get
out of them.
I think of things in terms ofoperating systems.
Every time you do a contextswitch, you lose a bit of
efficiency, and humans lose alot of efficiency every time you
(18:02):
change from one task to another.
I've seen numbers anywhere from22 minutes to a couple of hours
, depending on who you are.
So the more things you'retrying to do at one time, the
less you're actually going toget done.
But even beyond that, let's sayyou had a team and they had
(18:24):
four tasks that they weresupposed to work on.
Each one of those tasks wasgoing to take, I don't know,
let's say, a week.
There was no efficiencydifference at all.
If that team worked on thosefour tasks in parallel and got
them all done at the end of fourweeks, then you would have no
(18:46):
value delivered during thosefour weeks.
Okay, and at the end of thefour weeks you would have four
units of value.
Let's just make it all reallyeasy.
You say the team's going towork on the first unit and get
it done in a week.
Then, from week one to weekfour, you have one unit of value
(19:08):
delivered to your users, andthen, after week two, you've got
two units of value delivered tousers and after week three
you've now got three units ofvalue delivered to your users.
And then, after week four, youhave the same situation you had
before, except that during thoseintervening three weeks you've
got things that are out there,that are being used and, as we
(19:32):
know, once you've delivered thatfirst unit of value, it gets
out there into the wild, so tospeak.
You will get feedback on it andyou might know that the fourth
unit of value that you're goingto decide to deliver actually
doesn't even make sense to donow.
And it gives you the ability tobe flexible, to be agile,
(19:55):
adaptive to the data that cancome in if you delivered
finished work.
Mark (20:02):
So there is an aspect of these pressures or these
commitments coming from outsidethe team, but there are these,
like you say, the best ofintentions of this coming from
inside the team.
And I have lost track at thispoint of the number of times
I've run this experiment, tom.
But I've had teams that werethinking very, very
(20:23):
advantageously and thinking thatthey could have two goals for
the sprint because the firstone's really small so we can
pull another one in.
So I said, okay, if that's thecase, then we're going to break,
let's say, if we're working ina two week sprint, we're going
to effectively break this sprintup into two one week sprints.
This task that you say isreally small, that's going to
effectively break this sprint upinto two one-week sprints.
This task that you say is reallysmall, that's going to be our
(20:43):
sprint goal for our first week.
So that's like our sprint 1Aand the next sprint is our
sprint 1B.
So we're not going tonecessarily run a retrospective
at the end, but that gives ussome closure so that we can
focus and we're not thrashingbetween the two.
I've never had a team finishthat small little task in that
(21:04):
first one week sprint.
It always carries over and wenever get to the second sprint
goal, absolutely.
Tom (21:11):
Yeah, absolutely.
That's funny that you mentionedthat, because that brings me to
one of my things, which isestimation, and estimation is
just extraordinarily difficult.
My brother-in-law was anestimator for a large
construction firm.
As an estimator for aconstruction firm, you can look
at the blueprints, you can lookat the architectural drawings,
(21:35):
whatever, and you can go okay,this is how many yards of
concrete we're going to need.
This is what a wall looks like.
Whenever you build a wallthat's 20 by 40, it basically
takes about the same amount oftime every single time you do
that.
So he could look at it and gookay, well, this is the
materials we need, run it allthrough a spreadsheet and come
up with the right answer.
And that was his job and he didit really well.
(21:56):
In software, we're alwayscreating something that we
haven't created before.
We're always doing something.
We're always solving problemsthat have a level of complexity
that we really don't know howlong it's going to take.
We can get better at it, but wewill never know exactly how
long something's going to take.
My experience has been thatdevelopers by and large
(22:20):
underestimate, as a rule, howlong things are going to take
them to do and thereforeovercommit and put themselves in
a bind and then also put a bindaround the people that are
expecting whatever thisdeliverable is.
So, whether that's marketing orcustomer support, or the sales
team or whoever it is, which iswhy we do sprints, which is why
(22:44):
we break everything down intosmall, bite-sized stories right,
that the smaller we make thesethings, the easier it is to wrap
our heads around.
But, exactly, you're totallyright.
I can totally attest to whatyou're saying, that when the
team gets overambitious anddecides to commit to more, the
hardest thing to do is to reelthem in, because every external
(23:05):
pressure is like they said theycould do both, man, we want both
.
Give us both right, like youknow.
Mark (23:11):
Yeah, from your stakeholders like your
stakeholders.
Where's the negative in that?
That's right, yeah right.
If we could do two, then whycan't we do three the next time?
Then why?
Tom (23:20):
can't we do three the next time Exactly?
So yeah, that is absolutelytrue.
So focus stepwise incrementaldelivery of value.
I mean that's one of thefundamentals of this paradigm
that we call agile softwaredevelopment.
Mark (23:37):
As most things in life, it's not always black and white.
It's the shades of gray inbetween that make the difference
.
And so, as we measure goingfrom no process to having some
right amount and I'm giving airquotes here.
Right amount of process how doyou know when you've crossed the
(23:57):
line?
That's something that Istruggle with many times.
Is you know we're being toorigid or we're being too loose,
and it seems like you just neverquite get it right in the sweet
spot.
Tom (24:09):
That's a really important thing.
So what I like to do is I startwith as little as possible and
I move until it solves theproblems that we have, because,
you're absolutely right, moreprocess than what you need is
waste.
It frustrates everyone.
There's a few people it doesn'tfrustrate.
There's some people that are alittle OCD and I've known a few.
(24:31):
I'm not one of them, but Imight live with a few who really
just like to have everythingreally well documented and know
where all the things are goingto go.
But for most situations youwant as little process as solves
your problems, as gets thingsrunning smoothly.
As you grow, you will have tochange Once again.
(24:52):
That's why we do retrospectives.
That's why we're continuouslyimproving.
So the amount of process thatyou have in a team of 10, let's
say, just one bigger than apizza team, right, or 11, is not
the same process you're goingto have when you get to 20 or 25
or 30 or 50.
There's going to have to bemore structure when you get to
that size.
(25:13):
But you don't want all thatstructure.
You wouldn't implement SAFE ina pizza team, right?
You'd go, no, no, no, we don'tneed all of that, right.
That's way way too much.
So you look for the pieces thatsolve the problems that you've
got.
And this is difficult becauseit's easy to just take a
framework and just drop it in,because you can go and you can
(25:35):
read the literature around theframework.
It tells you all the thingsthat are part of that framework
and you can implement thatframework.
But if you don't understandwhat each one of those pieces is
there to do for you, for theteam and that's the plural, you
right If you don't understandwhat every single piece in that
is supposed to do for the team,you may end up implementing more
than what you need and you mayactually slow yourself down and
(25:57):
frustrate people who otherwisemight be really in favor of this
change.
But if they find, yeah, but nowwe're doing this thing and we
didn't really need to do thatthing and so it's that that
cynical management's telling usto do this stuff and that's not
particularly useful.
Mark (26:15):
I'll give you a really good example from one of our
past guests, mark Paul Sabral.
He supplied a story that was inreal life, that he was working
with a team and they weregrowing, they were adding more
teams and the team, in one ofthe retrospectives, said, when
we're onboarding these new teams, it really is slowing us down.
(26:35):
And so they started askingthose questions, like you
mentioned, like well, why isthat us down?
And so they started askingthose questions, like you
mentioned, like well, why isthat?
And the team finally camearound to we really don't have
any documentation for newdevelopers that are coming on
the team, so they're having topair with other developers and
that's taking time away fromthem.
So they said we need moredocumentation.
So Mark was really, really Icommend him highly.
(26:56):
He could have just said, okay,that's what we need to do, we
need to create moredocumentation.
But he took it a step furtherand he said, okay, we need more
documentation, but how do weknow that we're putting together
the right documentation?
How do we know that we'reputting together documentation?
That really helps, because, asyou mentioned, that is a form of
(27:16):
waste, but they had somerepository for their
documentation and he couldmeasure how many times each
document was accessed and heshowed the team.
You spent 10 hours putting thisdocument together.
We've had one person read it inthe last three weeks.
Is that really valuable for us?
And that really opened the eyesof the team and they're like
(27:37):
you know what?
You're right.
We thought we should bedocumenting these things, but
developers, when they come in,they really don't need it, they
just need to be to see thisexample or whatever the case may
be.
But I thought that was a veryclever way to go another level
deeper and actually monitor,when you're talking about adding
more steps to your process, toreally seeing are they truly
(28:00):
effective.
Tom (28:01):
No, that's beautiful, and I have a story that's almost the
exact opposite of that.
Mark (28:06):
Oh great, yeah, let's hear it.
Tom (28:09):
I was at a company it was a bit larger company, fortune 500
.
And we were a relatively largeteam.
I mean, it was about 400engineers in the team and we
were working on an importantproduct.
Obviously, every sprint, ourCTO had asked us to create a
document for each feature oreach change that we wanted to do
(28:31):
, and there was a particularformat for these documents, and
each one of these documentsended up being about 50 pages.
Mark (28:38):
And if there's anything, a developer loves it's
documentation, oh right, andthere were about 50 of these
documents being created forevery sprint.
Tom (28:48):
So, if you calculate that out, there was 2,500 pages of
documentation created eachsprint.
Now, mind you, these sprintswere longer than recommended,
but 2,500 pages of documentation.
Did anyone read these?
Well, the answer is I think waymore time was put into creating
them than was put into perusingthem, and the upshot was people
(29:11):
would still deliver things thatwere not what was expected or
wanted, and so it was.
It was absolutely waste, right?
Because, oh well, we just needto document this better, we'll
just make it even more detailed,and it doesn't matter if the
people don't read it.
The other problem withdocumentation documentation is
great, I love documentation isthat if it is not important,
(29:34):
then it will not be updated, andif it's not updated, it is
worse than not being there,because then it's wrong.
And now you have bad data, andwe all know that bad data is
worse than no data.
It's at least no data, you know.
You don't know what's going on.
Mark (29:52):
So, wow, that's an interesting situation.
It's a double whammy.
So you spend time deliveringsomething that isn't used.
But not only that you spendeven more time documenting
something that the customerdoesn't use.
Tom (30:04):
Exactly, and yeah, so, like we said, you know, excess
process.
So in this case, a lot ofexcess process, excess process
from a lean standpoint, is waste, because anything that doesn't
deliver, you know isn't part ofthe chain of things that deliver
value to the user, is waste.
Right, as we try to minimizethat, I like to make sure that,
like I said, the leastresponsible amount of process
(30:25):
that's what I like to deliver.
And you get there by startingsmall and incrementally
increasing until you've solvedthe problems that the team and
the stakeholders areexperiencing.
And once you get there, thenyou stop until you anticipate
new problems arising, andtypically I even say until you
(30:46):
start feeling a little bit ofthe pain, because if you
anticipate, you know people willbuild stuff that isn't
necessary.
You know there's a phrase youain't going to need it, and
that's in the software itself,but it's also in the process
that creates the software that'sin the software itself, but
it's also in the process thatcreates the software.
Mark (31:05):
Well, Tom, the time has flown by here.
We've talked about taming thechaos and feels like there's so
much more chaos that can andshould be tamed.
But trying to stay within ourtime box here, hey, if our
listeners want to get in touchwith you, what's the best way
for them to do that, Tom?
Tom (31:18):
Well, they can absolutely find me on LinkedIn, tom Holt.
My consulting agency that Ijust launched is called
Otterworks, and you can findthat on LinkedIn.
I also have a website,otterworksllccom, and they can
absolutely email me, tom, atotterworksllccom.
(31:38):
Yeah, and I would love to likeif anybody, if any of this,
resonates with any of yourlisteners people that are
starting to experience some ofthe pain of growing and being
successful but, realizing thatthe scaling has kind of got out
of hand, they would like somehelp taming that chaos.
I would absolutely love to talkto them.
They can reach out to me and wecan set up just a free
(32:00):
consultation.
I'll listen to what's going onand in those free consultations
I always give them a couple ofactionable things that they can
do right away, even withoutfurther engagement, that will
help them to progress from wherethey are, to alleviate some of
the pain that they've got toalleviate some of the pain that
they've got.
Mark (32:19):
Free consultation Does it get any better than that?
All right, tom.
Well, we'll put all thatinformation in the show notes,
as always, to make it easy forour listeners there to reach out
to you and to get in touch, tom, I really appreciate you coming
on the show, buddy.
This has been reallyinteresting and fascinating.
I really enjoyed this.
Tom (32:36):
Well, thanks.
I've really appreciated yourpodcast.
I like the way that you thinkabout the softer side of some of
these things, and I thinkthat's something that we as tech
people sometimes miss, and it'sterribly important.
So glad to be a part of that.
Mark (32:52):
I appreciate that a lot.
All right, everybody thatbrings it in to another episode
of the Agile Within.
We'll see you next time.
That brings it in to anotherepisode of the Agile Within.
We'll see you 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.
(33:12):
Just search for the AgileWithin and please spread the
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.
Well, hey there.
Welcome to the Agile Within.
This is Mark Metz.
I hope everybody is having anabsolutely fantastic day out
there.
Today's episode from St Louis,missouri.
(00:49):
I have Tom Holt.
Tom, welcome to the podcast.
Thanks, glad to be here, reallyglad to have you.
I've spent some time in StLouis, but you're the guest, not
me, so I want to know if I hadnever been to St Louis before,
tom and I was coming for a day.
What's one thing that you wouldsay I couldn't miss doing?
Tom (01:12):
Well, I've heard some other people do this.
I'm going to cheat and give youtwo.
Go for it.
One thing that you can't missin St Louis is we have a park
called Forest Park.
It's actually bigger thanCentral Park and it is
surrounded by a whole bunch ofthings that are absolutely free
to go to.
So we have a science museum.
(01:34):
We have a zoo that is free.
We have an art museum that'sfree.
There's a Missouri historymuseum that's free, which may be
not quite as exciting as theother it depends on your bent.
So that's really cool ForestPark.
I would check that out.
The other is a place called CityMuseum, and City Museum is
nothing like what it sounds andit's extraordinarily hard to
(01:55):
describe found, found object artexhibition.
This is like an entire buildingthat is a found object art
installation that is designedfor children and people that can
still crawl on their knees,which I can't.
You can explore it.
There's tunnels.
(02:16):
There's an airplane fuselagethat's attached to the outside
that you can crawl through.
It is the most amazing thing.
I recommend everybody to gothere.
I've never seen anything likeit.
I've traveled all over theplace and I've never seen
anything even remotely like it,so I recommend that highly.
Mark (02:34):
That sounds awesome.
I'm going to get some linksfrom you so we can post it to
the listeners here.
If they're ever in the areathey can visit.
Well, thank you for that.
That's awesome, All right, Well, Tom is the principal
consultant at OtterworksConsulting and before that he
was the head of engineering at afew different startups, and
he's been in technology forthree decades now and counting.
(02:57):
And, Tom, the title for theepisode today is called Taming
the Chaos, and I want to ask youTaming the Chaos?
What's that all about?
Tom (03:07):
So for me, I've been in a lot of situations where I've
come into a startup that hasreached the point where they're
starting to have some success.
They're growing A lot of thethings that they did when they
were small, when they were two,three, four, five, 10 people are
just not working for themanymore and they've created some
(03:29):
people might call them ad hocprocesses.
I like to call them organicprocesses, because they grew up
over time and those organicprocesses are just not serving
them anymore and they'restarting to feel the pain of the
chaos that used to feed thembut now is starting to give them
(03:49):
some pain, right, somedifficulty, as they are
continuing to grow.
So they realize the phrase iswhat got you here won't get you
there.
They've realized that what gotthem here, to this place of
growth, is not going to scalepast where they are right now.
That's my thing is I like tohelp people tame that chaos and
(04:14):
kind of put it in a box andfigure out where to go from
there.
Mark (04:18):
Give us some examples.
What kind of chaos and whatkind of pain are we talking
about here?
Tom (04:24):
There's a lot of different research around this, but one of
the really simplest things andthis is I'll have to kind of
draw a picture for you, sincethis is audio only.
But if you think about when youfirst start off, you know you
might have like a very, verybeginning.
You might have a single techperson and a single other
founder, right, so somebodythat's kind of on the sales idea
(04:45):
side, and you've got somebodythat's kind of the
implementation side, and whenyou have that, the communication
between those two people isjust a single line of
communication.
And so you've got these ideasand they're bouncing off each
other and the person isgenerating code and they're
making things happen.
And then you get a third personin the mix.
(05:07):
Whoever that third person is,when that happens, you now have,
instead of one communicationline, you now have three
communication lines.
Between each of those threepeople there's a communication
line.
So you've got threecommunication lines.
When you add a fourth person,you now have seven communication
lines.
By the time you've got threecommunication lines.
When you add a fourth person,you now have seven communication
lines.
By the time you've gotten toeight, you've got 28 different
(05:30):
communication lines, and at somepoint that just becomes more
than you can handle.
So you need to start beingreally intentional about how you
communicate within that team,that team of eight.
Now, still, you can kind ofhandle it, because, just as a
human being, you've been througha lot of situations where
(05:51):
there's teams of people and youknow who's got what information
by the time you've gone pastthat though, once you get to
double that to 16 or to 32,those just natural ways of
communicating, interacting witheach other, no longer mirror
family relationships or anythingelse that you might have, or
(06:13):
school situations or anythingelse that you might've come up
with in the past, and so youreally need some more structure,
people that haven't experiencedthis or have grown up in this
situation, in this company orthis organization.
But it can cause some actualemotional distress.
I mean, I've been in situationswhere you know, hey, we're all
(06:49):
professionals, but somebodykicked a hole in the wall, right
, because they were angry aboutstuff that shouldn't make you
that angry, right, but it'sbecause you're passionate about
what you're doing.
Maybe you're in a meeting andthings aren't going and you
don't know who's got theauthority to make what decisions
.
Or you don't know, some pieceof information didn't make it to
you and it's just making it toyou now.
(07:10):
We see these kinds of things inall sizes of organizations, but
they really happen a lot inthis transition from small to
midsize.
Mark (07:20):
So communication is important, but you also have
that dynamic of who's in chargeRight and who's calling the
shots.
So when it's two people, likeyou say, you may have one person
that's responsible for sales sothey're interfacing with the
customers and you've got anotherperson that's handling the
implementation.
(07:40):
Maybe they're a technologistand they're handling all that
side.
Maybe they're a technologistand they're handling all that
side.
But as the company startsgrowing, it's hard for either
one of those people to have ahold of everything that's going
on there.
There has to be some pointwhere that starts breaking down.
And it's interesting to findwhere that point really is,
because when you bring otherpeople in, you want other
(08:03):
perspectives, you want diversityof opinion.
Maybe you have to ask theleaders that start are you
really?
Is that really what you'relooking for?
Tom (08:12):
Well, right, and some of the best leaders I've ever been
around and learned from will saythings like if I'm the smartest
person in the room, then I'vehired the wrong people, and so
there is that transition as well, right?
When it's just two of you, Imean, you're both, hopefully,
(08:33):
the smartest person in the room,at least in your realm, in your
area that you're dealing with.
Once you grow to a largerorganization, you're going to
have to give up pieces of theauthority around that expertise
to others.
For example, if you are the CEOof this startup and you've got
the CTO, let's say, let's justimagine that there's two people
(08:57):
and the CEO is doing themarketing, the sales and the
product management, and the CTOhas got a little bit of product
management, is doing all thetechnical aspect and maybe the
customer support as well.
At some point you, hopefully,are going to hire some people to
handle some of those things.
So let's say, you as the CTO,you go listen, doing the
(09:20):
customer support is great,because I get to hear directly
from the customers, but wereally need somebody to answer
the phone when I'm deep in themiddle of some technical flow,
right, so we hire somebody.
And if you don't trust thatperson.
If that person doesn't have theauthority to interact with the
customers and to makecommitments to the customers,
even on the basis of their role,then you're going to have a
(09:43):
problem and that problem is onlygoing to get worse as you go
forward.
So sitting up those kinds ofauthority structures is really
important Not that it has to behierarchical, but people need to
know what they are empowered todo, and that goes into every
aspect of the organization.
I kind of concentrate on thedev team and the people that are
(10:05):
creating the product.
They need to know what they areempowered to do.
This is a podcast that is theAgile Within.
That's about Agile, right?
So within Agile we say that theteam should be as much as
possible empowered to makedecisions that are within their
realm of expertise.
We shouldn't have thatauthority held above them.
(10:27):
But it really, if you thinkabout it, has to go through the
whole organization.
Mark (10:33):
So as the company grows, we need to add some structure,
and the purpose of the structureis so that people are informed,
communication lines are openbetween everyone and decisions
are efficiently made.
But you don't just go from noprocess to very heavy process,
(10:53):
from one day to the next.
Right, what does it look likein making that transition?
Tom (10:59):
That's an excellent question.
The first thing, the mostimportant thing that you want to
establish, is a phrase that weuse a lot, which is
psychological safety.
There needs to be psychologicalsafety within the team.
All the other things you mightgo ahead to do aren't going to
have the impact that you want ifthere's not trust between the
(11:21):
people that are trying to affectthis change and the people that
have to live with the changethat you're doing.
This is going to sound weird,but I start with a retrospective
.
I might start with multipleretrospectives, depending on how
large the team is or how manyteams there are.
There may be a retrospectivethat includes the dev leader and
(11:43):
other stakeholders within thecompany, because maybe they have
some insight into the ways thatthe development organization
has been running that affectthem, and so that's really good
information.
You want to understand that.
Also, within the devorganization, you might have,
let's say, you've got two teamsor three teams.
(12:03):
Now you might want to haveindividual retrospectives with
each of those teams.
So you want to dig into what isgoing well, because there's
probably some things that aregoing pretty well and you want
to understand this.
You don't want to run overthose things.
And then you want to see, okay,what's not going well.
And by not going well, you wantto dig down.
You know kind of the five whys.
(12:24):
It's like these tickets areshowing up, they're not fully
baked.
You're like, well, you want todig into that and understand,
okay, how does that affect whatwe're doing?
Why do you feel like theyshould be different?
And you dig into it.
You need to understand what'sgoing on.
I like to make those things asfun as possible.
Depending on the companyculture, the team that you're
(12:47):
dealing with.
I often will have them off-site.
It takes them out of thecontext of.
A lot of people are remote now,so that's that's a different
thing.
But honestly, if you couldbring them in person to do this,
that is very helpful.
Include some what I callserious fun, some games that
(13:08):
lighten the mood, that takepeople to.
That's just a prescription forany good retrospective.
But that's how I like to start.
And then, once thatretrospective is done, you
hopefully have a body ofknowledge that you have
(13:30):
collected.
Now where do you go from there?
I would pick elements out ofScrum right, just because A it's
really well-documented howScrum works and it's actually a
really simple, relativelylightweight process.
Depends on how far along thecompany is, whether I would
implement all of Scrum orwhether just pieces of it.
If I were going to implementjust pieces of it, I might not
(13:52):
always go in this order, but Iwould probably go with daily
stand-up.
First, always retrospective,because anytime you go into this
situation you want to becontinuously improving.
That's one of your mainmechanisms for continuous
improvement is to involve theteam in it.
The other thing that I want tomake sure any company that's
doing dev work uses is astack-ranked backlog, and that's
(14:14):
a commitment that thestakeholders through the product
owner, if you're using Scrum,or whoever managed that product
manager that's the commandmentthat they need to make to the
team is to give them a sense ofwhat's most important.
Because if you can't tell theteam what's most important, it
is really difficult for them tomake that decision on their own,
and what you're really doing isabdicating that decision to
(14:37):
them, that decision to them.
So I think this is somethingthat I've seen in almost every
company that's going throughthis.
It's like, oh my gosh, we gethalfway through this project and
then somebody comes on and theyinterrupt it.
It's like, well, that's becauseno one has forced them to have
the discipline of prioritizingtheir own inputs to this
situation.
So stack correct backlog putsto this situation.
(14:58):
So stack rank backlog.
And then finally, if all ofthat stuff is in place, then I
might go to a iteration-basedprocess, so a sprint-based
process.
I think those are reallyvaluable, but it's also a
constraint.
There's also a cost to doing asprint versus just a free flow
(15:19):
of work, and that cost is thefact that your work doesn't
necessarily fit into one week ortwo weeks or, god forbid, four
weeks.
However long your sprint is,there's going to be, there's
going to be.
You know, as you're putting therocks into the sprint, some of
the rocks are too big.
You can fall into the trap oflike, well, we'll just squeeze
(15:40):
it in, which is terrible becauseyou you know everybody tries to
do that and we all know howthat works.
Right, you end up not gettingthat last bit done.
Or you have to say we're goingto commit to less, in which case
you've lost some efficiencythat everybody hopes you could
regain, although it's absolutelybetter than trying to do more
than you're actually capable.
Mark (15:59):
You talked about scrum.
They're doing their daily Scrumsor their daily stand-ups,
they're having retrospectives,they have a backlog, but what
happens is it becomes a wishlist and people want to know.
You have all these differentstakeholders, and this is
especially for a startup whereyou're trying to start something
new, especially if you aretrying to retire a legacy
(16:22):
application and trying to createa new version of an updated
version of an application or asuite of applications that are
in the marketplace Everybody isclaiming for I need this, I need
this, I need this, and I'veseen the temptation is well,
we're just going to start allthese things so we can tell
everybody we're working on it,we're working on it, right?
(16:46):
And then people oh, okay, well,I'm happy, they're working on it
.
So what you're telling thatperson is that you're working on
it, and what they perceive itto mean is oh, that means you're
going to deliver it to me verysoon.
But what you're telling them iswe're working on it to get you
off my back, but we're alsoworking on 10 other things that
(17:07):
we're also telling nine otherpeople that we're working on it,
and pretty soon.
You're not making anybody happy, but you're pleasing them in
the short term.
You have to pay the piper atsome point.
Tom (17:18):
It's what I call a pretty lie.
I don't think when peoplesometimes it is intentional, but
I think most of the time whenthe people that say, yeah, we
can work on that as well, I meanthey do it with the best of
intentions.
Wow, yeah, that does soundimportant.
Okay, we'll get started on thattoo.
I mean, the problem is thatfocus is incredibly important.
(17:40):
Okay, we'll get started on thattoo.
I mean, the problem is thatfocus is incredibly important.
There's a lot of research that'sbeen done that shows that the
more that you interrupt someone,the absolute less you will get
out of them.
I think of things in terms ofoperating systems.
Every time you do a contextswitch, you lose a bit of
efficiency, and humans lose alot of efficiency every time you
(18:02):
change from one task to another.
I've seen numbers anywhere from22 minutes to a couple of hours
, depending on who you are.
So the more things you'retrying to do at one time, the
less you're actually going toget done.
But even beyond that, let's sayyou had a team and they had
(18:24):
four tasks that they weresupposed to work on.
Each one of those tasks wasgoing to take, I don't know,
let's say, a week.
There was no efficiencydifference at all.
If that team worked on thosefour tasks in parallel and got
them all done at the end of fourweeks, then you would have no
(18:46):
value delivered during thosefour weeks.
Okay, and at the end of thefour weeks you would have four
units of value.
Let's just make it all reallyeasy.
You say the team's going towork on the first unit and get
it done in a week.
Then, from week one to weekfour, you have one unit of value
(19:08):
delivered to your users, andthen, after week two, you've got
two units of value delivered tousers and after week three
you've now got three units ofvalue delivered to your users.
And then, after week four, youhave the same situation you had
before, except that during thoseintervening three weeks you've
got things that are out there,that are being used and, as we
(19:32):
know, once you've delivered thatfirst unit of value, it gets
out there into the wild, so tospeak.
You will get feedback on it andyou might know that the fourth
unit of value that you're goingto decide to deliver actually
doesn't even make sense to donow.
And it gives you the ability tobe flexible, to be agile,
(19:55):
adaptive to the data that cancome in if you delivered
finished work.
Mark (20:02):
So there is an aspect of these pressures or these
commitments coming from outsidethe team, but there are these,
like you say, the best ofintentions of this coming from
inside the team.
And I have lost track at thispoint of the number of times
I've run this experiment, tom.
But I've had teams that werethinking very, very
(20:23):
advantageously and thinking thatthey could have two goals for
the sprint because the firstone's really small so we can
pull another one in.
So I said, okay, if that's thecase, then we're going to break,
let's say, if we're working ina two week sprint, we're going
to effectively break this sprintup into two one week sprints.
This task that you say isreally small, that's going to
effectively break this sprint upinto two one-week sprints.
This task that you say is reallysmall, that's going to be our
(20:43):
sprint goal for our first week.
So that's like our sprint 1Aand the next sprint is our
sprint 1B.
So we're not going tonecessarily run a retrospective
at the end, but that gives ussome closure so that we can
focus and we're not thrashingbetween the two.
I've never had a team finishthat small little task in that
(21:04):
first one week sprint.
It always carries over and wenever get to the second sprint
goal, absolutely.
Tom (21:11):
Yeah, absolutely.
That's funny that you mentionedthat, because that brings me to
one of my things, which isestimation, and estimation is
just extraordinarily difficult.
My brother-in-law was anestimator for a large
construction firm.
As an estimator for aconstruction firm, you can look
at the blueprints, you can lookat the architectural drawings,
(21:35):
whatever, and you can go okay,this is how many yards of
concrete we're going to need.
This is what a wall looks like.
Whenever you build a wallthat's 20 by 40, it basically
takes about the same amount oftime every single time you do
that.
So he could look at it and gookay, well, this is the
materials we need, run it allthrough a spreadsheet and come
up with the right answer.
And that was his job and he didit really well.
(21:56):
In software, we're alwayscreating something that we
haven't created before.
We're always doing something.
We're always solving problemsthat have a level of complexity
that we really don't know howlong it's going to take.
We can get better at it, but wewill never know exactly how
long something's going to take.
My experience has been thatdevelopers by and large
(22:20):
underestimate, as a rule, howlong things are going to take
them to do and thereforeovercommit and put themselves in
a bind and then also put a bindaround the people that are
expecting whatever thisdeliverable is.
So, whether that's marketing orcustomer support, or the sales
team or whoever it is, which iswhy we do sprints, which is why
(22:44):
we break everything down intosmall, bite-sized stories right,
that the smaller we make thesethings, the easier it is to wrap
our heads around.
But, exactly, you're totallyright.
I can totally attest to whatyou're saying, that when the
team gets overambitious anddecides to commit to more, the
hardest thing to do is to reelthem in, because every external
(23:05):
pressure is like they said theycould do both, man, we want both
.
Give us both right, like youknow.
Mark (23:11):
Yeah, from your stakeholders like your
stakeholders.
Where's the negative in that?
That's right, yeah right.
If we could do two, then whycan't we do three the next time?
Then why?
Tom (23:20):
can't we do three the next time Exactly?
So yeah, that is absolutelytrue.
So focus stepwise incrementaldelivery of value.
I mean that's one of thefundamentals of this paradigm
that we call agile softwaredevelopment.
Mark (23:37):
As most things in life, it's not always black and white.
It's the shades of gray inbetween that make the difference
.
And so, as we measure goingfrom no process to having some
right amount and I'm giving airquotes here.
Right amount of process how doyou know when you've crossed the
(23:57):
line?
That's something that Istruggle with many times.
Is you know we're being toorigid or we're being too loose,
and it seems like you just neverquite get it right in the sweet
spot.
Tom (24:09):
That's a really important thing.
So what I like to do is I startwith as little as possible and
I move until it solves theproblems that we have, because,
you're absolutely right, moreprocess than what you need is
waste.
It frustrates everyone.
There's a few people it doesn'tfrustrate.
There's some people that are alittle OCD and I've known a few.
(24:31):
I'm not one of them, but Imight live with a few who really
just like to have everythingreally well documented and know
where all the things are goingto go.
But for most situations youwant as little process as solves
your problems, as gets thingsrunning smoothly.
As you grow, you will have tochange Once again.
(24:52):
That's why we do retrospectives.
That's why we're continuouslyimproving.
So the amount of process thatyou have in a team of 10, let's
say, just one bigger than apizza team, right, or 11, is not
the same process you're goingto have when you get to 20 or 25
or 30 or 50.
There's going to have to bemore structure when you get to
that size.
(25:13):
But you don't want all thatstructure.
You wouldn't implement SAFE ina pizza team, right?
You'd go, no, no, no, we don'tneed all of that, right.
That's way way too much.
So you look for the pieces thatsolve the problems that you've
got.
And this is difficult becauseit's easy to just take a
framework and just drop it in,because you can go and you can
(25:35):
read the literature around theframework.
It tells you all the thingsthat are part of that framework
and you can implement thatframework.
But if you don't understandwhat each one of those pieces is
there to do for you, for theteam and that's the plural, you
right If you don't understandwhat every single piece in that
is supposed to do for the team,you may end up implementing more
than what you need and you mayactually slow yourself down and
(25:57):
frustrate people who otherwisemight be really in favor of this
change.
But if they find, yeah, but nowwe're doing this thing and we
didn't really need to do thatthing and so it's that that
cynical management's telling usto do this stuff and that's not
particularly useful.
Mark (26:15):
I'll give you a really good example from one of our
past guests, mark Paul Sabral.
He supplied a story that was inreal life, that he was working
with a team and they weregrowing, they were adding more
teams and the team, in one ofthe retrospectives, said, when
we're onboarding these new teams, it really is slowing us down.
(26:35):
And so they started askingthose questions, like you
mentioned, like well, why isthat us down?
And so they started askingthose questions, like you
mentioned, like well, why isthat?
And the team finally camearound to we really don't have
any documentation for newdevelopers that are coming on
the team, so they're having topair with other developers and
that's taking time away fromthem.
So they said we need moredocumentation.
So Mark was really, really Icommend him highly.
(26:56):
He could have just said, okay,that's what we need to do, we
need to create moredocumentation.
But he took it a step furtherand he said, okay, we need more
documentation, but how do weknow that we're putting together
the right documentation?
How do we know that we'reputting together documentation?
That really helps, because, asyou mentioned, that is a form of
(27:16):
waste, but they had somerepository for their
documentation and he couldmeasure how many times each
document was accessed and heshowed the team.
You spent 10 hours putting thisdocument together.
We've had one person read it inthe last three weeks.
Is that really valuable for us?
And that really opened the eyesof the team and they're like
(27:37):
you know what?
You're right.
We thought we should bedocumenting these things, but
developers, when they come in,they really don't need it, they
just need to be to see thisexample or whatever the case may
be.
But I thought that was a veryclever way to go another level
deeper and actually monitor,when you're talking about adding
more steps to your process, toreally seeing are they truly
(28:00):
effective.
Tom (28:01):
No, that's beautiful, and I have a story that's almost the
exact opposite of that.
Mark (28:06):
Oh great, yeah, let's hear it.
Tom (28:09):
I was at a company it was a bit larger company, fortune 500
.
And we were a relatively largeteam.
I mean, it was about 400engineers in the team and we
were working on an importantproduct.
Obviously, every sprint, ourCTO had asked us to create a
document for each feature oreach change that we wanted to do
(28:31):
, and there was a particularformat for these documents, and
each one of these documentsended up being about 50 pages.
Mark (28:38):
And if there's anything, a developer loves it's
documentation, oh right, andthere were about 50 of these
documents being created forevery sprint.
Tom (28:48):
So, if you calculate that out, there was 2,500 pages of
documentation created eachsprint.
Now, mind you, these sprintswere longer than recommended,
but 2,500 pages of documentation.
Did anyone read these?
Well, the answer is I think waymore time was put into creating
them than was put into perusingthem, and the upshot was people
(29:11):
would still deliver things thatwere not what was expected or
wanted, and so it was.
It was absolutely waste, right?
Because, oh well, we just needto document this better, we'll
just make it even more detailed,and it doesn't matter if the
people don't read it.
The other problem withdocumentation documentation is
great, I love documentation isthat if it is not important,
(29:34):
then it will not be updated, andif it's not updated, it is
worse than not being there,because then it's wrong.
And now you have bad data, andwe all know that bad data is
worse than no data.
It's at least no data, you know.
You don't know what's going on.
Mark (29:52):
So, wow, that's an interesting situation.
It's a double whammy.
So you spend time deliveringsomething that isn't used.
But not only that you spendeven more time documenting
something that the customerdoesn't use.
Tom (30:04):
Exactly, and yeah, so, like we said, you know, excess
process.
So in this case, a lot ofexcess process, excess process
from a lean standpoint, is waste, because anything that doesn't
deliver, you know isn't part ofthe chain of things that deliver
value to the user, is waste.
Right, as we try to minimizethat, I like to make sure that,
like I said, the leastresponsible amount of process
(30:25):
that's what I like to deliver.
And you get there by startingsmall and incrementally
increasing until you've solvedthe problems that the team and
the stakeholders areexperiencing.
And once you get there, thenyou stop until you anticipate
new problems arising, andtypically I even say until you
(30:46):
start feeling a little bit ofthe pain, because if you
anticipate, you know people willbuild stuff that isn't
necessary.
You know there's a phrase youain't going to need it, and
that's in the software itself,but it's also in the process
that creates the software that'sin the software itself, but
it's also in the process thatcreates the software.
Mark (31:05):
Well, Tom, the time has flown by here.
We've talked about taming thechaos and feels like there's so
much more chaos that can andshould be tamed.
But trying to stay within ourtime box here, hey, if our
listeners want to get in touchwith you, what's the best way
for them to do that, Tom?
Tom (31:18):
Well, they can absolutely find me on LinkedIn, tom Holt.
My consulting agency that Ijust launched is called
Otterworks, and you can findthat on LinkedIn.
I also have a website,otterworksllccom, and they can
absolutely email me, tom, atotterworksllccom.
(31:38):
Yeah, and I would love to likeif anybody, if any of this,
resonates with any of yourlisteners people that are
starting to experience some ofthe pain of growing and being
successful but, realizing thatthe scaling has kind of got out
of hand, they would like somehelp taming that chaos.
I would absolutely love to talkto them.
They can reach out to me and wecan set up just a free
(32:00):
consultation.
I'll listen to what's going onand in those free consultations
I always give them a couple ofactionable things that they can
do right away, even withoutfurther engagement, that will
help them to progress from wherethey are, to alleviate some of
the pain that they've got toalleviate some of the pain that
they've got.
Mark (32:19):
Free consultation Does it get any better than that?
All right, tom.
Well, we'll put all thatinformation in the show notes,
as always, to make it easy forour listeners there to reach out
to you and to get in touch, tom, I really appreciate you coming
on the show, buddy.
This has been reallyinteresting and fascinating.
I really enjoyed this.
Tom (32:36):
Well, thanks.
I've really appreciated yourpodcast.
I like the way that you thinkabout the softer side of some of
these things, and I thinkthat's something that we as tech
people sometimes miss, and it'sterribly important.
So glad to be a part of that.
Mark (32:52):
I appreciate that a lot.
All right, everybody thatbrings it in to another episode
of the Agile Within.
We'll see you next time.
That brings it in to anotherepisode of the Agile Within.
We'll see you 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.
(33:12):
Just search for the AgileWithin and please spread the
word with your friends andcolleagues.
Until next time.
This has been your host, markMetz.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!