People Driven Development

PDD: Episode 8 - Unit economics
===

[00:00:00]

Introduction and Listener's Dilemma
---

Morgan VanDerLeest: All right. Let's see what we've got here. Dear PDD. I was recently hired as an engineering manager of managers at a midsize SaaS company. This isn't my first rodeo, but my first week was overwhelming to say the least. During our first one on one, one of the three managers reporting to me asked how she should explain the recent round of layoffs to her team.

Morgan VanDerLeest: The second manager wanted to know what to say to someone who's been repeatedly promised a merit increase that isn't happening. And the third manager mentioned that their entire team was concerned about seeing fewer supplies in the communal kitchen, wondering if it was a sign of financial trouble. I found myself giving everyone the generic answer.

Morgan VanDerLeest: "I'm not aware of any issues, we're being lean, trust the system", but I didn't actually know the reason for any of this, nor was I briefed on anything in particular. This made me realize I don't actually understand how any of this works. I want to assume that my leadership team knows what they're doing, but I can't seem to build a mental model of their decision making.

Morgan VanDerLeest: I think I'm just not financially literate that way. [00:01:00] Can you help?

Morgan VanDerLeest: What a handful. You want to take a stab at this one?

Eddie Flaisler: Cue the intro? Let's do it.

Morgan VanDerLeest: I am Morgan.

Eddie Flaisler: And I am Eddie.

Morgan VanDerLeest: Eddie was my boss.

Eddie Flaisler: Yes.

Morgan VanDerLeest: And this is PDD: People Driven Development.

Understanding Corporate Finance
---

Morgan VanDerLeest: You know, as I was thinking through this question, I realized how big the gap here is. On one hand, we can talk about corporate finance and maybe give some insights into how this big old machine works, but that doesn't address the fact that there seems to be this issue with transparency about decision making in the company.

Morgan VanDerLeest: And we've talked about that some in the past. We can dive into communication and empathy for the team, but it seems like our listener is in this senior job. They're going to need to make some hard decisions for themselves. So maybe it's worth talking about what someone needs to know to make decisions like this.

Morgan VanDerLeest: A good chunk of ground to cover

Challenges of Discussing Money
---

Eddie Flaisler: Yeah, you know, I cannot think of a topic more challenging for a manager to talk about than money. It's, uh, it's the machine code of how the business works. Imagine having to walk people through [00:02:00] some functionality you wrote using only zeros and ones. It's not just hard to follow, but your audience is also quickly losing the bigger picture of what you're trying to accomplish. What's even worse with money is that conversation quickly starts feeling dirty. You know what I mean? We know we're all here to fund our needs and ambitions, but somehow it feels so frustrating knowing that we try to bring our best selves to this place, but at the end of the day, we're a line on a spreadsheet somewhere.

Morgan VanDerLeest: You know, the fact that it's challenging makes sense because this is also an area where an engineer likely hasn't picked up this understanding while rising through the IC ladder. And the less experienced someone is within an area anyway, the more uncomfortable they're going to feel talking about something. So how do we help this person?

Eddie Flaisler: Okay. So I definitely think we'll have to discuss what is and isn't healthy to share with the team.

SaaS Finance 101
---

Eddie Flaisler: But just to cover our bases, let's start with some SaaS Finance 101. And the first thing we should probably talk about is purpose. So, for the shareholders of a business, its purpose is what? [00:03:00] To make them money. Continuously increasing, or at least non decreasing amounts of money. It's an income generator. And from a government perspective, why would they want to support the existence of a business? growing tax income, and more jobs. Now, how does everyone get what they want? The business makes increasing amounts of money, aka revenue, and spends less and less of it doing the thing that gets them the money. There's actually a breakdown for that spend, but let's just call it business costs. So, increased revenue, and reduce business costs. This all might sound like an unnecessary lecture, but I think that the path to a healthier and less taxing, pun intended, relationship between team members and leadership is the shared understanding that ultimately, unless we chose the path of a non profit, This is why we're all here. You know what I mean? I'm not condoning greed. I'm not condoning cynical exploitation. You can do all of that and still be a decent human being. But it's important to start from the [00:04:00] assumption that we are being paid to be part of a machine with this agenda. I always say happiness. Is reality minus expectations. It's not me who always says that I copied it from somewhere, but I still use it.

Morgan VanDerLeest: You do say it a lot. That's one of the first things I thought was, you know, I've heard that before from you in this scenario. You're making an important point here and the ignorance of the system you work in doesn't absolve you of the impact of the system. It's like a product engineer, never learning anything about DevOps or infrastructure.

Morgan VanDerLeest: Eventually you're being borderline negligent by not at least getting a basic understanding of the thing that makes you better at the job that you're doing now. So, all right. How does this help our listener?

Eddie Flaisler: Okay.

Financial Decision Making in Tech
---

Eddie Flaisler: So I do want to go one level deeper into financial decision making before we start talking directly about what they ask. So about money manners and about how to handle engineering budgets and stuff.

Morgan VanDerLeest: That makes sense. Let's go for it.

Eddie Flaisler: This type of seemingly reactive decision making they're talking about, like playoffs or suddenly no bonuses or no team events, is definitely not typical for when the company is meeting its financial goals. [00:05:00] Oh, and, uh, and let's assume that financial goals are a bunch of metrics about the ratio between how much money comes in and how much money goes out.

