How Do I Invest Engineering Time?

About this Episode

The episode frames engineering as an investment rather than a cost. Mike opens with a parable: leaders who put capital (or engineers) to work create value; those who “protect” resources without progress destroy it. The panel builds on that: impact comes from choosing work that improves tomorrow—planning enough to ship, avoiding ivory-tower perfection, and recognizing that “cheap” talent can be expensive in management bandwidth. Good contractors and senior ICs pay for themselves by shipping and by freeing organizational attention.

They dive into technical debt with a pragmatic stance: prefer YAGNI, refactor when the change is hard so the right change becomes easy, and pay down debt “as you go” when you trip over it. Treat debt like a family credit card—budget a consistent tithe each sprint for the top, highest-leverage items and let the bottom 10% freeze or die. Too much debt maxes the card; you end up servicing interest (slow teams, broken features) instead of building. For growth and product strategy, pursue small, adjacent bets that serve existing customers and reduce risk rather than sweeping reinventions.

A major throughline is investing in people. Effectiveness scales when seniors make others effective: clear plans for distributed teams, social onboarding, and apprenticeship-style pipelines that move interns, QA, and juniors into productive engineers. Pair programming and XP practices are championed as systematic knowledge transfer—training juniors up, spreading domain context, and keeping work flowing despite constant change. The most rewarding ROI, they argue, is the compounding payoff of people who grow, stay, and ship.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'll be hosting again today. With me, I've got Dave.

DAVE: Hello.

MIKE: Eddy.

EDDY: Hello.

MIKE: We've got Will. Yeah, we’ve got Will Archer. We've got Jordan.

JORDAN: Hello.

MIKE: We've got Justin, and we've got Ramses.

RAMSES: Howdy.

MIKE: I'd like us to start off with a story. This time I'm going to go biblical.

WILL: Oh God.

MIKE: [chuckles] So, [inaudible 00:00:51] I’m going to tell an old story in a new context. No religious context, but I think it applies here. So, a boss is going to go on a year-long sabbatical, maybe not that realistic, but, you know, humor me here [chuckles]. And they're going to leave, you know, put some employees in charge. And they're going to put them in, you know, these are, you know, leaders, leaders of the company, and they're going to give one person responsible for 10 million worth of funds, another one 5 million, the third one 1 million. So, they're going to be responsible for some funds here while the boss is on sabbatical.

A year later, the boss comes back, and she asked each of the employees how things went. And the first employee, well, they've hired a new team, and they’ve built a new product that's going to bring in $10 million a year. So, "Well done," she says. So, the second employee has invested their millions in acquiring a small dev shop, brought them in, and they've increased the size of the dev team. And they expect that to contribute to $5 million in projected annual growth. So, "Well done," she says.

So, the third employee let go of some of their developers because they wanted to save their money. They wanted to make sure...I've only got a million dollars. I got to make sure that it stretches for this year. Customers are complaining because now there's not the support on the product. The product's been losing users because everybody's complaining. Reviews are going down online. And the boss says, "You know, why didn't you invest the money? You could at least put an investment account. You just sat on it." And the employee says, "You know, I was just scared to lose the money. So, I made sure I kept it all." The boss says, "You're fired [laughs]." And she gives the money to the first employee.

So, we hire engineers as an investment, right? Engineers are builders. And we build stuff because it makes companies money. You know, we're doing this on our own. We do it because we're trying to make money. I mean, we enjoy the job, but the reason that we get paid is so we can make the company money, and I think it's critical to remember that. Every minute we spend is an investment. And is it a good investment [chuckles]? Was it worth investing in us? When we get to next year, is the boss going to look at us and say, "Was it worth having them as an employee? Did we actually do better because of that?"

And it also affects the way that the company sees the engineers. There's sometimes a mindset where we're seen as a cost, just net cost. Like, "Oh, they're just the cost we have of doing business." And I think that's a dangerous way to think because it doesn't appreciate that you've got to spend some money or, you know, I got to put in some risk to make money. Money doesn't just come walking in the door. It happens because you've built something and maintained it.

So, in the broader picture, I'd like to talk, for today's discussion, I'd like to talk about what it means to treat ourselves as an investment and what that means for engineering. Go ahead.

DAVE: Can I jump on a tail on that?

MIKE: Please.

DAVE: I love when ideas from very far apart in my brain snap together. It's a psychological thing called synthesis. And you just synthesized this thing for me, which is, are we investments, or are we a cost?

And I took a financial literacy class 25 years ago. And the guy stood up and he said, "Do you have any assets? And what do you have are liabilities?" And we all started going through all the things. Well, I've got assets. I've got a car. I got, you know, and we just started listing all the things we had. And he's like, "Every single thing you just listed is a liability, not an asset." I'm like, "What are you talking about? My car is an asset." He’s like, "Is it going up or down in value?" "Oh, it's going down. And you had to pay for it." "Yep." And it doesn’t make you...well, I mean, it gets me to work. Okay, that's an investment. That's something you have to do. But you can't sell that car for more money than you had it. It is not an asset in and of itself. You can use it. And it's good, but it is not an asset.

When you acquire a company or you're in a company that's getting acquired, the first thing management does is say, "Nobody leave," right? "Here's the retention bonuses. If you stay for the next two years, here's this." Why? Because you are an asset. You increase the value, and your continued presence here continues to increase the value of the system you are in.

So, anybody who thinks their employees are a liability...you can point at a specific liability or a specific liability and call them an employee. That's an interesting wording, but you get what I mean. But that's like a onesie-twosie that the job, when an employee is a liability, is because they are failing to be the asset that you need them to be.

WILL: That wasn't my experience, but that's a tangent.

