People Driven Development

PDD: Episode 6 - Silos
===

Eddie Flaisler: [00:00:00] Okay, let's take a look at today's question.

Eddie Flaisler: Dear PDD, I work for a 10 year old company with some strong OGs.

Eddie Flaisler: OGs? Original gangsters. I recently took over managing the team of four well tenured engineers, been with the company about five years each, and they hold a lot of historical context in different parts of the application. Our domain has a big business opportunity, so we're hiring more engineers fast, but I'm really concerned that we won't be able to effectively bring more people up to speed with the domain knowledge so we can get this thing shipped in a timely manner.

Eddie Flaisler: How do I work around these silos of knowledge at a time when we're supposed to be speeding up our delivery?

Eddie Flaisler: Signed,

Eddie Flaisler: Grain Free.

Morgan VanDerLeest: Grain free. I love a good agricultural engineering joke. It's funny. I think you can squint at this question and it, even though it feels specific, it also feels like it could apply to just about anywhere that either one of us has worked, I'm sure. Let's cue the intro and get to 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 [00:01:00] Development.

Morgan VanDerLeest: All right, Eddie, you wanted us to select this question, which I find weird because it seems like there are a number of ways to interpret it. What are they worried about?

Eddie Flaisler: You know, one of my favorite authors is Haruki Murakami and he has this memoir called "What Do I Talk About When I Talk About Running?" And this question reminded me of the book's title because, it's always worth asking what do I talk about when I talk about silos? It's a word that's brought up so many times in corporate conversations and it can mean so many different things.

Eddie Flaisler: One typical use case is people not sharing information that needs to be shared. And that's either because they make a conscious choice or systemically, there are just no good mechanism for that. Second way to interpret this is decision making, which isn't always done through the correct lens. Because you have to lean towards few with the most familiarity or experience with a certain system, even if the decision itself isn't necessarily technical one, or others should be involved, like deciding milestones or [00:02:00] dates or how do we support the product or how we interact with customers and stakeholders.

Eddie Flaisler: Stuff like that. You are forced into a minority opinion. The third one can be maybe communication between all the involved nodes in the execution graph, so to speak. It takes too much overhead. Everyone always complains "it's too complicated to keep everyone in the loop". And last thing - which has always been for me a pain point managing platform teams - is managing dependencies.

Eddie Flaisler: Managing dependencies can be a nightmare because you need to get on everyone's calendar and you're not sure where you are in their priority list. And when I say priority list, it can be both in terms of project priority, you know what else they have going on, and incentive system. Are they motivated to help you?

Eddie Flaisler: But I think the bottom line here seems to be a question of efficiency. I think that silo breaking is the organizational design cousin of productivity engineering, right? So instead of talking about how we design my build and deployment pipeline in a way that is conducive to rapid iterations and happier [00:03:00] engineers who can actually focus on implementing the thing instead of getting their own freaking environment to work.

Eddie Flaisler: I talk about what structure I give to my people's work and, you know, it can be the culture I build or how I distribute them in teams or, what processes I come up with and even what architectural guidelines I enforce to make sure we don't build things that propagate silos where they're not the right way forward.

Eddie Flaisler: How do you think about that, Morgan?

Morgan VanDerLeest: I think the question's interesting because whether you explicitly talk about it or not, this is going to come up at every engineering software focused company, maybe any company period, just based on humanity at its core. I think silos are an inherently human thing because everything that you think and do is siloed to you unless you have some way to broadcast that information and share that with other folks.

Morgan VanDerLeest: Even on a personal level, you are siloed until you are married, at which point you share context with another person on a regular basis and you're able to act independently on the shared [00:04:00] context of thing, but that's because you are explicitly communicating and prioritizing with this other person. And so it's a classic business problem. When the team is small context is shared more easily and you don't have to worry about these things as much, but then as the company grows and as the teams grow, you split into different engineering teams, you have these different understandings of things that are going on and you have to worry more about that communication, prioritization, organization. Those are all things that just become more of a struggle as you work. And whether you explicitly call this out at the company or not, this is absolutely happening. And the better the business can set up processes to help support and encourage folks to share that context and not get into the situation.

