Acima Development

On this episode of the Acima Development podcast, Mike hosts a conversation about software development life cycle methodologies, opening with the line usually attributed to Mike Tyson: everybody has a plan until they get punched in the mouth. He illustrates it with a day from about 20 years ago in the suburbs of Chicago, when he and his wife planned to collect a free piano from an elementary school and a bunk bed with a slide from a seller farther south. The U-Haul turned out to be an hour away through traffic, the truck had no ramp, the movers he had hired gave up waiting, and the piano sat at the top of two flights of stone stairs. His wife's idea rescued it. They offered the movers' money to a construction crew working down the street, and the crew carried the piano out. Mike got home around 11 that night. From there he lays out the history, from the linear process Herbert D. Bennington documented in 1956 and nobody called Waterfall until the mid-1970s, to the 2001 Agile Manifesto, which he points out is four stated preferences rather than a process. The group resists the idea that Waterfall is simply obsolete. Justin notes that it got NASA to the moon on a budget worth several percent of GDP, and Kyle adds that it made sense when software shipped on CDs you burned and mailed, because there was no pivoting after the discs left the building. Dave recounts building the REALImage 3000 graphics card at Evans & Sutherland, where the chip spent six months in the fab and came back with two leads soldered backwards. Red and green were swapped, and the team had to write a very fast post filter to correct every pixel of every frame. He connects that to lean's idea of inventory, where the assumptions you have not verified bite harder the longer you carry them. Vivian questions whether Apollo was really Waterfall at all and argues the only genuine difference between the methodologies is the size of the planning scope. Will keeps pulling the conversation toward the business side, since engineering tends to love Agile while the people committing to quarterly numbers tend to hate it. Eddy floats a hybrid, Kyle calls it Wagilefall, and Mike credits Will with naming the version that fuses the worst of both: Whirlpool, because you circle the drain. The last stretch is about trust. Mike argues that iterative work only happens when leadership is genuinely willing to say go build something, which he compares to commissioning a Renaissance artist to paint a ceiling. Vivian asks whether psychological safety runs both directions, since managers also need confidence in their engineers, and wonders how an engineer earns that upward. Matt answers with communication and honesty about what might not work, and takes the position that a bad hire is the hiring manager's failure rather than the hire's. Thomas describes trust as a currency that compounds as you show progress. Mike closes with his friend's dairy farm, where the manure is unavoidable but gets washed into a reservoir, fermented, and spread on the fields. Software works the same way. You will not avoid the mess, but you can build a process that deals with it as you go rather than leaving one enormous pile to land in at the end. Transcript: MIKE: Hello and welcome to the Acima Development Podcast. I am Mike, and I am hosting again today. A little side note: Acima has a parent company, Upbound, and we're fusing more. Like, we're more of a family or a team or something. Like [laughs], somehow we're getting closer together. So, we may be putting Upbound in the title in the near future, so don't be taken by surprise if you're listening regularly. That's it. And with that, as usual, let's...Oh, I should introduce people who are here. We've got Dave; we've got Thomas; we've got Ramses; we've got Justin, Kyle, Eddy, and Vivian. I think we've all been here before, so we'll jump right in. I'm going to first reference a quote by Mike Tyson. Actually, it probably isn't by Mike Tyson, but it's attributed to him. I looked this up, and I guess there's no, like, clear connection, but he may have said it. And the quote says, "Everybody has a plan till they get punched in the mouth [laughs]." Whether or not he said it, he probably had the same idea. He probably had the idea at some point. And, you know, there's this idea plans don't last very long once you get into, you know, sparring. I was thinking of plans that I've had in the past that have failed. I had, like, a simple one. My family and I were going on vacation. As we went in the garage, literally in the garage, we were grabbing something out of the fridge before we left and noticed that the fridge wasn't running. Like, "Oh, that's not going to go very well for everything sitting in the fridge," and, you know, I had to redo the plan. But I got a better one that was further back. About 20 years ago-ish—it was a little less than that, but approximately 20 years ago—I determined there was a few things that I needed. My wife and I decided, oh, we need to get a couple...two things. There's two primary things we needed to get in the suburbs of Chicago. One, we found out that there was an elementary school that was giving away all of their pianos. They didn't think they needed pianos anymore. We thought, "Oh, great, we'll get a free piano and bring it home, and then we'll have a piano," because we didn't have one. So, we thought, "Oh, that'd be great. We'll get the free piano. We'll just have to pay to get U-Haul to bring it home." We also found that there was somebody farther south in the suburbs that was selling a cool bunk bed that had a slide, and it came down at the top bunk so you could take a slide, you know, it was cool. And we thought, "Okay, this is what our son needs." Came up with plans. So, I took work off that day, and I called U-Haul and asked them to find a location near where the piano was where I could pick up the truck, so I wasn't driving the truck through, you know, Chicago traffic. I'd pick up the truck, drive over to the school. I called some movers, and I was going to pay them to meet me at the elementary school, load up the piano, put it in the truck. And then we were going to drive down and pick up the dismantled bed from the house of the woman who was selling it; drive home, roll the piano down the ramp because, you know, you're going down. We could do that when we got home and pull everything off. Made all the plans. I got up, drove to the U-Haul facility, and found out that the U-Haul people had no idea what they were doing. And it was at least an hour away through dense traffic and neighborhoods over [chuckles] to the elementary school. You know, this was 20 years ago. This was before...You know, technology has advanced a lot. In those [laughs] years, they didn't have anything, and thus began the series of [chuckles] things that went wrong. We, like, "Well, this is the U-Haul we get." Turns out the lift haul that they had gotten for us also didn't have a ramp in the back. It just had a low bed. So, anything that went in and out had to be lifted in and out. Remember, this is just my wife and I and my, like, three-year-old son [laughs], and a very heavy piano. Like, "Well, this is what we get, I guess." And it took a lot longer to get there because of the traffic than I expected. I call ahead to the movers and asked if they could wait a little bit, but in the traffic, it was going to be, like, two hours. We weren't going to get there until hours after the movers were supposed to meet us. And, in fact, it took us so long to get to the elementary school that by the time we got there, they were just about to close. So, there was, like, one lady who was there who showed us where the piano was. There was one left. The others had all been taken. Like, okay. And this is this...It was an old school in this fancy, old building with, like, two flights of stone stairs being the only way out, and a really heavy piano, and my wife and I [laughs], and a truck with no ramp in the back. Like, oh, okay. It turns out we actually...There actually was an answer here. And my wife says, "You know, when we were driving down the street, I saw construction sky...There was a crew of people working there, crew of guys there building. How about...You had the money that you're going to pay the movers," you know, because they'd left hours ago. There's no way they were going to wait for us. "How about you offer them the money to come in and haul the piano down the stairs and into the truck?" Like, that's a good idea. Drove over there, and they were willing. They're like, "Yeah, sure," because we had, like, 100 bucks or something. Like, "Yeah, I'll do it. Sure. Free money." Well, not quite free, but close enough, because it was a big crew of burly guys. So, they picked up the piano, took it down the two flights of stone stairs into the truck. Okay, yay, we're that far. Next, we had to go pick up the bed, and the lady there had an appointment that night, and we had to...In order to get there ahead of that, we had to get there in, like, 30 minutes, and, by this point, it was rush hour. About two hours later [laughs], we arrived at her house. Luckily, she was really nice, and she had gone to her appointment or skipped her appointment just so she could get us the bed. I was so thankful [laughs]. There was no way. We were just driving through, you know, stop-and-go traffic for hours waiting to get to that place. And so, I was incredibly grateful. Finally, so now we've got the piano; we got the bed, and started driving toward home. And there was no way to get the piano out of the truck when we arrived there. And I had to have the truck dropped off that night, or I'd pay for an extra day. So, I called somebody. I called a friend. He ended up calling somebody else who had, like, three or four teenage boys [laughs] who were available. They ended up meeting us when we got home, and they came in, loaded up the piano, got it off the truck, and

