Why Engineers Should Understand the Business

About this Episode

In this episode of the Acima Development Podcast, host Mike and a panel of returning guests—Eddy, Dave, Kyle, and Ramses—engage in a reflective conversation about the importance of engineers and technical professionals understanding the broader business context of their work. Mike opens with metaphorical stories about differing perspectives on the same task and how having a broader view—like knowing you’re building a home, not just hammering wood—can significantly impact the decisions one makes. He compares this awareness to navigating without landmarks, emphasizing that understanding the “map” or business direction helps avoid disorientation in both literal and professional contexts.

The conversation pivots to real-life examples from the panelists’ careers, including Dave’s story about a freelance project where a critical bug caused a dangerous hardware malfunction, reminding him that technical choices can have serious, even life-or-death, consequences. The group discusses how engineers often work in silos, focusing on technical excellence while missing business priorities like revenue, customer needs, and risk management. Mike shares a story of how strategic engineering choices—like creating permanent ad spaces on news sites—prolonged a startup’s life. The discussion illustrates that understanding how a company makes money, or what problems are most pressing, empowers developers to make impactful contributions rather than waste time on low-value tasks.

Throughout the episode, the panelists stress the value of communication between technical teams and business leadership. They discuss the dangers of neglecting foundational issues—using examples like collapsing buildings and broken gondola cables—to highlight the long-term risks of ignoring maintenance and risk mitigation in favor of short-term gains. Eddy and Kyle bring up the role of auxiliary teams (QA, DevOps, IT) in cost-saving and risk reduction, further reinforcing the theme that everyone in a company, not just engineers, benefits from understanding the business landscape. Ultimately, they urge technical professionals to pop their heads up, ask “why,” and align their work with what matters most to the organization.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. I have with me a great panel. We've got Eddy, Dave, Kyle, and Ramses. They've all been here before, so, hopefully, you’ve heard their voices. And we're going to be digging into a topic.

Actually, there's a huge windstorm behind me. We've got a great editor. You probably won't hear it, but if you hear occasionally a weird sound, that's what's going on [laughs]. And let me start with some stories. And I'm not going to introduce the topic. I'd like not to introduce it because I think the stories often speak better than a title.

So, imagine three people, well, three people who are at a Habitat for Humanity site. We actually have... that's a charity that Upbound, our parent company, does a lot of work with. I can't remember how many houses they built last year. It was quite a few. Like, wow, they built that many houses [chuckles]?

DAVE: And Habitat is a charity that builds houses, right?

MIKE: Exactly. Exactly. They build houses for people who need houses. You know, imagine you walk in, you know, you're a reporter. You walk into a Habitat for Humanity site, and you find some people working. You know, yes, you walk up to the first guy and say, “Hey, what you doing?” He says, “Well, I'm nailing this two by four to the floor.” Fair enough, right? You’re like, okay, you know.

So, you go, and you talk to the second person like, “So, what are you working on?” She's like, “Well, I'm raising a wall here.” It's a little different perspective, right? They're working on the same job, but she has a little different perspective. She sees that [laughs] nailing something to the floor is part of a bigger project.

You go and you talk to the third person, you know, “What are you doing?” She says, “Well, I'm building a home for somebody in need.” Those three perspectives are very different. And the third person who, you know, this woman who sees the bigger picture, is going to make different choices because of her awareness of that broader situation. I can tell another story here. So, you know, put a pin in that one because I think it's really important. The choices that she's going to make are going to be affected by her understanding of the bigger picture.

Another story. So [chuckles], I lived in the Midwest for a long time [chuckles], and when I grew up as a kid, I was a landmark navigator. I learned to find places by looking at landmarks, and that actually works okay, right? That works okay, unless you get to a place where you can't see a landmark, and then you end up in a lot of trouble. I [chuckles] actually have, in my neighborhood, we got some friends that...a child who was walking around the neighborhood and couldn't see the water tower anymore, and they were completely lost. They were, like, 12 years old, you know, [chuckles]. They were the point where you think, well, really, they got lost?

Well, if you're used to navigating by looking at this prominent landmark and that goes out of sight, you have no point of reference. And so, you just wander around aimlessly, hoping you'll see the landmark again. It's not a great way [chuckles]. It's not [inaudible 03:29]. I've had to learn to think differently. In my head, I always know which way is north if I am going someplace I haven't been because, that way, I know I'm not going to get lost because I know where I'm at on the map. I know which way is north. I know that, you know, even if something goes off a different way, like, that will probably go the direction I need to go. And it makes a huge difference.