Morgan VanDerLeest: I think you're, you're going to be in a better spot. Also, the book "What Do I Talk About When I Talk About Running?" Just came off hold at the library for me. So the timing is beautiful.

Eddie Flaisler: Oh, wow. It really is a great book.

Morgan VanDerLeest: So I heard you say where they are not the right way forward. Now I've heard this notion of silos being demonized so many times that I wonder if there are cases where [00:05:00] silos are actually a good idea.

Eddie Flaisler: Well, I actually think you just specified it. You've mentioned the situation in which quote unquote silo is the right way to go at a certain point in time. All organizational silo means is that there is an aspect of what the organization generates. And it can be a product, a system, a pipeline, a set of components, where the number of people set up for success in developing and maintaining it is a subset of those who theoretically have the skill set to work on it.

Eddie Flaisler: And their time could be utilized in this area as well. So, you know, in that respect, today's question is a textbook example of a silo. You have a business opportunity, you have all these engineers that could work on it, but you're stuck, because for a variety of reasons, only four people can do it effectively.

Eddie Flaisler: But, you know, going back to what you actually asked me, what I claim is that instead of looking at how we're stuck now, we can also look at what we chose to gain by designing things this way. We reduced cognitive [00:06:00] load and context switching for other engineers because instead of making them have yet another thing to keep in their heads. We made a decision not to. We chose to put the time of other team members in areas that were more strategic or revenue generating at the time.

Eddie Flaisler: And just like you said, we prioritize time to market. So we limited the work on this particular thing to a small tightly knit team who would probably work faster. These are all valid choices, and I think it's important to call it out. The problem is that they sometimes become, what I call, an addiction to low hanging fruit.

Morgan VanDerLeest: Okay. Tell me about out this addiction to all hanging fruit.

Eddie Flaisler: Well, think about it this way, the most straightforward thing to do when a new business opportunity arises is to pull at zero notice some star developers from across the organization, make a tiger team, or scrum of scrums or whatever you call it, and have them go at it.

Eddie Flaisler: There is nothing inherently wrong with it the first time you do it. But one of the defining moments of who we are as engineering leaders [00:07:00] is what we choose to do after it happened the first time. So, do we carry on and have the same group of people jump at the next opportunity? Or, do we make a point to identify and act on what potentially makes these individuals more suited than others to take this on?

Eddie Flaisler: So, next time, not only is the business continuity not reliant on such a small subset of engineers, but also others can grow and challenge themselves with these types of products. I love Malcolm Gladwell's book, Outliers. I love the focus on, sure, these people are talented, but what are the systemic circumstances that brought them to where they are today?

Eddie Flaisler: And I think this can very easily be applied to work as well. What seems to happen sometimes, unfortunately, is that we make our lives easier by deeming everyone else besides these few individuals simply ill equipped to do this high impact, short term work.

Eddie Flaisler: And when the small group we cultivated burns out and leaves [00:08:00] or even starts behaving in ways that might require some performance management, we shrug and say, I just don't have the right talent bench to do this differently.

Morgan VanDerLeest: You know, this actually came up for me recently. We were talking about the different kind of types and flavors of more senior and staff people at the organization and how within those flavors, there's this, the style of, pioneer person who to your point, you would put on this style of team. Is that a long term thing?

Morgan VanDerLeest: Is this the type of role that this person kind of always upholds? And we once the business opportunity solidifies, we build up a team around that. Leave it. This person goes and does another thing. Or leaving them to become the new tech lead for that team and how does that transition happen? But, some people may want silos for their job security. That has its own troubles that come with it, either preventing you from being able to shift up or out into a different area. There can seem to be any way individual benefits and business benefits doing this thing. This to me comes, comes back to that [00:09:00] flexibility. It's that adaptability. How do we read the situation in the best way possible and set us up for what is the future of the business need? Do we need to be really flexible and adaptable and be able to have these kinds of spinning up teams for new opportunities quickly? Or if we can predict those things further out, can we build towards that and have it be a more organic shift versus plucking these star players from elsewhere in the organization, which now we're leaving behind these star player gaps for other areas, which is not a good thing. We don't want that.

