Acima Development

Mike Challis

4.5 (2)
Technology
Updated Biweekly

At Acima, we have a large software development team. We wanted to be able to share with the community things we have learned about the development process. We'll share some tech specifics (we do Ruby, Kotlin, Javascript, and Haskell), but also talk a lot about mentoring, communication, hiring, planning, and the other things that make up a lot of the software development process but don't always get talked about enough.

3d ago

Episode 109: AI-Powered Security Threats

This week on the Acima Development Podcast, Mike starts with the fall of the Roman Empire. Rome guarded its borders with largely autonomous armies. When attacks came from too many fronts at once, the empire couldn't hold them all off. Mike compares that to where software security stands today, now that AI puts world-class vulnerability tools in reach of attackers well beyond nation-states. Joining him are Justin Ellis, a longtime security engineer who now works in OT, and Tim Chaffin from the Acima security team. Will Archer brings experience from several large corporations, and Vivian Moore offers the view of someone who just finished school. The panel spends the first half on how fast the timeline has collapsed. Justin says attackers used to sit inside a network for 150 days or more before acting. Now an AI-assisted breach can go from first crack to ransomware in minutes. Tim shares numbers from Mandiant during a recent incident. Big telecoms take about 43 days to patch a critical vulnerability, but a proof of concept posted on a dark web forum gets exploited in about five. He also describes DEF CON capture-the-flag teams who handed their recon work to local models, and a mobile app his team decompiled with AI in about 10 minutes. Will notes that AI makes finding exploits easy, while writing a kernel patch remains beyond most developers. Vivian pushes back on Will's idea of cutting hostile countries off the internet. Cheap streaming sticks and TV boxes sell their owners' connections as residential proxies, so blocking by geography won't hold. Mike then lays out what teams should do. His first step is constant observation, with automated watchers that block abnormal behavior without waking anyone up. His second is patching critical vulnerabilities within a business week, which Tim says only works with automated testing in the pipeline. Mike also wants teams to attack their own systems, the way Netflix's Chaos Monkey shut off infrastructure on purpose. Tim adds countermeasures for specific AI threats, such as FIDO2 passkeys against AI-written phishing. His team is also building scripted proof-of-concept tests so patched vulnerabilities can't quietly return in a new release. The group closes on people as the weakest link. Tim describes a phishing email that spoofed his dad's name, and Justin raises deepfake scams aimed at older parents. Mike ends with a call to act today, because the barbarians are already at the gates. 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 Justin Ellis, Will Archer, Tim Chaffin, and Vivian Moore. And I'm going to start with a topic that I usually avoid. I'm going to talk about the Roman Empire. I avoid it for a few reasons [laughs]. You know, there was all the, what was it, 2005 or so, they...there was all the social media stuff about adult men thinking about the Roman Empire multiple times a week. If you haven't seen that, it's a thing out there that have girlfriends ask their boyfriend, "How often do you think of the Roman Empire?" And they're like, "Oh, I don't know, a few times a week." And they're like, "What? Who think..." [laughter] There's this weird gender divide. I don't follow social media much, but it was enough that, you know, it made a thing, like, made the news. It can be kinda trite, and also, I think, people sometimes portray it as like, "Oh, well, the Roman Empire fell. What a tragedy," and well, in some ways, yeah. But, I mean, it was this brutal, violent entity that destroyed the lives of many people for what cause? So, you know, you can make arguments for and against. My point is that it's a complex, morally and ethically ambiguous topic to talk about the fall of the Roman Empire. So, I'm not going to dig into all of that. But I am going to say [laughs] that there was this entity that is commonly read about in history where there was a large, complex system that existed, you know, along the coast of the Mediterranean and Southern Europe for hundreds of years. And they were able to maintain that for a long time, right? And eventually...and they managed the borders of the empire by having armies that were largely autonomous, right [chuckles]? Somebody would build their own army and go out and man the frontier, you know, walk along the frontier and expand it and take spoils as they chose [laughs]. And there eventually were so many different attacks coming from, particularly from the north, that they couldn't wage, you know, defenses against all of those fronts. And they had not kept their defenses up, and they'd been kind of rot from inside for a long time. And, eventually, those attackers made it all the way to Rome, and, you know, Rome was sacked. And there's still holdouts of the Roman Empire today. I mean, the city still exists. There is a Rome. But after the Roman Empire broke up, you had a series of smaller city-states, right? And you had what we, you know, the medieval era, where you had easier-to-defend smaller units that could defend themselves more or less autonomously. Probably couldn't defend themselves against a big attack, but you moved from, like, a monolith to microservices kind of idea [laughter]. And, you know, there had to be that fundamental change. I actually read an extensive article about this once. It said that the...you know, it's not definitive, right? But that the complexity of the Roman Empire was too much to sustain. They didn't have a system for managing that complexity, didn't manage their defenses, and eventually everything fell apart, and fell into something that could be managed because each of those units was less complex and could be managed by the systems they had at the time. Fascinating idea. Where am I going with this [laughter]? TIM: Yeah, where are you going with this [laughs]? MIKE: The barbarians are at the gates [chuckles]. We have a rise of AI now, and the tools that are available to exploit vulnerabilities are now potentially world-class, available to not just nation-states, but...you know, and maybe not quite the script kiddies, you know, somebody in the basement thinks, "Hey, what can I do here?" But getting close to that level. Some of the main things that are preventing it right now are cost. And some of the large frontier models are, you know, big companies publishing frontier models are holding back the strongest functionality for vulnerability detection because they know they can cause so much trouble. There are a couple of projects out there, Project Glasswing from Anthropic and Project Daybreak from OpenAI, where they're partnering with large government and business entities to try to test their systems, test libraries, and get things hardened because the clock is ticking. In some ways, we've already reached the point where it's starting to tick up. We're already seeing news items all over the place. If you look at your logs in your servers, you're probably seeing attacks. You've always seen the kinda script kiddie kind of attacks. Low-hanging fruit have been out there for a long time, but it's ramping up, and I'd like to talk today about what we can do about it. I've got some thoughts, but with...we've got Justin Ellis here. He's a long-standing security engineer who has worked in Acima in the past, but is not currently. Tim comes from our security team. Will has worked for a variety of large corporations [laughs] and can speak from that perspective. And, you know, so I think we've got a good crew here. And Vivian's recently come out of school, so she can talk about [laughs] things from, you know, the perspective of somebody coming to the industry today, because it's very different than the industry looked five years ago. You know, we're in a different world. I do have some thoughts on here about some tactics we should be doing, but I'd like to stop talking myself and get some initial thoughts from y'all. JUSTIN: So, just one thing: I'd like to, like, share the current status, and then, you know, other people can share. It used to be where somebody would crack a network or crack an organization, and then they would sit in that organization, you know, hidden inside their network, trying to scout out other things that are vulnerable inside and slowly go through that and spider web, and then do something with it, whether it's a ransomware, or something like that. But it was, like, the average time that they were in that network was, like, measured in, like, 150 days, so it was measured in, like, 100-plus days. Now, if your outer defenses get cracked, you can lose your inner devices almost instantaneously because of the AI assistance that is part of that attack. And they can go out and, you know, crack all of the vulnerable devices inside your network very, very rapidly and then decide to do something with it almost autonomously. I mean, that's the whole point to the AI, right? And it's making it such that the, you know, crack to ransomware or, you know, compromise of your entire system is measured in minutes rather than, you know, days, where it used to be, you know, hundreds of days. And so, it's just a very different landscape for cybersecurity than it used to. So, I'll just leave that there to start off with. TIM: Yeah, we had some...I recently was working with Mandiant on an incident, and some things that they said which were interesting to me was that the median time for groups like Verizon or big telecommunications groups to patch a zero-day or something that, like a CVE 10, 9, somewhere in there, something that's pretty critical, is about 43 days. And with the advent of AI, the average time from exploit PoC publication on a darknet or a dark web community to demonstration of that exploit being exercised is about five days now. So, someone will find a zero-day, put it on their forum, and then people with enough GPUs to run Kimi 3 on their local rig at home will then
Sep 30