MIKE: So, well, what's worth investing in? If we are assets, if we're worth investing in, what is? What should we actually be investing in? Because there's a lot of stuff you can do in a day. There’s choices. That's a broad question, intended to be open-ended.

JUSTIN: [laughs]

DAVE: I think on our last podcast, I mentioned the generic advice of prioritize later. And anything you can do now to improve tomorrow or improve later, I think, is a great way of an asset. And so, that's a very generic answer to what should we do as employees, but that's the thing that I try to do. I try to look at, like, where does it hurt the most, and what can we do about it?

MIKE: So, where does it hurt the most?

WILL: The question I've got, right, is, like, sort of, like, in what context, right? I mean, sort of, you know, as an individual contributor, like, I manage a department of one, right? You know, so I have things that I need to be doing, right? It's all good, you know? And so, you know, my discretionary spending, right, is limited, not zero, right? Because there is lots of interstitial time that I'm waiting for something, right? You know, like the factory is idle for whatever reason. It’s just sort of, like, move up the ladder, right, as your scope gets larger, like, that sort of time, like, you know, the latitude you have to make decisions gets bigger. And so, I guess the question is, like, who, right? Who would be investing and, you know, what?

MIKE: Well, I was thinking about this before the call as well. It also depends on the scale of the organization you're in. If you are alone, if you're the startup, you know, investing in yourself, building a new product, what matters probably is very different than if you're on a team of 50 or 100 or 1,000.

WILL: What if you're a startup and, like, you're not, you know, like, if you're not generating a profit, everything's an investment, isn't it? You know? It's a thing. I mean, like, you know what I mean? Like, you're building something, right? Like, the investment is fairly direct and, like, unambiguous and kind of cut and dry.

MIKE: But you can go for some perfect ivory tower implementation that's going to take you 10 years, and you don't make it to market before you run out of funds. So [laughs], I think it does matter. I think when you're that startup, you need to have a goal of getting in money fast. It's very sink or swim. Like, you need to prioritize, and you may make some cuts that you wouldn't do otherwise.

JUSTIN: So, I think it goes back to a little bit what you mentioned right there, Mike, is, like, you've got to plan, or you've got to have a plan. And if you don't have a plan, you have no plan. And so, whatever you do may not fit within that overall plan of making sure that I get paid tomorrow, next week, and, you know, next year. So, time spent planning, I think, is, you know, you don't want to do too much. But it usually pays off in droves.

DAVE: When I was a contractor, I always had to consider, when this contract ends, I will go back to the sales cycle, and you don't get paid for sales. That's a pure investment in speculative opportunity. And I get where people are like, "Well, your hourly rate is really high." And I'm like, "Yeah, because you're hiring me for a very short contract." And they're like, "Well, we only need you for this time." And I'm like, "Yeah, and then I'm going to go be unemployed. You understand that if I've got a two-week sales cycle and people hire me for two weeks, I'm unemployed 50% of the time. You're going to pay me 200% of the market value. That's just how it's going to work."

MIKE: Yeah. Fairly typical for contract work for that reason.

JUSTIN: So, talking a little bit more about investment, too, and I'm lucky enough to, like, be hiring people. And, unfortunately, the people I'm hiring are in India. But having said that, the investment that I make is getting up early and spending time with them to make sure that they understand what the vision is and what the plan is. Because I don't see them for, you know, I only see them for, like, two hours out of their eight-hour day.

And if they don't have a clear plan on what they need to be doing, the money that I'm saving by, you know, having people in India is getting thrown out the window because, you know, they're only productive for two hours. So, the time invested in helping other people be successful and helping make sure that they understand what the plan is really worth it as well.

And it's interesting because, like, a lot of this is not, like, coding. You know, this is not necessarily individual contributor work. It's like, "Hey, I need to plan. I need to make sure other people understand. I need to make sure I understand." All of that is very important before you sit down and code.

MIKE: So, you're saying if you help other people be effective by helping organize the work, you've made more efficient use of your time than if you just went in there and tried to build it yourself?

JUSTIN: Yeah, which is rough.

MIKE: Sure.

JUSTIN: Because if I go in and build it myself, I know it's done right. And, you know, I can be the hero because I did the thing.

MIKE: [laughs] Absolutely.

JUSTIN: [laughs] But it’s like one person is doing the thing.

WILL: So, would you say that you're investing in your sort of, like, contract team? Like, you've got an offshore contracting team that you're investing, like, not only in your team, your enterprise, but you're investing in them, right? So, you've got, like, contractors, right? But, like, you're training them.

JUSTIN: Yeah, and, like, any sort of success that I have is dependent on the success that they have.

MIKE: That's interesting, that idea you're exploring there, Will. You're investing in the people. And this is an idea that has come up a lot, I think, on the podcast, you know, people are human. You can't just drop somebody in, "Okay, you're productive, and you'll do this unit of work, and then you're done."

JUSTIN: [laughs]

MIKE: And that's just not how work works. There's that human element that requires the coordination that requires the training. And we say training and some of that is...it's not necessarily, you know, learn this language because that's kind of the baseline. That's the expectation a lot of times going in. It's rather, you know, "Here's the systems we work on. Here's the way we do things. And here's how you can be effective." It's around things that, like you say, aren't necessarily coding although there may be coding style and things in there. It's a lot of bringing somebody into the group.

DAVE: Mm-hmm, social onboarding.

MIKE: Yeah, well put: social onboarding. And that's an investment, and it's...you actually are lowering your return on investment if you think, okay, I'm going to hire these people for one month or two months, or anything less than, I mean, even up to a year or more. Sometimes, you know, I think that productivity is still climbing. We've got contractors I've been working with for almost 10 years, and I would hate to lose that, right? That is a valuable thing to have. We've got relationships, you know, we're friends. And we've got, you know, trust. These people know exactly what to get done, and they do it well. And that matters. You lose that if you just treat that relationship as disposable.