Eddie Flaisler: Okay, so it's not typical for when the company is doing well. But more importantly, this decision making is definitely not typical for one of the two scenarios people usually attribute it to. The first one is "ship is sinking". I cannot tell you how many times I heard those words. Not typical at all. If the downward spiral is already inevitable, it's actually deeply unwise to take away things from people, and your average employer knows that. There are laws in place about what needs to happen with employees when a business is winding down. And the last thing anyone wants is to deal with legal action, because at least on the surface, people were deprived of things. Right? So ship is sinking is not a very common explanation for that. The second story that isn't typical is that the leadership team of Evil Corp has decided to get even fatter paycheck by taking away money from the little people. That is not nearly as common as people think.

Morgan VanDerLeest: [00:06:00] Well, hang on a second. I love acknowledging reality and. Reality is that people do do that. They take away stuff from the organization, they show a reduction in spend, and then they somehow get a bonus or merit increase for their performance that could have stayed with the team.

Eddie Flaisler: I don't disagree at all. These things happen. I just think it's not super easy to make this scenario come to life. So you either need everyone above the person doing this to agree that it's legitimate because they'll be signing off the numbers. Or everyone needs to be completely oblivious that this is happening. In my mind, anyone listening to this podcast or in general intentional about being a manager worthy of their team would not last long in an environment where these things happen. These gaps in leadership tend to also affect many other areas of how the org is operating, so I don't see a reason to spend time on dealing with such places.

Morgan VanDerLeest: Easier said than done, I think, in a lot of cases, but thoughts and prayers go out to the people who do need to spend time there. Anyway, fair point, but if the ship isn't sinking [00:07:00] and we're not Evil Corp, then where is the money going?

Eddie Flaisler: Indeed, thoughts and prayers. The problem is there is no universally accepted definition of what doing well or promising means for a tech company. So there are some widely accepted benchmarks for minimum. Things like the rule of 40 people might've heard or other stuff we won't get into in this episode, but the maximum is anyone's guess.

Eddie Flaisler: Why is this relevant? It's relevant because while I don't have the exact numbers, I do know that most technology companies are not self sustaining, meaning they're not profitable and their growth isn't revenue driven, meaning they can't afford their own expansion. So when you're not self sustaining, who do you mostly rely on when you need money to grow or, or even to continue operating? Investors and lenders. And at that point, whatever these parties definitions of profitability and financial health is, it also becomes yours. And if that means you will have to let people go, cancel bonuses or strip down the kitchen to make your [00:08:00] ratios look better, given that you're currently unsure how to increase the revenue fast, then that's what you'll have to do. It's just one scenario. It can also be that you're a public company and you're trying to appease some needlessly strict yet important financial analyst with your efficiency so your stock can go up. The point is, it's always safe to assume that sooner or later operational efficiency will be a thing for the organization you're in. 99 percent of the time, that doesn't mean you're managing for the wrong company or that you need to get out of there. Before I shut up because I see you looking, I just want to say that I know it might sound like I'm this cold, well fed executive who intellectualizes a system where people end up homeless and their lives are ruined. I'm not. The most vivid memory of my childhood is my mom crying in the living room, having been rejected from yet another job and unsure how to pay rent this month. I do get it. What I'm saying is that as managers who approach leading our team and explaining the work ecosystem to them, It's important for us to understand what we can and cannot control and why.

Morgan VanDerLeest: Very much agree.

Engineering Budget Scrutiny
---

Morgan VanDerLeest: Alright, [00:09:00] let's zoom in on engineering in particular. I don't think either of us knows enough about what happens in other departments to draw super clean comparisons, but I think we can both agree that especially once the downturn hit almost two years ago, engineering teams were suddenly under this immense amount of scrutiny. Questions about engineering velocity are definitely not new. That's been going on for decades, but I feel like suddenly every engineering manager, I know how to justify why their team should not be severely cut. Am I imagining this?

Eddie Flaisler: I don't think you are, and I'd be lying if I said I'm certain of my explanation why that is, but I do have some speculations. So there's this very famous investment management firm named Iconic Capital. They're headquartered in San Francisco. I've never worked with them, but I'm an avid reader of all the reports they post. Their portfolio analytics team is something else. In 2021 and 2022, they reported that over 40 percent of the annual recurring revenue of B2B SaaS companies was spent on R& D, on engineering. So not 40 percent [00:10:00] of total spend, 40 percent of revenue. In late 2023 and early 2024, they posted again that companies in their survey were now targeting only 20 percent to 30 percent of the revenue going to R& D, and that this is the new gold standard. But in a recent report, it suddenly climbed to the 40s again. The moral of the story is that there is no moral to the story. I don't think anyone can explain mathematically just looking at engineering why one number is more correct than the other. Ultimately, you have your financial goals as a company, you have all the other functions that need to be in place for that thing that engineering is building to make you money, right?

Eddie Flaisler: You need marketing and sales and ops, et cetera, et cetera. And you need to identify a blend of investment allocation in these departments that gets you closer to the goal without hurting you in some other way. So let's say I want to have more salespeople. How do I do that without cutting engineering's budget in a way that they can no longer deliver that thing I'm selling?

.

Morgan VanDerLeest: But in that case, the question becomes if this is an [00:11:00] optimization problem that can be so clearly articulated and methodically solved, why do people feel like financial decision making, which ends up hurting engineering is a reactive thing. .

Eddie Flaisler: I think there are several reasons for that. The first one I can think of is that inherently engineering is the most opaque function in the company in terms of how it operates. It's a black box simply because understanding what we do and why we allocate resources the way we do requires some baseline of engineering understanding that isn't easy to align on with stakeholders if they're not from the field, right? If I don't understand in my gut how this team is spending their money, when it's time to prioritize who gets what percentage of the budget I have to spend, they're not at the top of my priority list.

Morgan VanDerLeest: Makes sense.