Eddie Flaisler: You know, it's funny you mentioned job security because I used to demonize people who engage in that a lot, right? How dare they, right? They don't care about other people. They only see themselves. What I know today is that it doesn't work like that. You know, ultimately, we come to work to make money, to support our family, to support our livelihood, because, you know, full time job takes most of your time.

Eddie Flaisler: We also use it for our growth needs. So, I cannot really judge those who are interested in having the organization depend on [00:10:00] them to a point that they are irreplaceable. So, I think our opportunity as a manager to help avoid situations where people do not share information or act in certain ways that are not constructive to maintain job security, it's in organizational design. So, you set expectations not through talking, but through doing. One thing that I always believed in is the concept of rotating technical leader.

Eddie Flaisler: I don't believe in having the tech lead for the team because that actually means you need to wait for several years for that person to leave. So it's your time to actually take the lead and shine and do more design work and do more product requirements work. I always like to have several work streams happening in parallel, you know, to extend that to the extent that it makes sense from work in progress, WIP, right? From the extent that it makes sense. And each of these efforts has a tech lead, and that tech lead actually can be very, very junior because it just depends on the scope. Everyone deserves and should be looking at the [00:11:00] entire life cycle of developing a product or a service or a system. So I'm with you completely. I just think that there is a lot we can do as managers to avoid creation of such cultures and not just put it on people for either being nice and friendly and collaborative and not wanting to build their own tiny empire with the software they use.

Morgan VanDerLeest: You know, it's interesting the way that you phrase those things. You have these loaded titles or these loaded roles where, for example, the tech lead doesn't necessarily need to be the person who's in charge of all the things. But the person who is in charge of making sure that the team is able to handle these things. And then you can build up those skillsets and either the ability to tech lead or whatnot with others on the team and have them own whole projects or initiatives and kind of fulfilling a tech lead style role while not necessarily being the lead of the team. The way that I interpret that more is a tech lead is more the engineering lead of this domain. I know more about this domain than anyone else [00:12:00] here for a variety of reasons and I'm most able to help coordinate technical shifts that need to happen. Even when other people rotating in, they're not necessarily going to replace that. So I think it is very important that whatever process or structure or whatnot that an organization may land on. They're very clear about how they define things, how they define their responsibilities and at the end of the day, it is still, how do we make sure that there are overlap. And making sure that there's not just the one person who is the end all be all of any particular area, really. You know, and even as I'm talking through this, it feels like we're touching on a lot of really foundational aspects of silo creation. And at the end of the day, that's culture, isn't it?

Eddie Flaisler: Yeah, this aspect of culture building is a bit of a problematic territory. Because every time I bring it up, I worry people will see me as this ruthless, not-people-first-individual. But I actually think it's very healthy for building a good culture. And what I'm talking about is succession management.

Eddie Flaisler: So you talked [00:13:00] about the notion of having the tech lead or the team lead as a supporting function. Kind of like a manager, but like on more technical issues. And by the way, some of the best teams I know combined the two roles, right? So the manager is a technical leader in that respect.

Eddie Flaisler: I do think it's really important to be very mindful about creating an environment. where succession is not painful. Life happens and we can always end up in this situation where we're overly reliant on one or more individuals to a point that we either burn them out or have to tolerate behaviors not in line with our operating principles and values because we need them.

Eddie Flaisler: But that doesn't mean we shouldn't be intentional about minimizing the frequency of these occurrences.

Morgan VanDerLeest: So how do you suggest we do that?

