Strategies and Pitfalls of Estimation

About this Episode

In this episode of the Acima Development Podcast, Mike and the panel talk about the intricacies of project estimation, sharing personal anecdotes and professional experiences. Mike begins with a story from his childhood, illustrating how his father's ability to estimate distances accurately influenced his understanding of estimation as a skill that can be developed with practice. He draws parallels between estimating physical distances and estimating project timelines, emphasizing the importance of breaking down tasks into smaller, manageable pieces to improve accuracy.

The conversation transitions to discussing the best practices for project estimation within engineering teams. Matt and Justin highlight the effectiveness of comparing new tasks to similar past projects and the necessity of having a stable team to ensure consistent delivery. They stress the importance of planning in small increments and maintaining clear communication among team members to mitigate risks and handle scope changes efficiently. Mike adds that understanding and identifying unknowns early in the process is crucial for making realistic estimates and avoiding common cognitive biases that can lead to significant project delays and budget overruns.

Towards the end, the team explores the challenges of maintaining estimation accuracy during organizational changes, such as team reassignments and company-wide reorgs. Will raises concerns about the impact of these changes on planning bandwidth and overall productivity. The group agrees that preserving team dynamics and ensuring clear lines of communication are essential to minimizing disruption. They discuss the importance of having documented rules and metrics at every planning level to measure effectiveness and ensure alignment with business goals. The episode concludes with a reflection on the necessity of disciplined planning and continuous improvement to successfully manage complex engineering projects.

Transcript:

 MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I have with me here Will, Justin, Eddy, and Matt. And we're going to be talking today about strategies and pitfalls in estimation. I'm going to start with just a story from my childhood.

We were talking in the pre-recording for a bit about math. I was remembering that my dad used to ask math-related questions to me and my siblings and make a game out of it. Like, he wasn't, like, grumpy, or pushy, or anything. He was like, "What do you think of this?" And then, we'd think about it. This is on road trips. He'd always do it on road trips. Like, that's the only time I ever remember this happening [laughs]. You know, you're on a road trip back in the long ago era before there was internet in your car [laughs]. And you had to do something to fill the space.

I remember that there was mountain ranges, and he'd pick a landmark. You know, there'd be, like, this mountain. "How far away do you think that is? Guess." And my dad was always right. And all of us were wildly wrong [laughter]. He was always really close. My dad's a carpenter. He's very, very good at recognizing distances. Like, he can look at something 15 inches long. He'll look at it and say, "That's 15 inches [laughs]." And he's right. You know, he's as good as a ruler [laughs].

He's just really good at that perception, you know, distance perception. But it applies even to larger scales. So, you know, he'd say, "How far is this away?" And I'd say, "Oh, that's three miles." And my sister would say, "Oh, that's two miles." My dad would say, "Oh, I think that's 13 miles." And it'd probably be, like, 12.5 [laughs]. And it's something that you have to work on. I've seen this.

Most people, you ask them, you know, "How long is three inches?" And they don't know because they don't work with it every day. Like, how would you develop that skill unless you're a carpenter [laughs], right? Unless you're practicing with it many times a day. And estimation of how long something takes, I don't think, is any different than that. It's something that can be developed as a skill, but it's hard. And it's especially hard when we're doing that with projects that you're working on.

You don't see the mountain out there, right [chuckles]? So, you don't really have a good landmark. You're basing it on where you think the landmark's going to be. So, you're not just guessing how far is the landmark, but you're guessing where that milestone is. And it makes for a really difficult problem that hits some of our cognitive biases really badly. And we just get it wrong over and over and over again. So, that's kind of framing of the problem.

Just in general, distance estimation is a tricky problem that you have to develop as a skill and estimating projects. And I think this, you know, we're talking about engineering, but it probably applies to other kinds of projects as well. It's a hard problem because the scale is hard to gauge, and, again, it hits some of our cognitive biases.

WILL: So, I've got a question for you guys, maybe for the group, right? Like, in your experience, right? We've got some miles under our belts. What's the best situation in terms of estimating projects and delivering on those estimations consistently that you guys have all individually experienced firsthand, not somebody that you read about in a book, or a friend's thing, or somebody's plan? Like, what's the best setup that you've had yourself?

JUSTIN: So, the best way for me to estimate something is to get asked to do something that I've done before.

[laughter]