Morgan VanDerLeest: It's no wonder that having a leadership that understands at least at some base level why engineering is important and what is happening within that black box. You have a lot more trust amongst that leadership team and helping make good decisions here.

Morgan VanDerLeest: You know, actually that feels like something we've talked about in the past on how [00:12:00] valuable and how important it is for the leader of the engineering function to be building bridges and trust amongst other leaders within the overall company leadership team because of how hard it is to understand looking in, but how valuable it is to have that level of understanding versus some other more clear cut parts of the business.

Morgan VanDerLeest: Okay. What else?

Eddie Flaisler: Well, earlier, we talked a bit about lenders and investors. Being involved with these parties means you operate in a dynamic very similar to that of the stock market. Think of how stock prices move. It's heavily influenced by market sentiment. How much you're willing to pay for something and your criteria for whether or not this is a good investment is heavily influenced by how much those before you paid and how they decided what's worth investing in, right? Well, that's also how the SaaS spend allocation benchmarks are ultimately created and become the guideposts for those funding our company, to help them decide if we're worth the risk. I've personally had to answer questions about R& D spend based solely on the fact that the ICONIC [00:13:00] analysis said we should be spending less. Now, there's absolutely nothing wrong with that. We just need to accept that these budget allocations don't necessarily start from some first principles of how an engineering team should operate. The answers are not there.

Morgan VanDerLeest: You know, to look back at leadership and how valuable good leadership is. Now we're getting into why it's not just engineering leadership that's important, but why your company's leadership is so important. It's something you should research either before joining a company or whatnot, because having a leadership team that's able to look at investors or lenders and say, this is why we're doing what we're doing and here's the supportive reasons why is much different than them saying, Oh", well, the experts are saying this. So now we've got to go back and we've got to cut 10 or 20 percent of our folks. Cause that's what the leading experts say."

Eddie Flaisler: Show buy in, show buy in, show buy in.

Morgan VanDerLeest: Now, do you have any other reasons? Yeah.

Eddie Flaisler: So, yes, and this one is the reason I hate the most. Prepare to throw tomatoes at me. It's because those wanting to take away the money from the team [00:14:00] are sometimes right. It's super unfair to those who did nothing wrong and are now being questioned every step of the way and don't get all the resources they need to do their job because of things that happened before they were even hired. But it's a pendulum effect. Sometimes they're right.

Morgan VanDerLeest: Say more about that.

Eddie Flaisler: I'll tell you a story about one of our favorite topics, the importance of DEI in business. When I worked for Box, I needed to hire a lead engineer for my new insights and reporting team. This was a super high stakes initiative. We had some huge deals contingent on us building that, but the customers also wanted a very high granularity of information. So it was also evident that to make this happen, we would need to process a lot of data. The reason this was a problem is because I was almost at capacity with the budget I had to spend on data infra. So I needed someone who knew how to do more with less. I started interviewing, and Box being Box, I had my pick of super strong people from every brand name you can imagine. Coincidentally or not, all men. These people [00:15:00] absolutely killed all the data structures and algorithms questions. But when we got to talking about strategies for the efficient use of cloud resources and how to optimize for space and processing power, they got stuck. All of them. Then, she arrived. She had the least impressive resume of them all. Not a single brand name. But because of that, she also had to repeatedly do more with less, because these companies had much less money. I didn't even finish my questions. I remember her interview. I didn't even finish my questions, and she knew exactly what I was talking about. She remains, to date, one of the best hires of my career.

Morgan VanDerLeest: You know, this is one of the reasons why I love getting involved in the interview process at whichever company I join because unfortunately, interview process often ends up becoming: can this person check these boxes? Yes or no. And it very rarely gets to the case where how do we contextually understand what this person can do, given what we contextually need as an engineering [00:16:00] team, organization, or a business as a whole.

Morgan VanDerLeest: And if you're not asking those kinds of questions in your interview process, you're missing out on the absolute gems of people that are out there because you're just trying to tick the box of this person is going to be able to come in and execute on tickets that they're given.

Morgan VanDerLeest: And that's not the most valuable part of an engineer.

Eddie Flaisler: That's exactly how you end up with a team, where everyone looks the same.

Morgan VanDerLeest: But just to be transparent, I want to make a quick clarification. We're not demonizing big tech, Ivy league people, right?

Eddie Flaisler: Heaven forbid. On average, these people have more IQ points that I could ever dream of and are a definite asset to their organizations. My point here is that the volume of cash that flooded technology industry over the past 15 years has also created generations of engineers who scaled their systems horizontally because they don't have to concern themselves with limited computer storage. This is obviously not the case everywhere, but enough examples of that [00:17:00] do exist. I can personally reflect on my work at Uber around 2016. It was their heyday, money was flowing in, and let me tell you, I wrote a bunch of RFCs there based on their meticulously crafted template. I don't recall being faced even once with a question, how much is this genius architecture going to cost us? I'm confident things are different today. The point is, it's just not a thing. I can also remember scenarios where trying to spend time on optimization was met with, you're wasting time. We can just scale horizontally.

Morgan VanDerLeest: I'm glad you brought up Uber because I feel like you were there at a very interesting time and I think it's a really good overhiring story.

Overhiring and Layoffs in Tech
---

Morgan VanDerLeest: When COVID layoffs hit, Uber was in the news quite a bit similar to Meta and other big technology companies. Can we talk a little bit about that practice of overhiring?

Morgan VanDerLeest: Because those things seem to end up in massive layoffs when things get tight.