And I've become a much more successful navigator as I've learned that, to learn the, you know, the lay of the map before I even set out because it makes a big difference as to the choices I make. And I do a lot of cycling with my kids; I've mentioned that before. And, you know, we do exploring. Sometimes we go places we've never been before and knowing where we're going makes a big difference, especially, you know, if you have to reroute, you better know where you are. And always knowing which way is north, knowing where you are on the map makes a big difference. It's a huge deal because you don't get that situation where you're untethered. Well, where do I go from next? I have no idea because I can't see the landmark.

DAVE: I love that you said change the way you think, that you became aware that you had to change the way you think. I grew up in Southern Utah with, you know, Canyon red rocks. I grew up in Moab, which is right outside of Arches National Park, so all these gorgeous red rocks. So, I always know that when I'm looking, you know, at the Blue Mountains, I'm looking at the La Sal range and that's east. And so, I grew up with very thick, I mean, geologic landmarks. Nobody's going to move that building.

And then, when I was 19, I went to Puerto Rico, and I spent 7 months living in Ponce. And I've got these mountains, which is on the south side of the island, south coast. So, I've got ocean to the south of me and a mountain on the north. And I was absolutely fine, and I was there for about eight months. And then, I moved to Bayamón, which is on the north side of the island, and I was lost for a month, like, actively disoriented every single time, because the sun was coming up in the west, and I couldn't figure out why. It was, like, genuinely jarring. It took me a surprisingly long time to realize that I have a thinking error that has me 180 degrees turned around.

So, I love that you said you became aware that you had to change your thinking. I love that.

MIKE: And I did, and it was hard, to be honest. It took a while. It took a while. I'm old enough that I used to navigate with paper maps, you know, this is pre-internet navigation days. And you would go to the store, and you would buy a booklet, I say booklet, but it's sometimes more bookish than booklet-ish. And you want to go somewhere? Well, you look up the street name in the back, and it tells you a page number and a letter and a number. You turn to that page, and you find the grid, and within that grid, you find the place that you're looking for. And then, you expand out, and you might have to...and then each map, you know, you see the direction of each side. You had to figure out how to navigate [chuckles] maps that way. It was --

EDDY: But of course, Mike, you did that without driving, right?

MIKE: Yes.

EDDY: Like, you had your own copilot. Okay [inaudible 06:32] listeners.

MIKE: Before you drive.

EDDY: [laughs]

MIKE: You'd see a lot of people in those days with the booklet open [laughs], you know, like, on their knee. Where am I going?

DAVE: Or pulled over on the side of the road with the map unfolded on the steering wheel. Yep.

MIKE: Exactly [laughs]. You know, you’ll learn to do things differently when you have to find things in a different way. So, I'm going to talk about software. About, I don't know, 15 years ago, we'll say, more or less, approximate [laughs], I was working at a place. It was a startup, and there was a big shakeup in leadership, and we basically...we went for about a year where we had no leadership at all for our engineering department. So, what do we work on? And we had to make a choice. We had to make a choice.

And, you know, a lot of times we as engineers don't think about making that choice. We don't think about the broader business perspective, right? So, we think, well, what is going to make this startup successful? In the end, it wasn't successful, so maybe it didn't matter. But we actually prolonged the life of the startup by several years because of what we did. We were building a...it was a website builder.

We worked with publishers like newspapers. And we knew that they needed more flexibility in publishing, and we reworked, well, there are two things we did. We reworked the interface for publishing, which, you know, made that a little nicer. And, honestly, that was the worst choice we made, the worst of the choices we made, because yeah, it made it look better, but the functionality didn't change that much. And when you’re a company that's struggling [chuckles], then a little window dressing is probably not the right answer.

We also worked on a project that allowed you to put a permanent ad, allowed companies to put a permanent ad on a newspaper, which is actually a huge deal because newspapers are one of the most reliable sites in terms of reputation from browsers, from search engines, I'll say, from search engines, not browsers, but search engines. So, if you get linked to from the newspaper, well, that makes you look really good.

And so, what we’d do is we’d allow a business...and this is just taking the newspaper model and putting it online. We'd allow them to have a permanent ad, like a car dealership, you know, car dealership puts an ad in the newspaper. Well, now they have a permanent mini-site within the newspaper that they can go to that not only has their advertisement there but also links back to their website. So, now their website when you search for cars in that area, well, they're the first one that comes up because they're linked to from the local newspaper.

We built a whole system for them to build out those little mini sites and that carried the company for, like, years [laughs] because making that choice, again, we didn't have somebody telling us to do this. We had to make the choice based on feedback from the business. We had to suddenly put on our product hat. I learned a lot from that experience about how important it is to know what's going on in the business.

We could very easily have said, oh yeah, we're just going to make this perfect interface on the inside, make it pretty, which does nothing to make money for our customers. And that would have been very much the wrong choice. We did enough of it that, you know, that there was a cost, and we probably shouldn't have done it at all. Thinking about what we should have worked on made a life-or-death choice for the company.