WILL: So, like, what's the con? What’s the flip side of that? Okay, you've got a contractor, right? So, I mean, the contractor and the expectation, I think, that I certainly work under, and I think a lot of people work under, is sort of like, "You're going to get it done. Like, what have you done for me lately," right? Like, there's a level of investment that you don't expect and you shouldn't expect. You shouldn’t expect to get hired if you're not making things happen now, right?

MIKE: Sure.

WILL: We discussed this as sort of like the mismatch, right, between contracting in that, like, a lot of shops can sort of, like, compete on a cost basis as contractors, right, for a job which, you know, if you think about onboarding, right, like, a contractor you're always onboarding. And that’s hard. That's really hard. And so, like, the expectation is that maybe that investment and, like, your sort of technical skill set is priced in already. And it's something you pay...you pay for something if you've already done it, right? Where's that line appropriately drawn?

Because this is also, like, sort of the converse where, like, you have, like, long-time contractors that are employees in all but name. And that's sort of, like, a weird, like, bureaucratic cul-de-sac that commonly people will find themselves in.

MIKE: It's an interesting question, I mean, because you're hiring somebody expecting them to know something [laughs]. Otherwise, you wouldn't be hiring them. So, how much do you invest? You know, how much is it worth investing there? If somebody doesn't really know what they're doing, how much do you put in? And I guess it does depend somewhat on the cost, right? How much you’re paying for it.

I'm thinking about if I was asking somebody to build a house, if I was hiring a contractor to build a house. Actually, earlier today, I was talking to a roofing contractor. My roof is getting old and needs to be replaced. And I did talk to multiple contractors, right? And I compared the price. But I didn't go and say, I'm going to find the absolutely cheapest contractor I can possibly find. And that was a deliberate choice. Because I knew that that would not save me time, or energy, or grief in the long run.

I made sure that the prices weren't way out of line, and it was somebody who was reputable and, you know, local, lots of reviews [laughs], somebody I can go back to six months from now and say, you know, "You messed something up,” and expect them to actually do something about it. Because it mattered, right, to get somebody who knew what they were doing and that I could have some trust in.

On the flip side, I wasn't actively looking for the most I could spend, you know, there's no, like, gold leaf on my roof [laughs]. You know, it's a roof. I needed it to get the job done. And it seems like there's some applicability there. I’d think that going for the cheapest you can possibly get probably is not going to save you money because there's going to be so much investment afterward in making it work. But you probably want to go a little bit higher up that ladder, right, and pay a little more and get somebody you can trust.

And then, you know, maybe thinking about people like engineers, right? Somebody is like, okay, I'm going to have these people with me for a few months. They have some basic competence enough that I can trust them to get the job done if I spend some time. I would advocate for something like that so many times. Go ahead.

WILL: I'll toot my own horn here as a fairly expensive contractor who still manages to get hired on a fairly consistent basis. When I say fairly consistent, I mean I've been overbooked forever, since the dawn of time. But the cost of your contractor is not strictly defined by the dollars that they're charging you because, in all honesty, there is organizational bandwidth that is a zero-sum game. There are so many managers in the company. They can get so many projects done. They have so much attention. They have so much planning. They have so much specking things out. And they can only deliver so many things per year. There's a hard limit on the number of things that they can push out per year, period.

And so, you can say, like, "Wow, you know, this guy's only, like, 10 bucks an hour." 10 bucks an hour at Bangladesh he’s so expensive. Yeah, but, like, he's taking up 20% of your management bandwidth for the entire year. You're not getting anything else out. It's not going to happen. You know, versus somebody who's much more than that, but they'll get it done, and you don't have to worry about them. Like, I'm saving your bandwidth. And that's, I think, a value proposition that most people in the business who have been there for a while understand. And they're like, "Yeah, but he'll do it, and he won't bother me. It'll just happen."

MIKE: We recently hired, I won't give names here, recently hired a contractor to work with a team, local. And he stepped in and immediately started getting stuff done, went and found some organizational efficiencies, called them out, and improved things just kind of from day one. He doesn't know everything, right? You know, nobody's...of course they don't. But they’ll make a huge difference. And I'm like, "Wow, give me 10 more people like this."

Again, not perfect, nobody is expected to be, but knew what they were doing. And I can trust that they'll get the job done. And that was worth its weight in gold, right [chuckles]? Like, [inaudible 19:24] making us money. Absolutely. That ability to get stuff done just is absolutely critical. You can have people who are less experienced, but only up to a certain critical mass. They need to have basic competence, right? Somebody you can tell them what to do, and they'll get it done. But you need to have people who can help direct that, who can work really independently.

Because if you have these people who are less experienced and can't just get stuff done, they reach a critical mass, and then nothing gets done, right? You reach a level of work, and it doesn't matter how many people you hire. You're not going to get anything else done because there's just a lot of people running around and nobody knowing what to do. The only way I've seen things be effective is you have people who really know what they're doing, who can help those other people.

So, Justin talked about working with a group and spending a lot of time working with them, helping them know what to do and keep them going. That gets work done. But there's a limited number of Justins [chuckles], and you have to have more. You have to have enough of those hubs of the wheel to keep those pods moving, or else it just falls apart.

So, we’ve talked some about this balance of getting what you pay for and being willing to invest in people. I'd like to hit a little different topic related to this: technical debt. So, we talked a lot about investment, and then there's the flip side, where you're taking on debt. And you may be taking on debt in order to invest, right? So, you're building something. So, going back to the startup idea, if you don't get the product out the door, you run out of money, and your business fails. Maybe you incur some technical debt along the way. And that might be very much the right decision. You're taking on some debt to invest.

