Velocity vs Thoroughness

About this Episode

In this episode of the Acima Development Podcast, Mike shares a personal story about his father, a custom staircase builder, to illustrate the importance of balancing speed and thoroughness in work. Mike’s father, known for his meticulous craftsmanship, often took extra time to perfect even the smallest details of his projects. Mike contrasts this with a quick-fix job he once helped with, where speed was prioritized over perfection to meet a deadline. Both situations were appropriate for their respective contexts, highlighting the need to adjust the level of care based on the type of project at hand.

The hosts dive deeper into this theme, exploring how the right balance between velocity and thoroughness can differ depending on a company’s stage of growth. Will points out that startups often need to prioritize speed to survive, while established companies must focus more on quality and performance. They discuss the challenges of maintaining speed when stakes are high, particularly in large organizations where even small inefficiencies can have significant financial impacts. The conversation emphasizes the importance of adapting processes and expectations based on the specific goals and constraints of the work.

Finally, the episode touches on the crucial role of communication and knowledge sharing within development teams. Pair programming, mentoring, and asking questions openly are all identified as valuable practices for ensuring that team members can move quickly while maintaining quality. The hosts stress that leadership should stay involved in the coding process to maintain a connection with the work, encourage a culture of learning, and foster an environment where mistakes are seen as opportunities for growth, ultimately helping teams strike the right balance between speed and quality.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I have Dave and Will.

DAVE: Howdy, howdy.

MIKE: I'm going to start with a story, actually, well, two kind of connected stories. I'm going to talk about my dad. He's a builder. Well, he's retired, but [laughs] he spent most of his career as a builder. And most of what he did was custom stairs. Most people don't want custom stairs [chuckles]. It's the people who can afford the custom stairs who ask for the custom stairs. So, he did a lot of work for, you know, people who can afford to pay to have custom stairs done. And the people who pay to have custom stairs done are looking for a certain kind of work, right?

WILL: Gone with the wind, grand entrance, duh. Yeah, I didn't get the Scarlett O'Hara dress for nothing.

MIKE: [laughs] So, circular stairs, you know, he did the spiral stairs, and that was kind of his specialty. And it's not just my dad; he did it with his brothers. He's got two brothers he did with. And they, you know, built stairs for years. And in my...well, I have personal experience. So, my dad built a house to sell, and this was in the late '70s. Everybody knows a big economic issue happened then, and people weren't buying. So...

DAVE: That was like the gas crunch, right?

MIKE: Yeah, exactly. So, the house didn't sell. He ended up moving in, and he's still there. [laughter] So, he probably over-housed, but he's been there. But, you know, he just can't...he spent his career doing this custom work, this custom, you know, the best quality you can get, right? And he's continued to work on the house. Can't help himself [laughs]. And so, everything he does, the floor and the kitchen, it's amazing. But you wouldn't pay for it because you couldn't pay for it.

He found an apple orchard where they were getting rid of their trees, and he cut the trees into layers and dried the wood, and then sanded it down, and cut it into the right shape. Well, cut it into shape, then sand it down because it warps after you've cut it. And so, it had to be cut thick, and then process every one of those pieces to get it to the right shape. And it's like every one is, like, at the heart of the tree. Once it was sanded, laid it all down, put epoxy on it instead of, like, your standard polyurethane, so it will last forever. It is just absolutely stunning.

But it's the thing you can only get by doing custom work, right? And when I've helped him...and I've helped him a lot. I've done some work there, and I, of course, worked with him when he was working outside the house, and [laughs] his standards are exacting. He's not a jerk, but [laughs], you know, he does quality work. And people work for him; he wants that work done.

And so [laughs], the work is great. Everything he does is done, exacting perfection. A lot of the work he does himself because he knows he's the only one who will give it that kind of attention [laughs] to actually get it done the way he wants it done. The one time when I've been doing a lot of work with my dad, I went and helped a cousin of mine who was moving out of the trailer he'd been living in. Though it was kind of a dump, and they wanted to make it look nicer before they moved out.

And I remember I was putting in some molding along the floor, just some cheap, little, thin stuff, and they asked me if I could do the corners. I was like, "Yeah, sure." And the speed at which we did the work in that trailer...I was getting together some, you know, some other family folks. And we got together and quickly did a whole bunch of work, you know, got together in three hours and redid all kinds of stuff in this trailer.

The floor was totally out of true, right [laughs]? So, trying to get that corner right was nearly impossible. I think, eventually, I put some sand under the linoleum to get it [laughs] leveled so [laughs] [inaudible 04:11]. And we got it all together. It looked a lot nicer, so we could sell it. And we were done. And here's the thing: in both situations, the right work was done. If you're going build a custom stair for somebody who wants a custom stair, well, you're going to give that every little bit of attention to detail that it deserves. If you were getting that trailer ready to go so you can quickly sell it, you're going to do that quick because that's what it deserves.

And that's not to say that the trailer doesn't deserve care, but it would be incongruous [chuckles] with the rest of it. It wouldn't be worth the value of that whole structure. You know, there's people who actually make a small home look really nice. I've seen that before. This one was not. This was not one of those homes [laughs]. This was not [laughs] one of them. But both of them were right.

There's a balance that you have to strike based on the work at hand, and sometimes you got to get that done. And, in fact, most of the time, the work we do is probably more like that trailer, right [chuckles]? We need to get the work done. And I'd say this: I say more like, I don't like to do shoddy work. I want to do quality work, but some things need to get done.

But then there are other things, you know, if I'm building something that has anything to do with money [chuckles], I want that to be done right. And I want somebody inspecting that [laughs], going over with the white glove to make sure there's no dust on it, you know, because you do not want to mess that up. And, you know, there's a time and a place for both.

What we're going to talk...I'm leading with a story. I haven't even talked about our topic today. We're going to talk about the trade-off between velocity, you know, between working fast, getting things done, and being thorough. And I thought about, you know, the stories because it is a trade-off. If there was a clean answer, then we'd all be doing it.