WILL: No, no, no, no, no, no, no. Hang on, hang on, no, no, I'm talking about, like, the best setup, like, doing the work. The best setup where you've been like, "Hey, we're going to have to do this thing." And you're like, "Okay, I'm going to do this thing," you know what I mean? And, like, "I think it's going to take me six weeks." And it takes you, you know, only eight, you know [laughter], or whatever it's going to be, like, the best system that you've worked in yourself.

MATT: I find what works the best for myself, anyway, is to do a comparison on something I've done that's very similar in nature. You know, you have that mountain that Mike spoke about, and it's a lot easier than just conceptualizing it. If you can relate it to something else, then it's a lot easier to break down into the problems. And I find the smaller you can break those problems down, and if you can estimate the problems one at a time, then you have a really good idea of what the larger scope is going to be. That's where I've had the most success.

WILL: Have you had the opportunity to consistently work in that fashion? I mean, like, has that been, like, an ongoing experience for you, or is just, like, what you would like to work on if you could but you can't?

MIKE: I've seen this on teams I've worked with and teams I've worked closely with. And Matt hit on a few of the things that are critical. First of all [chuckles], you have to break it down into small, discrete pieces that are small enough you can wrap your head around them. That is absolutely critical, and that is not free. It takes time.

You have to break down the work into a map and, you know, say, "I'm going to do this, and I'm going to do this, and I'm going to do this." When I say "I," a collective I, you know, the we. We're going to do this, and we're going to do this, and we're going to do this. And, you know, we usually use story points in software development, which is this unitless measure, right? You say, "This is how complex it is." And if there's anything above a three, then you're not good. It has to be small, discrete projects that somebody can say, "Oh yeah, I know how to do that."

Unless you've broken down everything into, I know how to do that, and they're in order, then you're going to be off. And if you do that, though, if you have everything broken down into, like, nothing bigger than size three, and you have a team that you've worked with before, because unless you have some sort of history to know how...you have to have a history. There's a big caveat here. You have to work together as a team for a while so that you know what you can do as a team over time in terms of those points. Then, it tends to land very close. Maybe not exactly perfect, but on average, pretty good.

WILL: I agree with all of that. And you can't mess with the scope midstream.

MIKE: So, you can't change the team. You can't change the scope. Those have to be fixed. You change the team, well, now you've changed the dynamics, right? You've changed the dynamics of how you work together, and work gets done as a team. It doesn't get done as individuals in that way because the team dynamics are relevant. So, you have to have a stable team. And, yeah, if you change the scope, well, that has to be planned just like everything else, and it has to be additive to it.

MATT: Scope changes will happen, but if you tackle them the same way you tackle the initial problem, then you can also estimate, hey, it's going to add X number of weeks to this particular project, right? Or whatever piece of time that is. The key is small, workable pieces.

JUSTIN: Clearly identifying the unknowns.

MIKE: Well, if it's unknown...so, I'm going to dig a little bit more on that because I think it's critical. Identifying the unknowns, that's not a one-liner [laughs] because...so, I mentioned that, and I said this when I was talking about it, you're measuring the complexity. I don't think the story points should ever be used to measure time when you're estimating. They're not a measurement of time.

MATT: Absolutely not.

MIKE: They are a measurement of complexity. And if there is unknowns, it's not truly estimable because that means that you don't understand the work yet. Like, the rules for this plan, right? This only works if you can do everything that I said, which is that you know what those pieces are. I mean, you don't know exactly what you are, but you can wrap your head around it, right? And you know what you can do. If there are unknowns, that means that you haven't refined it down enough. And it's a measurement of complexity. As for those, you'd bump it up to, like, eight or, you know, something outside of what your boundaries are. Because unless it's down to three, then you don't really know. And here's a critical reason why.

I read an article about this, and I don't have it up in front of me, years ago, but it's brilliant. It says that we're very good at estimating the median time to finish, but the mean is way higher than the median. So, if you line up all the projects, and you pick the one in the middle, we're pretty good at that. So, talking about these cognitive biases, we're actually pretty good at picking that one.

The problem is the complexity is very non-linear, and we have a hard time wrapping our heads around non-linear things. So, anything to the higher end of that median doesn't just go up linearly. It goes up exponentially or worse. So, the projects that are harder, that are worse than that median, might be ten times worse, or a hundred times worse, and so they drive the mean up really high. And then, you have a project that's three years late and over budget because it's really hard to predict where those unknowns and complexity are going to land.