So, if we think about this idea of investing in ourselves, when should technical debt be paid? Where do you balance? Like, I've got this money. Do I pay down the debt or build something new?

DAVE: Mike, all I heard you say was, "It's too quiet in here. Let's start a fight."

MIKE: [laughs]

DAVE: I will say that as I've gotten older as a programmer, I have learned more and more, (YAGNI) You Ain't Going to Need It, right? So, a lot of technical debt came from preemptively trying to prevent the wrong technical debt, trying to build something that it turns out we never ever needed. And we see this all the time. Eddy, you and I have ripped some stuff out this week, I think, that somebody built, and it never happened, right?

There's a thing on our team right now where we had a build-out so that the individual developers could be running Docker to standardize our configuration. And then we realized that we have a service-oriented architecture. You can't run 12 Dockers on a laptop. It's just not going to work. It makes a great lap warmer, but it doesn't make a good development environment. But there was all this stuff to support the Docker initiative that just died. And then that code got maintained for another three years because it's separate. So, YAGNI, YAGNI, YAGNI.

So, as I've gotten older, I've started thinking, when I'm done with something, I will do the refactor to try to clean and make things readable and understandable. But I try very, very hard to never let myself say, "We need to do this for this future thing." I've gotten much, much better at saying, "Tomorrow, Dave can handle that." We all joke, that sounds like a future me problem. No, it really is. This sounds like a future me solution. This sounds like something future me absolutely can handle. I'm going to do stuff today to be kind to future me, but I'm not going to try and tie future me's hands or try to paint the wall that future me hasn't built yet because it's just a nightmare. You end up with a bunch of dried paint in the shape of a house. It's like, how do you put that on?

But if you've got Cowboy Coders on your team, they will weaponize that against you because they will go out and crap out all the technical debt they can to get their stuff done and polish all the rivets they want because they know you are going to come back and clean up their latrine. And I've started fights over this. Legitimately, I'm just like, "Yeah." I have so many metaphors that are inappropriate for this. Cleaning up the latrine, I'll just leave it there. I've yelled at people in this company recently, so...not recently, right? Months ago. I'm much calmer after the sabbatical, so...

MIKE: [laughs] So, you're saying build enough and not more.

DAVE: Build enough...oh, sorry, there's one more instinctive habit that I just realized I skipped over. All of this is enabled by the specific habit of when you get an assignment. I'm a very high-latency developer. You give me an assignment, I'm going to take a while to get started on it because the first thing I do is refactor. I will look at the code, and I'll go, the change you want me to make is very, very hard to make.

Kent Beck, famous quote, if the change you need to make is hard, refactor the code until the change you want to make is easy to make, then make the easy change. So, like, Kent was like, I'm really lazy. I only make easy changes. And then he's like, yeah, I spend most of my week doing the hard work to make the easy change possible. You have to do that. So, it's like, anytime I get a new ticket, I'm like, yep, the technical debt that I wasn't paying off before, I have to pay it off now because now I know where the house is. We have to paint this wall before we cut a hole in it.

MIKE: Are you suggesting that you should pay off technical debt as you bump into it?

DAVE: As you go. As you go, yeah, basically. Because when you bump into it, now you know, I really do need this. You can't say, "You Ain't Gonna Need It" when I'm literally stubbing my toe on it.

WILL: I don't know, I like...like, having done this for a long time, like, I do consider technical debt. Like, the YAGNI principle there I think it has a lot of merit. I personally think you should just...I think you should [inaudible 25:18]. Like, you know what I like? I like to stack rank technical debt. The bottom 10% of the technical tickets, relegate them. Relegate them to the freezer.

So, I think the family credit card is a good analogy for technical debt. I mean, you should have a bunch of, like, you should have a wish list, right? And, like, every once in a while, get your leads together and rank them, you know? Bottom 10%? Yeah, yeah, probably. Probably that's just never going to get fixed, you know? And you should take a certain number of points, you know, maybe every sprint, maybe a quarter, maybe something, you know?

Like, yeah, yeah, you know, the bottom 10% if things have been, like, nah, we don't really care that much, you know? Versus, like, you know, honestly, like, there's stuff that, like, you know, like, people do care about. People will, like, get out and fight for it. Like, that stuff actually matters, like, you know?

Like, one form of technical debt that I've found particularly pervasive is the sort of, like, performance creep on, like, developer workstations as a result of, like, IT overhead, let's say. You know, there's administrative IT, things running on these workstations, which I don't care. You [inaudible 26:42] work my workstation all day, all day, you know? Like, that's no problem. I have a smartphone that I can do all my personal stuff on. It's not a problem.

But performance tends to degrade as more and more things are being checked and exclusions aren't being maintained. And that's the kind of thing where it's just, like, you know, people will rumble with you, but it'll never show up on a sprint. It's just...it's a silent tax across an organization, and that's a little bit of a personal anecdote.

DAVE: I remember talking with Mike a couple of years ago, and I'm like, "I keep getting bumped off the VPN." And Mike said, "Yeah, that happens," I’m like, okay, okay. And I talk...I keep getting...and it was starting to sound like Dave's kind of a complainer. He's constantly whining about the VPN. We all get bumped off the VPN. I got so annoyed one night that I cracked open the laptop. It's like Tuesday night, and I wrote a thing to just check, is the VPN up, and then log it.

And then I came back, and I'm like, okay, I've got this graph. Every 6 minutes, my VPN goes down, and that's a 30-second timeout, and whatever I'm doing just halts. And I go to Mike, and I'm like, "So, should I be losing my VPN 70 times a day?" And Mike was like, "What? No, wait, wait, what?" But the patterning, the social onboarding was my VPN is going down. No quantity information supplied. Everyone else assumed quantity being far, far less. And I'm like, no, I'm not oversensitive. I'm getting my face punched in by this stupid VPN [laughs].