In this episode of the Acima Development Podcast, the team digs into what happens to engineers when the org chart shifts underneath them. The timing is deliberate: Acima recently consolidated teams and realigned around value streams, the structure recommended in Team Topologies. Mike opens with sleep. After five years of falling asleep next to his youngest son, on the floor as often as the bed, he can now drop off anywhere. A habit he had held since infancy turned out to be trainable once he had no choice. Guest Seema joins from parent company Upbound on the eve of her 21st work anniversary. She traces a career that began in 2005 as a PowerBuilder developer in the servicing department, moved to classic ASP corporate applications when that department closed, pivoted to call center and IVR work during COVID, and landed on the RACPad point of sale team about six years ago. Six or seven office buildings and more reorgs than she can count later, two things have kept her there. One is staying relevant, which for her meant telling leadership she was bored and asking for harder work. The other is the community of coworkers she can call when a deadline like the RACPad Mexico rollout gets tight. She recommends Mel Robbins' The Let Them Theory and Simon Sinek on finding your why, and she starts her mornings by counting small wins. The rest of the panel pushes on where acceptance ends. Dave argues for judging change by its trade-offs instead of by good and bad, and defends leaders who cut through a stalled debate even when half the team ends up unhappy. Vivian, an intern about to join a new team, describes trust in the people around her as the thing that made two months of constant change workable, and notes that strong engineers tend to hold tightly to one or two things and stay loose about everything else. Jordan brings the counterweight from a startup acquired by a large bank, where the rules could not be changed and the honest options were acceptance or an exit. The point everyone converges on is the why. When leaders explain their reasoning and take feedback seriously, people absorb hard changes. When they skip it, the resentment is about not being heard rather than about the change. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. A bit of context before I give more of the intro. Acima is part of a parent organization, Upbound. And, you know, we've got people from Upbound that, you know, we have joined with, with lots of experience, which will be relevant today, as we've got Seema, who's joining us from, you know, from Upbound, who'll be joining our conversation today, will be very relevant for the conversation. But first, I'll give you a bit of an intro. I'm going to talk about sleep. So, you [laughter] ever tried to sleep in someplace different than your own bed [laughs]? And you know how hard that is. You know, it takes, like, days. You know, you go to a hotel, and you never sleep as well, wherever it is you have to sleep. And I think almost everybody has experienced this. It's a pretty universal experience, and something that I've historically had to deal with. A few years ago...it's getting to be a few more years ago now, probably more than five years ago. I used to be, like, a side sleeper and sometimes even sleep on my belly. And I did a lot of camping with my kids, like, in the backyard especially. And laying on your arm on the hard ground overnight doesn't do good things. And [laughs] I noticed that after a summer, like, wow, I'm getting tingling in my fingers. This isn't a good thing. So [chuckles], I had to learn to redo my sleep position, which was really, really hard at first because changing something that you've done for decades is just...it's a really hard habit to break, you know, something you've been doing since probably I was a baby, right? And [chuckles] making that change was really hard, and, eventually, I got used to it. I can now sleep on my back, roll over my side a little bit. It works. And then I've got [chuckles]...my youngest child is a terrible sleeper. He...well, let me rephrase that. He actually sleeps pretty well, but if he's alone, he just doesn't sleep well. So, I usually lay next to him to get him to fall asleep, and I've done that since...he's five. He's five years old. So, I've been...I had to do it so much, I ended up just usually falling asleep next to him, right [chuckles]? And I have fallen asleep on the floor. I have fallen asleep on his bed. I have fallen asleep somewhere in between the floor and the bed [laughs], you know, just about anywhere. And having dealt with that for the last five years, I'm to the point where he doesn't need to lay on my arm to fall asleep. He's okay with that. You know, I'll read a book to him while he's falling asleep. You know, he loves laying on my arm, but now he'll do without that. And I can usually go somewhere else for a while, but he'll still wake up in the night and say, you know, "Papa," and needs somebody there. So, I'll tell you, five years of sleeping in random places makes you get really good at dealing with sleeping someplace different, and now I can sleep anywhere [laughs]. I go to a hotel, I just drop right off, and I am fine. Uncomfortable, fine, you know [laughs], with sleeping on the floor, I sleep great. It doesn't matter. If you go through enough of these things, eventually it breaks you, and you're just okay. And [chuckles] I slept...I was traveling down to our corporate office in Texas about a month ago, and I hate hotel pillows. They always give me a kink in my neck. I got a terrible kink in my neck, but I slept through it anyway. I still got a kink in my neck a month later. Like, if you see me [laughs] wincing a little bit, that's why. But you know what? I still sleep fine. So, apparently, even though it's so hard to undo that, you can train yourself to be able to sleep anyway in different places. Today, we're going to be talking about dealing with change, particularly org changes, and all the changes that happen in an organization. You know, we like to hunker down and do our engineering work, but sometimes we can't always do that. Recently, we've kind of realigned our team structure to be oriented toward value streams, which is considered best practice in the industry. I mean, this is a pretty standard thing to do. There's a well-known book, Team Topologies, that goes in all the research about team structure that a lot of us have read. It says we should be doing exactly this. We have the stream-aligned teams, platform teams, enabling teams, complicated subsystem teams, is what they recommend. And, primarily, you should have these stream-aligned teams, and we've been organizing around that. We've been gradually moving this way for years, but, you know, we've really made a significant change where we consolidated some teams recently. So, it seemed timely to talk about change. Now, Seema has been with Upbound, I think, longer than any of the rest of us here, so she's a perfect person to talk to dealing with these org changes that happen over time. And you've survived, Seema, and you've survived it. And you're still here to tell the story, or more stories, and hopefully some dirt that we could hear [laughs]. So, that's the topic today, and tactically, how do you deal with it? Because it's disruptive, right? Anytime you have change, it's disruptive. It slows you down. It makes things harder, and it's painful; it's awkward. Change is not fun. So, what do you do? That's what we're talking about today. I'm going to start by opening things up. And do y'all have any initial thoughts, any of you, Seema or anybody else, about, you know, what do you do to deal with change? SEEMA: Yeah, what a great topic, Mike. But, first of all, thank you so much for having me here; what an honor. And, to be honest, definitely it's my first time to be on Acima Podcast, but it's my first time to be on any podcast. MIKE: [laughs] DAVE: Oh, nice. SEEMA: So, I'm super excited, but a little bit nervous as well, but looking forward to talking to you all for the next 45, what, 50 minutes, right? As I was mentioning earlier, talking about my name, in all our teams' transcriptions, you know, every time somebody says, "Acima" it shows up as Seema, so maybe it's time that I should change my name, right [laughter]? Well, that was one fun fact. Another fun fact about me, like, talking about how many years I have been here, Mike, I don't like to talk about this fun fact because I'm a little bit shy [laughs]. I don't want to share this, but tomorrow is my 21st work anniversary with Upbound, so yeah. So, I don't like to share it with people, but then, obviously, Mike has given me this opportunity to be on this podcast, so I wanted to share it with you guys. And I couldn't be more proud to be talking about RAC and changes and various reorgs we, or I, have gone through and still survived, I guess, you know? So, just to give you guys...can I go ahead and give a little bit of intro about myself, Mike? MIKE: Please. SEEMA: Yeah. So, I joined Rent-A-Center on August 8th, back in 2005 as a PowerBuilder developer. I don't know how many of you still remember PowerBuilder. It was a software used to develop the client-server applications. So, I joined as a developer to build applications in our servicing department. But then, I think, two or three years after I joined, they decided to close the servicing department because it was not cost-effective. So, basically, they gave the responsibility for servicing our items to the individual stores. So, at that time, I moved into our corporate applications department, the team that maintains or builds applications for the corporate departments, like HR, finance, legal, and things like that, right? So, I was...I learned ASP, classic ASP, not even .NET. We were not in .NET [laughter] at that time. So, it was classic ASP. So, I was doing corporate applications for a