MATT: And you can't predict things that aren't known. That's the whole thing. Generally, yes, you're going to bump into a few unknowns. Part of it is trying to account for a rough percentage in your complexity. I mean, and it's really, I would say, experience. There are certain things that you encounter often. You just really have to think through and understand your problem to be able to accurately represent it.

JUSTIN: Yeah. And it's almost like going back to what you said, Mike, you've got to resolve those unknowns before you can give an estimate, and so that's separate work. It's, like, a spike to resolve the unknowns.

MIKE: Yes, absolutely. Listeners can't see this, but I just posted in our chat together. There's an xkcd comic that I think is fantastic. Boss is coming in, talking to the developer. He says, "User takes a photo. The app should check whether they're in a national park." She's like, "Sure, easy GPS lookup. Give me a few hours."

JUSTIN: [laughs]

MIKE: He says, "Check whether the photo's a bird." She says, "I'll need a research team in five years [laughter]." In computer science, it can be hard to explain the difference between the easy and the virtually impossible, and that is so true. And there's this thing that things that are easy for humans are hard for machines, and vice versa. Like, yeah, fold the laundry, sure, I'll do that in five minutes. Have the machine fold the laundry? Good luck [laughs]. Good luck. In your mind, that little mental shortcut that says, "Oh yeah, then I'll do the next step," may not map very well to how you actually make that happen.

JUSTIN: As an aside, that comic, the second comment from the lady programmer, says, "I'll need a research team in five years." Nowadays, it's like, "Let me make an API call to ChatGPT." It's done in five minutes.

MIKE: Well, what's even better is the [inaudible 11:24] message, which, [inaudible 11:27] xkcd is perfect. It says, "In the 1960s, Marvin Minsky assigned a couple of undergrads to spend the summer programming a computer to use a camera to identify objects in a scene. He figured they'd have the problem solved by the end of the summer. Half a century later, we're still working on it [laughter]." That's how it goes.

WILL: So, I'm curious, what is this, like...so, this is an organizational problem, and I think we all sort of, more or less, like, understand, like, how to manage this, right? But on an organizational level, it's really, like, sort of, like, interfacing with, like, the broader teams and, like, where's it gone right and where's it gone wrong and how. Because I myself, like, I've experienced some pretty functional teams in that regard in that, like, you know, we come in with, like, sort of a product plan. We plan the tickets before the sprint starts. We hold to the sprint scope. We plan everything out. Boom, boom, boom, right down the line. And we do MVPs, things like that.

And, you know, I mean, I'm sort of, like, experiencing right now in real time a degradation of that process, where product doesn't want to come into the sprint with a defined scope. Our product wants to give me...they want us to start work when I don't have, you know, a Figma design document that tells me where all the buttons are going to be and what they might want to do, you know what I mean?

I'm going out, and I'm developing the frontend when there is no backend at all. And I'm sort of like, and I'm like, "Well, do you have a schema for what the backend might eventually look like?" "Well, not really," you know what I mean? You could work on all that kind of stuff, but it increases [inaudible 13:16]. It increases rework, inefficiency. And, quite frankly, like, it really kind of pisses me off, you know, like, where, like, I have to, like, my job gets three times harder because people couldn't be bothered to, like, you know, make an effort at the outset of the project. Now I'm kind of curious about, like, sort of like, I've seen it go good and, like, where you've seen the process break down and how.

MIKE: You just hit on, like, all the failure modes, right [laughter]? Requirements not gathered before the work starts. Now, in the real world, sometimes you don't know everything. But, like, you should at least have the overall direction defined so that...certainly, by the sprint, you know what you're going to be working on. If you don't have the requirements, that's just a recipe for burnout and over budget, over time, over everything.

And cross-team, you talked about different teams that are not in alignment. And you're like, maybe the backend's not working yet, but the frontend is. And so, now you have all the misalignment between teams, and getting those coordinated is always, like, the hardest part [laughter]. And this sounds like you're also talking about some team dysfunction, where people are like, "No, I don't feel like doing that." Like, you don't have the sense of collaboration between the parties. And, man, if you don't have engineering and product working together, you're in for a world of hurt.