And that's what we're going to be talking about today is, why we as engineers should know about the business. Why should engineers care about revenue? Why should engineers care about any of these things that the business usually is concerned about: prioritization, money, gathering requirements? I'm going to argue it is a big deal, and one of the key differentiators between engineers who are really successful and those who maybe end up lost quite a bit.

Dave, you've already run with this a little bit. Do you have any more thoughts or anybody else? You know, what are your thoughts about this idea of knowing about business, knowing about the business and its inner workings as an engineer?

DAVE: I have so many stories I could go into, and if you know me personally, you know that that's...I can often not be persuaded to not tell them. I'm going to try to stay concise. What seems to me is very essential is that you need to know, what do we need to succeed? And you want to close that feedback loop. And a lot of times, we just trust. We trust in the society, and the society in this case could be just the ecosystem at your business. I trust that my manager is doing the right thing. It might not be. They might not be.

I lost a job once because the accountant couldn't keep the books straight. You had one job, and that was to save mine [laughter]. And so, the reason I have a ton of these stories is I spent about 15 years as a freelancer, contractor, ran my own shop for a while. And we would go in, and we would fire jump Rails projects like firefighters that jump out of airplanes right in the mess.

I was the guy that you would call if you had a website built by somebody, you know, by your nephew who's, you know, a high school student or whatever. And it kind of works, but it's 90% there, and it doesn't...and it's inefficient, da, da, da. And so, I would jump in and then untangle this and make it work. And I usually...because I was a contractor, I often had an expiration date on my hiring time. I would go into a system like I'm already dead. I'm just going to work really hard while I'm alive, you know, fiscally alive or dead at this company.

And because of that time box and because it was...like, this company they've backed into the meat grinder a little bit, and they're like, “Oh, we have this website that we need to make money.” This is going to sound so obvious that it will sound stupid that I'm mentioning it right up until you realize if you look around the room, nobody is paying attention to this. And that is, if the company doesn't make money, they can't make payroll. If they can't make payroll, you don't have a job. It's absolutely critical that you get that sorted out.

I will append something to this, which is Uncle Dave's career hacks. The most powerful trick I've ever learned from my career was look at the person one level up of you and figure out what does that person need to look good and to succeed? I want to look good to my boss. The best way you can look good to your boss is to make your boss look good to their boss. And if you go high enough up the hierarchy, you're going to reach the C-suite. And, at that point, what's important to them is staying solvent, making money, right? There might be a mission. There might be, you know, noble goals and all that, but if there's no margin, there's no mission.

And so, figure out where the money is going, figure out where your business model is, and be prepared to embrace it and engage and be willing to step down if the boss says, “No, we're not doing that way because you're a technical person. You might not understand the business.” But you need to know the business exists and not shoot everyone in the foot with some bad code.

I'm not sure how perfectly this adapts. I don't know if anybody needs to hear this, but I will add this one bit to it. I worked with an engineer, about 20 years ago, who was amazing. He was a senior in college. And while he was working with us, he got out of college and graduated and [inaudible 13:57]. And this guy had a work ethic that would not quit. If you...well, no, he had a work ethic that would not quit from 8:00 to 5:00. And at 5:01, he was out the door, and he'd go home. But you could trust him to write 1,200 lines of code every single day. You could just about set your watch to this person, very, very smart.

In Dungeons & Dragons terms, he had a very high intelligence, not necessarily a high wisdom or not a very high experience level. He could solve any problem from first principles, but he had to solve every problem from first principles, if that makes sense. And I described him to a co-worker at one point saying, “If you tell him to go plow that field, he will go plow that field. You'll get up in the morning, and you go out and you look and that field will be plowed.” But if you accidentally told him, “Plow that field,” and you pointed at the interstate, you're going to come in tomorrow, and there's going to be a field plowed right through the interstate.

MIKE: [chuckles]

DAVE: And this is that. It's the same thing, right? You need to be an expert at what you're doing. But you also need to be paying attention to, you know, am I hammering a nail correctly, or am I building the house correctly?

MIKE: Yes. You know, I'm going to ask a follow-up question. What sort of choices...so you talked about, you know, plowing the wrong field [chuckles]. What are some of the choices you get into? So, this might take a moment to think about. What are some of these choices where it really matters to understand why you're doing what you're doing?

DAVE: Man, I don't know if I have good examples. I think I've told the story multiple times about the time I got a bug report that began with, “Fortunately no one was killed, but...” that happened.

MIKE: [chuckles]

DAVE: I was building a hardware controller that would shake things to vibrate them. I'll tell the story very, very quickly. It would shake things very, very quickly to do squeak and rattle. And Toyota had one of these machines of ours, and it's like a sound card. You play out waves, and you listen to the feedback from the accelerometer [inaudible 15:43], so you can tell how much you're shaking the car. And we had a bug that caused energy to store up in the system and then suddenly be just released all at once.