Eddie Flaisler: You know, so there are two approaches, start from the beginning and start from the end. Start from the end is more painful, but you know, when faced with no choice, I've taken it multiple times. You make a strict, [00:14:00] widely communicated decision about the acceptable capacity of an engineer in your organization and the consequences of behaving in ways that are not aligned with your team's values.

Eddie Flaisler: And you enforce them. You enforce them while momentarily turning a blind eye to immediate business consequences. So I'm trying to say that I understand a customer is waiting. This is a strategic, important moment for the team. So almost every time I said no to something because my only option was someone who could not do it either could not do it because they were at capacity and it's not the right thing at this moment to add this to their plate or because I don't think they should move forward with us regardless of how productive they are individually or have a great technical ability.

Eddie Flaisler: You know what? We ended up finding a workaround as a business and giving opportunities to others. And you know what, Morgan, if the sustainability of the business depends on that specific instance which requires this specific person, we have much deeper issues to deal with. So that [00:15:00] is what I call start from the end.

Eddie Flaisler: Start from the beginning is more technical work, which is, you know, it's often not easy to do unless you're building something from scratch, but at least in part it is possible, right? It's important to get alignment, but it's doable. And what I mean here is: investing heavily in, how should I put it, textbook product management.

Eddie Flaisler: So you see, writing long specs and RFCs that get stale and nobody reads doesn't help. But there are a bunch of things I think can be very helpful. The first thing, and that's a personal passion of mine, is living documentation. So there's a framework called Cucumber, which I discovered only a few years ago for behavior driven design.

Eddie Flaisler: So basically instead of writing this long wall of text, you do write a lot of text, which is how the system should behave in certain cases. So when I am on this page, I click this button and then X, then Y. And what's really magical [00:16:00] about this is that it creates a situation because it's tied into tests. It creates a situation that free flowing English, or it can be any other language, English language description of what the system does, is tied directly to the actual system. So, unless you truly game it, you don't get to a situation where the paper says one thing and the actual behavior is different.

Eddie Flaisler: So at any point, everyone is aligned around what the system should behave like, which you know very well, causes so much friction when developing products, or like fixing issues, because wait, was that expected or was that not expected? So that's one thing. The second thing, and that's something that I've received a lot of pushback over the years on, but it ended up being very useful: military level discipline, even for the tiniest of startups, about where and when technical decisions are made. You know, in one of my companies, the engineering team for a certain product was split across two offices. And the OGs, to use the same word [00:17:00] from the question, were actually all in one office. And they would make these design choices in private Slack channels, or by the water cooler in their own private hallway.

Eddie Flaisler: And then everyone else had to play catch up. With this culture, no smart AI that indexes information can help you. So I don't care what you use as a system of record, but it should be accessible to everyone and in one place. Two more things I can think of is convention over configuration. So what is convention over configuration?

Eddie Flaisler: When you set up a development environment, I want to maximize chances that the person who inherits the system from you can find answers on a public search engine instead of having to deal with this cryptic config file that makes sense only to the person who wrote it. And similarly, when you choose a framework or a library, choose it based on community support as opposed to personal interest or hype. I think it's a very delicate topic because it's true that sometimes people make choices because [00:18:00] they're curious about learning the latest framework, but other times it actually makes some sense. So I've been in situations where developers wanted to adopt a certain framework because they thought the syntax is very free flowing.

Eddie Flaisler: It'll be easy to read. So that's actually great, right? Succession management, readability. However, they were also experts of that framework, which was rare. Most people were not. So chances were that the person after them would not be able to contribute as effectively to this code base. We decided against it.

Eddie Flaisler: Any other examples you can think of?

Morgan VanDerLeest: You know, Eddie, as were talking through these things, a key importance that seems to come up is a responsibility as a leader or manager to say, we either have silos or want to try to prevent them in the best way possible. And that we are prioritizing improving that. So that both individuals and other managers feel like they have the support to actually go about and make these changes. Cause it's a lot harder when you're the only one that knows about it, or the only one that thinks you know [00:19:00] about it. And you're trying to make all these changes yourself versus cool. You know what? I've made the case. Maybe that's something this individual needs to do is make the case to their leadership.