And why does this happen? I think it tends to happen for the same reasons repeatedly is that unless we're working at non-profits, and I think it even applies there, I mean, we're trying to make money, or, you know, we're trying to maximize our utility, and something comes up. They want to get it done. They being leadership at some level, wherever that is, it can happen at any tier, wants to get something done. And you don't have a great process for aligning that to reality. Then you're going to have more than you can get done.

And there's going to be this misalignment of reporting because you said, "Oh, I gave a prediction." But now you've added to the scope. You've thrown some other things in there, or you changed the team. You've done a reorg. Whatever it is you've done, you've broken the rules. And when that happens, things get out of kilter, and it's hard to get them back because you need to make a conscious effort to say, "No, we can't do this." The only way this works is when we follow all the rules. And there's a lot of times when somebody is going to not want to follow those rules. And it's hard to explain why those rules are important. It involves math and [laughter] discussion, yeah.

WILL: I mean, I suppose so, and I agree with what you're saying. But, I mean, like, I'm a lot more interested in sort of the fundamental psychology of, like, the planning. And the reason I'm sort of most interested in it is because if we were all sort of, like, very rational, logical actors, even on an upper management leadership level, the better you plan the stuff, the more efficient things run. And, honestly, I mean, like, really spending time in investing up front in your product planning and development that will make you more money.

We do better when we're very, very, very deliberate about when, where, why, and how we're taking on projects. That lack of discipline, like, it not only hurts, like, sort of the engineering efficiency, but, in my view, it's extremely hazardous in terms of, like, business impacts.

JUSTIN: So, Will, I mean, you're going more towards the clearly defined problems and everything, but, classically, that's called, like, the waterfall solution, which is a bad word these days, right? So, where do you draw the line between planning everything and planning just enough?

MATT: But planning being the operative word here, right? You can be extremely agile. You know, I've worked where we were extreme programming weekly sprints. We planned every single week. We had our work ready every Monday for that week. You can break problems into smaller problems and then just plan those smaller problems. But you do have to have a really good idea of what the primary problem is, right? And the thing you're trying to solve for and your ultimate goal. But once you understand that, you can break it into small problems, and then you plan pieces at a time, and you can be super effective.

WILL: I do agree that, like, waterfall is a dirty word, and it should stay one, frankly. Because where I see things go, like, most badly, is shipping these grand visions versus tiny, little, agile, incremental pieces. Maybe analogize it with the sort of, like, the Apple iOS grand reveal of the new version of their operating system. Versus maybe, like, the Google Android, like, things are coming out all the time. Like, what's even the current version?

JUSTIN: [laughs]

WILL: Is it Oreo, or Nougat, or Zeta [laughter], or whatever? I don't even know. Like --

MATT: But do you care?

WILL: Come on, who cares? Stuff's coming out just helter skelter pelmel, all the time, right? Versus, like, this, like, this grand, like, unveiling that happens once a year. It's cool that Apple can pull that off, you know, but, like, --

MIKE: Will, do you think that, internally, they're actually having a grand pull-off? Or do you think that they're doing the same thing that Android is doing and they're just tidying it behind the scenes doing these incremental builds, and when they finally have it ready, then they push it out? I think it's the latter. Like, I think that --

JUSTIN: Yeah, I think it's the latter, too.

MATT: Yeah, I mean, when you're incremental, you're mitigating risk.

MIKE: Exactly. There's huge risk when you're doing it. So, there's aerospace example, and it's easy because it's big, expensive projects people know about. There's the Space Launch System recently launched successfully. After years, you know, they finally have a launch. I don't think they...[laughter] they, like, don't even launch a real payload, and it costs, like, two billion dollars, or something, just to launch, not the development but, like, the launch costs that. And then, I read the other day that one of the SpaceX rockets, the Falcon 9, did its 20th launch, reused, like, the same rocket, launched its 20th time.

[laughter]

And, you know, I'm sure it costs some millions, but orders of magnitude difference in price. And SpaceX has blown a lot more things up, but they did it on purpose because they said, "We're going to do this incrementally, and we're going to start small. And we're going to iterate." And now they're just the steamroller that is launching more rockets than, like, all of the nation states put together.

MATT: They're miles ahead.

JUSTIN: Yeah, if only they weren't led by a crazy guy, but anyway.

WILL: Well, you have to be crazy.

MATT: That's why they are so successful [laughs].

WILL: Because, I mean, like, there's...I --