And the problem is we often tend to err on one side or the other, right? We tend to maybe go the wrong way for the work at hand, and we get in trouble. And sometimes, you maybe get...and we've probably all worked with somebody who had the work to do, and then they just didn't do it at all, you know, they're off [inaudible 06:37] [laughs].

I did some construction work in New Orleans area. I used to work for a construction company in New Orleans. And there was one job we'd worked on it for months, and, basically, it was done, right? It was done, but we weren't ready to move on to the other contract. And there was a couple of days where there was nothing to do. So, they said, you know, "Go around and look busy." I spent two days polishing the outlet covers [laughs]. So, when somebody came in, it looked like we knew what we were doing.

And there were some people who probably spent more time polishing those outlet covers on other days [laughs] than they should have. There's that problem, too. I think we may delve a little bit into that, but starting with the topic of balancing this work of, you know, this balancing between being thorough and being fast. I've been talking a lot. I heard that Will had a story. I'm interested in what y'all's thoughts are and how you'd link it up.

WILL: So, more I have a thought to share because I think a big piece of the thoroughness is sort of the phase of the company that you're in, right? But when you're in a startup and you're throwing features out the door as fast as you possibly can, and maybe you're going to take down the app; it'll come back up, there's not that much...you have different set of risk, right? Like, the risk you have now is you're fundamentally insolvent. You're going to run out of money. You're going to run out of time. And you have to figure out how to make a product that is worth buying. And that is your existential risk.

However, if you're working for a large, multi-billion dollar company and you screw something up, and your page loads 5% slower, you know, there are direct correlations to sort of website performance and click-through rate, and conversion, sales conversion, right? Like, Amazon did studies on this stuff, and if your stuff is too slow, people don't buy. If your site is not fast to navigate around, people will leave. And so, that stuff is really, really important.

And so, I'm talking about sort of a thoroughness-fitted finish kind of a thing. I'm not even talking about your stuff crashing. I'm talking about your stuff not being fast enough. It's like, oh, well, what if I lose five basis points worth of sales because I just didn't do as good a job as maybe I could have? Five basis points. A basis point is a percent of a percent, right? I just burned my salary for the year, just like that.

This is the phase of the company, and there are indisputable properties of just having a going concern that makes a lot of money. The impacts to the bottom line are substantial. You do need to be thorough, and I would...I always advocate for my developers. Like, if you've got a billion-dollar business, you should pay more for the people working on your site because it makes a difference, whether they're good or bad.

And one of the things...and maybe I'm going to answer your question with a question, or maybe I'll just add on another one. How do you maintain velocity in a situation where you have a big enterprise; you have a going concern; you have stakes? If you screw something up, how do you keep that velocity? Because it's easy to analyze yourself into a state of paralysis. You still need to innovate. You still need to develop products. You need to be, you know, delivering results on a quarterly basis. Because, on every level of the company, they demand that, and that is what you're getting paid for. How do you balance that, right? Because both things are true. You can't screw up, but you got to get things out.

MIKE: That's a good question.

DAVE: I keep coming back to this idea of, what are you really trying to do? What are you trying to accomplish? If you're in a startup, you're not going to be taking on IBM or Amazon. You're not competing at that level. And there's a phrase that you'll hear a lot which is, "The ideas that got us here won't get us there," when you're trying to scale. And the ideas that got you out of startup mode into productivity those ideas will not get you to scaled enterprise-level stuff. But the reverse is true.

 When you transcend the old ideas, don't discard the old ideas because what gets us there won't get the next cohort here. You end up transcending, and then pulling the ladder up behind you. I don't know if I'm making sense with that, but it's like, you start saying, "Hey, we need to have SOX compliance. We need to have peer review. The person who writes the code should not be deploying the code."

And then, you bring in a scrap team that are going to do a skunk work thing of like, "Hey, we want to stand up a quick, little server that will just check this thing on this rating service." And you're like, "Okay, cool. Where's my SOX team? Where's..." no, no, no. You have 30 days to ship this, and the right solution is to just ship it. Cut features until you ship. When you have to play at that level, like, if that little service is going to connect to the accounting database, okay, no, you cannot ship this in 30 days. That is not a working solution. But if you're just trying to do something like, oh, I just want to check your membership loyalty points, that's easy. It doesn't need auditing. It doesn't need review. Just ship what they need.

I'm sure you've all heard this. Growing up, I grew up in a kind of rural, you know, redneck part of the country. And I always heard all the time, "If you don't do it right the first time, when will you have time to do it over?" And then, I got into the software business, and I realized, no, the mantra in startups is, if you don't do it wrong fast, when are you going to get the cash flow to fix it and do it right?

And so, yeah, the ideas that get us to here are not the same ideas that will get us to there. And you need both, but not at the same time. You have to stay alert to, which mode am I in? Am I in enterprise, secure mode? Am I trying not to lose the eggs that we've collected into our basket? Or am I desperately trying to forage quickly and get as many eggs into the basket as I can, and then we'll sort out if I accidentally stole your eggs, or whatever; we'll sort that out later? But at the enterprise level, I don't need that level of security. I have to get the eggs collected. That's 17 metaphors rolled up in a weird ball, but there you go.

MIKE: You know, you're talking, Will, yes, you know, how do you keep the velocity going when you have those constraints? Another story [laughs]. I ride bikes a lot with my kids, bicycles, not motorbikes, but, you know, pedal-powered. And I discovered something great [laughs], and it took me years to find this, and I'm glad I did.

You can attach a tow...it's not a rope. You can attach a tow cable. Basically, it's a bungee cord that's wrapped in ripstop nylon that's been scrunched, so it's tough. You got the bungee cord inside. So, you don't have all the problems with a bungee cord, where it's going to have that hook, and it's going to tear your eye out [laughs]. But it, you know, it expands and contracts.