Morgan VanDerLeest: Hey, I'm noticing this thing. This is an issue. It's probably happening in more areas, but there's a thing here. Let's make this a higher priority and can you just give me some buy in or support to start making some of these fundamental shifts or to your point earlier support making the right call as a team over the near term win for the business of fixing this thing for the customer. It's very hard in the moment to make that decision.

Morgan VanDerLeest: And I don't want to have to run that up the chain at the moment to make sure that it's okay to do this. I want to say, Hey, I've been given support from my leadership that this is the thing we want to fix. We're okay with making these changes now I can broadcast that to whoever needs to know about it in that particular support engagement and we make the shifts in that way.

Eddie Flaisler: So Morgan, I think you hit the nail on the head with this because this takes us back to more foundational aspects of the work that we covered in previous episodes, which is alignment. It is so important to have alignment across your [00:20:00] leadership team on certain directions or lenses of decision making, values, operation principles, and what you just said is a perfect example of that.

Eddie Flaisler: Because, it's very easy for me as the executive to tell my manager who reports into me, you're not courageous enough. You don't bring things to the table. You prioritize, as Brene Brown says, comfort over courage, but it doesn't work like that.

Eddie Flaisler: It takes two to tango, right? If the environment is not such where a manager is not worried about their reputation or the response, and they know they can bring to the table an argument that is not abundantly obvious for everyone, that it's directly tied to the business. And you need some expertise in engineering or some trust to take a leap of faith and be like, okay, it, it makes sense.

Eddie Flaisler: I see. It's very well researched. Let's do this. I asked the right questions. I am convinced. If the environment is not like that, people will not be motivated. I have not [00:21:00] always been motivated. One of the reasons I love doing this podcast is that yes, we talk about real experiences, but we also talk a lot about best practices that we have found over the years to be very, very useful.

Eddie Flaisler: But in reality, these are not always possible to execute. Because it's humans, right? And human dynamic. And we are not always put in a situation where we feel comfortable as people doing the right thing. So I think what you said is incredibly important.

Morgan VanDerLeest: It's always nice to be agreed with. Let's double click into a typical scenario where you have an existing system with existing processes that are more conducive to problematic silos. What do you do now to break those?

Eddie Flaisler: So, first, I'll say that most of what we just mentioned can be applied going forward, right? Even if not retroactively, it will still add up. Just because it hasn't been done historically doesn't mean you can't start. And at some point, you have a sufficient body of work that was done in this way to make your life much easier. It's never too late.

Eddie Flaisler: [00:22:00] Second, I think, we spent some time at the beginning of this session, trying to demystify what the question was and look at the various options. I think this is one of these situations where you can't just look at the high level problem of breaking silos. I need to know what is the underlying problem we're solving because that's what will dictate what we do.

Eddie Flaisler: So, for example, if it's a coordination between different teams problem, which it so often is because the underlying issue is engineering velocity or how quickly we iterate or how painful it is, right? Everyone wants single threaded execution. So if the coordination is the issue, I want to stop and ask myself, why is the current organizational structure the way it is?

Eddie Flaisler: Why are teams distributed a certain way? There must be a reason. It made sense at some point. And from there, I asked myself, what will it take to change it? I'll tell you a story, because I love telling stories. I've inherited this team, which was everyone's bottleneck. And, you know, these poor people were just working around the clock.

Eddie Flaisler: Everyone was always [00:23:00] complaining that their asks from the team were blocked. And the manager was burning out in front of my eyes by doing this constant apology tour. Because they were always having to justify why are they behind and why they have to say no to this and why they can't do that. And they came to me one day and asked for more headcount.

Eddie Flaisler: But we did the math together and they needed at least four more seniors. That's like a million dollars a year, right? Not to mention these people would not be immediately productive, the time to hire, cetera, et cetera. What I did was review with the manager how they were doing on self serve and platformization.