And we bent the frame of the car, like, we literally launched it. I say we launched it; this was a car. We launched it, like, up in the air, like, six inches and then over a foot and then back down, which was enough that everyone on the shop floor was wearing their brown trousers at the end of this event, right? Nobody got out of this without, like, holy crap, we could have been hurt, or we could have been killed by this.

Up to that moment, I was just designing data transfer. I had these beautiful acoustic wave patterns, and I knew all about frequency distributions, and they were elegant. And I had ways of generating random data that could then be massaged to fit a pattern but still be random, all this lovely, lovely stuff. And then, we got that bug report, and I just realized there are people's lives at stake. If I screw this up, somebody could die, and that sobered me very, very fast, and, interestingly enough, made me that much more excited about my work because, all of a sudden, what I was doing was important, and was relevant, and there was meaning in it.

I hadn't thought of that. Oh my gosh, the value of knowing where the money's coming and going isn't just that you're going to help protect the money. It's going to get you up in the morning and get you out of bed and excited to go to work. And if you've ever been in a deathmatch slog or had a difficult time at a company, you know that meaning is precious. Finding meaningfulness in your work can be very, very precious. And yeah, knowing where the money is, fantastic. And you won't get pushback from the CEO if you're making them more money.

MIKE: Side story. There was an engineer who worked on a side project for a couple of months, just on the side, and came back and said, “I've got this thing that solves the problem.” I'm not going to go into the details of it, so I’m deliberately being a little vague here. And we looked at it like, um, yeah, that does solve the problem. And it's made, like, tens of millions of dollars in less than a year. It was a critical piece that made an enormous difference. And it's because this engineer looked and said, “Hey, there's a problem here with the thing that is most sensitive in bringing in revenue, and I know how to fix that. I know how to address that problem.”

And so, he looked into the most important problem, came up with a solution, and it made a tremendous difference, a small project with enormous impact because he was thinking, well, what do they need most? That wasn't life and death [chuckles], but it sure makes a huge difference to the trajectory of the company.

DAVE: Oh, yeah.

MIKE: And you're talking about meaning, that is it [chuckles]. Getting up in the morning, like you say, it is...some people may be highly motivated to get up and dig ditches every day. But I think most people want to know that they are building something profound [chuckles], that those ditches are the foundation, right, of some great edifice. And, again, you know, you can be hammering nails, and then you go, and you leave, and you say, “Yeah I nailed some two by fours.” Or you can be the person who built a home and that woman who built a home is going to come back, and she's going to build another one because it meant something.

DAVE: I grew up in a small, rural conservative town in the ‘70s and ‘80s, and I was raised on the general concept that police are your friend, like, Officer Friendly. We literally had skits and movies about Officer Friendly. And as I got older and started getting my first speeding tickets, I was, like, not as happy with the police, at least the traffic enforcement part of it. And a friend of mine was the son of a highway patrolman. And I happened to overhear this officer get up and go...sorry, highway patrol, so it would be a trooper.

This trooper got up and on the way out the door, he said, “Well, I’m going to go save some lives,” and walked out the door. And that's all he was doing. He was speed-trapping on the freeway; making people slow down so that they would stay alive. He didn't see it as like, oh, I can't wait to just confront angry people and take their money. No, that had nothing to do with it. It was literally keeping people safe.

MIKE: I have a friend who was a police officer who ended up in a life-and-death situation [chuckles] and made a choice that ended up sparing the life of the person he was in a confrontation with. And the mother of this young man, you know, just came to him in tears, the officer, in tears afterward. “Thank you for saving the life of my son.” Her son was doing something wrong [laughs], but he managed to address the situation without resorting to lethal force. And he had a mission in mind, which was to keep people safe and alive, and because he followed through on that, lives were changed.

DAVE: Absolutely.

MIKE: Now, in software, as you pointed out, a lot of times it's not life or death stakes. Maybe you're working on pacemakers, yeah, maybe that is critical, right, or anything medical. But, you know, doing things with money is a big deal. And it's very important to not disempower people by, you know, separating them from their money in a way that you shouldn't. And having the meaning where you come in and you’re like, well, you know, I'm providing financial opportunity for people in a fair way really does make a difference. It keeps you going.

Again, I’m going to ask the question again. Dave, you've answered a little bit. What do other people think about? Are there times when you thought, oh, I need to make this choice? And I've got some ideas in mind, and I can throw them out there. But are there others who've had decision points where they had to think about what the business is doing and it made a real difference?

EDDY: Well, I think having the domain knowledge is critical in order to know what you're building, right? If you don't understand the business use case of whatever you're being asked to build, right, you're isolated. And so, you don't have the blueprint of, like, how the user experience is going to look like.