On this episode of the Acima Development Podcast, Mike opens with military surgeons as his model for triage, doctors who decide fast and accept ugly outcomes because the only goal that matters is getting the patient home. He uses that to introduce time management, and Will immediately splits the problem in two, since a downed server and a rough quarter call for very different responses. In a real emergency Will cuts off limbs to save the body. He kills the API that is taking the server down, flags off the broken subsystem, or pulls a bad release, and he describes a feature flag as a tourniquet that stops the bleeding without killing the patient. Mobile complicates this because a shipped version cannot be clawed back, so the circuit breakers have to exist before anything catches fire. Kyle pushes on the harder case, which is triage when one boss wants revenue, another wants the release, and another wants one customer happy. Vivian answers with mass-casualty triage, where hospitals categorize patients by tag and pre-decide who gets treated, and Kyle counters that his problem is everything arriving tagged as immediate. That leads to the episode's core argument, which Matt states plainly: priority is singular, and juggling several at once means none of them get done well. Will adds that ranking the queue is a manager's first job, so a manager who cannot rank has already lost the plot and left the engineer to figure out which failure will cause the least grief. He admits he keeps a second thread going anyway, because the first one gets blocked waiting on another team. The panel gets specific about human throughput. Will puts a good work block at roughly two hours, task-switching cost at thirty minutes, and realistic coding time at about six hours a day. Vivian objects that productive hours vary by person and by life stage, citing her own 1:00 to 4:00 a.m. window in high school, while Will argues that a schedule nobody else shares collapses the moment you need to coordinate. Mike admits to twelve to fifteen meetings a day and triaging which of four stacked invitations to attend. Matt estimates that eighty percent of meetings could be eliminated, and the group agrees a meeting should be small and should end with a decision or an action item. On decision-making itself, Mike points to the psychological cost and to fear of being punished for a wrong call, which pushes teams into paralysis. Matt's position is that a decision beats no decision, and Will's tactic is to make the call himself, email his boss, and keep receipts. The last stretch turns to sustainability. Vivian argues that leaders have to avoid putting people in positions where every option causes damage, and she uses competitive swimming as her example, where teammates blew out their shoulders training twenty-five hours a week instead of the twenty they could sustain. Companies want twenty-year employees to stay another twenty, so breaking people the way a military breaks soldiers does not pay off. Mike compares it to parenting, where rule by beatings works at first and then works less and less, while respect and clear consequences take longer and actually hold. He notes that his own boss makes a point of leaving at 4:30 so the team sees what a normal day looks like, and stays late only when the situation genuinely calls for it. Mike closes with his personal system, which is early morning quiet time before the day fills up, often on a bike ride, where he picks the few critical items and launches them first so they can move through other people while his calendar takes over. Vivian gives the line the episode lands on when she asks whether the first priority should be prioritization, and Mike agrees. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With me, I've got Vivian Moore, Will Archer, Kyle Archer. We've got Eddy Lopez and Ramses Bateman. And I'm going to start off today by talking about military surgeons. I've not served in the military, but I've read about this. You can imagine that, in the military, particularly, you know, in, like, active warfare, there are a lot of injuries. And they've got to set, you know, a whole medical establishment within the military. The striking thing that I've read about...and, again, I haven't served there myself, so I'm speaking secondhand or thirdhand, having read about it. The military surgeons are incredibly pragmatic. That is, if somebody comes in and they're badly injured, they don't think about the plastic surgery this person might have to get later. They think, "I need to save this person's life. I want this person to walk away." And, you know, if they've got to remove the leg, they're going to remove that leg, you know, whatever it is they've got to do. I'm not going to go into the details because it's graphic [chuckles]. But, you know, they have to be exceptionally pragmatic about what they do. In general, they're not being sentimental. They're saying, you know, "What can I do to save this person's life? Everything else is secondary. How do I keep this person moving along?" And so, that's what they do. And they've got to deal with all the gruesome details of it. But because they are so concerned about making those decisions, making them early, making them immediately, right, and having one priority: how do I keep this person alive? How do I get this person, you know, home? They save lives. They make all the difference between that person going home and not going home. And those are tough choices. But if you think about the end goal, they're making the right ones. They've made the choice there that they're not going to get caught up in the stress of the moment because they care about saving somebody's life. We're building software. We're not on a battlefield. Hopefully, you're not on a battlefield. There may be some people out here, you know, building software for the battlefield. That does happen. But most of us are doing stuff that's much more mundane. But there's some lessons that we can learn there [chuckles], lessons we can learn about prioritization. So, I gave that intro because today we're going to be talking about time management. And if you're like me, there is...And, I think, like most people, there's more to do than you can do. There's always more to do than you can do, and sometimes it's just a complete torrent. There is such a constant stream of stuff coming in that you can't even think about it. You can't even think about prioritizing because it's just...it's just a flood. And that is a hard situation to deal with, right? It is an endless challenge. We were talking a little bit in the pre-call about how we all deal with this, and I certainly do. So, we're going to talk about that today because I think that it's something that we can all grow from. So, I'm going to start with thinking about these military surgeons as the kickoff point and their pragmatic prioritization with a solitary goal in mind, because I think that's a great place to kick this off. And rather than add anything else myself, because I've been talking for a few minutes now, where would you all like to run with that? WILL: Well, I just want to...I want to narrow this down to, like, are we talking about an emergent situation where the server is down and you need to fix the server right now? How do you do it? Or are we talking about, like, a rough sprint or a rough quarter? Because they're different. MIKE: Ah, they are different. And I think that's a critical distinction. I was thinking about that again ahead of time myself, because it's different rules, right? Going back to the military triage, there's some situations where if you don't act now, then you don't get a chance, and there's other situations that can wait a little bit. And in any emergency room anywhere, they make those decisions all day, right? They do the triage, and that's why you go, and you sit, and you wait for three hours in the emergency room. Again, I haven't had much experience in the emergency room, luckily, but I know that's -– EDDY: I'm trying to equate, like, how you're mapping that to, like, engineering, right? So, are you saying, like, someone is on their deathbed; they need priority. Is that equivalent to a software engineer saying, "Oh, the house is on fire. We're no longer...Our server's not up. That takes precedence"? MIKE: It does. So, server's down, server's down. You're bleeding money, right? Your lifeblood is that revenue coming in, and if you're down, then you're not doing business. Depending on the size of your business, you might be losing millions of dollars a minute, you know? That is a direct threat to your livelihood. And the tech debt you have that makes everything really slow, yeah, that's important, but it'll be the same way tomorrow. WILL: It's true. Well, I mean, like, in those situations, like, really what you're trying to do, like, I, think, you know, like, I am much like a civil war surgeon. I'm lopping off limbs. I'm applying tourniquets. I'm applying, like, real, like, macro carpet bombing type solutions. Like, oh, this API is taking the server down? Not anymore. Like, we're just not going to, you know, we're not going to run leases, or we're not going to do...Whatever it happens to be. Oh, this SKU is crashing with 500s, and it's taking all that stuff down? Like, what SKU? I've never heard of that. We don't sell it. We're done [laughter], you know? And I will do those things, you know, like I will cut off a limb to save the body. Those are the sort of actions that I'm immediately looking to take. Like, is there a feature flag? Can I feature flag this off? Can I turn this gateway off, you know what I mean? This subsystem, can I turn it off? I'm turning things off, you know? It's like, oh, did we push a version? Well, we're not pushing that version no more. That version [laughter] goes away now. Like, 11.9? It sounds like an 11.81 day