Eddie Flaisler: So how difficult was it for someone outside the team to contribute effectively to their code base? That ended up being where the bone was buried. We allocated some resources into doing that work, which introduced this cost of delay worth something like, I don't know, 100k. But then everything became so much easier for everyone else.

Eddie Flaisler: The thing is, it's cute that I tell this [00:24:00] war story, but I want to go back to my earlier point. These things are not easy to achieve if you do not have alignment. Ultimately, if my leadership team at that point, as senior as I was, would shut down the moment they heard anything not directly related to new product development, the conversation would be over.

Eddie Flaisler: I was very fortunate to have built credibility with my leadership team, who was truly interested in solving the right problem. And we had an understanding that reality is a balance. between the tactical and the strategic. It cannot be any of those in a silo, so to speak. It has to be a combination of both.

Eddie Flaisler: And this was one of those situations where it was well worth it.

Morgan VanDerLeest: It almost comes back to the five Whys. Why is this a thing? Okay. I get that. Why is that a thing? Okay. But why there until you get to whatever the actual cause of the thing is. And then like, oh, okay, well now we're in a whole different ballpark of a solution here versus just more people.

Morgan VanDerLeest: Honestly, this feels like [00:25:00] something that in the majority of organizations that I've worked with, we've needed to combat this in some way. Whether it's explicit or not, you have people who are probably dealing with this. I can think of one where, come onto a new team. There were kind of two folks on the team who had a ton of context and who knew most of the things about the domain. But it was in a particularly important area for the business. So there were transitioning some folks and we were hiring some new folks onto the team and we had to get this knowledge sharing done essentially ASAP. So couldn't take these people off of projects necessarily. That didn't make as much sense in this scenario, but there were a couple of things that we were able to kind of tactically do to help with knowledge sharing in general.

Morgan VanDerLeest: One was grouping on projects. So never had the two of them working on the same project. It was always them and somebody who knew less about it. That way they were building up that knowledge sharing amongst the team. And also we set up a cadence within our meetings of regular share outs of things that you learned or how to do new stuff within the team. So new domain for a lot of folks. How did you do when you were doing the support rotation or on call, was there a new tactic you [00:26:00] needed to use to be able to figure something out?

Morgan VanDerLeest: Okay, cool. Share that out to the team so that that's now in everybody's toolbox. Make that a thing. And then there's a scenario when there are incidents, which occurred from time to time. And instead of saying, okay, these experts, they're going to go handle this. We kind of took the quote unquote business hit and said, Nope, everybody come mob in here. We need to figure out what's going on and why we're going to split out these action items of how we're going to go about fixing this thing.

Morgan VanDerLeest: So folks to kind of build up the muscle of how to handle when certain things went wrong within the code base. And that really, especially under such like a high stress situation makes projects within the domain a lot easier. Oh, I I've done this under high stress. I can do this under a typical work week. That's not a problem at all.

Morgan VanDerLeest: So that was one situation. I had another one where had an engineer who had originally set up a new set of services within the company. They were the only one that had really kept up with it over time. A couple of people had poked their heads in, but it really wasn't this thing that was spread out outside of this person. But lo and behold, the problem with individual wanting job security, they had a sabbatical [00:27:00] that they had earned coming up. And so they were going to be gone for a month. When there's this big area of the code base that was solely their responsibility, essentially. So we had to come up with a game plan for if you didn't touch this at all, and it was only other people on the team, what would that look like? So a couple of things there.

Morgan VanDerLeest: This was a scenario where it was okay to say Hey, you're the expert, but we're actually going to pull you off of any projects that have to do with this. You can be consulted, but you're not going to be actually actively working on the project. So that alone helped force other members of the team to help pick up some of that understanding. And that was something that we need to be very clear about. Hey, a priority of the team right now is to build understanding in this area of the code. It's going to be a little messy. It's going to be a little murky.