Eddie Flaisler: Yeah. So I think the most important thing to start with is that contrary to common belief, overhiring isn't some form of negligence. [00:18:00] It's very much intentional. You know, workforce planning, isn't this cutting edge science that people overlook because they don't know what to do. When my parents went to college in 1970s Romania, the size of the class for any given discipline like engineering or medicine was determined by the Department of Labor, who predicted quite well how many doctors and engineers Romania would need by the time the cohort graduates. So the science is there, but that's not how the technology sector has operated. One doesn't need to be an analyst to see that over the past 15 years, there's been this significant trend in tech towards growth companies. So I mean, companies where the earnings are supposed to grow fast and you keep reinvesting them in expansion. Well, when that's your goal, and especially when you have a lot of money to spend and you want to grow, you hire for two reasons. One, so you have a talent pipeline ready for emerging opportunities. Two, so others don't. And this is again a tomatoes moment, but it's [00:19:00] true. If your definition of tech talent is those with background and track record that would help you build this conventionally attractive engineering brand, then the tech talent pool is finite. So you just grab them before others can.

Morgan VanDerLeest: You mentioned attractive there, attractive to whom?

Eddie Flaisler: To investors, to prospective customers who read about the makeup of your company in the news, to more prospective hires from that background?

Morgan VanDerLeest: So if I'm understanding correctly. They're not necessarily hired because there's mission critical work for them. And if the business suddenly needs to flip a switch to staying afloat mode, they'll be let go.

Eddie Flaisler: Correct. I will say, as someone who attended quite a few hiring strategy sessions in my career, that the talent pipeline for new opportunities is the dominant reason. People typically don't come to work trying to actively hurt the competition, but I think subconsciously the second reason does end up being a guiding principle in many cases.

Morgan VanDerLeest: And I'll kind of retap into what I mentioned earlier around how that process can be shifted. The people that are [00:20:00] going to make. Okay. The biggest difference in your business are likely not the ones that seem to fly through a lot of the interview process and that in finding those folks, and like I say, how you get them into the pipeline of the first place can be an enormous effort in and of itself, finding people outside of the normal stream, the people that aren't exactly like the other folks that you have.

Morgan VanDerLeest: They may be outside of your current referral pool, but how do you bring those folks in. And then how do you catch them? What's your net for actually catching them through the interview and the hiring process that doesn't slip by just because, "oh, well, you know, These other eight people did better in the coding section." So we're going to cut this person and they may never even get the chance to talk in that strategy interview or that system design call where they're really thinking through what are the most important trade offs for your business. Now that cost actually is a problem when maybe three or four years ago, they didn't need to talk about that in the same way.

Morgan VanDerLeest: Okay. So we spent a lot of time today drawing what seems to be a very dreary picture of the tech business landscape. But I hope listeners can hear the opportunity [00:21:00] here: by understanding these dynamics, you can have a lot more positive impact on your teams and your company.

Strategies for Managing Budget Cuts
---

Morgan VanDerLeest: So let's focus on some strategies for how to manage in this new economic climate and also how to talk about it with your teams.

Eddie Flaisler: Perfect timing. Let's do that at a top down waterfall style. Ha, I said waterfall in a conversation about tech. NIXED! Anyhow, , , I only make myself laugh. At the top of the waterfall, you have your entry point to the situation, and that's the moment your updated budget or headcount is provided to you by someone in the organization with access to the bigger picture than you, typically your boss. When that new number arrives, you can very rarely negotiate it. But there are still things you can do, which I consider foundational obligations of us as org leaders. The first one is, to the extent possible, and we'll get back to these words, to the extent possible. Ask for transparency about the decision, especially if the new numbers you have will require that you make some painful cuts in your organization. [00:22:00] It's important to be able to explain them. Reality is that word salads about macroeconomic downturns don't help. Humans are a curious species and we tend to assume negative if we're missing context. Part of your ability to retain people and maintain a trusting relationship with them is to be able to coherently explain these changes to them. Your boss doesn't owe you context about how much money was given to other teams, but definitely to yours. And, and by the way, none of this is to imply that decisions to cut budget don't make sense or are done from ulterior motives. People are busy and we all sometimes need a push to explain our thought process.

Morgan VanDerLeest: Relevant to that point, hopefully you're having conversations with your manager prior to this to help influence that budget and headcount for your area in advance. So that even if you're not in the room, you have someone in the room advocating for you or for your team. If you haven't done that yet, there is no time like the present to start.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: Okay. You mentioned you had a couple of things. What's next? Yeah.

Eddie Flaisler: The second obligation is [00:23:00] to ask for a sensible point of view on what adjustments can be made to make sure your team is set up for success still. For example, we're closing your open headcount, but we know your team has been spending a lot of time maintaining legacy system X. will help you transition into a lower cost offshore team so the people you have here can still focus on innovation. If all I do is tell you, "Morgan, here's your reduced budget. Everything else stays the same. Good luck." I'm not doing my job.

Morgan VanDerLeest: That's a fair point, but this may also be something you can draw out of your manager. They may need to have a number of conversations like this, and just because it wasn't communicated to you on the first go, don't be afraid to ask questions, especially when those questions showcase how you're aware of the impact that this shift has on your team and your team's priorities.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: What else?

Eddie Flaisler: The last obligation is That's a little bit of a controversial one, but I always err on doing that. The last obligation is pushing back at attempts to dictate how [00:24:00] you're going to achieve that budget cut. So, as a leader for the group, you're uniquely positioned to know what's best for your technology and for your team. So unless there's a reasonable explanation for why you need to cut budget in a very specific way, like a layoff, you should have the flexibility to figure out a solution to the monetary challenge yourself. Not only does it make us more of an owner than a victim when we communicate this to the team, but it's actually our job as leaders to solve these problems. To be clear, this last obligation is more applicable to senior roles like director plus, because if you're a frontline manager, you don't typically manage things like the infra budget to support the product you're building, and you're not authorized to sign deals with vendors. So overall, you have less flexibility in solutioning.