So, I attach it to the back of my bike, and then I attach it to the bike of one of my kids, right? And then, I've actually got two of them, so then I attach it again in a daisy chain [laughs]. And I've got my three-year-old that I'll put on a seat on my rack. So, I've got three kids, you know, all in a line behind me, and I'll go for a ride. And I've been doing that a lot over the last year.

And I'll tell you, the first time was hard [laughs] because that adjustment from riding, you know, riding with no constraints on you to riding with three people pulling behind you is a shift [chuckles]. And I even had to make a change. The bike that I was riding a lot...well, I've got a fat bike. So, I've got fat tires that are, like, four and a half inches wide, so I can ride in winter right on the snow, packed snow. It still doesn't work in too deep snow [chuckles]. And I've done a lot of riding on that and some mountain biking stuff. Even though it was made to go up some steep stuff, it wasn't geared low enough. So, I've got a gravel bike that's got a...lots of stories about bike, but we need it for context here [chuckles].

DAVE: It's okay.

MIKE: It's got a huge gear ratio. It's got a gearbox. It's got a huge gear ratio. And I can go really slow. And I can go pretty fast, too. But I can drop that thing down into an incredibly low gear. I have never gotten to the bottom gear yet, even pulling three kids, even going up a steep hill. I've never gotten to the bottom gear. I rarely get below...like, the lowest I ever get is, like, fourth [chuckles] out of 12. So, I'll give you a sense that, you know, this thing goes way low. It's awesome.

But [laughs] I had to change the way I rode my bike so I could keep moving forward, right? I had to change. And then, the reverse is also true. On the occasions I go out alone, I, like, almost fall down [laughs] because I'm used to having all of this mass behind me. And I have to rethink my riding style. We've got the same kind of thing, you know, thinking about this velocity. One time, I went on a longer ride with my kids, and I went up this, like, mile-long hill. And there was a headwind, a really strong headwind. And I was going mostly up that hill at, like, between three and five miles an hour, so, basically, at a walking pace.

DAVE: Just fast enough to keep the bike from tipping over.

MIKE: Exactly. Fast enough to keep the bike from tipping over. And if you were trying to do that, like, most people on a bicycle would just agonize over that because you're just not getting...that spot in the distance is not getting there very quickly. But the important part was not to get there quickly. I had a headwind. That was just the reality, right? I'm going up a hill. That's the reality. I've got all this weight, and this is the reality.

The important thing is that I keep pedaling. And as long as I'm keeping on moving, you know, your brain, you can adjust to it, right? You can adjust to these new constraints, and you just keep on going, right? You're not going to go as far. You're not going to go as fast, but it doesn't matter. The important thing is that you don't stop. Because you could think, well, I'm not going very fast. What difference does it make if I just stop? Well, it makes a huge difference [chuckles]. Stopped is very different from moving forward.

We're going to be in different situations, right? Sometimes we're going to have the headwind. Sometimes we're going to have a bunch of constraints we have to deal with, a bunch of weight we pull along with SOX compliance, you name it. But you can still set up the processes and run basically the same, right? If you're moving forward, you're moving forward.

The key thing is that you never get in that situation like, well, we're not going as fast as we were over there. So, what we're doing doesn't work. We've got to break everything, either by stopping because, like, well, this doesn't even matter. Very bad choice. Or saying, "Well, we need to completely reorganize our process. We need to get our velocity up to exactly this." Well, that's not realistic either. Because if you've got all these constraints, I think they're there, and you got to just deal with that. And you can adjust to it. Like, you can adjust to a lot, as long as you're keeping on moving. And it's really critical not to try to compare different kinds of work because they really don't correlate.

DAVE: You just connected two epiphanies that I've been carrying around for 20 years. This is exciting. When you mentioned that the important thing is to keep peddling, to keep moving, I had a job very early on in my career. I was moving out of, like, minimum wage jobs and into, like, my career. I was actually writing software for a living. I was on the networking side, so I was pulling cable as well. I was literally, like, crawling around behind people's desks and dragging cable. And if there was a hardware problem, I had to deal with the hardware. I ran a soldering iron at one point, right? I was all over the map.

And my job was to be the network guy. My job was not to break down boxes in the shipping room. My job was not to, you know, manage the sales cycle. My job was the networking stuff. And I came in and the stockroom in the back was getting piled and piled up and piled up with supplies of stuff. And I was in this mentality of, hey, I got to get this network stuff. It's not my job to do this.

And I walked in, and my boss was in the back room cutting down boxes and breaking everything down. And I'm like, "Wait a minute, if it's not my job, it's really not your job. What are you doing?" And he just looked at me, and he's like, "We need the space in order to get our job done. I'm an expensive stock boy, but I'm going to get it done."

And that was the epiphany for me of; sometimes the objective is, am I doing the job that I'm supposed to be doing? And sometimes, the focus is what do we need to accomplish? The how doesn't matter, but the what is what matters. So, I've literally carried that around in my head: I'm an expensive stock boy. I carry that around, and it has availed me very good over the years.

There's been times when it's like, there's this big, messy part of the project that nobody wants to touch, and I don't want to touch it either. But then I look, and I'm like, well, that is between us and done. So, I'm going to go be an expensive stock boy and just take care of it. And, usually, somebody higher up on the chain will go, "Ooh, that's an expensive stock boy. Let's get a stock boy." Or they go, "Yeah, we just needed that room cleaned out once, and it needed to be done. So, that was the right price to pay for it once."

WILL: I think that's a big...I've seen it a lot as sort of like, you know, teams specialize, right? And they sort of fragment into this archipelago of little islands, you know, that make up this country. And then, you have, you know, directors and VPs and stuff that they have their little region, their little fiefdom.