JUSTIN: Okay. So, at the start, he was crazy, but he was focused on his stuff. Now he's crazy and focused on other things; at least, that's what it seems like.

WILL: A lot of those guys are difficult people. Steve Jobs, God rest his soul, [inaudible 20:24], you know what I mean, had his halo shined considerably in his death. And, at the very least, he was disciplined enough to keep his mouth shut and most of his sociopathic behavior behind closed doors. But, I mean, like, the stories abound of that guy doing terrible stuff, and he never really stopped. His PR team got better, but, like, he was a jerk till the day he died. God bless him, you know?

MIKE: One thing that they have in common, though, is that they honor the engineering process. And I'm not going to even touch Elon Musk as a person, right? That's a topic I'm just not going to bring up here. But he came from the software world and brought that engineering process and cultivated it among engineers.

MATT: That is very true.

MIKE: It really doesn't matter about him, right? What he brought was the process. He brought the agile engineering process with him from software world and just applied it to aerospace, and it works. If you do it, it works. If you don't do it, a recurring theme here, it doesn't work.

WILL: I think it is a validation of that process, you know what I mean, in a lot of different, you know what I mean? You're moving that into other industries and avenues, provided that it is permissible to explode the rockets, and there's nobody [laughter] on them.

MATT: And we all agree, waterfall, bad word. But I would argue a waterfall process is better than no process at all.

MIKE: Sure. So, I think a lot of people they think, Agile, hey, we don't have to plan anymore.

JUSTIN: [laughs].

WILL: You can't be farther from the truth.

MIKE: Exactly. All you're doing is you're tightening your planning loop, right? You're tightening your feedback loop. And instead of doing all of your documentation upfront when you know the least, you are choosing to actively plan, and document, and iterate the whole time. So, instead of doing it once, you never stop doing it. And if you think that being agile means, oh, wait, you know, I'm just not going to plan at all; we'll just wing it, then you're missing the whole idea, which is that these interactions, the communication is hard, and that interaction is critical. And you need to have interaction with your hardware, with your stakeholders, with your software. You know, you're testing it. You are evaluating it. You're improving it continuously rather than once.

And it's actually more planning work in the end because you're doing it along a line. But because it's distributed, it's more efficient because you're doing it when you have the most information, which is after you've already done some of the iterations already.

MATT: And it becomes easier with experience because then you have that association. If you've been doing this for a while, which all of us have, there's very few problems that we have never seen before. They just are in a little different context. But, generally, it's the same problems over and over, and we know how to solve them. I think --

MIKE: You're taking text out of the database and transforming it and showing it to somebody?

MATT: Exactly [laughter]. It's only data, right [laughter]? But, you know, there are new things coming out, AI, for instance. GenAI is new to a lot of people, and we're going to learn that as well. And it may be a little harder to plan those technologies because we don't have the experience yet. So, we may not be as accurate with our estimates on those types of projects. But, for the most part, most of the work we're doing, we have done before in some form. And if you break it down, isn't any different than other problems we've already solved.

JUSTIN: So, I do want to add a caveat to that. Well, not a caveat, just, like, an addendum. It's interesting the organizational changes that are happening within Acima, right? Well, Upbound, right? And last year was, like, a record year for Acima and RAC. And this year, we've got a big organizational change where teams are shifting. Directors are shifting. Product owners are shifting. There's a lot of moving parts here. And I'm afraid that they're going to expect the same record level production from an engineering standpoint that they had last year this year because it's, like, oh, we're reorganizing in a more efficient manner. That means we're going to do even better. And it's like, maybe long term, but that short term is really going to suck.

MATT: Well, and maybe it's up to us, right? Well, it is up to us. I really think, just highlighting what I just said, if we look at it as these aren't different problems; they're the same problems, whether I was on Team A or Team B, I'm still facing the same types of problems today that I was yesterday, and we approach it in that manner, I think we can be absolutely as efficient. Change is hard for people. When you are shifting so many things around all at one time, it's up to us to kind of get our bearings and have that compass to remind us that we're still doing the same thing.

MIKE: Well, there's a couple of things that need to happen. First of all, we should work very hard to preserve team boundaries where we can. Like, let's not disrupt high-functioning teams. Second, leadership needs to be focused on using this as intended to improve lines of communication and not just change them. You know [laughs], let's just shuffle things around, and it looks better on a whiteboard. That's just going to slow us down.