Morgan VanDerLeest: Would love to kind of double click on that though. Do you have a concrete example ?

Eddie Flaisler: Yes. So I mentioned layoffs. In one of my jobs, I was approached one day by my VP. Their ask was that I let go of seven people because we could no longer afford them. Me being difficult, I double clicked until we got to the number we needed to reduce [00:25:00] the budget by. And I was also able to understand that there was no specific reason to reduce by cutting headcount. It was just an obvious solution. I'm not going to get into too many details out of respect for the privacy of that previous employer. But bottom line is I was able to demonstrate that there was some work we could do to reduce data processing costs, which we had not prioritized so far, and would actually yield marginally better savings than taking away the jobs of three out of those seven people. And now these people could be repurposed for some other domain. So we did just that. And I only had to let go of four. I will say that this is a beautiful war story, but I have a similar one where I presented the math and the response was still. You need to fire them, because we said so.

Alignment of Values in Leadership
---

Eddie Flaisler: So this goes back to our conversation about alignment of values. You can only do your job as well as your leadership team allows you to.

Morgan VanDerLeest: There are some cases where it's just going to be out of your sphere of control, right? Where no matter what you do, it's just a thing that you can't manage to shift. And you kind of need to be okay with [00:26:00] that for the job and level that you're in, unless you are the tip top of the leadership and the company are actually making those direct decisions.

Morgan VanDerLeest: To add on to that, it's helpful, especially if you can sense this kind of situation coming about to be able to support why you need the people that you have, especially if there may not be direct ties to why it's valuable to have each individual person and how they all add up to a greater whole.

Morgan VanDerLeest: What is it? The whole is greater than the sum of its parts. That's the thing where I had a similar situation where VP was coming to me and asking if I had to rehire the team that I had now, would I hire everyone that I have. And my answer was yes. I could go through and explain why each of those, even for someone who was a lower level, less tenured engineer, because I knew that their work helped bring about better work from the other engineers on the team who wouldn't have to talk or think or ask questions in the same way. So even when it seems like you could get a [00:27:00] higher quote unquote value out of somebody else, that's not necessarily the whole that you need to be talking about.

Eddie Flaisler: What a great analogy, Morgan. This is exactly right. I think when you build a team, it's so important how the pieces fit together. As opposed to looking at everyone individually.

Morgan VanDerLeest: Absolutely. Okay. Next step in the waterfall, your new budget is here. You have all the context you could hope to get. You have all the flexibility to meet it that you could get. Now what?

Eddie Flaisler: Now that's the fun part. So far, I was busy forcing everyone to involve me in the process. But now, I actually need to manage in a way that is deserving of the trust I demand. So, here's how I'm thinking about it, and these things are not situation specific. For richer, for poorer, wartime, peacetime, I need to do that on autopilot, always.

Defensible Organizational Design
---

Eddie Flaisler: The first and probably biggest thing is what you would call defensible organizational design. Now, when people hear org design, they start imagining these charts and who's placed where, that's just details. What matters [00:28:00] is a few things. One is the ratio of managers to engineers, PMs to engineers, and designers to engineers. You need to find a balance that your leadership chain is aligned on between having enough people coding and having a sufficiently staffed support system for the coders. So the EM, the PM, the designers, you need that support system so that the coders are not blocked. The second thing is staying mindful of top heavy engineering teams. So Morgan, do you remember how in the previous episode we talked about role based promotions to staff plus and how no one besides Eddie believes in them? Well, you'd be surprised, but when an engineering organization comes under scrutiny, suddenly people are curious why in a team of eight people, you have six staffers and two juniors. This again goes to alignment, like we said in the analytics episode. It all depends on what staff means. If we're going to pretend that staff is this unicornish technical leader, but then put six of them in a team [00:29:00] that works on a low usage set of features. We have a problem. If we agree. It's just about recognizing tenure and contribution, cool.

Morgan VanDerLeest: I love it. Organizational design is one of my favorite topics. And I also love that you were talking about the ratio of managers to engineers, PMs to engineers, et cetera, and, I was going through a situation recently where those ratios were already set.

Morgan VanDerLeest: And then we were looking more at, okay, how can we adjust our kind of structure and processes and system to better enable the ratios between folks? Because the ratio that applies at one company does not necessarily have to apply to another one. It depends on the context around those ratios. And those are the kinds of things that are, they're just fun that I've been to.

Morgan VanDerLeest: Figure out for what fits best for your team, your, or your company, et cetera,

Eddie Flaisler: Why were they preset?

Morgan VanDerLeest: Great question. The situation was. I had just recently come into the team and we've kind of done a flurry of hiring. Wasn't too many, wasn't an overhiring situation, but we were finishing up the [00:30:00] hiring that was already set for the team at the time.

Morgan VanDerLeest: And so then we were looking at, all right, these are the folks that we've currently got at the moment. How do we make sure that this set of people can work together in the best way? And then how do we potentially bridge that bridge out the things that we've been learning to other teams or other parts of the business?

Morgan VanDerLeest: Because in general, the processes and types of working may be similar across teams, but then those ratios were different, but it wasn't necessarily because somebody thought through those ratios in advance, but just because. there were certain check boxes for what teams in general need. We were essentially living through the shift from previous ratio made sense for the way the company was operating at one time. Now we're getting into more of matching teams and ratios to what the company needed moving forward. And we're in somewhat of that messy middle of, all right, this is what we have at the moment.