And I think that is one of the hardest things in terms of scalability, in that you still need people who take ownership of the entire organization, the entire app, the entire end-to-end experience. And, honestly, like, one of the things...I was just talking about this today. Like, where I think that breaks down really badly is sort of in the corporate hierarchy, like, the people you'll have are, like, VP or a director that isn't in the code every day, doesn't know where the bodies are buried, doesn't know how all these things interoperate. They have the visibility, but because they're not in it every day, they're very detached.

And I think there's a little bit of a black spot in the industry for somebody who is VP level or whatever your broad organizational level leadership. But they're an engineer. They're doing work. They will cut down boxes. Oh, this ticket was screwed up? I'm going to clear the ticket, and if you can't...I mean, bluntly, I know a lot of smart people, and I know a lot of smart people who've moved into management, you know, leadership positions. But you have to pay your dues. You have to pay the toll. If you want to ship code, you got to ship code. You got to put in your [inaudible 22:46]. Nobody gets an out.

If you are rusting, you know, then you're rusting. I mean, just like after a year on the bench as the manager of the team, like, you're going to have to ramp up just like a new hire would, maybe not that bad. I've seen it fixed places, you know, with things like principal engineers and stuff like that, but it's a systemic problem. And I haven't really seen a systemic solution other than senior, senior leadership recognizing the problem and being proactive and making sure those people are there and empowered.

Because a lot of the stuff you'll see is, they'll go around peeing in some Cheerios. There are a lot of people who have pet projects. They have things that they're doing. They have deliverables and stuff. And somebody comes in and says, "Hey, like, the interop between this department and this other department is all screwed up. Our codebase is all screwed up. We have technical debt. We've got performance and security considerations. And I'm going to have to like, you know, I'm going to screw up your quarterly results because this broad thing happens at like..." you know, there are a lot of smart people with interests in kneecapping those kinds of systemic engineering initiatives and accountabilities and stuff like that, you know, it's a ferociously difficult problem.

And I was contending with that earlier today, like, wanting that person in that role to come save me like Superman. I need heads cracked, and I don't have the juice to call these people, you know, behind the [inaudible 24:44] I can't do it. I know it's screwed up. They know it's screwed up. Anybody who's looking at it knows it's screwed up, but, like, the people that can can't [laughs], you know what I mean? I suppose a tangent, but a thought that was on my mind.

MIKE: Well, you said something. It's something I've thought about a lot. I've heard a lot of times, people who do hands-on, you know, typically blue-collar work, working with their hands, talk about how much the leadership doesn't get it. Like, "They just don't understand the work we do." And I can't count the number of times I've heard that.

And I think it's generally, like, I almost take it as a truism because I've heard it so many times that if you have somebody who hasn't done the work or is not connected to the work, they're going to miss things that are important. They're not actually going to understand what's going on. And, to your point, it doesn't matter how much you're looking at it if you don't know what to see. And it seems like there is a critical need for leadership to actually have either gotten their hands dirty or be willing to listen to the people who have and actually respect what they have to say.

WILL: Well, I don't want to be a jerk about it, but I will say this directly. You got to keep on paying the toll. Rust never sleeps. Every...I don't want to say every but, virtually, every senior engineering, leadership, management person that I have worked with I know in my bones started out as an extremely competent individual contributor. At one point, they were all good. They were all really good. I mean, once you get to the director and above level, present company accepted; once you get to that level and above, it starts to catch up with you because you know what your schedule looks like. Mike's shown me his calendar.

MIKE: [laughs]

WILL: When are you going to get your hands on the iron and do it? It's a luxury. That's like a day off. And if you don't do it, it catches up with you because everybody has to pay the same toll. If you want to be good, you have to continue sharpening the saw. Rust never sleeps. And that's when you run into these sorts of difficulties, the very difficult line to walk.

DAVE: It works backwards as well. I remember the first time I worked for a manager who had a string of managers in the early noughties and mid-noughties. They were, like, senior developers. And cowboy coders didn't get along with anybody, but they were very, very good. And they ended up in, like, CTO positions, and nobody wanted to work for them, right? Because they had no people skills. And the ones that had people skills weren't necessarily applying themselves to what type of battles do I need to fight at this level? They were still trying to focus down here.

And the first time I worked with a manager who came in and said, "Yeah, I used to be a developer, but now I'm a manager, and this is my job," and, like, the first three or four months working for him I hated because he would actually make me do one on ones.

WILL: [laughs]

DAVE: And I'm like, no, everyone knows that one-on-ones are uncomfortable, and nobody likes doing them. And after three or four of them, I'm like, this is really productive. I actually feel like I'm driving my career in a great direction because I'm actually doing this.

And that was the time that I finally realized that...and it goes back to what I said earlier. The ideas that will get us there are not the ideas that got us here, right? You need that reference. You need that empathy for the people working under you. And you need to be able to look beyond and say, "What..." It's the same thing. If you're not focused on what it costs to write code, you're going to have some struggles.

But if you are the manager and your job is to be aware of like, oh, AI is coming, and we need to be ready, or we're going to wake up, and our industry is going to be gone, you know. And do we want to have gone with it wherever it goes? And, I mean, that's one example. Somebody will react too strong to the mention of AI, but you get what I mean, right? There'll be something that, like, we're going to do this initiative.

We talked about this in a meeting earlier today about a manager who said, "We're going to pursue this initiative." And it was the wrong initiative. Turned out we got there, and there was no opportunity there. And it cost some people their jobs as a result, and that was no fun. And it was failure in both directions. Like, this person didn't understand the engineering, and they also didn't understand...they had a view of what ecosystem they wanted to put in place. And they managed to solve the wrong problem in both directions.

WILL: [laughs]

DAVE: Somebody said, "We're leveraging the inefficiencies of both approaches. [laughter]" That was, like, anti-synergy.

WILL: That's almost impressive.