WILL: Yeah, right.

DAVE: We fixed that, and my life got so much better. So, yeah, communicate, I guess, is the answer to that.

WILL: Oh yeah, well, exactly. I mean, it's just, like, you know, just, like, tithe, you know? Just pay your tithe to the tech debt gods and, like, rank them and relegate them, you know?

MIKE: Well, I agree with it. I agree with what you're saying strongly. Take a chunk to every sprint, you know, schedule it so whatever percentage your company's okay with, you know, 10% of your time, 20%, 30%, you know, that you're working on each sprint, be working on paying those things. And you said, you know, don't worry about the bottom 10%. Honestly, it's rare to get past the top 30%, right? Because new things come up.

DAVE: Top 10, yeah. Pareto's rule rules here, like, the power law. 90% of benefit and 10% of effort.

WILL: Just delete them or, like, you know, [crosstalk 29:03] just get rid of them. But yeah, you're right. I don't know, I mean, like, in the limit case, right, a long-running enterprise, right, like, a long-running technical enterprise, you're paying your technical debt tithe. You pay. You either pay because you're actively working on it, or you pay because it's, you know what I mean, you're taxing your organization. But in the limit case, as, you know, T approaches infinity, right, you're paying your card down more than --

DAVE: You pay for it in customers that go to Amazon instead of you because their site comes back in under eight seconds every time.

WILL: Yeah. You don't get out of it. There's no off-ramp. Where you can find yourself in a really nasty situation is when you're in a situation where credit card is maxed, right, and the minimum payment is substantial, and you don't have the bandwidth to fix it. You just have to work around it, right? So, like, product development is as slow as can be sustained. And the technical debt is taxing you with every ticket. And now you're stuck.

MIKE: And it can get so bad that you can't move forward anymore. You can't build new stuff because you break other stuff. You reach a stasis point, right? A balance point where you cannot actually introduce new features because everything you do fights so hard that it breaks something.

We all live in reality. There's a quote that I've been bandying about that I just realized is a... I love that Will and I, like, we end up in violent agreement so often because we come at things, like, orthogonally, but we're saying the same thing. I've been telling people, "You cannot build software faster than you can build stable software." It's the same thing. You will eventually end up paying interest. All your money is going to the interest. And the only way to get out of it is to make your minimum interest payment, and if that's your entire paycheck, that's great. But you've got to go run a lemonade stand and make 20 cents extra to pay a little bit. You've got to get the principal down.

MIKE: So, if you want to be effective in making money, you've got to keep paying that payment, bringing it down consistently.

So, we've tackled kind of broadly how to invest. We've talked about paying down technical debt. Let's think about it a little bit bigger in terms of how business works.

In a large corporation, in an established business, you've got some sort of product line, and you're maintaining that. You're adding features, and things are great. And you can treat it like that's your only gig forever, and that is risky because the world changes. You ask Standard Oil [chuckles], or you name your big business of the past that has since been forgotten. You look at the S&P 500, and it's not the same as it was 10 years ago, and very different than it was 20, and completely different than it was, you know, you go back a few decades, and you see names you’ve never even heard of anymore because the industry changed, the world changed, and those businesses did not adapt as that change happened.

So, how do you build new products? How do you go about investing in something new, even though it might even have a negative impact, might even cannibalize some of your current business? How do you do that effectively? So, this is kind of a bigger question than engineering [inaudible 32:50], but kind of a business question. What are y'all's thoughts?

WILL: Small deltas. I love a tiny, tiny delta. I mean, like, you're doing business right now, right? Something is working, right? Hopefully, at least, something is working, right? So, like, prospecting is so expensive. So, what more can I do, right, for my customers, right? I mean, this is, like, way afield from, like, software engineering and stuff.

MIKE: Sure.

WILL: How can I expand to adjacent customers, and how can I sort of, like, add some sort of value onto, like, my existing customers? Now I'm putting on my, like, I ran a software product company for 10 years hat, which is not, like [laughs], what we do here but, like, you know. It’s just the most --

MIKE: But it matters.

WILL: Well, for most places, like, you want to mitigate risk, right? Like, we did do...like, we’re Acima, right? We went over to Upbound. We got a very natural move, the natural, like, I'm taking one block over, right? I'm taking one step over. You know, Upbound was like, hey, we're doing this thing, and now this is, like, this is where things are going, and so it was a natural outgrowth. And so, like, and it's acquisition of work, like, that played. It was successful. And I think it was successful for those reasons, right? So, you want to mitigate your delta as much as you possibly can.

You don't want to get into a...even, like, there's a...I think it was...I forget the one. I forget whether it was Bentley or Rolls-Royce, right? Luxury car company, right? Well, how did they get started? Well, they were carriage companies, right? They were carriage companies and sort of, like, they built the top of a carriage, like, a horse-drawn carriage, right? Like, the top that people rode in, right? It was, like, real nice and, like, you know, the furniture was nice because people hung out, you know, for a while. And they were, like, okay, well, I'm building a carriage for a horse. When you got rid of the horse, you still had to sit somewhere, right? And so, the buggy-wheel people, those guys are gone, but the carriage company is doing great.

MIKE: Because they were willing to pivot. But you said small delta. They didn't switch over to making trains or boats.

WILL: They didn't even build engines for a long time, right? Not even engines because engines were hard.

MIKE: They just built the top of the vehicle. That's interesting. Yeah.