Episode 108: Pressure and Burnout

This time on the Acima Development Podcast, Mike opens with Nitinol, the nickel-titanium alloy developed at the Naval Ordnance Laboratory that can be bent far out of shape and spring back more or less indefinitely. NASA has prototyped woven Nitinol mesh wheels for future rovers, which would spare them the battered look of Curiosity's wheels after a decade on Martian rock. Mike uses the alloy as the frame for the episode's real subject, which is pressure. Pressure at work is not optional, and in the right amount it is what keeps people from getting bored, so the question is how to bend under it and come back to shape. Will Archer argues that anything worth shipping costs you something, and he quotes bodybuilder Ronnie Coleman on the gap between wanting to get big and wanting to lift heavy weights. He has stopped punishing himself for needing a hard push at the end of a project, and he describes recording studio days that come in 12-hour blocks as the same bargain in a different industry. Mike adds that the author behind "follow your passion" meant something closer to finding work you care enough about to survive the misery of doing it. Tim Chaffin brings in what cybersecurity calls ethical pressure, the practice of rehearsing failure through penetration tests and chaos monkey runs so that a real incident calls for calm execution instead of improvisation. He compares it to the expansion joints in a Florida causeway, which are built to split so the rest of the road survives. That connects to the "Antifragile" idea Mike read about, where a muscle under load gets stronger and an unused one withers away, and to a study finding that people in hunter-gatherer societies burn about the same daily calories as an office worker while spending them very differently. The back half is about the other end of the bell curve. Tim points out that chronic urgency produces burnout, turnover, and lost tribal knowledge, and that on-call rotations need real recovery built in. Will describes the drop that follows a launch, the sprint or two where nobody is any good, and the doom loop that follows when leaders crunch a team on promises the capacity was never there to keep. Dave Brady brings up Dan Pink's "Drive" and its three motivators of autonomy, purpose, and mastery, then contrasts a boss whose reward for a 90-hour push was "you get to keep your job" with an employer who handed out comp days. He also tells the story of an engineer who lost the company a lot of money and was sent back to his desk with the line that the company had just paid $25 million to train him. Mike closes with Balaji's habit of handing a promising person a hard project, checking in weekly without micromanaging, and thanking them specifically when it lands. His last image is riding in front on long bike rides with his son, setting a pace the younger rider can hold instead of letting him burn hot and crash. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me today, I've got Thomas Wilcox, Will Archer, Vivian Moore, and Tim...It is Chaffin, right? You know, I've heard people say Chaffin all the time for your name. It's Chaffin, right? TIM: It's Chaffin, but, you know, elementary school just damages us all, and I don't really know [laughter] what it is, so... MIKE: [laughs] Yeah. As usual, I'm going to start with a lead-in. I'm going to go to aerospace. There is a cool alloy I learned about a few years ago. I've looked it up in advance of the call to make sure I knew what I was talking about. They call it Nitinol, which sounds like it would be some sort of alcohol, but it's not. They just stuck some words together for nickel, titanium, and NOL comes from the Naval Ordnance Laboratory, where they developed it. So, it sounds like it's an alcohol, but it's not. It's just nickel and titanium in equal parts. That's really it. And they just did some very slight variation, like a few percent between equal parts, but basically, it's equal parts nickel and titanium. And it's got a few interesting features, but the one that I want to talk about is that it can be deformed significantly and spring back to its initial shape pretty much indefinitely. You know, normally, you know, you think, like, steel. Steel's pretty good at having some elasticity, right? But, you know, you bend some steel bar, you know, steel bar enough times, it's probably going to lose something. To some degree, it'll do well. You know, if you have some springs, you know, they'll spring back a lot of times. This nickel-titanium alloy is even better. It's just basically forever, you know, it'll always spring back, and it's relatively light. And they've made wire out of it and woven the wire into a mesh, and they're using that woven mesh. It looks kind of like chain mail-like, so it's not...It kind of retains its shape. And they plan to use it for wheels, and they've got prototypes of this for future rovers for NASA. So, instead of having a solid metal wheel like they have...And have you ever seen, like, the selfies that the Curiosity Rover takes on Mars? Those wheels do not look good. They've been [laughs] riding around on rocks for, like, over a decade now, and they do not look good [laughs], all kinds of big holes in them. Because they kind of fly the...you know, send the thing up on a rocket, so they make them super light. These nickel-titanium alloy wheels are basically just a...they're even lighter because there's...it's not like foil; it's just this wire mesh, right? Just this really thin wire. But they can put a vehicle on it, and it'll behave like a rubber tire because it'll spring back as many times as you want. Super light. So, it takes the pressure from the vehicle above, and as it goes, it just springs back. There was a Kickstarter a couple of years back where they were selling bicycle tires made out of this stuff, and I didn't hear about it till after. " Oh, that would be cool [laughs]." Because if you put that on your bike, you'll never get a flat again, ever, and it lasts for, like, decades. So, it's the last tires you ever have to buy. Just, it's a really cool idea. I guess it's an expensive alloy to make; that's why we haven't seen it widespread. But they use it...I guess there's quite a few usages of it in aerospace and other places where they really need something that's resilient. So, cool stuff. Worth looking up if you haven't looked it up before, and just, like, watching videos of it. It's pretty cool. It has some other cool properties, too, that are a little off-topic, but I guess you can put it to a lower temperature, bend it, and it'll hold that shape. And then you raise it up to the original temperature, it'll spring back to its original shape. Interesting stuff. And there is a tie-in here because today we want to talk about pressure and resilience under pressure. We often talk about pressure as a bad thing, but pressure is reality [laughs]. We're all going to be under pressure of some sort. We are paid to go do a job. You could say, "Oh, it just doesn't matter," and just wander off, and that's not going to work very well. There are demands. There are demands in life, and they're not going to go away. And, in many cases, pressure can even be motivating. Like, you know, if you don't have any demands, you can get bored. People actively seek out more interesting and demanding work and activities. People who are retired still do something interesting because they want to have a little bit of pressure. We don't do well without it. Then again, people break, right? Burnout is a real thing, and it's something we got to deal with. So, there's the topic for today. How do we get ourselves in a position so we're like that nickel-titanium alloy, you know? Pressure...under pressure, we bend, we spring back; we're good, and keep going. How do we get there? WILL: We all know about the bad parts of pressure. Those are pretty well-established. We've sort of, like, gotten over them, like, many times. Foundationally, I keep on going back to the two things that I think most people want, right? I mean, people want excellence, right? I think that's a foundational thing that, like, most human beings, and certainly most engineers, are driven towards excellence. And people are also driven towards growth. And both of those things, I believe, are uncomfortable. They're painful. They're going to hurt, you know? One of my favorite quotes is from a guy named Ronnie Coleman, absolute monstrous freak of a man, one of the legendary bodybuilders of the world, and quite the wordsmith. And I quote, "Everybody wanna get big, but ain't nobody want to lift no heavy-ass weights." [laughter] You know, it sums up so many things in life. Getting the opportunity in the year of our Lord 20-odd-26 to work as a professional engineer is hard yards. People struggled for years. Even me, who grandfathered in in Gen X when it was, quote-unquote, "easy," I saw the wrong side of midnight a whole lot. I spent a lot of nights and weekends studying to, like, get an opportunity to do this thing. And if you can't deal with pressure, if you can't push yourself to an uncomfortable level of effort, it's hard to imagine people being successful or people being very good at this stuff. For a long time, I have held as my, like, sort of platonic ideal, like, a good marathon runner pace as what I aspire to in my professional career, right, like, where I'm running hard, and I'm feeling it, and I'm hurting. If you run for a long distance, it doesn't feel good, you know? But at the same time, like, you are in a flow state. You're rolling. You're in this pace that works. But as I've sort of gotten older, I've maybe come to a level of acceptance of, like, how I work and, like, kind of how everybody works forever. It's very rare, very much the exception rather than the rule, that if you're going to do anything, if you're going to accom
Sep 16