Morgan VanDerLeest: That's fine. We're going to figure it out, but this is really important for us as a team and as an org, and, as a business. And then similarly, there was actually an incident around that particular service and while that person was pulled in because they were the expert and they tackled the very short term fix. There were some longer term followup and we said, [00:28:00] all right, expert, you are not allowed to do this.

Morgan VanDerLeest: This has to be somebody else on the team. And actually needed to go to bat a number of times to say Hey, no, this is really important that this person who is not this individual goes in and works on these things and helps kind of get us back up to a good space. Took a couple of months. That's another thing. Knowledge sharing, breaking silos. This is not a, Oh, cool we flipped a switch and it's fixed next week. It's probably a multi month at least process to really get to the point where everything is okay again. But that was a great scenario where that expert ended up going on sabbatical, there was an incident while they were gone, handled it, nothing to worry about while they were out because the team was able to do what the team needed to do, which is own and be responsible for the area of the code base. There's plenty other examples for how you do things, but it's with the team and your leadership around this is important to us and we need to prioritize improving the situation and figuring out those Whys within your group so that you can actually handle what's going on.

Morgan VanDerLeest: If this person is the silo, why? Okay, well [00:29:00] now we can figure out how to work out a new cultural foundation instead of just relying on this individual.

Eddie Flaisler: This is incredible, Morgan. I just think you touched upon two of what I think are probably the most important points around this. The first one is around starting from the end, which we discussed. The idea of, okay, we're going to do this. And I understand that this person is best suited to work on this right now.

Eddie Flaisler: And it will be the fastest and easiest. No, because then this person leaves and we're stuck. And I understand that right now we have a date coming up that date is slightly before this person leaves. But guess what? There will be additions and there will be iterations and the customer will be coming back and there will be questions. So we need to think a little bit more long term, and that involves taking a calculated risk. So I love that.

Eddie Flaisler: The second thing, I really, really enjoyed your example about everyone huddling when there's an [00:30:00] incident. You know, Originally, I was quite opposed to people who are not on call intervening in the on call. Because there was this whole issue about people having difficulty focusing on their own work, so they just jump into every fire that happens or every question on slack and we kind of get addicted to the dopamine of like seeing the new messages or answering questions or all these quick wins.

Eddie Flaisler: And I needed to be very disciplined with my team about who's on call, who's on call, who is not on call, is not on call. However, I do think that in situations like you mentioned, having this structure where temporarily or like for a few minutes or just for a kickoff, everyone is brought in together to understand what's going on.

Eddie Flaisler: And it's time box and it's clear how we delegate the roles. And who's tasked with what, by when, I actually think it's incredibly healthy. Because it keeps everyone in the [00:31:00] loop, it provides succession management in case something is needed and someone needs to be replaced, more ideas, which is great, but also then people go back to doing their own thing and it's not a huge mess.

Eddie Flaisler: So I really, really like it.

Morgan VanDerLeest: I think it is important to reiterate: this is a business issue and not an individual issue. This is not something you can say, Hey, you need to figure out how to go and share your knowledge to other people. But the business and managers and leaders and more senior folks need to figure out how do we solve this problem? So kind of relatedly, if we want to flip the scenario a bit, what do you do if the problem is keeping too many people in the loop?

Eddie Flaisler: Yeah. When you approach solving any problem, you need to start from clearing noise. And noise is situations or feedback that isn't actually related to the problem, but on the surface seems to be so, they make the problem feel bigger and worse. And it adds unnecessary pressure and stress to those dealing with it and ultimately impacts the quality of the solution.

Eddie Flaisler: [00:32:00] I think the too many nodes in the communication graph issue is one that is prone to a lot of noise. I'll give a concrete example. When I joined Box, I was assigned a program manager who was managing our projects. I've never worked with one before, and as someone who loves doing project management myself, I saw their job as redundant, and I'm embarrassed to admit that I was visibly demotivated every time I needed to interact with them or I needed to discuss schedule, and that was not fair to them at all.

Eddie Flaisler: That program manager ended up catching some huge incorrect assumptions my team and I made around certain availability of resources, which would have caused a lot of reputational damage with this strategic customer. And they ended up being a viable part of our team, right?