DAVE: There's a fun story. I wish it was true that the wheelbase on your car, the distance between your wheels, is based on the fact that the rail gauges were of a similar size. Well, the reason the rail gauge is the way that it is is because of the width of a carriage. The reason a carriage is that way is because if you drive in Europe on the roads that were built by the Romans, they have grits in the stones, and it will break the wheelbase if you're not the right width. And those grits come from horses two abreast, pounding down.

WILL: [inaudible 36:03]

DAVE: I wish it was true. I'm sure that it was an influence. But a tape measure will tell you it's not true. You can just go out and measure any of those things. They don't actually match. But oh, I want that story to be true.

MIKE: You're right, influence.

DAVE: Influence, absolutely.

MIKE: I'm sure it's not completely true, right? There’s differences between horses.

DAVE: Not a governing principle.

MIKE: Yeah. But the general idea...you don't have lanes on your road that are 30 feet wide or 3 feet.

DAVE: Or 70 feet wide.

MIKE: Yeah. They're within an expected range that came from history.

WILL: Well, I mean, I think, honestly, it probably is very, well, no, no, that's not. I mean, the reason roads are now is dictated almost entirely by technology and sort of, like, width, right, and, like, the speed that people travel and stuff like that. So, I mean, like, right now, in the year 2025, it's all technically specified, road [inaudible 37:08], road, you know, the camber, like, you know, like, stuff like that. That stuff is all, like, you know, we tried it every which way. And I'm like, if you're going to go 80 miles an hour, you need this, and this, and this. We need to have a crown on it so water comes off and, like, all this stuff, right? And I need to have a semi go down it, too, and semis are built, you know, a certain way. Anyway.

DAVE: I think roads are now in the should phase, right? The RFC 2119 is the one that gives you the definitions of must, shall, should, should not, must not. And should means you must build it this way unless you have a good reason. So, if you're in a small town or you're building a driveway straight up a cliff face, you can have a four-foot road. You can do it that way. But yeah, if you're building a federal interstate, it's going to be standard width.

WILL: Yeah, well, I mean, like, it's almost always, like, you have, like, a very exotic environmental, you know, situation. And you have some sort of, like, grandfathered in. My dad actually was, like, putting...he was rebuilding his cabin, right? He lives, like, way up north of Michigan, and he’s got a fishing cabin. He wanted to, like, go and, like, build it, right? And so, it's, like, way out in the woods and, like, he had to widen the road. He had to, like, build out the road because the road is, like, a hundred years old and, like, they needed to move the equipment down to, like, dig a septic tank. And you had to build out the road because you just couldn't do it.

But yeah, these days, civil engineering is a pretty solved problem, you know? We might not maintain the roads, but we know how to build a road that will last for a thousand years. That's figured out. We just might not do it.

MIKE: [laughs] We've detoured into civil engineering.

WILL: Yeah. Save us. Save us, Mike. Can we bring it back? We can bring it back. We're supposed to be about woodworking [laughter].

MIKE: Going back to the idea, I'd like to go back to the idea that we talked some about early on, and that's about investment in people. This is something that's kind of dear to my heart, right? It's something I care about.

So, I'll do another analogy. Hundreds of years ago, generally, every town had a blacksmith shop. And the blacksmiths, like every other human being, pass on, right? They're not there forever. So, you have people who want to go into that trade, and they maybe couldn't stay in their own town. They find a town somewhere in the region where there was somebody who was taking on an apprentice, and they'd bring them on. They would learn the trade over a number of years, and, eventually, they'd take over the job of the master that was helping them out.

And that worked out pretty...there's flaws in the system, right? But it was a persistent system for a reason. It stayed that way for a long time because it worked because the kind of...and it works for many trades. We still have it in many trades. You have apprentices, right? You have an apprenticeship program. It's pretty standard practice. People work up, you know, apprentice, journeyman, and they eventually work up to the master of their trade because learning alongside people works.

And sometimes in engineering, we forget the lessons of the past and think, oh, we'll just bring people in, and they'll know exactly what they're doing, and it doesn't work that way. There's always a need to do some of this apprenticeship. And people can sometimes come from non-traditional backgrounds in that way as well if they can take the time to apprentice. I think it's very important to always have somebody growing and a group of people.

So, you don't have everybody be the experts then you lose an expert. It's a huge loss. Instead, you have some experts and you have some people who are less experts, and then you have some people just getting started. And you keep this pipeline going because it's a system that works. And if you forget that and you shut down the pipeline, it works for a little while until you've got no water flowing, right? Everything dries out, and you're in a really bad situation.

So, what do you all think about the importance of career pipelines? I’m going to take this a little further. I’m just going to...storytelling. There's a number of people that I've worked with who worked in QA or application support who switched over into engineering and have become very successful. Some of those people might even be on this call. And I am very happy that they were able to make that move and become successful by taking the time to learn the trade, partner with other people, develop the skills, and go on to become successful.

And by providing that opportunity, we ended up with people with huge domain knowledge and know what they're doing, know the business, and were able to kind of step into the role and be successful very quickly and be strong contributors. Whereas if we just pulled somebody off the street, they would have taken as much time to get up to speed and would not have the same kind of domain knowledge and the social cohesion. We're already friends here.

So, I think there's huge value in having that kind of pipeline. We may also have somebody who brought in as an intern who joined us on the call [chuckles]. There is value in people coming through that kind of pipeline.

So, I'm just going to sing the praises of that idea, and I'm saying, yes, you need to be investing in that. If you don't invest in that...I've described it before as eating your seed corn. You're fine this year, and it's a lot worse next [laughs] because you've got nothing to grow with. I'm laying down my stance here. I'm taking a strong stance in favor of the criticality of having a healthy department, of having this sort of pipeline in place.

DAVE: I could not agree more.

WILL: It sounds like the point of the podcast where I start to proselytize for extreme programming.

DAVE: Kind of.