This episode of the Acima Development Podcast tackles how job seekers, especially new grads, should present themselves to employers. Mike opens with an analogy comparing modern hiring to online dating: both have shifted from relationship-based filtering to app-driven processes that strip away the context you'd normally get from a trusted network. Interns Vivian and Jordan share their recent experiences, with Vivian noting that her degree, hard classes, and high GPA did almost nothing to land interviews, while the opportunities she did get came through people who knew her. The panel adds that credentials can even backfire, since some hiring managers screen out prestigious schools or high GPAs, assuming those candidates will be hard to work with or quick to leave. The group converges on what actually matters to interviewers: evidence that a candidate can think, solve problems, and tolerate the constant frustration inherent to software work. Jordan's apartment-scraping side project, built to solve his own problem, was what interviewers consistently asked about, and Mike recalls hiring someone whose homeschooling app proved she could identify and solve real problems even if the code was rough. Dave and Will emphasize the psychological side of the job, including grinding through failure, reading far more code than you write, and managing imposter syndrome. They also make a half-joking but sincere case for taking work at sketchy startups, since even dubious employers provide real experience, connections, and a paycheck while you build toward something better. The dominant through line is that connections beat credentials. Nearly every panelist got their jobs through people they knew, and Dave offers a detailed playbook: cultivate loose acquaintances rather than close friends, ask curious questions over lunch, and let warm introductions bypass corporate filtering. Justin recommends joining active local industry groups like OWASP or user groups, where presenting your work makes you visible to people who hire. On the AI question, the panel agrees on tailoring effort to the audience: if an AI will screen your resume, let AI write it, but a human touch still differentiates when real people are reading. Vivian's closing takeaway captures the consensus, that human connection transcends any amount of resume optimization, and Will signs off urging listeners to add everyone they've ever worked with on LinkedIn. 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've got Dave Brady. DAVE: Howdy, howdy. MIKE: We've got Eddy Lopez, Vivian Moore, Justin Ellis, Will Archer, Kyle Archer, and Jordan Dickerson. And we had a lot of interest in the pre-call here today, and I've been thinking about how to present the topic. So, there's been a huge transformation in the way people meet each other over the last couple of decades. 20 years ago, you say, "I met somebody online," you'd get some side eye. "You met them where? On the internet? Are you one of those people [laughs]?" And now date using an app, right? It's how it's done. DAVE: It's de facto. MIKE: Yeah, de facto, exactly. So, fundamental shift, right? Fundamental shift in the way that that's done. There's some consequences to that. There is a loss of a lot of the filtering that you got previously because a lot of times previously you'd get people out of this network of people that you knew. It still happens, right? People still meet each other that way. They don't follow the de facto route because that's not working. They still meet somebody through somebody they knew. But, you know, there's this lack of filter because you're going to be meeting somebody you met on, you know, on your dating app. You don't have all the context that you have, and the people say, "Oh no. Stay away from that guy [laughs]." And so, there's a lot more of this...who am I talking to? And the sudden evaluation that you got to do. Now, I haven't been dating for a long time. Very happily married, I have been for [laughter]...28 years now. It'll be 30 years in just a couple of years. I've been married for a long time. Glad I'm not dating [chuckles], that can be painful. But I don't even hardly remember doing it that way [chuckles] back when. But there's that evaluation process you go through very quickly. You know, is this...first of all, am I safe with this person [laughs]? Are they going to kill me? Followed by, you know, what's the next choice? You know, are they gross? Do they smell bad? You know [chuckles], to the acceptable...[laughs] Are they an acceptable person to be around? And, you know, they gradually move into your circles of trust, and you see how close they're going to get. And you have to go through the evaluation process. The same thing has happened in hiring, where hiring has very much been taken over, in many cases, by this whole stream of filtering that happens online before you ever meet people. And people spend a lot of work carefully crafting their resume to meet keywords. And sometimes we miss the right people. Sometimes we miss the right people because they didn't have the right keywords. And then when you meet somebody, you know, you have to go through that evaluation process. I've done a lot of interviews. I've done a lot of interviews over the years. I interviewed two people today, as a matter of fact [chuckles]. It's a thing I've done many times. And it's always tricky, right? Because you have to try to go through that filter because you don't have the context. You know, how do I quickly evaluate whether this person is somebody I want to work with? And coming from the other side, if you're looking for work, that's a tricky problem, too. I know, Justin, you've recently done this. We've got Vivian and Jordan who were recently applying for an internship. You know, so we've got some folks here who've recently been through this process. It's hard. What do I put on my resume? And this broader sense of, "How do I present myself to employers?" is a tricky one. And that's what our topic's going to be today. How do I represent myself, and what do I do? Just kind of a broader sense. What do I do? Should I get certificates? Should I not get certificates, or should I even put them on my resume if I've got them? Should I do networking? Should I go do volunteer work? Should I go and work on projects and put them on my GitHub? Do none of those matter at all [laughs]? I just have to put the right keywords on my resume. That's the topic we're going to talk about. And I could throw some of my spin on this because I have, like I said, done quite a bit of interviewing. I might actually start with the interns we've got here because I know that they have very recently been going through the hiring process. And I'm curious: the first question I'm going to ask is, what did you focus on? And that [laughs] can give us a launching point. You know, what did you focus on that you thought, "Hey, this will maybe work," as you put it on your resume? And then we can maybe talk about how that landed. VIVIAN: Coming out of college, I assumed that a degree, working hard in school, taking difficult classes, having a high GPA would be the ways that I would get a job after college. I was immediately confronted by the fact that that did absolutely nothing to do anything for me, especially in the industry that I came into in 2024. WILL: Not nothing. Not nothing. Not enough [laughter]. VIVIAN: Not enough. Definitely not enough. I would say, for sure, not nothing. It taught me the skills that I needed to eventually do the jobs that I could potentially apply for. But in terms of actually securing an interview and moving on to the next steps, that was next to inconsequential in terms of what it actually provided for me. The situations where I have been able to, at the very least, have an interview to potentially move forward to the next step, it has been finding a place where not a lot of people are applying for, or knowing someone who already works there who can give me a reference for something that I can apply for that either, again, not a lot of people are applying for. Or they know that I'm capable, and so they can vouch for me to get me onto the top of the pile. WILL: God bless a sketchy, trashy, bottom-feeding, scum-sucking, borderline felonious startup. MIKE: [laughs] WILL: Who among us, who among us didn't break in, like, on the bottom of the barrel [laughter]? Oh yeah. Oh yeah. Oh yeah. I want to see...I mean, go lower. How [laughter]...how low can you go? If it pays [inaudible 06:38] better than DoorDash and the check only bounces [laughter] half the time -- DAVE: Half the time [laughter]. WILL: You're in, baby. You're in. VIVIAN: So, the lesson I'm learning from this is compromise your morals and values. WILL: Yeah. Yeah. DAVE: It's just...be ready to settle. WILL: Yeah. Yeah. There you go. Yeah, you got it. That's a wrap, boys. MIKE: [laughs] KYLE: I was going to say, I think it's interesting, too, for new grads to join the job market. I don't know how many hiring managers had the bias of...I won't give names, but the location that I went to [laughter] after college, he had a bias in the sense of what schools. If you had certain schools on your resume, he wasn't interested. He had hired those schools before and no longer wanted to deal with them. If you had certain GPAs and you're thinking, "Okay, cool, 3.9, 4.0, that's great," nope, you were out of the list. He didn't want the high GPAs. He wanted 3.4s. He wanted 3.0s. He had a certain opinion of those. So, I'm saying, sometimes, it's even awkward in the sense that your school, your GPA, your classes, those might even negatively affect you for some individuals. WILL: I have run into people who will not hire from certain top-tier schools, right? KYLE: Oh yeah. Top tiers are not uncommon for...especially smaller companies. WILL: If you went