DAVE: And I've been there. I've been on a team where I had a cowboy coder working with me, and I was, like, the meticulous, make sure your tests pass; make sure your code is expressive; make sure to actually dah, dah, dah. And there were times when I'm like, "You're going so fast, and you're breaking things." And he was like, "You're dragging an anchor when we need to get stuff done." And there were times when we got so much at loggerheads that we ended up shipping too little, too low quality and too late because we leveraged both of us. We both dug in our heels, and we ended up with nothing.

And I think I've told this story here, but I worked with a guy named TJ at CoverMyMeds who was astonishingly good at picking his battles. And he and I were really good friends, and he got really, really good at seeing when I was about to turn and go down a rabbit hole. And he would just kind of put his hand on the back of my belt, and say, "Whoa, whoa, whoa, whoa, wait, we don't need to go down that rabbit hole." And we fought a few times over [inaudible 30:55]. And I finally said, "You know what? You're right. We don't need to go down that rabbit hole."

He was one of the first people I've ever worked with where pair programming delivered on every promise pair programming has ever promised anyone. And we were also linearly faster. Like, the two of us could complete a sprint's worth of work for two people in, you know, a week and a half. We literally...every way we went faster because the synergy worked so, so well because we were solving the right problems, and we were leaving the wrong problems alone. And that...oh, so good.

WILL: I'm a pair programming seller, and I always evangelize pair programming.

DAVE: Amen.

WILL: I think it's good. It's not a silver bullet. It shouldn't always be everythings all the time, but I think it should be...I think we should do a lot more of it. You know, pair programming now, pair programming, you know, forever. Like, that's all. That's all I'll say on that. That's all I'll say right now.

[laughter]

MIKE: I got to say, it's one of my favorite things to do because the amount that you learn on both sides of a pair [inaudible 32:11]... a lot of times, you have a more senior, a more junior person, but it tends to flow both ways. The amount of knowledge transfer that happens there is unlike anything else that I've experienced in software development.

Like, you can read documentation, and a majority of that is just going to pass right through your brain [laughs], not that it's not technically possible to go read some dry technical documentation and get lots of clarity from it. But when you're watching somebody work, or they're watching you work and seeing how you make each of those decisions, it just changes that equation typically. You see all that weren't captured in the documentation that you just wouldn't see otherwise.

WILL: Yeah, well, I mean, and if it's your stuff, you know you didn't write everything down. You know you didn't do it. But, anyway, a lot of stuff you're talking about, I really do feel like a lot of those that, as line-level managers, I'm going to say flat out, I'll take my hot take; this is your hot take of the session, I think all line-level engineering managers should spend 25% of their week, maybe 20%, right? Eight hours a week, a full workday, every single week should be pairing with the people on their team so that they have both an understanding of like, okay, here's what's going on.

If you're a line-level manager, you should be a very proficient coder. You should be a senior-level engineer. You should be good at that. You can't be like, "I'm a VP. I don't care anymore." No, no, no, you don't get that out anymore. You should be providing that kind of judgment, that kind of insight, that kind of understanding. You should be working with your team and figuring out where everybody is. Don't [inaudible 34:15] like a one-on-one. Get in there and feel it.

All right. Are you writing tests good? Are you thinking about parallelism? Are you thinking about error handling? Are you thinking about design? You know, all this stuff. You get paid for that. That's why people pay you to be around. And it keeps your hands, you know, in the iron, and you have a feeling for how things are going.

I'm actually on a Slack thread right now with three, four staff engineers who are like, "Why are my builds so slow on these laptops?" And I have been fighting the good fight. There is a security team that has installed real-time virus checking on all engineering workstations. And it is virus scanning intermediate build products in real-time. It's a substantial CPU hit. I have been wrestling with these guys for a long time, many months. And these guys didn't even know. They're just like, "Wait. Wait, what? It's doing what?"

And I'm like, "Yeah, man." I've been arm-wrestling these guys to try and find a more economical accommodation to satisfy their security concerns while I can still ship these features. And if you never code, okay, you know what I mean? You're a director. You're a VP. You're up the levels. That's not actually your job anymore. You probably are wasting your time doing that.

But, like, line-level managers, I want your hands...I want you in the muck with the rest of us, at least a little bit, so you know what the hell's going on. Because even when that front line, you know, your NCOs or whatever you want to call them, you know, the people who are on the front line, if they've checked out, how's the information going to filter up? You know what I mean? Anyway, my two cents.

DAVE: It's how do you get feedback? Yeah.

MIKE: I've got one pushback against your hot take. I don't think 20% is enough [chuckles].

WILL: Yeah, sure. I mean, you're right. I agree. I think 25%...I think 50% is probably where I would cap it, but it's somewhere in between there. But I don't think...how do I put it? Like, I'm not asking for 30% and expecting to get 20%. This isn't like a negotiation where I know I'm not going to get everything I want. Like, I'm just saying what I need. This is the real number. I want a real 20%, and getting 8 hours consistently every week out of a manager's schedule to pair program is a substantial ask. That's hard to do. You need support. That is a rare bird to make even that happen.

MIKE: I stepped into leading an internship once, where the person who was leading it...I say an internship, it was an apprenticeship. There were some people that we wanted to bring in to be full-time engineers. They weren't coming straight out of college. These were generally people who'd maybe been in another profession, and they were ready to come and learn what they're doing. And I'm not the one who started it. The one who did left, and I stepped into it. This was a number of years ago.

My manager at the time said, "I think you should be spending 50% of your time writing code." And I laughed at him [laughs] because I was spending, you know, like, 80% of my time pairing with those apprentices. Because how else were they going to learn the ropes unless they were working with somebody? And --

WILL: Well, but that counts. Pairing time is coding time.

MIKE: That's true. Fair. Fair.

DAVE: I remember pairing with Eddy Lopez here at Acima when he was fresh out of it. He was fresh on the engineering team from QA. He might have still been on QA. And he and I were pairing, and I asked him something, you know, "Where's this in the source control?" And he wasn't sure how to...and he's like...And I'm like, "Okay, hang on." And I cracked open a terminal, and we spent an hour playing with Git. "And I'm like, here's where to put it. Here's where your sandbox is. Here's the distributed nature. I can be the server. You can connect to me, and I've got all the changes because da da da da da." And I was explaining where the deltas go and all that stuff.