If we see that there were...you know, in a large organization, there are difficulties with communication; of course, there are. And if we reorganize to try to improve that while allowing the engineers to keep doing their work with minimally disrupting the teams, then we could actually become more effective. But that is a, you know, to Matt's point, it's up to us. Like there is a decision point here, and we have to be aware of that destination. We have a choice, right? We make things better, or we make things worse.

WILL: So, I mean, in regards to, like, sort of, like, these major, like, company-wide reorganizations, how do you account for and even measure sort of, like, impacts of the reorganization, right? Like, impacts on sort of, like, planning bandwidth, right? I mean, you've got people who are, like, coming up with a plan for the next sprint, writing the tickets, like, measuring the stuff out, right? And so, like, they have a certain amount of planning that they can do, right? And that's affected by their familiarity with, like, their operating environment, right?

Like, you bring a manager into a brand new team. They haven't touched any of the code. They have, you know, a certain amount of planning bandwidth, right? And, like, that's going to be constrained by them getting up on the stuff, right? You have a new team, right? Okay, you know, like, you don't want to disrupt high-performing teams. But, honestly, like, maybe you do want to give your A players your biggest impact priority work, right?

So, you move those people in, and they have to acclimate, right? How do you account for impacts of reorganization? Because this is something that I have seen as well. You know, the large retailer that I work for they love their Q1 reorg. They love, you know, rearranging the furniture. But they're going to have a cost, and I don't know that the cost is accounted for organizationally.

MIKE: And because it's hard to measure, it doesn't get measured, and --

WILL: If it doesn't get measured, then they can't plan for it, you know what I mean? Upper management, you know, those executives that are sort of, like, rearranging the furniture they don't have that. Do they have that in their heads? Do they have it in their mind? There's a cost. We've all felt it.

JUSTIN: I think you treat it as you would, you know, you're onboarding any new member to your team. This is something that happens all the time with engineering teams. People leave; people come in. And you have to get to know this person and, you know, put them through the same onboarding and really get to know their capabilities and stuff. And so, I think your estimates are going to suffer a little bit until you've had a couple of sprints with them. You treat that as an unknown, and make sure you communicate that up. That's kind of what you would do at the team level.

And then, I would think that the folks in the engineering leadership, if they make changes at team levels like that, they just need to get those lines of communication going such that you can set expectations and really understand, "Hey, we just on-boarded two new people, you know, our estimates are going to suffer for the next sprint or two. And then, we'll be able to give a more accurate estimate after that."

MIKE: And there's that bigger question. What metric can you use to measure, aggregated across teams, across an organization? What metric can you use to capture effectiveness as you're doing a reorg? Because we know every metric captures a slice of something and has its own biases. So, what would be an effective metric? Does anybody have an answer to this? What's an effective metric to see how...when you do a reorg, what do you use to measure it? Did this work?

MATT: Velocity over time. I mean --

MIKE: The tricky thing is velocity is team-specific. You rearrange all your teams, velocity changes. If you measure that, then everybody's going to say, "Oh yeah, we're just going to have..." this is five points. That's not three. That's five. Like, you're going to bias it toward higher story points, and velocity ceases to become effective as a number. So, it's hard to measure that precisely. And business initiatives aren't exactly equal to each other. So, you can't necessarily say, "Oh yeah, we've done five initiatives per year [laughs]." It's a tricky problem.

JUSTIN: Yeah, I think if you had an answer to that, you could write your software engineering estimation book, Mike, and retire on that, so...

[laughter]

MIKE: But it's not a new problem. It's not a new problem. Everybody's dealing with it. And then, we fall into these gut, you know, we don't have an answer, so we just kind of look the other way and go with our gut and don't measure it very well. And then, maybe you have your annual reorg [chuckles] that does more harm than good.

WILL: Well, I mean, I don't know. I mean, I feel like you ought to have, internally, a general rule of thumb for, like, okay, if I have a new hire, this is what I expect the onboarding to look like. At week 1, I'll get X. At week 5, I'll get Y. At week 10, I'll get Z, right? Like, you'll have an arc of their productivity, at their level, right? Like, you know a junior will onboard. You know a senior will onboard, you know, et cetera.