I would argue, though, I kind of ask myself a question, if what I'm working on is going to make the company money, and if it isn't, is it going to provide value in any way, right? And so, trying to find a balance between actively working on something that will pay dividends versus actively working on something that will sustain the software so that it does keep making it money [laughs], you know what I mean? So, I wonder if we can sort of dive into that a little bit. And how are we able to find the balance between understanding that the company that you're working for needs to make profits, but at the same time, right, needs to also maintain its libraries?

MIKE: Absolutely. I was going to dig a little bit further there. So, you're finishing up the ticket. You don't have one [inaudible 22:59] line. What do you do?

EDDY: I think we naturally gravitate to CI or bugs.

MIKE: Bugs. [crosstalk 23:09]

DAVE: What needs doing? Go look at Jira. What needs doing? Yeah, what's in the backlog?

MIKE: Your CI, you know, there's a lot of things that that could mean, continuous integration. I think you're talking about continuous improvement. You're going to go pay down some tech debt, or improve something, or work on a bug. And why is that? Why is that your default? And I think that's the answer probably for most people, but why is that?

EDDY: It's a great question. I don't know. I think I normally gravitate to that to maintain busy, like, busy work.

MIKE: So, I think that the reason we do that...I think there are some reasons; work comes in different sizes, and a lot of times the strategic work we're working on. Well, the business says, “This is the big thing we need to build.” We work on that. It's a big thing, right? We get to the end of that, and we’re like, well, I know there's another big thing coming along in the next sprint or, you know, in the near future, and I'm done with that big thing. Now I need a little thing, right [laughs]? I need something to fill in that space. Because if I start a big thing, I'm not going to get very far because then I'll have the real big thing I need to work on next.

So, we try to size it, and we say, “Okay, well, what's going to fit in that space?” And so, we try to go for something smaller, and I think that's the right thing to do [chuckles]. I think we go and we grab, okay, well yeah, I'm going to grab something small that'll fit. And that's just something really important because there are usually a few things in that size, right?

So, do you do something that shores up the foundation, or do you do something that's kind of cosmetic? Do you do something that solves a customer issue? Those could all have valid reasons to work on them. And if you don't know the reasons, you're just going to pick up something at random. And it suggests something about not just the engineers working on it, but, you know, the leaders, product organization, trying to provide priority here and trying to provide a map. You know, we talked about maps, giving a road map so that you know, well, this is actually what's most important. I need to build up the foundation here because foundation is eroded [chuckles], right? There's a weak spot here, and losing the foundation is not good.

You know, there was a hotel, and it was a hotel or a condominium, I think it was a condominium, in Florida a few years back where the parking garage had been eroding for a number of years and then finally collapsed, which ended up taking down the whole building.

DAVE: Wow.

MIKE: It was tragic. People died. And, you know, they'd known about it for years. They were like, “Wow, that is some exposed rebar there with water running over it. That's probably not a good thing [laughs],” but nobody did anything. And there's another life-or-death situation where it wasn't life or death until it was. Shoring up that foundation really is important. So, that may be the right thing to do, and often is the right thing to do because a lot of times the business can't see it, right? They're looking for the grand aspirations and don't always see that water running over the rebar.

EDDY: So, let's go a little extreme here, right? So, you mentioned, unfortunately, people died because of that restructure. Basically, what you're saying is, okay, if we work on fixing up our foundation for this building, it's going to cost money, right? And it's not going to give us a direct or an immediate profit, right? But your justification is, yeah, but then when this building collapses, you're going to lose more money trying to build a new building. And then, you have all these legal litigations that you have to deal with.

So, I think that's sort of how you can justify working on stuff, where you're like, it's not going to immediately make you money, but it reinforces our framework so that we don't have to go into those critical masses and having to invest more. [inaudible 27:11]

MIKE: Absolutely. And it's hard for the company to keep on that, especially if you've been, like, a startup, because if you're a startup, the answer may be, “You know what, we built that last year. It'll hold for a few years. Don't work on shoring that up because if we don't get revenue, we go out of business, you know, we lose that solvency.” And so, it can be a difficult decision. And then, when you do get solvent, and you've got some money, sometimes the default becomes, “Well, let's just keep building on top.” And you have to make that transition to say, “Well, no, we have to make that investment,” and it's important to voice that. Dave, you were going to say something.

DAVE: I was going to say, I was talking to somebody a little while ago...a long time ago, about 10 years ago. They were talking about how when you get a request from business to say, “Hey, I want to do this,” you should ask them “Why?” and you should follow...it's called popping the why stack. “Oh, it's for that? Okay, well, why do you need that?” “Oh, it's for this.” “Okay, well, why do you need this?” And you keep going until you get an answer that matches one of three categories. It's either going to make us money, or it's going to save us money, or it's going to reduce risk of a catastrophic loss of money.