And we were on the podcast a few months ago and Eddy pulled this story from his perspective, which is that he has paid that forward so many times. And I'm like, that was probably one of the most effective hours of my entire career because I invested in someone who then has now paid in, you know, bazillions of dividends. And I'm not trying to blow my own horn. I'm really happy that that happened. When Eddy was like, "Oh, yeah, you did this, and I love it," I'm like [vocalization], I'm going to go for a long time on that compliment. So, it's awesome.

MIKE: We landed into the value of sharing information. We've rerouted a little bit because [laughs] it was just such an important topic. Have we really hit how you keep that velocity going, how you keep moving? Because you asked, I think, a vital question, Will. And I gave kind of a metaphor, but I don't know if I got really into the technical details, how you do it on a development team. How do you keep that motion going?

WILL: And, you know, actually, like, so there's another issue. Like, I have a lot of meetings on Friday. I'm trying to put my meetings on Fridays, because, listen, man, I'm going to show up to work on Friday because they're paying me, and I will do it, but they're not spending their best [laughter]. It's a fairly linear degradation of my engineering effectiveness. I'm still not bad, okay? You got your money's worth out of me today, but yeah, you know.

And so, I was talking with my boss, so my boss long-time consultant. And he sort of, like, you know, went full-time and moved into engineering management. But he spent a lot of time as a consultant freelance, you know, developer, you know, that's me. Like I'm, you know, technically unemployed. Like, I've got a long-term contract with my large electronics retailer.

And it's sort of like my team, you know, that I run sort of runs things my way, which is sort of very like, what have you done for me lately? Like, because I'm just used to the mentality of, like, people are writing me a substantial check for my services every week, and I want them to know what they're getting all the time, and that gets my contract renewed. I got another year. And it's a mentality that sort of the boss shares, and I share. And he's working with another team, and they don't necessarily think about things the same way because they were not brought up in an environment of existential fear [laughs] the way we were.

So, I have a story, right? And it's my mom. She had dogs for a long time. She had greyhounds. Greyhounds were her favorite dogs. She had greyhounds. And she liked to get, like, rescue greyhounds, like, retired dog track racers. I don't know if that's such a thing anymore. I think we've kind of phased out dog racing, which is probably good. But, you know, they would retire. They couldn't run anymore. They tore their ACL. Whatever. And they'd just be like, well, we're just going to dump them in a landfill. But I guess if you want them, you can have them, right?

So, she would get these dogs. And they were the laziest animals that have ever lived. You'll roll home, and you'll have a golden retriever, and it'll just be ecstatic beside itself, jumping on you, giving you kisses in the face. Almost, if not literally, like, wetting itself because it's so excited that its people are home. It's so happy. The greyhound version of that was...they would lift their head off the ground as they were lounging [laughter], look at you, and their tail would wag three times [laughter], wag, wag, wag. Boom.

DAVE: Head back down.

WILL: Head back down. But every time you would take them out in the backyard to feed them, you would get the most magnificent, beautiful, joyous, absolutely astounding run. They would tear around the backyard in a figure 8 at 30 miles an hour. I swear to God.

MIKE: [laughs]

WILL: It was magnificent. Magnificent. The most beautiful thing you've ever seen in the world would be just to see the beautiful athletic power and grace of a greyhound, wholesale. Because they had grown up in this environment [laughs] of existential fear, where literally, if they wanted to eat, they needed to run like their lives depended on it because they kind of did.

And sort of like, you know, so my boss and I were talking about how can we...it's not that this other team doesn't have...it's not that they're not smart. It's not that they're not hardworking. It's nothing of the kind, but they don't necessarily have that mentality. And so, the question was like, we've got these sort of deadlines, you know what I mean? Economy is tough. Macro is tough. The business is like...it's not bad, but it's certainly challenging. Everybody is pushing really hard to keep their head above water. Everybody's working hard. And how do we get this team to do the thing?

And what he settled on, and it's been on my mind since we had this meeting, and now that we have this conversation, it kind of brings it full circle, what he settled on was he just sat down with them, and he's like, "Okay, you know, this is our thing." And he just started coding it up.

And he exhibited the mindset of like, okay, we've got to move fast, so let's move fast. Let's do this then. Let's just put it together. Let's get the scaffold up. Let's get the skeleton, the framework. We're going to make some...we're going to build a jig. We're going to make some operating assumptions that allow us to move forward. And we're going to sort of start the rough sketch, and then we start filling in the outline, filling in the details. We're going to paint the color, and the shading, and all those things.

And the only way he could really get this mindset onto these people, you know, which comes from decades of high pressure, high production consulting is to just get in there and show it to them, show them how it feels. And then, as he did it, the clouds parted. And they were like, "Oh, okay, I see what you need. I see what you want to do." And that kind of knowledge transfer, endemic to the work we do. That's why I'm a paring zealot because I don't know of a better way to do it. I don't know of any other way to do it. And I am fully aware of how fantastically indulgent it seems on the surface, and the sort of visceral, like, oh my God, I'm going to pay two of you to just sit there on a single keyboard all day?

MIKE: [laughs]

DAVE: That's twice as expensive.

WILL: Do you have any idea how much this is costing me, you know, to do this? But I just don't have a better --

DAVE: And then, you let that stop you out, and you're like, okay, well, I'm going to work alone. And you just kind of sit there and go, do you have any idea how much it's costing you to have me work on this without a second brain? It's, you know, yeah.

MIKE: Well, that's it, right? That what works is what works. It doesn't matter how much you don't like seeing 2 people sitting next to each other on 1 keyboard. It's what works [laughs].