Episode 107: Agile vs Waterfall

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, go
Sep 2

Episode 106: Dealing with Change

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 doin
Aug 19

Episode 105: Time Management

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
Aug 5

Episode 104: Job Hunting in Tech

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
Jul 22

Episode 103: Organizational Complexity

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 lot
Jul 8

Episode 102: Distributed Authority

This episode of the Acima Developers Podcast continues a series on a NASA paper about engineering failures, focusing this time on decentralization of authority. The core question Dave poses is where breaking things down and simplifying goes wrong, and the group lands on a shared answer: complexity doesn't disappear when you split systems or teams apart, it migrates into the seams between them. Will frames organizations as multi-threaded programs, arguing that distributed work is inherently less efficient than a single mind holding everything, and that the real failure is that nobody budgets for that inefficiency. Teams plan sprints as if they operate at maximum efficiency, then get blocked waiting on other teams like threads waiting on a mutex. The conversation moves into war stories about organizational structure. Kyle describes how Acima's DevOps team, once embedded with engineering under one budget, now sits in a separate department requiring alignment several layers up before work can happen. Dave cites a Microsoft study finding that bug difficulty scales dramatically with org-chart distance between the person who needs a fix and the person who can make it, and recounts a previous employer where carving out a DBA team concentrated all database authority in one group while the blame stayed distributed everywhere else. Will's proposed remedy is cross-functional "tiger teams": pull a dedicated body from every needed discipline (DBA, DevOps, security) onto one team for the life of the project, deliberately over-allocating rather than pretending ticket queues between silos are free. He argues for institutional checks and balances over exhortations to "speak truth to power," since pressure, layoffs, and optimistic scheduling make honesty structurally difficult. The back half turns philosophical, sparked by Vivian's observation that startups work like mesh networks (everyone connected, nothing precious to break) while enterprises are hierarchies protecting a "golden goose." That leads to a warm tangent on being kind to your future self: Dave's story of leaving network diagrams inside junction boxes that paid off 15 years later, Vivian's "second brain" note-taking practice, and the YAGNI principle of trusting tomorrow-you to solve tomorrow's problems with better information. Will counters with a lament about corporate chat retention policies deleting institutional knowledge after three months, which he calls "leadership malpractice." Vivian closes with a fitting meta-observation: without Mike there to keep them on track, the decentralized conversation never actually reached a conclusion about decentralization, inadvertently proving why some centralized accountability matters. Transcript: DAVE: Hello and welcome to the Acima Developers Podcast. I'm your host today, Dave Brady. We have got a really good panel today. We're still talking about the NASA disaster stuff. Today on the panel, we've got Will Archer. We've got Eddy Lopez. We've got Vivian Moore. We've got Kyle Archer. We've got Will's dead camera connection from his previous dropped call, and we've got Ramses Bateman on the call. So, we've been talking about this NASA paper, if you've been following along at home. You can get this on the Googs or wherever: Elements of Engineering Excellence by J.C. Blair, R.S. Ryan, and L.A...Oh boy, Shutzenhofer, from AI Signal Research in...if you find that, Google for that, you'll find this. And, basically, it was...they prepared this paper for NASA telling them, "This is why your stuff keeps breaking, and you keep killing people when they try to go into orbit or come back from it." And we've already talked about, like, normalization of deviance and, I don't know, some other stuff. We did a whole show a couple of times, and I kept making it a forum for AI. So, I'm hosting today, so I'm going to be asking questions and trying not to turn it into the Dave show. We're really excited to have Vivian on the show. Vivian, you're one of our interns for the summer. Do you want to say hi to the audience, just tell them who you are? VIVIAN: Yeah, sure. So, I'm Vivian Moore. I'm going to be one of the software engineering interns for the summer. I've been actually listening to the podcast for the last, like, couple months or so, kind of getting prepared for the internship, getting to know everybody. So, it's kind of a weird experience being on here now that I'm actually at the company, but it's very fun. DAVE: Right on. Welcome. So, Mike always starts with a story, and I usually have 20 of them on hand, but all stories that I have are going to go immediately onto a tangent. So, I kind of wanted to just kind of open the floor a little bit. Mike commented to me...Mike's running late today. He might make it. I'm hoping he does make it. But he sent me the meme from Office Space of, like, when you have eight bosses, nobody's actually in charge when you answer to eight people, right? It's the bystander problem, bystander effect where, you know, if a crisis is happening and there's eight people standing there with their cell phones, and you say, "Call 911," nobody calls 911 because everyone assumes that everyone else will do it. Paper hones in a little more sharply on this, that it has almost more to do with siloing teams and isolating teams from each other and stopping them from communicating in between each other. And, in the pre-call, I mentioned that the devil kind of lives in that space. I've seen so many software ideologies come down the pipe over the past decade or two, where people have, you know, like, "I've got the answer, and this is going to solve everything. All you have to do is simplify the piece that you're working on." And they show you this really simplified thing, and it looks good. It looks clean. It's obviously true, but it doesn't solve the complexity. It just pushes the complexity outside the thing you're actually working on. And if the other team on the other side of the wall is pushing that complexity back at you, that complexity now lives in between. Honestly, that was my big grief with, like, the way Java architected things out by default. I mean, like, Java's great. It's a good plan. But the naive approach to the way Java breaks everything down into tiny, tiny, tiny, tiny, tiny, tiny...Like, I can remember people saying, "You should not have a class longer than 25 lines of code, and you should not have a method longer than 5 lines." And I wish I could write software like that. I know people who can, and, I tell you what, they are very, very good at finding the file they need or the seven files that they need because they're all over the disk, right? Which arguably is probably better than trying to sift through a 3,000-line chunk of code, which actually might be an allegory for this organizational problem. But my issue is that you start having problems with how the modules get picked up and put together, because complexity starts to live in the seams, not the units, but the integrations between them. What do you guys think about, like, decentralization, breaking stuff down? We all know simplifying things is good, but where does it go bad? If we just take simplifying and breaking things down as an objective good with absolutely no qualifications, where does it go wrong? WILL: So, whenever I think about, like, sort of, like, these sort of, like, distributed processes, right, like, across engineering organizations, individual engineers, like, I always think about a multi-threaded program, right? So, one of the things that we've seen over the past, like, you know, however many years, like, really since we broke out of the 486, you know, line of computing is more and more and more cores, right? More and more cores: 18 cores, 16 cores, 32 cores, lots and lots of cores. Well, the problem with lots of cores is there's lots of threads. And one of the sort of dirty, little secrets of, like, this sort of, like, nitty-gritty systems-level programming is your efficiency, as you have these multi-threaded processes, intrinsically, like...And I think this is mathematically provable. It always goes down relative to a linear A to B to C to D to E to F, all the way to Z, like, one at a time, right, maximally efficient. But, you know, then you only have one person working one way. For people who've experienced, like, the joy of creating a system, or a service, or a program, or a protocol soup to nuts, and it all lives in your head─you made all the decisions; you did every single thing; you know where all the bodies are buried─you will never in your life experience efficiency like that. But you're still only one person of flesh and bone. You only have 24 hours in the day, just the same as everybody else. And if the enterprise is going to scale, you're going to have to scale out to different people. And that comes with inherent inefficiency. If you did it right...and writing multi-threaded programs is astonishingly complex if you've had the burden. A lot of people don't really do it. It's pretty rare for people to write hardcore, nitty-gritty, multi-threaded programs anymore. All of that heavy lifting has been done by, like, really, really, really, really smart people at several different layers, you know, like, to the database, to the operating system, to the sort of, like...Anyway, the frameworks, all that stuff has been done, but it's astonishingly hard to do. We have, you know, general organizational principles to do it, and they're all pretty good. They're all easier said than done, but, like, where I feel like things break down foundationally is we don't allocate for the inefficiencies inherent in the system, like, that's the problem. Every team schedules themselves. They plan their prod. They plan their releases. They plan their sprints, their production quotas, you know what I mean, their timelines for this maximally efficient thing. And it's always wrong because you're always g

See All (109)

4.5

out of 5

2 Ratings

Interesting and Measured Advice

12/19/2025

LouFranco

Been enjoying this show for the past few months. Just a few co-workers sharing tech stories, but very relatable and fun.

Creator

Mike Challis
Years Active

2022 - 2026
Episodes

109
Rating

Explicit
Show Website

Acima Development

Acima Development

Episode 109: AI-Powered Security Threats

Episode 108: Pressure and Burnout

Episode 107: Agile vs Waterfall

Episode 106: Dealing with Change

Episode 105: Time Management

Episode 104: Job Hunting in Tech

Episode 103: Organizational Complexity

Episode 102: Distributed Authority

Ratings & Reviews

Interesting and Measured Advice

About

Information

Acima Development

Episodes

Episode 109: AI-Powered Security Threats

Episode 108: Pressure and Burnout

Episode 107: Agile vs Waterfall

Episode 106: Dealing with Change

Episode 105: Time Management

Episode 104: Job Hunting in Tech

Episode 103: Organizational Complexity

Episode 102: Distributed Authority

Ratings & Reviews

About

Information