And that third one is the...because nobody wants to pay to shore up the rebar in the garage when the only money to be made is you get to keep making the money you're already making, so that's a siren song to just, you know, not worry about it, not worry about it, not worry about it. And you can get in a situation where you push your risk off and off and off, and eventually, your risk management strategy becomes hope. And, you know, how hard can you hope? Because you're going to have to hope pretty darn hard because that's the only thing we're doing is just hoping it doesn't break. And it's terrible when that happens.

There was an accident...somebody else will be able to find this better than me. A tram car...one of the gondola things that go up the mountain in Italy fell down the mountain. Like, literally, the cable snapped, and it was near the top. And it was the other side, so the car stayed suspended. But it was now the only weight on the cable, and it flew down the thing. It killed everyone aboard. And the people that maintained it came out and said, “This is a terrible tragedy that nobody could have seen.”

And I remember an engineer sitting down and saying, “Let me give you five reasons why this was criminal negligence, starting with that cable cannot possibly fail until it is visibly frayed in...” Steel cable, you can literally break, like, half the fibers in that cable, and as long as you space them out, the fibers adjacent to them will support. You just about have to cut the thing to ribbons or shred it to rags to get those cables to fail. They're incredibly fault-tolerant. And this cable failed. It literally snapped that cable. And you can't have that happen.

If anybody had just gone up and looked at the cable in the previous five years, they would have immediately said, “Oh man, we have to fix this. This is way too many threads broken per foot, or whatever it was.” There were two or three other systems that also failed, and that engineer then proceeded to say, “And let me tell you why I know they weren't checking the braking system, and why they weren't checking the safety arrest line,” because that also broke. And yeah, just all the way down the line.

It is so tempting to just look at that freight cable and go, “Replacing that cable is going to cost the company a million dollars. I do not want to be the engineer that tells the CEO that we have to replace this cable,” but it was necessary. And some people paid with their lives because they didn't want to save that money, or they wanted to save the money, instead of didn't want to spend it.

EDDY: So, what you're saying is, working on that it's justification for saving the company money in the long run, is what I'm understanding.

DAVE: And there's an art form to that, right? There are times when you're polishing code, and you’re really satisfied. Oh, I want to use this design pattern. I'm going to tuck this in. It's going to be so satisfying to have this. We've all written code that you just sit back and go, “That works, and I like it,” and it makes you very happy. But you can end up polishing rivets, and you think you're doing all this noble good. But what you're really doing is something that makes you feel good but maybe doesn't help the business.

And that's, I think, the point of this discussion is pop your head up and look around and say, what direction is the company going? Is this important? Is this essential? You might find, you know, oh, these classes aren't namespaced correctly. That's a technical debt thing that's going to put us all out of business in 3 weeks. No, it's not. You're fine. We don't need to stop development for 9 months to just change around some scoping rules. That's probably not the severity of risk.

EDDY: What kind of scares me a little bit is when you have, let's say, for example, you're a construction company, and you make a bid. And you're like, “Okay, cool, no, we can make this building for you in three months,” right? And then, you're reaching the deadline, right? You're a few weeks away, and suddenly, you're like, “Okay, we're reaching the end, right? This is going to hit the budget that we have proposed.”

So, suddenly [chuckles], you get murmurs saying, "Eh, you know, this base foundation that's going to keep the building afloat we don't really need that right now.” But it would be nice to kind of go back and say, “Hey, by the way, this building can have tenants, and it's fine for the next couple of years. But if we don't go back there and add this foundation, this is going to crumble.” And you finish, and then, suddenly, you turn the cheek. You work on other stuff, right, you get other contracts. You get other stuff, and then you forget.

Suddenly, it gets forgotten about, and you're like, oh, man, right, suddenly, the building is starting to shake, and you're like, see, I knew that was a problem. We documented it as a problem, and suddenly, we have to go back. And so, I guess my concern is, there is a judgment call at that point, right, on whether it's worth taking the extra days that it would take in order to do it correctly. But what are the repercussions for doing that? And I feel like sometimes business tends to do that, you know, so you have to find that balance as well.

MIKE: Well, and you just suggested something. You said, the business wanted to do something different. Well, the business is made of people, and we're part of the business. We have the obligation to communicate. “Hey, this foundation is unstable,” because somebody in a different place in the business can't see that.

Think about that parking garage, the security guard, right, who's wandering around the garage. They're going to see that every day. The remote owner of the building is not and has no way to see it. And unless the person whose job it is to be looking, right, and maybe their job isn't even to look at the foundation, you know, they're just looking to make sure that there's no thieves. They're in a position to see something. And we're in that situation sometimes, where we have to bring up this uncomfortable fact. You know, there's a security issue, and if we don't deal with this, there's a lot of risk.