Morgan VanDerLeest: How do we set up the best environment for the team with what we have now.

Eddie Flaisler: I think this is a perfect example of how you need to have the process working [00:31:00] for you, as opposed to you working for the process. One of my previous bosses, who was a very senior VP at a public company, Was given at some point in his career, a team of four people. His original scope was 500, and then he was asked to solve a problem with four people.

Eddie Flaisler: And there was so much scrutiny and so much concern that there is a VP of engineering with four people, but he was the best person technically in the company to lead a Greenfields initiative that ended up bringing a lot of money to the company, and that was the team size needed for it. So sometimes it's not about what numbers you have set in place. It's how you solve the problem.

Morgan VanDerLeest: Could note agree more. Anything else on org design here?.

Eddie Flaisler: Yeah, so you kind of alluded to that. Not less important than the ratios we talked about. It's what the people actually do, right?

Investment Allocation Strategies
---

Eddie Flaisler: So investment allocation. The first thing I did when I became [00:32:00] VP Engineering at Lob was to start sending our COO a weekly report describing what engineering did. I had four categories.

Eddie Flaisler: I had metrics and bets, aka new stuff. I had engineering efficiency and technical foundations. issue response, and KTLO, or keep the lights on. KTLO work is things like interviews, security patches, these ad hoc third party upgrades, stuff like that. Now, you can and totally should define your own. The important thing is consistent categorization of activities into these buckets so you can have an accurate picture of how the work changes over time that you can use to educate the C suite on engineering priorities. This ended up being by far the most effective thing I've done in terms of managing up because this way the education of our C suite regarding why engineering should also do other things besides building new cool stuff happened offline and not when there is some dramatic event that requires major changes right now [00:33:00] and no one has bandwidth to listen.

Morgan VanDerLeest: I think that's a great point too. And how of course, there's always some kind of value that can be driven from a thing, but how do you make sure that you are again, showcasing it in a way that the people that you're communicating with, i. e. Leadership outside of engineering. Can understand what you are doing and why it could be sending origami birds if that's the language that the leadership understands and it is clear and they can see, okay, cool. Things are good. Or, Hey, we need to readjust some things.

Build vs. Buy Decisions
---

Eddie Flaisler: 100%. So the next on the list of strategies, informed build versus buy decisions. And the less frequently discussed cousin, open source versus vendor. Now, you know, this is the topic for a whole episode. But the point is that there are so many parameters that go into build versus buy decisions, which have direct impact on spend. Things like opportunity costs. So basically, which option would actually cost me less to develop if you account for customization, integration, and what I'm [00:34:00] not doing because I'm doing this. There is software licenses. There is differences in infra costs. Differences in supportability. How quickly can the vendor make a change if we need them to? All these things end up translating into money.

Morgan VanDerLeest: It's interesting hearing you talk through that because those are things that you can translate into just an engineering project in general. So take it into a scope that you understand. Very rarely is the simple happy path, the thing that is going to work and the thing that is actually going to match reality in the end. There's all these other pieces that really build into how you go about thinking through decisions like that. To call back to what I mentioned earlier, this is a good example of an engineering project, actually helping you be able to learn how to have these kinds of conversations with your leadership and up when it comes to a budgeting and headcount, because you have thought about things like this before in general, as long as you were at a certain level of whatnot within your engineering organization, you likely thought through: what are the costs associated with this? What are the secondary costs [00:35:00] associated with this thing? What is it going to cost to maintain this? All these pieces are just kind of different, you know, call them different cells in the spreadsheet that up add up to: as much of the understanding as we have, this is the complete picture of what we think this thing is going to cost and why, and what are the different levers that we have to be able to adjust this thing.

Eddie Flaisler: 100 percent.

Morgan VanDerLeest: All right. What else do you have?

Eddie Flaisler: Okay, so it's tomatoes time again. But like big tomatoes. You ready?

Morgan VanDerLeest: I am not, I have run out of my tomatoes. Let me go to the store. All right. Go

Morgan VanDerLeest: for it.

Eddie Flaisler: God, I'm gonna sound like a boomer.

Importance of Fundamentals in Engineering
---

Eddie Flaisler: Never underestimate the importance of proper use of data structures and algorithms in software engineering. Require that knowledge when you hire and make sure it's put to use when appropriate in your team's work. I can see your face, hear me out. I welcome with a lot of enthusiasm the movement towards skill based hiring, where you no longer have to graduate from a university you cannot afford to get a job. The [00:36:00] problem starts when instead of finding alternative ways to get people from diverse backgrounds up to speed on these foundations, we start a campaign of questioning the need for them altogether. I cannot tell you the number of times I heard engineers joke about how they were asked to implement some use case for hashing in their interview, and how, quote, you never use this stuff at work. Well, let me tell you what you never use this stuff at work looks like. At one of my previous companies, we lost several strategic customers in one month over a shockingly slow event processing system. It turned out that the bottleneck was this piece of code that checked whether a certain object exists in this massive in memory set of objects, and whoever implemented it used plain linear search. Every time a request came, they would check against the entire set, one by one. Now, meanwhile, waiting patiently to be used since the 1970s is the Bloom filter data structure, which checks for set [00:37:00] membership in constant time. Not using that is literally leaving money on the table. Not to mention all the products in place, things like Redis or in memory databases that have these quick query time, which you can utilize. But even if you cannot afford that service, you can totally implement that yourself. But it's about knowing that these things exist.

Morgan VanDerLeest: It's funny. It really just gets back to fundamentals at the end of the day. Right. And that's an interesting thing that it feels like we don't necessarily get back to enough within the profession. Even for the folks that you have on your team, regardless of the foundation that they have, you likely have some kind of learning development education stipend thing.