Eddie Flaisler: We would have been lost without them. So is keeping them as well in the loop yet another thing I need to do? Yes, but it's a price I started paying consciously. There are so many irreplaceable benefits to employing humans, but a price you pay is that [00:33:00] if you have work for 1.3 humans, you have to hire two. And it's definitely not the fault of the 0.3 person that they're yet another someone to keep in the loop. So to that extent, sometimes you will have more nodes than ideal and it's okay. What you can do is make sure that technical communication is a first class citizen in your team. So both sharing information and taking it in. There's some excellent classes online that over the years I've assigned myself and my team to complete as growth goals because we can take this conversation to places of tooling, like Monday.Com or Basecamp, which do help reduce this type of communication load. But if you're not populating your updates properly, what's the point?

Eddie Flaisler: So when you learn how to communicate and you communicate effectively, the load is less. Similarly for meetings. I hate meetings. And I must confess that over the years, my aversion to meetings [00:34:00] bit me multiple times because I needed to learn that sometimes there is no better way to keep people in the loop.

Eddie Flaisler: Now, it's true that you can get addicted to pointless meetings or meetings that are not managed effectively, but that doesn't mean the whole concept is wrong, especially when you work remotely. So face time and talking through issues, even if they don't seem completely relevant at the moment, ends up being very, very useful.

Eddie Flaisler: I've been in so many situations and so have many individuals. I know where we all complain about being pulled into this meeting that we don't actually care about because we're working on something else right now. And then that context proves to be useful. So again, not saying to abuse meetings. But it's okay to sometimes know that organizationally, we're willing to pay a price in terms of the time we spend in meetings or in terms of the headcount we hire, which may not be always perfectly aligned, such that every single person has [00:35:00] 100 percent capacity or with assigning people who are not necessarily the best and fastest in the moment to work on something because that's the right thing long term.

Eddie Flaisler: So being cognizant that you will have to pay this price as an organization and it's okay is key to a healthy culture. And it's also super important to actually be able to focus on the problem and not be overwhelmed by the noise, which makes the problem seem bigger than it actually is.

Morgan VanDerLeest: That's a great point around being overwhelmed by the noise. To call back to something you mentioned earlier around reducing cognitive load and context Not everyone needs to know everything as long as you know where to find the context. I think having that good high level view of things is helpful.

Morgan VanDerLeest: And if I can double click and get the fidelity or the higher fidelity information when I need it is important. Good example of this, most organizations, there's a run book when a certain alert is triggered. That's because in the moment, I may not the context, but somebody before me knew that they should add this important contextual thing [00:36:00] when this thing happens. That type of process and structure and organization can keep everyone in the loop without keeping everyone in the loop all the time about everything.

Eddie Flaisler: Well, you know, this reminds me of a conversation I was having with my friend about AI, AI, and self updating runbooks, which is a whole thing. And I'm not sure, what different products are currently developing that, but this is a feature that I have seen being discussed multiple times. I think LLMs are very useful in that respect of taking working knowledge, which can be extracted from channels like Slack or existing documentation or P Rs and transforming it into a live run book, right? We were talking about live documentation for product. So it's a perfectly valid and useful idea to have run books that get updated based on existing changes, something to think about for your next startup.

Morgan VanDerLeest: That seems like a really useful case for AI within your organization and helping to tie the nodes together in a great way.

Eddie Flaisler: Well, now that we said the word A. I. I think we're [00:37:00] good to finish.

Morgan VanDerLeest: I appreciate some time with you as always. Listeners, if you enjoy this, don't forget to share and subscribe on your podcast player of choice. We'd love your feedback. And if you have a particularly interesting engineering challenge or business problem, Or even if it's not interesting, if you think it's boring, but you don't know how to fix it. Happy to chat about it. You can reach us at peopledrivendevelopment@gmail.Com. Have a great weekend, y'all.

Eddie Flaisler: Bye bye.​