DAVE: And if you're banging out 30 controllers with just RESTful actions, then one or two for pairing to make sure everybody understands this is how we roll this out. And then, yeah, go to your office and just I'll do these 15. You do those 15. Let's meet back up at 5:00, and we'll review each other's stuff because you're just banging out boilerplate at that point. But you do the first ones together because there's knowledge transfer going on, and yeah.

WILL: Yeah, absolutely. The question that we had was sort of, like, how do you get that mentality? Because it wasn't even a technical thing. These guys don't know how to do the work. They understand the work. They're very competent programmers. They're really good. But that sort of, you know, that piece wasn't something that they really understood until they saw it. And then, once they saw it, they're like, "Oh, oh, okay, I get it. I understand now. All right, let's go." And then, you know, boom, that's how I [inaudible 48:00]

MIKE: You know, the kind of meta stuff around software development is so vital. It ends being most of what we talk about on the podcast because [chuckles] it's critically important. But you're probably not going to learn it in school because it's...I don't know if it's...it's probably hard to communicate about but it also sometimes, I think, seems trivial.

You think, well, we need to teach you the hard stuff. We need to teach you about writing code, and writing code is critical, right? Learning to express yourself in that way is a change in mindset that does not generally come naturally. And you have to bang on that for years to get good at it. But if you just focus on that, you're missing half the picture.

Like, Dave, you talked about spending an hour teaching somebody Git. I mean, that is important, learning how to use those command line tools, you know, whatever tools that you use, you know, that are on the command line. Like, learning the tools for your job —that's important. And without that, you're not going to be able to work very effectively. And there are so many things like that.

WILL: I thought so many people like the debugging, you know what I mean? Like debugging. Like, hey, how to use a debugger. Like, some people don't like using debuggers. Like, you should know how because a well-configured debugger where you could just stop the code, it's like, whoa, whoa, whoa, hang on. What are we doing? Why is that X instead of Y? That's critical. Just the idea, the mentality of debugging.

I taught some kid just today, you know, another one of my golden bedrock principles, which Mike has heard out of my mouth many times, and I'll repeat it a thousand times more with no shame at all: Always debug from the known to the unknown. I had a guy, he was like, "Oh, my analytics, they're not working. I thought I turned this analytics thing off, but I'm still seeing [inaudible 50:17]. This is all screwed up." I'm like, "Known to the unknown," you know what I mean? And I'm like, "Okay, I wish you'd check out the whole component."

And he's like, "Okay." But the analytics are still fine, but known to the unknown, take out more, delete more code. You got version control. Rampage. Don't do the thing. And he's like, "Oh my God, you know, 15 minutes of just taking a [inaudible 50:40] at this thing until I finally made the noises stop." And I was like, oh, somebody duplicated it. Like, this thing exists in two places from, like, known to the unknown, always go from the known to the unknown. However, you can make it work, make it work, and then move from there.

I'm like, that's just the kind of thing where it's just like, I think, hopefully, if I got it into his head, that was another one of those, like, one-hour conversations that he'll be like, "Old man Archer said, 'Known to the unknown.'" And I'm going to pop up over his shoulder like Yoda, if I did it right. And I will save him a thousand times [laughs].

DAVE: Amen.

MIKE: It's interesting the arc this conversation has followed because we talked about velocity and balancing that. And, certainly, there's a balancing act. But we didn't really linger much on that idea because maybe it's clear in all these different kinds of work. We've talked about how to communicate with each other, and share information, and keep organizational structures effective.

WILL: Going fast is a feeling. You got to feel it. When you're on a team, and it's clicking, when you're writing code, and it's clicking, when you have the feeling of like, you know, mastering the command of your tools, understanding the organization, the needs, the codebase, it's a feeling. When it all comes together, you feel it in your gut. It feels good. I can't explain it to you, but I can show you how it feels.

DAVE: It feels like flow, right?

WILL: Yeah.

DAVE: You get into it, and you're excited, and then, all of a sudden, it's 6:30, and your wife is like, "Are you coming home?" And I'm like, "Oh, did I miss lunch?" And she's like, "Yeah, you missed lunch. Come home. You're missing dinner."

WILL: Like, you know, the mentality of like, you know, we need this thing out. We are going to make compromises. If we are going to cut some corners, we're going to cut the right corners, not the wrong corners. We're going to give an appropriate amount of spit and polish to this thing. How do you make those judgment calls? I mean, you just got to know it, and you can get it through osmosis by sitting here with me, or with my boss, with whoever.

DAVE: Sure.

WILL: But I can't give you a book and just be like, "Here you go." And that's the weird part of engineering; you got to feel it.

DAVE: I think it's interesting that we're in a phone call talking about velocity versus thoroughness and all three of us are bringing communication. And what I realize is I think at intermediate to senior levels in your career, interpersonal communication becomes the most difficult technical skill that you want to scale. And if I was having this conversation with you 25 years ago, I would be like, you got to know your text editor. You got to know how to do da da da da. You got to know this tool and that tool, and you got to know this other thing. And, oh, you need to learn this other thing.

And it was all the kind of things that a junior to intermediate level developer would be focusing on, mastery of what's right in front of me. And then, you start realizing, oh, I spend all my time tackling problems that are bigger than 12 people together. We need to learn how to communicate. And I'm no longer in a spot...

And the great thing is, we end up hiring juniors who are trying to master their tools and, like, don't bother me about communication. I got to figure out how to use this tool to do this thing. And you're like, yes, you need to keep mastering your basics, but while you're doing that, I need you to come talk to me about...And I think it's interesting that the higher up in the seniority you go, the larger the problems you take down, and then, all of a sudden, the problems that you've experienced are at that level instead of one level down.

WILL: Well, I mean, I also say this. I think one of the real bear traps in the industry, another [inaudible 54:48] difficult problem in the industry is not knowledge transfer from juniors. Juniors are actually pretty comfortable, usually. Usually, they're very comfortable. The really tough ones are the seniors.

MIKE: [laughs]