Morgan VanDerLeest: How do you go about enabling people to refocus on fundamentals, because that's stuff that even if you had learned it at some point in the past, it's probably gonna slip away and you need to bring that back in. I'm gonna torture myself later for going into sports metaphors. But it's like being a professional basketball player, you dribble everywhere. You shoot thousands of the same shot over [00:38:00] and over and over again. We don't do anything similarly in engineering where you are really kind of repeating and going through those phases so that you are prepared to use whatever the best tool is in the situation, because you probably haven't experienced it in the same way that many times in the same way that a professional athlete in that way has.

Morgan VanDerLeest: So I will slightly step off my soapbox also say part of this very much feels like the speed versus quality conversation. But not from an engineering standpoint, from a business standpoint, where the faster thing is just hacking the thing out and getting it done. And then you're living with this awful complex, or maybe not even complex, but just non performant code that if you had taken the time to get a little more quality polished up in the process, you'd say like, Oh, duh, obviously there's a more efficient way to do this thing. But I didn't think of the efficient way to do it when I was trying to solve this other business case thing in the moment. Having that time built in so that you can get the simple, clean, [00:39:00] performant answer is not the simple, clean, fastest thing the first time you go through.

Eddie Flaisler: I'm not going to deny that. And we touched upon it several times in previous episodes. There's a lot of pressure, a lot of pressure to do things fast. And oftentimes it's explicitly at the expense of thinking it through. But then, of course, when things explode, we should be better about quality.

Morgan VanDerLeest: 100%, it's always a balance. You got to figure out what that balance is for you, your team, your company. What do you have next?

Cost Consciousness and Budget Management
---

Eddie Flaisler: Mindful utilization of usage based tools and also don't buy software you don't need. Do we really need to talk about the Coinbase 65 million 2022 data dog bill or were lessons learned?

Morgan VanDerLeest: I feel like that's one of those things that I saw and thought, Oh goodness. No. Can you talk me through, was that actually negligence there, by the way?

Eddie Flaisler: I don't think it was. I think, you know, It perfectly fits what we've been talking about this entire episode. I know we're both huge fans [00:40:00] of Gergely Orosz. I'm so sorry if I butchered that, the Pragmatic Engineer, and he described it really well. The story is that Coinbase had a great 2021, trading volumes were surging. They needed to track all this activity, but didn't see the need to pay much attention to efficient logging practices or anything else that would save them money. They had plenty of cash, so they spent $65 million on Datadog. In 2022, the crypto business started declining, so they needed to cut back on infra cost. Boom, customizing open source. They switched to Prometheus and Grafana. Same cycle everyone goes through. The thing is, as you can imagine, cuts were needed to fund the time between realizing the overspend and implementing the alternative solution because that transition didn't happen overnight. And in the meantime, you're spending more money than you can right now. So you need to cut somewhere else. I don't know what it was. I don't know if it was people, if it was [00:41:00] something else, but something must give. And that's my point. Maybe we can be a little more proactive,

Morgan VanDerLeest: Frustrated with how many times and having to point to "have a good leadership team" in this episode. But that's why it's so valuable to have a leadership team that's not stuck in the weeds all day and micromanaging the teams. When they're able to look ahead and see the things that are coming up and be proactive about the situations and have the context from their teams, aware of what's going on and being able to hopefully help either prevent those poor situations from happening or give their team the runway to help make a shift as it's needed.

Eddie Flaisler: You know, Morgan, I don't think you're wrong. And again, it's easier for me to have more empathy because I spend more time in these positions, but I do think that hindsight is 2020. And the only reason to avoid or minimize the situation where only in hindsight, you get it is to have discipline. So you remember when I started listing this and this list of things I'm talking [00:42:00] about right now, I said, this is something you do always rain or shine. And the reason you do it always, because you don't think about it. You don't need to think is now a good time to utilize this practice. You simply do it. So you get into it, right? You get in the habit of thinking through the lens of what will this mean in the situation of X, Y, Z. And if you think about it. The core of this episode is there's no such thing as bad spend or good spend. There was a time in the past 15 years where the right way to go was throw money, throw money, throw money as long as we grow. But it's no longer the time. And my point is from personal experience, not as a theorist, having done that myself multiple times. It is possible to find a balance, to be a little more productive, a little more structured, maybe not super, super conservative, because then you kill innovation, you kill all the opportunities you were not expecting. But that doesn't mean you need to let go completely [00:43:00] of thinking things through.

Morgan VanDerLeest: 100%.

Eddie Flaisler: And, regarding not buying software you don't need, the issue here is actually not just about money you spend. Each such tool comes with its own baggage of security and compliance management to make sure you're not compromising your data or your systems. Then there's this lack of standardization. So, imagine I'm writing my docs in Notion, and you're writing your docs in Coda, and we need to review each other's docs, so suddenly it's two seats of each. And as the number of seats grows, there is more work on I. T. To administer the vendors. I can go on, right? So mind your online shopping, please.

Morgan VanDerLeest: That's an area too, where you're going to get pushback from people in the business, no matter which way you go. You got to be okay with that. And at the end of the day, the efficiency and the promise of using one standardized tool set as much as you can. There's a ton of benefits to that.

Eddie Flaisler: Totally thankless job.

Morgan VanDerLeest: Alright, we're nearing the end of our time today.

Communicating Budget Changes to the Team
---

Morgan VanDerLeest: So let's get to the bottom of the waterfall and finish it off with some tips about explaining budget and budget driven changes to the team.