And then, like, I think you should probably also have, like, a rough idea of what an internal transfer is going to look like, right? Like, if I move from, like, you know, Team A to Team B, it's not going to look like a new hire, you hope. Although, depending on the team, you know what I mean? Like, I know I'm familiar enough with Acima that there's some teams that you don't just, like, walk into [laughter].

MIKE: One does not simply walk [laughter].

WILL: One does not simply walk into a --

MIKE: An underwriting -- [laughs]

WILL: Yeah, underwriting. Yeah, underwriting.

MATT: Or the [inaudible 31:48] service.

JUSTIN: [laughs]

WILL: Oh no, that one is fine. Like --

MATT: Oh yeah, you worked on that team.

WILL: Yeah, the Haskell. The Haskell, the Haskell folks, you know what I mean? Like e-comm.

MATT: Oh, Lambda.

JUSTIN: Lambda. Yeah.

WILL: That one's there. You know, there's stuff you don't just walk into. So, like, you have that, right? Then you say, okay, reorg. Then I have, like, X number of, like, people moving teams, and probably the same for managers, although, I mean, I will say that, like, I don't think we think enough about management sort of, like, the bandwidth, right? You know, like, we spend a lot of time thinking about, like, okay, coordinating engineers, right? But, like, management bandwidth in terms of planning bandwidth I think it's, you know what I mean, I think it's a little bit unsung. We have a general feeling for, you know, how many engineers a manager can be sort of overseeing, but beyond that, it gets pretty mushy, wouldn't you say? Or am I wrong?

MATT: No, I think about that every day. I'm new to the management team over here on the Upbound side. And it's true that bandwidth gets spread a little thin, right? And that's part of being able to organize your team, having the right people to lead those teams. And everyone has been on...well, not everyone. But a lot of us have been on very large teams versus, like, 3-to-5-member team and seeing the difference in efficiencies, right? And how those teams are managed.

And, ideally, smaller teams, in my opinion, are better. So, you need to do that with management as well and whether there's levels. We have a new concept here at our company of delivery managers. And they've kind of taken over a lot of that responsibility to kind of help spread that bandwidth for planning and let people focus where they should be focused. That's the way think about it.

MIKE: So, we've wandered far and wide here a bit [laughter] as to...we started, like, well, yeah, we know what it takes to run a team well. And then, we started getting into all the complexities when you increase in scale, you know. You go to the next tier, and you've got managers and managers over managers over managers, and it can fall apart. Because, at any place in this hierarchy, if somebody isn't paying attention to the rules, then it can fall apart.

It seems to say something about what you do to run an effective engineering organization is that everybody has to be aware of what the constraints are, be upfront about them, and be willing to stick to some simple rules, right? The planning happens. It happens every time. Every time you can. You don't give it a short shrift, you know; you keep on it. And you don't skip it at any tier.

You know, up at the top level of management, you know, they have to make some estimates based on incomplete information. That's something we all have to do. But they do everything they can to follow the best process they can: gather the information, make the best estimates they can with the information. It has to be all the way down. And then, you have a really well-run organization, right?

WILL: Mm-hmm. Is there [inaudible 35:06] where, like, people who are just sort of guessing, because the company...and what I mean by that it's like, sort of if you say, like, okay, I've got a corporate, let's call it, like, five-year plan, right? Which is not a crazy thing, like, you don't get a business corporate, you know, strategy kind of a thing, right? But on a software, you know, estimation sort of a thing, that's [laughs] a joke. That's comedy, you know what I mean? Like a five-year, like, I can't plan that, you know what I'm saying? And so, it does need to be done on some kind of level, right? Where does that transition happen, and how?

MIKE: There's a really good thing that we've done for a few years now that's spreading throughout the organization, which is that we recognize explicitly that there are tiers of planning. You can map these to a couple of really useful things. You can map them to groups of employees, or you can map them to Jira issue types. And it works either way. So, tier one, you know, planning level one is what the executives do, and it's associated with an initiative in your project management software.

Tier two, planning level two, is associated with milestones within that initiative. I'm going to expand to Columbia, so I've got an initiative. And then, when it comes to milestones, well, maybe you need to negotiate with the government contracts, you know, maybe you need to build some sort of new tax integration. You know, figure out whatever those pieces are. You're developing the milestones, right? But now you have something that's a bigger shape.

And then, there's a tier-three level of planning. Now you're talking with your team leads. Those team leads are breaking this, and that's associated with, like, an epic in your project management software, where now you're coordinating between teams. You know which teams are going to be working on it and where those boundaries are, you know, who's going to be working on what.