It's uncomfortable, and it's easy to just not worry about it. But in the end, you know, the financial viability of the company depends on it. And if you've got leadership that cares about the right things, and I'd like to think that most people do, you know, that always can deviate, right? But assuming that you have capable leadership, they will, I think, in general, appreciate the fact that you told the truth.

EDDY: So, what do you do then if you have to tell your client, right, “Oh, you know what, the projection that we told you about, three months, you know, it's going to actually three and a half months.” What repercussions do those conversations have?

DAVE: Coming in from contracting land, I’ve tried to develop a habit of if something's going to go wrong, I want to tell the customer as quickly as possible. Because if I find a catastrophic error, like, if we literally, you know, we did not consider that this architecture literally cannot accomplish the task that we are doing, if we continue, we have thrown away the money up to this point, if we continue, we're just going to keep throwing good money after bad.

But I also try to present solutions. We had that same problem writ small here at Acima. I had a task to make a database change, and it was just a normalization change, shouldn't have been that hard. But we had left that change for seven years, and so we had this massive First Normal Form problem in some of our data. And trying to extract it, there's all these reports from the data team that they're looking at the data in the wrong place, you know, in that First Normal Form. And to extract it, it's going to put it in another table. That's going to break all the reports. So, I had to sit down and think for a minute about, what can we do to keep the system running the entire time that we're fixing it?

And when we had a, you know, when business comes in and says, “Stop working on that, start working on this,” we had one of those. And I had gotten this refactoring to a point where you can talk to the object like it's in the new pattern, but you can keep talking to it with the old pattern. And the First Normal Form continuously sinks into the third normal and vice versa that if you update this other record, it will update the master.

It's inefficient. It's not great. We shouldn't run this way forever, but if we had to, we could because the system works, and that data is in the right place. And I'd love to be able to circle back, and I might not. I'm not anticipating that I won't be able to. It's near and dear to my heart. I would like to see it finished and, you know, I will love that and adore that topic and push on it with people. But if it never comes up in the budget codes again, then, okay, well, it's probably not as essential as we thought. We went seven years on that First Normal Form thing, and we could have just added two more columns to that table and been done.

It would have been a one-day story and, you know, I turned it into, you know, a two-month tilting at windmills. But, and this is your fault, Mike, I was in the meeting where I said, “This is what happened. This is the problem I ran into. This is how we could fix it.” And I think I actually presented, we could just do it the bad way and just be done, or we can clean it out. And, to this day, I remember Mike saying, “Thank you for doing this the right way.”

I was nervous going into that team meeting of, like, man, I might get yelled at because I'm proposing we blow the budget wide open on this, and that's above my pay grade. And it was nice to have other people in the room saying, “No, I absolutely support. Do this the right way. We need this done the right way. We’ve put this off too long.” But I had to run it. That's my point is, I had to communicate it up the chain because I don't like it when technical people make business decisions, and I don't like it when businesspeople make technical decisions.

If you're a one-man company, you have to do it all yourself, but businesspeople know what the value of something is, and technical people know how much something is going to cost to build. And I don't like it when businesspeople say, “I want you to build this, and I want it to take two days.” Okay, you're welcome to want that as hard as you want. But I'm the technical guy, and I'm telling you this is a seven-day task.

I've also had times where the reverse is true. I come in and I say...Michael on our team I walked in, and I said “Hey, I saw this little problem over here. I can fix it in, like, three hours. Let me just cut a ticket real quick, and I'll turn around and burn it.” And Michael just immediately said, “No. No, that's worthless. This is all wasted money. Please, don't even think about this anymore.” And I'm like, “Oh, okay.”

Because from a technical side, it made a lot of sense, and it was easy, and it was going to make our job a little bit easier, eh, maybe. But I found out that business we're not, you know, that this is supporting an initiative that is no longer important to the company. So, you know, please, there are more valuable things you could be working on. I'd love for you to, even just for 2 or 3 hours, just give them over here to where we need the budget. So, yeah do communicate is what I'm saying.

MIKE: Yeah, that was a fantastic question, right? You know, what do you do when there seems to be misalignment? Going back to our central idea, you can't do that unless you have some awareness of what the business goals are, right, and at least some high levels going on. Maybe you don't know the exact financial status of the company [chuckles], and that may not be important. But you do know that this thing is broken, and I can communicate that and balance that with other concerns.

And you may know that the company said, “Well, right now, we care a lot about revenue,” or “Right now, we care a lot about yield on our existing assets, you know, because we've got good things, and we want to make sure that they work well. We're not going to put in a lot of new investment.” Or, you know, maybe we care about risk management. Or maybe we're a startup, and we're desperate to get a new client, and we need to have a pretty web page [chuckles] that makes the client think that we're great. It can be any of a number of things. And understanding those priorities makes sometimes all the difference as to which choice you make.