MIKE: Please do, yeah.

DAVE: Please do, yeah. That is very adjacent to the story I'm about to lay, so please.

WILL: Because, you know, that's how you do it in extreme programming, because everybody is pairing all the time, which is how you do knowledge transfer. And you train juniors to become seniors, and seniors to become staff, and staff to become, like, whatever, super staff, or whatever the heck.

And, like, that sort of flow of training is endemic and intrinsic to sort of a healthy, functioning engineering organization because, like, nothing is ever static. Everything is in flux. Everything is changing. People are coming. People are going. People are moving up. People are, like, I don't know, probably not moving down, but, like, moving out, right? And so, I don't know. Like, there is this sort of you have to accept, like, that intrinsic, undeniable, like, flux, change, right? It's happening all the time.

And, like, I think, you know, the reason I harp on XP is because I have not encountered a systematic way of addressing this as a first-class citizen that it is. I would love to just be able to be, like, hey, what if I just pay somebody a lot of money, and then, like, I don't have to think about it? And, I mean, like, you can do that if you could find the people, but, like, it's, you know what I mean? Like, Google can't do it, so can you, you know?

Like, Google can do it, and, like, they write a check, you know? And, like, if you talk to anybody from Google, they're, like, yeah, it's better, but, you know? So, anyway, so, you know, not to harp on it, but, like, you've got to get it done somehow. And I haven't heard a lot of answers. I've heard a lot of people sort of, like, taunting or advocating or throwing their hands up in despair. But, like, if you're actually trying to solve a problem, once again, extreme programming, shooting [inaudible 45:16] away.

DAVE: Pair programming, yeah, absolutely.

Related to both of those things, we have kind of a career pipeline here, and I love that. I can't remember if I was super interested to be hired here because we had one or if you guys were interested in me because you wanted one. But, like, I was coming out of CoverMyMeds, where we had established a career pipeline, absolutely.

And, like, when I was there, we had this rule that everyone codes. Like, we had code from the CEO. It was terrible, but it was there. We had people from QA that were contributing code into our corporate…Everybody codes, but the QA people would just sit quietly and get crapped on by the dev teams. I was the one that started going in and saying, "No, we're going to pair program."

I would grab a QA person and say, "Come pair with me." And they would look at me like, I'm going to waste your time. And I'm like, are you kidding me? You're QA. You know where all the bodies are hidden. Sit with me, please. And very quickly, they’d find out that even the juniors have an incredible amount of contribution. So, I cannot sing the praises of that high enough.

But Dan Pink wrote a book called Drive, and he talks about what motivates us. And mastery, autonomy, and purpose are the three biggest things that will get you out of bed every single day. And when you take somebody and say, "You can grow your skills. You can increase your mastery. It's hard to do, and you can get better at it, and that feels great." Autonomy means we're going to open a hatch at the top of your career pipeline, so that when you are at the top of your pay scale, you can slide into the middle of the pay scale of the next harder level. If you want to go up in a belt rank in the dojo of engineering, we've got another team for you where it's harder. And you're a much greater investment because you're solving even bigger problems, and it's fantastic.

The reason I get so excited about this, and this is kind of heavy, so I realize you guys are...I'm usually the poop joke guy. But when I was at CMM, I had two people come...well, I had about seven or eight people come to me and say...this was when Ruby Rogues was really, really famous. I wasn't the most popular person on the panel, but I was there. And I would tell people, come work with me. Come work with me. Come work with me. We're fixing the healthcare system.

And now I'm telling people, "Let's..." At Acima, we are servicing a part of the economy that is wildly underserviced, underrepresented, and it is heavily predated. There are a lot of predators down here. And being able to operate in that environment and help people is incredibly emotionally fulfilling.

But the thing that knocked my head right off my shoulders was it happened back-to-back over a two-week period. I sat down with a guy, and we're just coding, and just out of nowhere, he says, "I work here because of you." I'm like, "Wait, what? I didn't interview." He said, "No, I was listening to your podcast. And I'm like, that does sound cool. I want to go do that. So, I'm like, okay, hey, that's really, really cool. I thought that was my shining tiara. I brought somebody in. That was great.

And then, two weeks later, I was programming with a woman. And that's significant because women are wildly underrepresented in tech. And we're typing along. And I don't want to niche or brag or politicize. She was also trans, which is even more underrepresented, and that's the only reason I bring it up. It's even more underrepresented. It's an even more hostile environment.

So, I'm sitting next to this woman. We're typing along. And she said the same thing, except I knew that Cover My Meds was her first job. And she didn't say, "I came here because of you." She said, "I got into programming because of you. You convinced me that I could do this. You convinced me that I could survive in this environment, and here I am." And I'm like, "Can I give you a hug?" I will carry that to my grave as one of the top ten core moments of my career.

Yeah, invest in people. It is so worth it. It is so worth it. That's my speech.

EDDY: I've said it before, and I’ll say it again. Dave was the first person here at Acima that taught me how to create a branch and push it up to that repository. No one before then had taught me how to do that.

DAVE: Awesome.

EDDY: And so, the fact that you did has gone and paid in credit, I think, so...

DAVE: And I forgot that we did that. And you were subtweeting me in the room. You were like, "Well, I got to be one of...there's an engineer. He sat down git da-da-da-da-da." And I'm like, "That guy sounds really cool. You need to do that for people." Eddy’s like, "Dude, it was you." And I'm like, "Wait, what?

So, yeah. Don't do it for the credit. Don't do it because you want. I'm just saying do it, and when it pays off, it feels amazing. Plus there's all these other programmers that are now going and having careers that are...and that's the real purpose.

