.jpg)
The Agile Within
Providing agile insights into human values and behaviors through genuine connections.
The Agile Within
Taming the Chaos with Tom Holt
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
Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Well, hey there. Welcome to the Agile Within. This is Mark Metz. I hope everybody is having an absolutely fantastic day out there. Today's episode from St Louis, missouri. I have Tom Holt. Tom, welcome to the podcast. Thanks, glad to be here, really glad to have you. I've spent some time in St Louis, but you're the guest, not me, so I want to know if I had never been to St Louis before, tom and I was coming for a day. What's one thing that you would say I couldn't miss doing?
Tom:Well, I've heard some other people do this. I'm going to cheat and give you two. Go for it. One thing that you can't miss in St Louis is we have a park called Forest Park. It's actually bigger than Central Park and it is surrounded by a whole bunch of things that are absolutely free to go to. So we have a science museum. We have a zoo that is free. We have an art museum that's free. There's a Missouri history museum that's free, which may be not quite as exciting as the other it depends on your bent. So that's really cool Forest Park. I would check that out.
Tom:The other is a place called City Museum, and City Museum is nothing like what it sounds and it's extraordinarily hard to describe found, found object art exhibition. This is like an entire building that is a found object art installation that is designed for children and people that can still crawl on their knees, which I can't. You can explore it. There's tunnels. There's an airplane fuselage that's attached to the outside that you can crawl through. It is the most amazing thing. I recommend everybody to go there. I've never seen anything like it. I've traveled all over the place and I've never seen anything even remotely like it, so I recommend that highly.
Mark:That sounds awesome. I'm going to get some links from you so we can post it to the listeners here. If they're ever in the area they can visit. Well, thank you for that. That's awesome, All right, Well, Tom is the principal consultant at Otterworks Consulting and before that he was the head of engineering at a few different startups, and he's been in technology for three decades now and counting. And, Tom, the title for the episode today is called Taming the Chaos, and I want to ask you Taming the Chaos? What's that all about?
Tom:So for me, I've been in a lot of situations where I've come into a startup that has reached the point where they're starting to have some success. They're growing A lot of the things that they did when they were small, when they were two, three, four, five, 10 people are just not working for them anymore and they've created some people might call them ad hoc processes. I like to call them organic processes, because they grew up over time and those organic processes are just not serving them anymore and they're starting to feel the pain of the chaos that used to feed them but now is starting to give them some pain, right, some difficulty, as they are continuing to grow. So they realize the phrase is what got you here won't get you there. They've realized that what got them here, to this place of growth, is not going to scale past where they are right now. That's my thing is I like to help people tame that chaos and kind of put it in a box and figure out where to go from there.
Mark:Give us some examples. What kind of chaos and what kind of pain are we talking about here?
Tom:There's a lot of different research around this, but one of the really simplest things and this is I'll have to kind of draw a picture for you, since this is audio only. But if you think about when you first start off, you know you might have like a very, very beginning. You might have a single tech person and a single other founder, right, so somebody that's kind of on the sales idea side, and you've got somebody that's kind of the implementation side, and when you have that, the communication between those two people is just a single line of communication. And so you've got these ideas and they're bouncing off each other and the person is generating code and they're making things happen. And then you get a third person in the mix.
Tom:Whoever that third person is, when that happens, you now have, instead of one communication line, you now have three communication lines. Between each of those three people there's a communication line. So you've got three communication lines. When you add a fourth person, you now have seven communication lines. By the time you've got three communication lines. When you add a fourth person, you now have seven communication lines.
Tom:By the time you've gotten to eight, you've got 28 different communication lines, and at some point that just becomes more than you can handle.
Tom:So you need to start being really intentional about how you communicate within that team, that team of eight.
Tom:Now, still, you can kind of handle it, because, just as a human being, you've been through a lot of situations where there's teams of people and you know who's got what information by the time you've gone past that though, once you get to double that to 16 or to 32, those just natural ways of communicating, interacting with each other, no longer mirror family relationships or anything else that you might have, or school situations or anything else that you might've come up with in the past, and so you really need some more structure, people that haven't experienced this or have grown up in this situation, in this company or this organization.
Tom:But it can cause some actual emotional distress. I mean, I've been in situations where you know, hey, we're all professionals, but somebody kicked a hole in the wall, right, because they were angry about stuff that shouldn't make you that angry, right, but it's because you're passionate about what you're doing. Maybe you're in a meeting and things aren't going and you don't know who's got the authority to make what decisions. Or you don't know, some piece of information didn't make it to you and it's just making it to you now. We see these kinds of things in all sizes of organizations, but they really happen a lot in this transition from small to midsize.
Mark:So communication is important, but you also have that dynamic of who's in charge Right and who's calling the shots. So when it's two people, like you say, you may have one person that's responsible for sales so they're interfacing with the customers and you've got another person that's handling the implementation. Maybe they're a technologist and they're handling all that side. Maybe they're a technologist and they're handling all that side. But as the company starts growing, it's hard for either one of those people to have a hold of everything that's going on there. There has to be some point where that starts breaking down. And it's interesting to find where that point really is, because when you bring other people in, you want other perspectives, you want diversity of opinion. Maybe you have to ask the leaders that start are you really? Is that really what you're looking for?
Tom:Well, right, and some of the best leaders I've ever been around and learned from will say things like if I'm the smartest person in the room, then I've hired the wrong people, and so there is that transition as well, right? When it's just two of you, I mean, you're both, hopefully, the smartest person in the room, at least in your realm, in your area that you're dealing with. Once you grow to a larger organization, you're going to have to give up pieces of the authority around that expertise to others. For example, if you are the CEO of this startup and you've got the CTO, let's say, let's just imagine that there's two people and the CEO is doing the marketing, the sales and the product management, and the CTO has got a little bit of product management, is doing all the technical 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 customer support is great, because I get to hear directly from the customers, but we really need somebody to answer the phone when I'm deep in the middle of some technical flow, right, so we hire somebody.
Tom:And if you don't trust that person. If that person doesn't have the authority to interact with the customers and to make commitments to the customers, even on the basis of their role, then you're going to have a problem and that problem is only going to get worse as you go forward. So sitting up those kinds of authority structures is really important Not that it has to be hierarchical, but people need to know what they are empowered to do, and that goes into every aspect of the organization. I kind of concentrate on the dev team and the people that are creating the product. They need to know what they are empowered to do. This is a podcast that is the Agile Within. That's about Agile, right? So within Agile we say that the team should be as much as possible empowered to make decisions that are within their realm of expertise. We shouldn't have that authority held above them. But it really, if you think about it, has to go through the whole organization.
Mark:So as the company grows, we need to add some structure, and the purpose of the structure is so that people are informed, communication lines are open between everyone and decisions are efficiently made. But you don't just go from no process to very heavy process, from one day to the next. Right, what does it look like in making that transition?
Tom:That's an excellent question. The first thing, the most important thing that you want to establish, is a phrase that we use a lot, which is psychological safety. There needs to be psychological safety within the team. All the other things you might go ahead to do aren't going to have the impact that you want if there's not trust between the people that are trying to affect this change and the people that have to live with the change that you're doing. This is going to sound weird, but I start with a retrospective. I might start with multiple retrospectives, depending on how large the team is or how many teams there are. There may be a retrospective that includes the dev leader and other stakeholders within the company, because maybe they have some insight into the ways that the development organization has been running that affect them, and so that's really good information. You want to understand that. Also, within the dev organization, you might have, let's say, you've got two teams or three teams. Now you might want to have individual retrospectives with each of those teams. So you want to dig into what is going well, because there's probably some things that are going pretty well and you want to understand this. You don't want to run over those things. And then you want to see, okay, what's not going well. And by not going well, you want to dig down. You know kind of the five whys. It's like these tickets are showing up, they're not fully baked. You're like, well, you want to dig into that and understand, okay, how does that affect what we're doing? Why do you feel like they should be different? And you dig into it. You need to understand what's going on.
Tom:I like to make those things as fun as possible. Depending on the company culture, the team that you're dealing with. I often will have them off-site. It takes them out of the context of. A lot of people are remote now, so that's that's a different thing. But honestly, if you could bring them in person to do this, that is very helpful. Include some what I call serious fun, some games that lighten the mood, that take people to. That's just a prescription for any good retrospective. But that's how I like to start. And then, once that retrospective is done, you hopefully have a body of knowledge that you have collected.
Tom:Now where do you go from there? I would pick elements out of Scrum right, just because A it's really well-documented how Scrum works and it's actually a really simple, relatively lightweight process. Depends on how far along the company is, whether I would implement all of Scrum or whether just pieces of it. If I were going to implement just pieces of it, I might not always go in this order, but I would probably go with daily stand-up.
Tom:First, always retrospective, because anytime you go into this situation you want to be continuously improving. That's one of your main mechanisms for continuous improvement is to involve the team in it. The other thing that I want to make sure any company that's doing dev work uses is a stack-ranked backlog, and that's a commitment that the stakeholders through the product owner, if you're using Scrum, or whoever managed that product manager that's the commandment that they need to make to the team is to give them a sense of what's most important. Because if you can't tell the team what's most important, it is really difficult for them to make that decision on their own, and what you're really doing is abdicating that decision to them, that decision to them. So I think this is something that I've seen in almost every company that's going through this. It's like, oh my gosh, we get halfway through this project and then somebody comes on and they interrupt it. It's like, well, that's because no one has forced them to have the discipline of prioritizing their own inputs to this situation. So stack correct backlog puts to this situation. So stack rank backlog. And then finally, if all of that stuff is in place, then I might go to a iteration-based process, so a sprint-based process.
Tom:I think those are really valuable, but it's also a constraint. There's also a cost to doing a sprint versus just a free flow of work, and that cost is the fact that your work doesn't necessarily fit into one week or two 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 the rocks into the sprint, some of the rocks are too big. You can fall into the trap of like, well, we'll just squeeze it in, which is terrible because you you know everybody tries to do that and we all know how that works. Right, you end up not getting that last bit done. Or you have to say we're going to commit to less, in which case you've lost some efficiency that everybody hopes you could regain, although it's absolutely better than trying to do more than you're actually capable.
Mark:You talked about scrum.
Mark:They're doing their daily Scrums or their daily stand-ups, they're having retrospectives, they have a backlog, but what happens is it becomes a wish list and people want to know.
Mark:You have all these different stakeholders, and this is especially for a startup where you're trying to start something new, especially if you are trying to retire a legacy application and trying to create a new version of an updated version of an application or a suite of applications that are in the marketplace Everybody is claiming for I need this, I need this, I need this, and I've seen the temptation is well, we're just going to start all these things so we can tell everybody we're working on it, we're working on it, right?
Mark:And then people oh, okay, well, I'm happy, they're working on it. So what you're telling that person is that you're working on it, and what they perceive it to mean is oh, that means you're going to deliver it to me very soon. But what you're telling them is we're working on it to get you off my back, but we're also working on 10 other things that we're also telling nine other people 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 at some point.
Tom:It's what I call a pretty lie. I don't think when people sometimes it is intentional, but I think most of the time when the people that say, yeah, we can work on that as well, I mean they do it with the best of intentions. Wow, yeah, that does sound important. Okay, we'll get started on that too. I mean, the problem is that focus is incredibly important. Okay, we'll get started on that too. I mean, the problem is that focus is incredibly important.
Tom:There's a lot of research that's been 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 of operating systems. Every time you do a context switch, you lose a bit of efficiency, and humans lose a lot of efficiency every time you change from one task to another. I've seen numbers anywhere from 22 minutes to a couple of hours, depending on who you are. So the more things you're trying to do at one time, the less you're actually going to get done. But even beyond that, let's say you had a team and they had four tasks that they were supposed to work on. Each one of those tasks was going to take, I don't know, let's say, a week. There was no efficiency difference at all. If that team worked on those four tasks in parallel and got them all done at the end of four weeks, then you would have no value delivered during those four weeks. Okay, and at the end of the four weeks you would have four units of value.
Tom:Let's just make it all really easy. You say the team's going to work on the first unit and get it done in a week. Then, from week one to week four, you have one unit of value delivered to your users, and then, after week two, you've got two units of value delivered to users and after week three you've now got three units of value delivered to your users. And then, after week four, you have the same situation you had before, except that during those intervening three weeks you've got things that are out there, that are being used and, as we know, once you've delivered that first unit of value, it gets out there into the wild, so to speak. You will get feedback on it and you might know that the fourth unit of value that you're going to decide to deliver actually doesn't even make sense to do now. And it gives you the ability to be flexible, to be agile, adaptive to the data that can come in if you delivered finished work.
Mark:So there is an aspect of these pressures or these commitments coming from outside the team, but there are these, like you say, the best of intentions of this coming from inside the team. And I have lost track at this point of the number of times I've run this experiment, tom. But I've had teams that were thinking very, very advantageously and thinking that they could have two goals for the sprint because the first one's really small so we can pull another one in. So I said, okay, if that's the case, then we're going to break, let's say, if we're working in a two week sprint, we're going to effectively break this sprint up into two one week sprints. This task that you say is really small, that's going to effectively break this sprint up into two one-week sprints.
Mark:This task that you say is really small, that's going to be our sprint goal for our first week. So that's like our sprint 1A and the next sprint is our sprint 1B. So we're not going to necessarily run a retrospective at the end, but that gives us some closure so that we can focus and we're not thrashing between the two. I've never had a team finish that small little task in that first one week sprint. It always carries over and we never get to the second sprint goal, absolutely.
Tom:Yeah, absolutely. That's funny that you mentioned that, because that brings me to one of my things, which is estimation, and estimation is just extraordinarily difficult. My brother-in-law was an estimator for a large construction firm. As an estimator for a construction firm, you can look at the blueprints, you can look at the architectural drawings, 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 wall that's 20 by 40, it basically takes about the same amount of time every single time you do that. So he could look at it and go okay, well, this is the materials we need, run it all through a spreadsheet and come up with the right answer. And that was his job and he did it really well.
Tom:In software, we're always creating something that we haven't created before. We're always doing something. We're always solving problems that have a level of complexity that we really don't know how long it's going to take. We can get better at it, but we will never know exactly how long something's going to take.
Tom:My experience has been that developers by and large underestimate, as a rule, how long things are going to take them to do and therefore overcommit and put themselves in a bind and then also put a bind around the people that are expecting whatever this deliverable is. So, whether that's marketing or customer support, or the sales team or whoever it is, which is why we do sprints, which is why we break everything down into small, bite-sized stories right, that the smaller we make these things, the easier it is to wrap our heads around. But, exactly, you're totally right. I can totally attest to what you're saying, that when the team gets overambitious and decides to commit to more, the hardest thing to do is to reel them in, because every external pressure is like they said they could do both, man, we want both. Give us both right, like you know.
Mark:Yeah, from your stakeholders like your stakeholders. Where's the negative in that? That's right, yeah right. If we could do two, then why can't we do three the next time? Then why?
Tom:can't we do three the next time Exactly? So yeah, that is absolutely true. So focus stepwise incremental delivery of value. I mean that's one of the fundamentals of this paradigm that we call agile software development.
Mark:As most things in life, it's not always black and white. It's the shades of gray in between that make the difference. And so, as we measure going from no process to having some right amount and I'm giving air quotes here. Right amount of process how do you know when you've crossed the line? That's something that I struggle with many times. Is you know we're being too rigid or we're being too loose, and it seems like you just never quite get it right in the sweet spot.
Tom:That's a really important thing. So what I like to do is I start with as little as possible and I move until it solves the problems that we have, because, you're absolutely right, more process than what you need is waste. It frustrates everyone. There's a few people it doesn't frustrate. There's some people that are a little OCD and I've known a few. I'm not one of them, but I might live with a few who really just like to have everything really well documented and know where all the things are going to go. But for most situations you want as little process as solves your problems, as gets things running smoothly. As you grow, you will have to change Once again. That's why we do retrospectives. That's why we're continuously improving.
Tom:So the amount of process that you have in a team of 10, let's say, just one bigger than a pizza team, right, or 11, is not the same process you're going to have when you get to 20 or 25 or 30 or 50. There's going to have to be more structure when you get to that size. But you don't want all that structure. You wouldn't implement SAFE in a pizza team, right? You'd go, no, no, no, we don't need all of that, right. That's way way too much.
Tom:So you look for the pieces that solve the problems that you've got. And this is difficult because it's easy to just take a framework and just drop it in, because you can go and you can read the literature around the framework. It tells you all the things that are part of that framework and you can implement that framework. But if you don't understand what each one of those pieces is there to do for you, for the team and that's the plural, you right If you don't understand what every single piece in that is supposed to do for the team, you may end up implementing more than what you need and you may actually slow yourself down and frustrate people who otherwise might be really in favor of this change. But if they find, yeah, but now we're doing this thing and we didn't really need to do that thing and so it's that that cynical management's telling us to do this stuff and that's not particularly useful.
Mark:I'll give you a really good example from one of our past guests, mark Paul Sabral. He supplied a story that was in real life, that he was working with a team and they were growing, they were adding more teams and the team, in one of the retrospectives, said, when we're onboarding these new teams, it really is slowing us down. And so they started asking those questions, like you mentioned, like well, why is that us down? And so they started asking those questions, like you mentioned, like well, why is that? And the team finally came around to we really don't have any documentation for new developers that are coming on the team, so they're having to pair with other developers and that's taking time away from them. So they said we need more documentation.
Mark:So Mark was really, really I commend him highly. He could have just said, okay, that's what we need to do, we need to create more documentation. But he took it a step further and he said, okay, we need more documentation, but how do we know that we're putting together the right documentation? How do we know that we're putting together documentation? That really helps, because, as you mentioned, that is a form of waste, but they had some repository for their documentation and he could measure how many times each document was accessed and he showed the team.
Mark:You spent 10 hours putting this document together. We've had one person read it in the last three weeks. Is that really valuable for us? And that really opened the eyes of the team and they're like you know what? You're right. We thought we should be documenting these things, but developers, when they come in, they really don't need it, they just need to be to see this example or whatever the case may be. But I thought that was a very clever way to go another level deeper and actually monitor, when you're talking about adding more steps to your process, to really seeing are they truly effective.
Tom:No, that's beautiful, and I have a story that's almost the exact opposite of that.
Mark:Oh great, yeah, let's hear it.
Tom:I was at a company it was a bit larger company, fortune 500. And we were a relatively large team. I mean, it was about 400 engineers in the team and we were working on an important product. Obviously, every sprint, our CTO had asked us to create a document for each feature or each change that we wanted to do, and there was a particular format for these documents, and each one of these documents ended up being about 50 pages.
Mark:And if there's anything, a developer loves it's documentation, oh right, and there were about 50 of these documents being created for every sprint.
Tom:So, if you calculate that out, there was 2,500 pages of documentation created each sprint. Now, mind you, these sprints were longer than recommended, but 2,500 pages of documentation. Did anyone read these? Well, the answer is I think way more time was put into creating them than was put into perusing them, and the upshot was people would still deliver things that were not what was expected or wanted, and so it was. It was absolutely waste, right? Because, oh well, we just need to 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 with documentation documentation is great, I love documentation is that if it is not important, then it will not be updated, and if it's not updated, it is worse than not being there, because then it's wrong. And now you have bad data, and we 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:So, wow, that's an interesting situation. It's a double whammy. So you spend time delivering something that isn't used. But not only that you spend even more time documenting something that the customer doesn't use.
Tom:Exactly, and yeah, so, like we said, you know, excess process. So in this case, a lot of excess process, excess process from a lean standpoint, is waste, because anything that doesn't deliver, you know isn't part of the chain of things that deliver value to the user, is waste. Right, as we try to minimize that, I like to make sure that, like I said, the least responsible amount of process that's what I like to deliver. And you get there by starting small and incrementally increasing until you've solved the problems that the team and the stakeholders are experiencing. And once you get there, then you stop until you anticipate new problems arising, and typically I even say until you start feeling a little bit of the pain, because if you anticipate, you know people will build stuff that isn't necessary. You know there's a phrase you ain't going to need it, and that's in the software itself, but it's also in the process that creates the software that's in the software itself, but it's also in the process that creates the software.
Mark:Well, Tom, the time has flown by here. We've talked about taming the chaos and feels like there's so much more chaos that can and should be tamed. But trying to stay within our time box here, hey, if our listeners want to get in touch with you, what's the best way for them to do that, Tom?
Tom:Well, they can absolutely find me on LinkedIn, tom Holt. My consulting agency that I just launched is called Otterworks, and you can find that on LinkedIn. I also have a website, otterworksllccom, and they can absolutely email me, tom, at otterworksllccom. Yeah, and I would love to like if anybody, if any of this, resonates with any of your listeners people that are starting to experience some of the pain of growing and being successful but, realizing that the scaling has kind of got out of hand, they would like some help taming that chaos. I would absolutely love to talk to them. They can reach out to me and we can set up just a free consultation. I'll listen to what's going on and in those free consultations I always give them a couple of actionable things that they can do right away, even without further engagement, that will help them to progress from where they are, to alleviate some of the pain that they've got to alleviate some of the pain that they've got.
Mark:Free consultation Does it get any better than that? All right, tom. Well, we'll put all that information in the show notes, as always, to make it easy for our 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 really interesting and fascinating. I really enjoyed this.
Tom:Well, thanks. I've really appreciated your podcast. I like the way that you think about the softer side of some of these things, and I think that's something that we as tech people sometimes miss, and it's terribly important. So glad to be a part of that.
Mark:I appreciate that a lot. All right, everybody that brings it in to another episode of the Agile Within. We'll see you next time. That brings it in to another episode of the Agile Within. We'll see you next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues. Until next time. This has been your host, mark Metz.