WILL: That's leadership with a capital L because, like, you know what I mean? You're going to take Ls. Things are going to move. Things are going to change. The needs of the organization are going to change. The needs of the industry are going to change. Like, things are going to move, and there's a natural human reluctance to look foolish to, like, be a beginner again, and again, and again, and again, and again, and again, and again. Knowledge transfer among seniors, and keeping seniors current, and keeping seniors flexible and empathetic, and stuff like that, that's the real challenge.

DAVE: Convincing somebody that this style of code is more readable than this other style when they are utterly familiar with that other style, and they're like, "Well, clearly, it's readable." And I'm like, "Nobody else on the team agrees with you. It's familiar to you. It is unreadable to us. Would you consider doing it this way?"

And you get that spot where, as a junior, you're humble, and you're willing to change anything. And you get to intermediate, and you're like, "What I know works." And then, to get from there to senior, you have to go, "What I know works, and what you know will also work, and we're going to do it your way because we need to move."

MIKE: And that is hard. I read an article the other day by a scholar of the Hebrew scripture. The specific text isn't that important. The important thing is that it was written a long time ago. And what he said was that there's this recurring theme that you have a leader who starts out humble, and they apply that humility, and they become very prosperous, and they get set in their ways, and it causes all kinds of trouble [laughs]. And it's not a new problem. It's not a new...but we still have to fight it, you know [laughs]? And we have to be willing to do some introspection and say, "I'm that guy now. And I need to be willing to humiliate myself."

WILL: Well, I mean...so, go ahead.

DAVE: I'll just say the biggest compliment, I think, I have ever been given in the last year was also from Eddy, ironically. I like Eddy. He says nice things about me.

WILL: [laughs]

DAVE: But we were in a meeting, and I asked, like, a bone stupid...I mean, like, the kind of question that everyone in the room was like, you're asking that? I won't go into the question now because if I don't give you enough context, it's going to sound like an offensively stupid question.

WILL: [laughs]

DAVE: And it was, it was borderline offensively stupid. But as soon as I asked it, all the juniors went, "Yeah, I want to know the answer to that, too." And so, we realized we had zero knowledge share. Like, everyone on the team thought everyone else on the team knew the answer, so they didn't want to ask. And Eddy turns to me, and he says, "You are fearless about asking stupid questions."

[laughter]

And momentarily, I was kind of offended. And I'm like, no, he meant that as a compliment, and he's sincere, and he's right. I'm willing to ask really, really dumb questions. If I feel guilty, if I'm self-conscious, I will say, "I know the answer to this, but just so everyone else knows, you know, it's like, how is this working?" And you got to be willing to do it. I've had people get impatient with a stupid question, but I've never had somebody think I was stupid for asking a stupid question. I've never had somebody think I was a coward for asking a stupid question, to put it that way.

WILL: Do you guys want a life hack for embracing your inner idiot?

DAVE: Oh yeah.

MIKE: Yeah.

WILL: All right, so this is what I do. This is, like, actionable stuff. This is the Slack life hack. I won't discuss ticket work in a DM, and I won't tolerate other people discussing ticket work in DM. If you got a question about how to do your job, it goes in a channel. Maybe the team channel. It doesn't have to be in a public channel. You don't have to put it on general, or whatever, but everything.

If it's like, "How does this work? Hey, do you remember how to do this API?" Anything. Anything at all. I mean, if you want to have a private conversation with me, it's totally fine. Let's talk about our weekend. Let's talk about the dumb thing that thus and such said in thus and such meeting. Like, "I can't believe David had to ask that, Jesus, that guy [laughs]." But, like, none. Ever. None. Zero. No chance.

DAVE: There's a countervailing force that you have to be very vigilant for, which is all it takes is one VP to say, "Just get it done," when somebody asks a question. Those questions will evaporate because, all of a sudden...we've talked about psychological safety before on the podcast, right? Where it's like, if you have someone out there...when somebody asks a question like that, the response from the people who know the answer should never be, "You should know this."

The answer should be, "Yeah, you should know this. Let me tell you. Thank you for asking this because I should have told you this." And that is so, so helpful is to be welcoming of the dumb questions because if somebody's not willing to ask a dumb question, you got a lot of people walking around with a dumb question unasked, which means they don't have the obvious answer, which means they're dumb. It's...yeah.

WILL: And, I mean, the other thing that is like, you know, to be perfectly honest with you, I mean, there's always teams shifts and teams ebb and flow, and people come in. And conventional wisdom that everybody knew six months ago it's like, well, you got three new devs on the team. They don't know that. How could they? They weren't there.

And sometimes I just forget, okay? Like, I'm lazy, okay? I am. I'm as lazy as I can get away with being. And also, also, also, it becomes, like, an unofficial Wiki. I'll search a Slack, you know what I mean? I'll search a Slack Channel. Oh, weren't we talking about that thing the other day? And then, I'll find it, and I'll probably post it again. I'll probably repost that link because that's just how it goes.

I mean, in terms of VPs just being like, "Just get it done," you want to be out of this thread because you got other stuff? The response to that is, "No problem, Jim Bob. We're going to work it out." I'm going to start another thread, and Dave and Mike, and I are going to figure out exactly how this thing gets done, right?

If VP is saying, "I'm delegating this," that's fine. The only thing I want to hear is, "We got you." And then, the team figures out how to do it, and, like, they don't pinged every 30 seconds as we're hashing it out. That's fine. If he wants to go cook, let him cook. It's fine. This is my job. I got it.

MIKE: I think that's a pretty good stopping spot.

DAVE: It is. This was awesome [laughter]. You know it's a good podcast when you want to do two more hours on the tangents that you've dug up part way along the thing, yeah.

WILL: Well, happy Friday, gentlemen.

DAVE: All right.

WILL: You all be well.

DAVE: Have a good one. Cheers.

MIKE: Thank you. Until next time on the Acima Development Podcast.