MIKE: Absolutely. I've said it for years. It's the most gratifying part of my career is when I can help somebody be successful and see them move on. And when you see that happen, it's just incredibly rewarding. And it goes back to this idea of investment. You watch that investment pay off [chuckles]. You invested in that crypto coin 10 years ago, and now suddenly you're rich [laughs].

DAVE: Survivor bias fallacy. Yep.

MIKE: There are some investments worth making and investing in people because you care, I think, is worth it.

Now, this is not to say that we can function exclusively as an educational institution because that doesn't work either. As we talked about, if somebody is not ready and the business is there to make money [chuckles], that doesn't work. But if somebody is competent and willing and able to do that work, give them all the support that you can.

As Justin was saying, his time is best spent helping other people be more successful. And as you move up and move forward in your career, whatever it is, as you advance in your career, that becomes more and more true. The more that you can help other people be successful, you're going to be accomplishing more than if you're just walling yourself off into a corner and banging out some code.

DAVE: Stephen Covey, if there's no margin, there's no mission. There's times when the people have been bright and ready to learn. And we had two weeks to ship eight weeks of code, or we were all going to lose our jobs. We didn't do a lot of skill-building that week. We did a lot of overtime and a lot of typing because that's all the margin we had for.

MIKE: But when you have some, you pay down your debt, and you invest in the future.

DAVE: And there's a valuable investment to trauma bonding with your co-workers [laughter]. That's funny, but I'm not joking. That is absolutely a true statement.

MIKE: It is true. I laugh because I identify it, not because it was wrong. So, I think I've covered everything I wanted to talk about today. Anybody else have any final words they'd like to throw in here before we break?

WILL: Everybody should be doing XP all the time. Do it. If you have the power to do it, do it. If you don't have the power to do it, do it anyway. Just don't tell your boss. Invest in people. If you can’t invest in people, invest in yourself. There’s always this, like, because you're going to find yourself...As an individual contributor, you're going to bump up against just these things where it's like, what is that? What is that? What is that?

Just keep, like, a slush pile of things you're run into, either, like, a piece of the codebase, a library, just some kind of thing that it's just like, what the hell is that? And just keep a list. It's just a list of stuff, like, Google's I need to do, you know, in the future. And just, like, just check it out.

Just keep stuff in your down cycles because you're going to get them, right? They're going to happen. And it's always about, like, you know, getting better and getting smarter and building extra understanding. Because, you know, civil practical fact, right, like, none of the work that we do is really that complicated. None of it's that hard. It's really pretty simple.

Like, most of the stuff you did in school is more complicated. Like, I built an operating system, like, an entire operating system with a memory manager in school, and I don't have to do anything like that at work, you know. But I do need to know how a bunch of, like, dumb business logic operates. And, like, how does the DI that gets our cookies to authenticate a user, like, how does that get initialized, and when? Because if it's not ready, then you don't log in. That's a problem for some people.

And there's nothing about it that's special. You just have to know. And, like, what's the difference between, like, the best guy in your team and, like, the worst guy in your team is, like, the best guy in your team, like, he paid that toll already, and he knows. And, like, it's just a matter of showing up every day and, like, just getting a little bit smarter.

I mean, because, like, to be perfectly honest with you, like, completely average developers can become exceptionally productive, and valuable, and talented ,and have wonderful careers, just by doing, like, a little bit extra. It's not that much work, but people won't do it. And it's a matter of investing in yourself, you know. And that kind of stuff is entirely within your control.

You know, XP now, XP forever.

MIKE: I’m not going to argue about the pairing [laughs]. So, I'm going to conclude by supporting that. So, we've got Jordan here, who was an intern recently. And one of the best things that happened to me this summer is, at the end of the summer, the interns were doing their presentation. And they brought up pairing on their slide and said, you know, we've been doing this all summer, working almost the entire time pairing. And I was like, yes [laughs], yes, learn how to work together. That's, like, one of the most...maybe the most important thing you could have learned this summer, and you did. It worked.

JORDAN: I want to say that this summer, compared to last summer, just felt so much more productive. And I kind of...I low-key became kind of dependent on pairing because we would have the hour in the morning before stand-up where we just worked on our own stuff, like, I don't know, catching up on our tickets or, like, the Exercism.

And I would sit there, and I'd be like, well, I can't get anything done. Like, I don't have Chloe sitting here, like [laughter], to discuss on what we should be doing next or, like, what we're currently working on. And so, we’d pair, even when it felt like there was nothing to do because we could talk and, like, find something to do. And that just felt so much more productive. So, I'm a big advocate for that [laughs].

WILL: Yeah. And keep a slush file. Every day, and usually a couple of times a day, I'll come up against something that's just like, how's that? What did you do? And there's always a story, right? It's always a story. It doesn't matter whether it's, like, it could be, like, a Git, Jira spelunking story, or it could be, like, some kind of trip thing, or it could be, like, some technical debt that maybe needs to be on the list. Just keep a note file of just like, what the f*** was that? You know? Like, I can't encourage it enough, you know, because there's always something.

EDDY: I will say, Jordan, you don't necessarily need a Chloe to talk to, right? Like, you need something just arbitrary just laying next to your desk, you know, something where you can express yourself to. I mean, I can't count the number of times that, like, I started typing out a message to someone, and I'm trying to articulate all the things that I've done, right? And I'm like, dude, I'm stuck here. I can't figure this out. I've done this, this, this, this, this, this. And then I'm about to send them like, ah, wait, you know? And I just laid everything out, right? And --

WILL: ChatGPT is my work wifey [laughter]. Not like that. Not like that [laughter]. But, like, I can [crosstalk 57:14] you know what I mean? Like --

MIKE: Probably a good slot to close. The social aspect matters. Invest in your people.

Until next time on the Acima Development Podcast.

DAVE: Cheers.