This episode of the Acima Development Podcast centers on organizational complexity, using NASA's root cause analysis as a jumping-off point. Mike opens by contrasting the military's rigid hierarchy with the failed free-form communes of the 1970s, arguing that both extremes reveal something about what makes human structures work. NASA's finding was that technical complexity should not be matched with organizational complexity; simplicity is the path to success in both. Dave reinforces this with a Microsoft study showing that bug severity correlates with organizational distance between the people involved, growing exponentially with each layer of hierarchy separating them. The group discusses product-vertical "pod" teams, where cross-functional members own an entire stack and success is tied to customer outcomes, versus discipline-based teams like a dedicated database group. Justin describes guilds, a parallel structure where specialists across teams meet and share expertise, as essential for keeping vertical teams from becoming siloed, and Mike ties this to the Team Topologies framework of four fundamental team types with clearly defined, unambiguous roles. The conversation shifts to how expertise is actually developed, with strong consensus that software engineering is fundamentally an apprenticeship trade. Will argues that engineering has always worked this way and attempts to replace mentorship with formal structures fail. Vivian, an intern on the call, agrees, noting that simply sitting in meetings watching senior engineers reason through decisions has taught her things she otherwise wouldn't learn for a decade. The group critiques code review as a mentoring tool (too late in the process) and advocates for pair programming instead. Vivian draws an analogy to the brain: intelligence comes not from the number of neurons but from the depth of their interconnections, so 10,000 employees who never talk to each other are just one person 10,000 times over. This leads to discussion of how leadership scales, with Kyle and Will emphasizing that approachable leaders matter, that "open door policies" can be declared but trust must be earned, and that policies made without consulting end users (like tool purchases) create dysfunction. The final stretch becomes practical career advice prompted by Vivian's questions about building trust as a newcomer. The panel's answers converge on consistency: show up, do the work, take responsibility when things go wrong, and never pretend to know something you don't. Will offers his "secret silver bullet" for getting help from anyone: make a genuine effort first, document what you tried, and ask a specific question, and people will do backflips to help you. Dave adds the notebook rule (never ask the same question twice) and a rough heuristic for when to stop grinding on a problem alone: value your time like a senior's, and escalate when an hour of their help outweighs hours of your spinning. On Vivian's tendency to hyperfocus, Will and Dave both encourage her to "let it cook," arguing that obsession at her career stage builds lasting skill, as long as she's engaged and learning rather than stuck. The episode closes by looping back to psychological safety as the throughline connecting organizational design, trust, and team success. 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 Brady, Thomas Wilcox, Justin Ellis, Vivian Moore, and Kyle Archer. And I'm going to start by sharing, not a personal story, but one I read. Actually, I'm going to share two things. Well, first, a little bit of context before my story. We've been talking for several weeks now, several episodes. We're going to continue on our final, final episode talking about the NASA root cause analysis that they did─I think it was back in 2012─talking about things that led to some institutional failures that they needed to pivot from. And I'm going to start by talking a little about the military. I've not served in the military, and, frankly, I haven't wanted to [chuckles]. That's a tough thing to do, you know, all of the risk that's associated with it, all of the risks of PTSD, and so on. But I give respect to anybody who has served, because, you know, that's a real thing. The one thing that the military does do is they have a very rigid hierarchy, so everybody always knows who they report to, and that's pretty universal, I think, in militaries, you know, successful militaries. They have this rigid hierarchy. And so, there's this question: why do they have such a rigid hierarchy? And rather than answering that question, I'm going to share another thing that I read, and it's brief. I read...I don't know if story is the right word. I did an analysis of counter-cultural communes back in their heyday, back in 1970s. The opposite of the military hierarchy, right? As far from it as you can get. And in one of these particular communes, there was one where they said, "We're not going to have anybody married to each other, free love, you know, and everybody just be with whoever they want." And they interviewed somebody, and he said, "There is nothing more lonely than every night having to find a new partner," you know, like, begging them to spend the night with you. And I thought that was fascinating. In one case, you know, you have this rigid hierarchy with all the constraints and all of the potential downsides that come with that. It's hard to be in an environment with such a rigid hierarchy. I report to this person; I do what I'm told. But on the flip side, if you have no hierarchy and no commitments, it can be even more crushing. And almost all of those societies have fallen apart. They were experimental, and they fall apart because there is that lack of commitment. And the social structures just deteriorate, you know, you don't see very many. There do exist some communes, but most of those experiments that happened in, like, '60s and '70s have fallen apart, and they don't exist anymore, or exist only at extremely small scale. And the ones that did tend to exist are those that look very hierarchical, much like monasteries, where you have people with a strong dedication to a cause, and, you know, single-minded, and not that kind of social conflict. Once again, they've ended up looking more like the military, and that's fascinating. It says something about what is effective in running human structures. Also, my heart broke for that poor guy, the loneliness. He said, "There's nothing more lonely..." and you picture just kind of begging for somebody to care enough about you, and you have to do that every day. Coming back [chuckles] to this NASA study -- JUSTIN: I was thinking of how you're going to relate that, you know, begging for somebody to relate to you at work, or something like that [laughs]. MIKE: No. So, NASA's final element in the root cause analysis...and I'm going to read this just straight verbatim from their report, because I think it's interesting. They said, "The final root cause is closely related to the fourth and is driven by the technical and organizational complexity. Space systems are highly complex and very sensitive to small uncertainties. This complexity requires in-depth penetration and understanding, where small technical glitches result in major problems. The technical complexity leads one to think that the technical complexity must be matched with organizational complexity." I'm going to pause there for a second. So, they have this innate technical complexity, right? You're building a rocket. It's complicated. And you might think, "Okay, so my organizational structure needs to be complicated." You have 20 bosses, right? And I go back to what they said, "We know that when managing the organizational complexity becomes as large as or larger effort than managing the technical, then the product success is in question. Simplicity is the pathway to product success, both technically and organizationally." Now, we tend to focus a lot on technical simplicity. Well, we know the simplest solution that's almost certainly the best. But we don't always think about the organizational simplicity. DAVE: Mike, I love that you hit on this. Last week, when I hosted when you were out, one of the things that I mentioned is that, at Microsoft, they did an in-depth longitudinal thing on, like, what's likely to cause a bug and how severe and difficult is it to fix? And the dominant variable was how far away in the organization the person who fixes it is from the person who wrote it, or the two modules that have to interact. And they measured it by how many layers up the hierarchy you have to go to get to the common person to take you back down to approve this other person working on your thing, and it's exponential. Somebody on your team, pretty straightforward. Somebody on the next team over, kind of difficult. Somebody in the next department, very, very hard. And if it's in another business unit, forget about it. You might as well just open a ticket and pray. MIKE: You're saying if you don't have that person that you know and trust and can rely on, things fall apart. DAVE: Mm-hmm. MIKE: It's fascinating to me how much human aspect there is to software engineering. We have talked about technical stuff. Sometimes we've gone deep into unit testing here, right? But here we come back, and this is going to be a very human-focused episode. We're talking about that idea of organizational complexity driving, as they said at NASA, product success. Product success is in question when your organizational complexity grows. So, Dave, you mentioned the study at Microsoft [chuckles]. DAVE: Yeah, it's straight-up complexity and the hierarchy. And if you think about hierarchy like a snowflake or a star graph, it becomes fractal, right? You've got these two great big branches, and then lots of little medium branches, and