Morgan VanDerLeest: What comes to mind to you [00:44:00] when I say that?

Eddie Flaisler: Probably the most important thing for everyone to remember, and I mean, managers and their reports alike is that there is such a thing as TMI, too much information. Many times it's our responsibility to look our team in the eye and say, "That's all I'm at liberty to share right now. We're actively working through this. Nothing to worry about at the moment. When we have relevant updates to share, we will." I had a manager who used to tell me anything and everything that was going on in the boardroom, until I myself asked the person to stop. It was needlessly impacting my emotional health. There is such a thing as above my pay grade. I don't have all the context. So learning about things I don't fully understand and can interpret incorrectly doesn't help the situation. It can actually make me even more worried for no good reason. There is also such a thing as too many cooks in the kitchen. Not every decision can or should consider everyone's opinions. And most importantly, there is such a thing as system equilibrium. Given time and consistent action, [00:45:00] things do have a tendency to sort themselves out. So sometime before you induce panic, it's better to wait and see how things pan out.

Morgan VanDerLeest: it's part of our jobs as leaders and as managers, communication isn't just parroting what you've heard. It's about making sure that the information that you are then sharing is useful to the people that you're sharing it with, whether that's context on a project or budgeting impact on your priorities for the next year, or how the next year strategy may impact hiring or current team size. Until you know something for sure, or until that information is something you can actually pass on,

Morgan VanDerLeest: it's not necessarily something that you should pass on.

Eddie Flaisler: 100%.

Morgan VanDerLeest: Anything else?

Eddie Flaisler: Yes, and it's kind of related to what you just mentioned. I cannot stress enough how important it is to make cost consciousness part of the day to day conversation with the team. We're just talking about generations of horizontal scalers. Well, think about it. These engineers are also used to a world where you don't talk about cost savings [00:46:00] unless something is wrong and the business is in distress. So they adapt it to the snacks in the kitchen or to the tickets for the conferences that are not necessarily related to their work and to the automatic sign off on every tool they want to purchase. And that becomes their baseline. Now, don't get me wrong. I love free company dinners. I love cool holiday gifts. I love business trips. And I want to be able to offer that to my team as well. It makes you feel special, important. It's fun. So the idea is not to deprive them of that so they don't learn to expect it, but to give them a sense of shared ownership on the budget allocated to that. Protect it together. So negotiate the best group menu costs. Find the cheapest flight tickets that are still comfortable. Remind people that these budgets are finite and that it's up to us as a group to use them in a way that gives everyone access to the same benefit. Side micro story, you cannot imagine how important it used to make me feel when I was an engineer and my manager tasked me with finding the best [00:47:00] menu for the team. The one that optimizes price and what we get for it.

Morgan VanDerLeest: And that actually harkens back to our conversation around ownership and helping to build up that ownership amongst your team is looking at: how can I improve the situation that I'm in, given the tools that are available to me. And that could be the menu for the team dinner or a million dollars savings in AWS cost. It's all valuable.

Morgan VanDerLeest: And I should clarify, I'm not opposed to being transparent in communications. But for example, if I walk by the window of the sausage factory, I would be horrified by what I saw looking through that window. But that doesn't mean I'm not going to eat the sausage on the other end, and then I'm going to be damn happy doing it.

Eddie Flaisler: Totally. What an analogy. Now I cannot unsee it. Thank you.

Morgan VanDerLeest: Oh, that's, that's what I'm here for. Any last thoughts?

Final Thoughts and Feedback
---

Eddie Flaisler: Yes. Own the difficult decisions you're communicating. It's very uncomfortable in the moment when you're delivering the news, [00:48:00] but it's actually the most effective thing you can do to retain your team and continue building trust with them. Now, when I say owning it, I don't mean, you know, saying, I decided to lay off XYZ or I decided to close the headcount. Unless you're the VP, you're probably just lying. Taking ownership is explaining the rationale behind the decision in a way that shows you're bought in and are already working on a path forward for the team. Managers who are avoidant of hard conversations with their teammates would often say things like, I wanted you to have this, but leadership said no, or that person sucked anyhow, they deserve to be let go. It might feel better in the moment because I feel less guilty, but the impact of a manager using this language is devastating because it's telling the team they have no agency. No seat at the table. The person who is meant to protect their interest in this organization actually has no say.

Morgan VanDerLeest: Situations like this are often, like you mentioned, a uniquely valuable time to [00:49:00] build that trust with your team, because there are also ways to share that you're not a number crunching monster and this person who's like: " This was a tough thing to do. These are why these things are happening. I understand how you may be feeling X, Y, Z way because of this. And I understand that that can be a hard thing. I want to make sure that I'm giving you the time and the space to talk through the reasoning why. If there's something that I don't have an answer for, for you, I'll do my best to figure out what that is." Because that's the other thing. It's not just, I have all the answers and I know why this is happening to your point. It's how do I make sure that we are in the best possible state in the end and doing the best that we can moving forward for the company.

Eddie Flaisler: I'll drink to that.

Morgan VanDerLeest: All right, y'all, if you enjoyed this, don't forget to share and subscribe on your podcast player of choice. And as always, we would love to hear your feedback. Did anything resonate with you? More importantly, did we get anything completely wrong? Let us know. Actually, you know what? Not just completely wrong.

Morgan VanDerLeest: If we got it a little wrong, I would still like to know, cause that just [00:50:00] makes me better than I was yesterday. So I still want to hear it. Share your thoughts on today's conversation to peopledrivendevelopment@gmail.Com, or you can find us on X or that Once was Twitter thing @pddpod. Bye everyone.

Eddie Flaisler: Cheers!