And then, you have a tier four, you know, planning level four, which is within the team. That's your refinement, your sprint planning, and so on, where now I know what my team needs to do, right? So that I know what those boundaries are. And I have the epic, so I know what the overall story is I need for my team. Now, I need to break that down into the two and three-pointed stories.

And that works really well because, at every level, you're doing planning based on the information that you have. And you recognize that the accuracy of that planning goes up dramatically as you go from levels one to four. By the time you've done a level four planning and you've completely pointed something out, you know, you can say pretty well when that's going to land.

When you're just at the initiative level, you're like, I'm going to expand into Columbia, right? You really don't know. You really don't know very much, but you know something, right? You know something. You know that that is a business priority that you can shuffle around with other business priorities and say, "Well, this is something I want to do first. And I can start to gather information on it.

WILL: Well, okay, sure. But, I mean, like, so, like, you know, a company like the size of Upbound, right? It's a public traded company. They need to have, like, sort of, like, forward-looking projections about, like, when is this stuff going to land, you know?

MIKE: Yes.

WILL: And what are the business impacts and, like, because, like, because they're beholden to their shareholders. Their shareholders want regularly scheduled updates about, like, okay, you've got an initiative. When am I going to get the initiative? And, I mean, like, is the best we can do on these initiatives just sort of, like, we've done it before and this is about how long it took, you know what I mean? Like, where it's like, okay, you know, I did this, you know, when I expanded into Cincinnati. Like, this is what I got and how. And if I'm doing Columbia, then it's going to be, you know what I mean, ten times harder than doing Cincinnati, right? Like, you got a whole other regulatory language business entity, et cetera. Like, is that the best you could do?

MIKE: Well, I think you can even put time frames on here. So, I'll say, also, that this map roughly to divisions of time. Annual plan, initiative. Quarterly plan; it may be milestones, right?

WILL: Right.

MIKE: And then, you can slot your epics, perhaps, into months. And by the time you get to your stories, you can get that down to about weeks. It kind of maps loosely. Again, this maps to some of these divisions. The precision you get gets more specific. And, generally, at the executive level, you're usually communicating at an annual or a quarterly level. You say, "Well, this year, we intend to expand into Columbia. By quarter three, we expect to be operational at some stores," and so on. You know, you speak in those kinds of broader periods, right? Your resolution is a lot less fine-grained, and that's okay. That's actually expected.

WILL: How do you enforce discipline? I mean, I know, like, on the tier 4 level, right? You're sitting like, okay, I want two or 3-point tickets, right? Like, I want two or 3-point tickets. I want, you know, that's all I want. And, like, if you're doing five or, God help you, an 8 [laughter], you know, things are probably going to go bad, right? And I see how that fundamental process it's got to scale up. But it's a lot less clear how you enforce it, you know, as you go from tier 4 to tier 3 in planning or tier 3 to tier 2 planning or tier 2, God help you, to tier 1 planning. How do you keep a lid on that? Well, because it matters. Like being off by a quarter, that's a big problem.

MIKE: Right, right.

MATT: It is a big problem.

WILL: And for a tier 1, being off by a quarter is actually doing a pretty good job, in my opinion.

MIKE: I agree.

WILL: You're delivering an initiative, and you're only off by a quarter? Not bad, y'all. Not bad.

MIKE: [laughs]

WILL: You know? Like...

MIKE: So, one thing I think you can do...and we talked about the rules down at tier 4, right? That's what we think a lot about. But there's no reason you can't have documented rules at every tier. This is the output. This is the data that went into it. And these are the requirements. Like, you don't say that this initiative is going to get done this year, and unless you have done this, this, and this [laughs], being off by a quarter, that's...it's going to be hard to be within a quarter resolution.

But you can do the things, the executive things [laughs] that executives need to do: gathering information, delegating that out to people that you trust to go and gather the necessary information, and establish a culture that demands honesty and rewards it, rather than one that rewards saying, "Yes." I mean, there's things that can be done there. And now we're getting into business management.

To bring it back to the beginning, we've all got some landmarks we're trying to move our way towards. Hopefully, this has provided some food for thought, how to better figure out when we're going to get there.

WILL: Cool. Thanks, y'all.

MATT: Yes. Thank you, everyone.