DAVE: An adjacent thought to that is I realized that what frustrates me the most about work is when the person in charge of the capacity to make the correct decision [SP] lunches the call, makes it wrong. I hate it when I make a technical call and I'm just flat wrong. I waited that database refactoring. I waited into it fully cavalierly thinking I was going to have this done by Wednesday. And, no, you're not going to have it done by March, think again. And I hated that because it was a technical call, and I made it wrong.

But I've worked at a shop, and some of you people have heard this story. There was a shop that I was at that brought in a VP that said, “I want this. I worked at this other company, and we used this thing, and we want it. We want to give it to our customers because it's fantastic. Everybody in the world is going to want this.” And the whole engineering department dropped what they were doing for a year to go work on this, and we shipped it, and nobody wanted it. It was just DOA absolutely. And the VP lost his job for that. The company took a big hit on the stock price. And, like, when they found out where we'd wasted all that money, nobody wanted it.

Amy Hoy calls it kosher ham, where even if you could make it, there's no market for it. [chuckles] You could say, “Here's some ham, and it's kosher. My Jewish friends, come eat.” And they're going to look at you and go “No, we don't do that, even if it's kosher. I don't care. I don't want that.” So, you'll see the same thing, right? It's like, if you're going to build a report for somebody on the data team and they're saying, “Can I get that as an Excel spreadsheet?” And you're like “No, no, no I can do this. I can do this all for you with a JSON transformed in GraphQL.” Even if it worked, they don't want it. They want a spreadsheet. They want their Excel so they can do it.

And it's the same thing, right? Know what the customer wants so that you're not accidentally...I guess the definition of kosher ham is if you did it perfectly and did the best possible version of this, it would still not be what the customer wanted. And it hurts when the business lunches that call.

MIKE: And we can help. Now, leaders who are listening to this, there's an added burden, right [chuckles]? Communicate early and often. Do that market research. Find out whether that's something that actually will work. Think it through. And sometimes we're going to make wrong choices. But try to minimize the impact of those where we can, right? And get feedback all the way along. Be listening so that when the people who are working with you tell you something, you hear that information and don't just go on your solo mission because it really isn't just you.

Well, I think that we're reaching a good stopping point here. We've shared some stories. We’ve shared some figures of speech and metaphors that connect things to, you know, to other aspects of life to show just how important it is to know where you're going, where you are as you build something. Any final words?

KYLE: Just one thing that I was thinking is because this, I feel like, has been a little bit more specific to developers and new features and how that can bring revenue into the company. Just if you're in an auxiliary position, meaning, like, QA, or, you know, DevOps, roles like that, IT, something like that, always keep in mind, what can you save the company? There's, you know, there's always improvements. There's always, what can you save?

And, you know, you might have a great architect or engineer that maybe doesn't know about a newer technology that's coming out that's cheaper or, you know, there might be newer processes that you can put in place to save the company money. And a lot of the time, especially for these auxiliary roles, that's just as important, if sometimes not more important than some of the work that's being done to bring in additional revenue.

DAVE: That reminds me of the central tenet of, like, agile programming when we were first telling people 25 years ago “How about we don't give you an estimate, how about we don't tell you how long this is going to take. We're just going to tell you what we're working on, and what we think is the most important next step.” And the allegory they use or the analogy that they use is, it's like a deck of cards. And everything you work on, every task you work on on this product should be one of these cards. And you want to stack the deck so that the most important thing is always on top, that way, you know you're not wasting your time padding out, polishing rivets when the engine hasn't been finished.

And there comes a point in your development when you hit kind of, like, around the 80% mark, where you start realizing this is a working MVP. This is a minimum viable product. We could ship this if we had to. And it gets you out of that mindset of, no, we can't let the customer see this until every pixel is perfect, and balanced, and we need the thing, and it's got to adapt. Otherwise...look, we can probably get you 80% of this product in 30% of the time if you just let us work on the most important thing first. But all the other parts have to be there.

You know, the feedback loop, understanding the business, talking to the people that are in charge of that the communication is essential. That goes back, by the way, it goes back to what Eddy was saying that if you're in a shop that's very rigidly working from, like, a story backlog, when you finish the task and you don't know what to work on, well, you do. Go look at the backlog and take the top card. If your product owner is prioritizing, you always know what the next most important thing is, and that is very, very satisfying when you can get that, when you're tired and you don't want to think through the whole project. You know, I could just work on that. We already did this work.

MIKE: Well, thank you. Thank you, everybody here for your input. And, hopefully, our listeners will think a little bit more about what's going on, you know, around them. What am I doing? What am I doing here? And based on that, what should I do next? Until next time on the Acima Development Podcast.