Switching context

Episode 11: Context Switching
===

Eddie Flaisler: [00:00:00] Hey everyone, welcome back to the PDD podcast. Today we'll be dealing with another challenge that is often articulated but not always addressed in R& D organizations. But before we turn to today's question, I thought I could use this platform to share some thoughts on a topic closely related to what we do here.

Eddie Flaisler: You see, I commute regularly between Oakland and San Francisco. Interstate 80, which is where I do most of my driving, has a lot of billboards. A few months ago, a new billboard appeared by a company named Artisan AI. It says in big, bold letters, "stop hiring humans, hire Ava, the AI business development representative."

Eddie Flaisler: I'm not familiar with Artisan. I did some unsuccessful Googling to try and understand if there was some tongue in cheek or any inside humor behind this message. But having failed to find any, I am left assuming they're serious. Now, I think we've mentioned in the past how wrong the direction of replacing humans with AI is from a socioeconomic standpoint.

Eddie Flaisler: But today, I [00:01:00] want to look at it from a different angle. The rising popularity of narratives like this, especially given how new and immature AI technology still is, is a symptom of the very same issue our podcast was created to address: the loss of faith in the potential of management to be more than paper pushing and more than reactive responses to issues, and instead the acceptance of the idea that what you currently get from your human employees is probably the most you can, so might as well pay less to a piece of software.

Morgan VanDerLeest: You know that's a lot for Morgan Friday Brain to handle. Tell me more about this.

Eddie Flaisler: Okay, so let's take a step back and talk high level about AI. What we have today in the wild is models that were trained on human data. They can offer very efficient extraction capabilities of this information, as well as some reasoning capabilities that are admittedly improving quickly, but still rely on what the model learned from the data it was trained on.

Eddie Flaisler: Are we in agreement so far?

Morgan VanDerLeest: Okay, so far, so good.

Eddie Flaisler: Okay, now let's go from a [00:02:00] macro level to a micro level. At a macro level, what this tells you is that you have two options for what happens next with this technology. One which I hope no one wants is that AI begins increasingly relying on its own insights for training rather than on human inputs, and then gradually taking on greater and greater responsibilities within society. This option leaves human beings, I'm not sure what, right?

Morgan VanDerLeest: Yeah, totally. Okay. Okay.

Eddie Flaisler: Two, is that us humans continue leading the way, which I hope is what's going to happen.

Eddie Flaisler: And what this means is that AI will forever keep playing catch up, meaning it's trained on what we found so far, so it can help us find even more. So, if we start from the assumption we don't want a world of mindless humans doing what the machine tells them, like in some effed up movie.

Eddie Flaisler: We need to maintain a critical mass of people doing work that requires thinking, ideating, and producing stuff.

Eddie Flaisler: I

Morgan VanDerLeest: I think I see now where you're going with this. So if we're looking from the micro level, a company can't innovate if it's heavily reliant on a [00:03:00] workforce whose problem solving capabilities are limited to solutions that are already known.

Eddie Flaisler: That's exactly right.

Morgan VanDerLeest: Okay. That checks out for me. How does this translate into effective management?

Eddie Flaisler: Yeah, so every decision we make in business, and in life for that matter, follows one of two strategies, maximizing gains or minimizing losses, or playing to win and playing not to lose.

Eddie Flaisler: Now, if there's one thing we know from game theory, it's that minimizing losses is categorically the correct strategy in one of three cases only. One, emergency response with limited resources, so like the economic downturn we face. Two, high stakes decisions in a specific scenario where a mistake can cause irreversible damage.

Eddie Flaisler: And three is where you're an established company in a mature, not to say saturated market, and it's all about staying alive. In all other cases, if your mindset is less, less, less, there's a good chance you already lost. When you rush to replace people with AI, as opposed to, you know, [00:04:00] increasing their scope and using this new productivity booster as a way to achieve more and grow your business by orders of magnitude more with every person you hire, you are not playing to win.

Eddie Flaisler: But here's the thing, Morgan, and hopefully that will finally connect the dots. People don't just blindly go to the cutting approach. You don't become a founder or an executive just to send people home, at least I hope not.

Eddie Flaisler: You resort to cutting when you're convinced there is nothing more you can get out of the people you currently have to justify their cost. And isn't that exactly what People Driven Development is all about? Finding the areas of huge opportunity in a job that is so often deemed nothing more than a necessary evil.

Morgan VanDerLeest: Very much agree. 100%. And I think that's something that hopefully we're over time making a difference with as well. So this should be fun. I'd love a good chat about areas of opportunity. So let's get to today's question.

Morgan VanDerLeest: Dear PDD, I'm a frontline engineering manager at an established public company. I'm very [00:05:00] fortunate to have a great team. They truly are a super motivated, high energy bunch. They all want to help. They're online. Even when I asked them not to, and I also consider them very technical. The thing is everything takes a very long time to ship and no one can tell me why. I thought I had it after listening to your episode on developer productivity, but I did some homework on our pipeline and code base, and I didn't find anything egregious that can be that big of a bottleneck. I'm starting to suspect there's some time management issues here, but how could it be that everyone shares the same issue? Sure. We have meetings, but doesn't everyone?

Morgan VanDerLeest: Yours, Confused.

Morgan VanDerLeest: Wow. So many assumptions to make here. And I have a few thoughts, curious if you'd agree, let's cue the intro.

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.

Morgan VanDerLeest: I feel like it's something we've all seen at some point. You hire someone really good, it's possibly even a greenfield project, nothing holds them back, but the return on investment is so much lower than expected, you know? [00:06:00] Productivity doesn't increase over time and you just see this decline when compared to the person's first days on the job.

Eddie Flaisler: Yea it's super common, and you're right about the question not giving

Eddie Flaisler: us much context to work with. So I would probably resort to the immediate suspect. You know, Morgan, we can still respect our employees and still not respect their time, attention span and bandwidth when we design the work, when we design how we meet, how we discuss, how we contact each other, document, search for information, etc. It's very easy to forget that employee productivity is designed, not assumed. And I deliberately said employee and not developer. It's true for everyone.

Morgan VanDerLeest: Very true. But before we get into what all this means, you mentioned respect. People know when they're disrespected, don't you think someone would have said something to their manager if they felt they weren't being set up for success?

Eddie Flaisler: So, I'll answer this with a personal story. As some of our listeners already know, over the past few months I've launched my own product company, making me my own boss. So when Eddie doesn't get things [00:07:00] done, Eddie is the one who feels it the most. I have learned more in the past few months about what makes Eddie have a productive day and what doesn't, than I have in my entire lifetime.

Eddie Flaisler: Things like timing, sleep, real impact of meetings, type of work activities that wear me out faster than others, I can go on. So the question is, why only now? I've always been so proud of the owner I am at workplaces and how hardworking and driven I am. So you would expect me to have educated myself by now on what makes me tick.

Morgan VanDerLeest: I see, and yet you haven't.

Eddie Flaisler: That's right, and I think it's because

Eddie Flaisler: working at a corporate environment, pretty much universally, comes built in with meetings, instant messaging, and a lot of reactive work and interruptions inherent to having a lot of people who need something from you. So we take the constant context switching for granted and are oblivious to what it does to our brain.

Eddie Flaisler: We think it's just how we are and that things move slowly because that's just how it is when you're more than a few people in the proverbial garage.

Morgan VanDerLeest: You know, it's funny having worked at organizations that [00:08:00] are very tiny, 40, 50 people total to organizations that are 7, 000. And it's funny how the same problems seem to affect all of them. So once, once you get to a certain minimal stage, context switching is just. A drag on everyone. And if for the even bigger organizations, it's even more impactful because that's just multiplied over the number of people that you have.

Eddie Flaisler: That's exactly right. The bigger the organization is, the more you feel it.

Morgan VanDerLeest: Speaking of before we go any further: context switching, we should probably

Morgan VanDerLeest: take a moment to define that.

Eddie Flaisler: Yeah, I feel like we use that expression a lot, but it's definitely worth looking at it closely. Context switching is a term from computer operating systems. The idea is that for a single CPU to be able to multitask, you need to keep storing the state of the process or the thread handling the task it was doing before it switches to a different state.

Eddie Flaisler: And the reason is you want to be able to load that information back at a later point to resume working on that first task. Now, if you go to the Wikipedia page for context [00:09:00] switching, literally the first section after the intro is cost. That's the biggest issue with context switching. It's computationally intensive. And much of the design of operating systems is to optimize the use of context switches. We talked about AI today, which is essentially an attempt to replicate human neural networks.

Eddie Flaisler: And I think context switching is one of the most clear examples of how computer design is a mirror to the brain of the designers. Humans context switch too. But more importantly, for humans, the operation of context switching is very, very expensive. So expensive that it can take us up to an hour to recover from a context switch.

Eddie Flaisler: Not because we're stupid, not because we're lazy, it's just the way it is.

Morgan VanDerLeest: Love this, you know, that's just how the brain works, right? It's fascinating. Too often. I think we. And by we, I mean, everyone, not just managers. I think we get caught up in this idea that we can do so much and almost act superhuman, but at the end of the day, we're really just limited by the way that our [00:10:00] brain works. Our brains have not evolved as quickly as our technology has, or as quickly as our job expectations have, and we have to acknowledge the reality of our brain if we're going to truly be our best selves.

Morgan VanDerLeest: Anyway. It is probably safe to assume that this manager's team is dealing with some form or maybe even a lot of context switching. You yourself said it's inherent to a corporate environment. Where should we get started?

Eddie Flaisler: Well, I think the first thing that's important to acknowledge is that even though I completely agree with you that the larger the organization is, the more chances are you have a lot of context switching.

Eddie Flaisler: Context switching can occur in extreme form, even when you're just two, three people, because there are certain rules that need to be maintained if you want people to be able to focus and do their work. And when those are abused, when those are not maintained, you get very poor outcomes. So, to that end, let's start with incremental improvements to the big rocks of individual productivity that are not team size dependent. And the first thing that comes to mind is large blocks [00:11:00] of uninterrupted time for individual contribution.

Morgan VanDerLeest: Okay, I noticed you mentioned large there. Is that deliberate?

Eddie Flaisler: Absolutely. So there is a scientifically proven time window of 30 minutes after an interruption, as well as 30 minutes before, if the interruption is expected, you know such as a planned meeting, during which we are either not productive at all or productive but not focused enough to work on complex problems.

Eddie Flaisler: Now, we don't have a visual aid here to make it easier, but let's try to imagine a day where we work 9am to 5pm. Now, let's say that during that day we only have three meetings, 9. 30 to 10, 10. 30 to 11, and 12. 30 to 1. The rest of the day is free. Más o menos, Slack message at 1. 30, a five minutes unplanned sync at 2.

Eddie Flaisler: 30, a short but time sensitive survey at 3 p. m., and an oddly placed and timed design discussion, again on Slack, between 3. 30 and 4. 30. And that's a design discussion where [00:12:00] you don't necessarily have something to contribute, but the idea of you missing context about big changes in your code base freaks you out, so you feel compelled to follow. Factoring in the 30 minute rule, you only had one hour during that day to focus, between 9 and 5, broken into two pieces of 30 minutes each. Check my math. And even that is assuming you don't eat lunch, or you can focus while eating without choking to death, and assuming you're indeed able to recover within 30 minutes, which, at least in my experience, is the lower bound for people.

Eddie Flaisler: And that you purchased a urination bottle, which I was only half surprised to find out is available on Amazon and is quite popular. But looking at your calendar, Morgan, you only had one and a half hours of meetings. Even assuming you had a luxurious 30 minutes break, this leaves you with six full hours to focus.

Eddie Flaisler: What did you do with all that time?

Morgan VanDerLeest: I think I see your point. And if only Slack metrics were counted similarly to GitHub, I'd be considered a wizard.

Eddie Flaisler: Oh, totally. Story of my [00:13:00] life.

Morgan VanDerLeest: So much to unpack here. So first let's talk about work hours. I think some people might've lost you at the nine to five thing. Not saying I agree, but I personally know people who work 12 hour days in tech and that's just expected. They finish their meetings and they get focused on work.

Eddie Flaisler: Yeah, I hear you, but I actually don't think this is a valid technique to spend time on while discussing solutions. And I want to explain why, because I know it's very easy to dismiss this with, look at him and his theoretical bubbly organization where nothing actually gets done, right? So this is about making friends with reality.

Eddie Flaisler: And reality is that for knowledge work, it's mostly not about quantity, but about quality. You finished an 8 or 9 hour workday where your mind was juggling so much different context, and now you need to sit down and create.

Eddie Flaisler: It just doesn't happen, Morgan. Sure, I had days where I wrote code till 2am, but I knew exactly what I needed to do. The design and prototypes were already in place and I was just on autopilot. It's a very specific situation. [00:14:00] You know, work hours were defined for a reason. They were defined in the mid 19th century, not in a vacuum, but following observations on productivity, on efficiency, and on safety.

Eddie Flaisler: And the jobs in question were not even knowledge jobs. Mental fatigue happens much faster than physical fatigue.

Morgan VanDerLeest: You know, that's a fair point. And I also don't think there's anything wrong with purely looking at employee happiness, even if theoretically they could produce great quality stuff at night instead of investing in their personal lives.

Eddie Flaisler: Oh, absolutely. There's, um, there's even, um,

Morgan VanDerLeest: Y'all, are you really going to ruin this moment by quoting more research?

Eddie Flaisler: I am, and you made me. The Hawthorne studies. In the 1920s, a research was conducted at the Hawthorne plant of the Western Electric Company in Illinois. It was actually a very cynical idea disguised as we want to make your life easier by finding areas of improvement in the production line.

Eddie Flaisler: They increased the lighting in the factory because they wanted to check if employees on the production floor would work better knowing it's easier to [00:15:00] watch them from the windows on the management floor.

Eddie Flaisler: As expected, production increased. But then, they dimmed the lights again and guess what? Production didn't go back down. So after some investigation, it turned out the employees were highly responsive to the feeling that their managers actually cared about them and wanted to improve their work environment.

Eddie Flaisler: The moral of the story is you can only gain by genuine interest in your team's well being, even though this interest wasn't actually genuine.

Morgan VanDerLeest: Funny, I know that wasn't necessarily the intent of that story, but it's almost like you bubbled down like everything that we've been talking about into a single line. And since we're quoting things, there is actually a lot of really interesting literature around this as well. Um, I can call out like Cal Newport specifically has a number of books around deep work, focused time, reducing interruptions, highly recommended reading.

Morgan VanDerLeest: If you're looking to understand more for yourself or your team about deep work. So large blocks of uninterrupted time are good for work. How do we make that happen? [00:16:00] In the day you used as an example, there were so many things that were messing with that.

Eddie Flaisler: I think we can start with the biggest disruptor. Timing. Timing of meetings, timing of instant messaging. I'm not going to take credit for this because I didn't initiate it, but some of my teams have had incredible success with the concept of team hours. Have you heard of that?

Morgan VanDerLeest: That is familiar.

Eddie Flaisler: The idea is that we limit meetings and otherwise professional interactions between team members to specific time blocks. During that time, All team members are expected to be available to communicate, attend meetings, and be generally responsive.

Eddie Flaisler: Focused work is of course allowed, but deprioritized during that time window. But the rest of the workday is completely blocked for focused work.

Morgan VanDerLeest: You know, that concept sounds great, but it sounds like it would be very difficult to implement. It feels like different teams who work together would have different schedules. People might work in different time zones. Some things do require immediate attention. How do you get around that?

Eddie Flaisler: All very fair questions. And I'll start with the last point, which is the immediate attention. [00:17:00] The only things in R& D that might require immediate attention, whether an incident, an escalation, or just a technical question to unblock someone right now, can and should be handled by the on call engineer.

Eddie Flaisler: Teams who don't manage live systems or customer facing software sometimes don't have an on call rotation. I think that's a mistake because then, whether they admit it or not, the entire team is on call all the time. If someone uses your software externally or internally, you need to have a dedicated person tasked with unblocking people on a moment's notice so others can focus on their work.

Morgan VanDerLeest: This reminds me of how insistent you used to be that team members who aren't primary or secondary on call are temporarily removed from the public facing Slack channel of the team because people like dopamine. And if they're part of the channel, they're tempted to keep checking it and also jump in when they're not supposed to. That was a hard sell, but it did work wonders.

Eddie Flaisler: That's right.

Morgan VanDerLeest: So on that point, I agree with you about on call, but it's not always something that a single person can answer. [00:18:00] Sometimes everyone should put their minds together.

Eddie Flaisler: I don't disagree, but I want you to remember, Morgan, that we're talking about blocking hours here, not days. In an 8 hour workday, we used to have 4 team hours and 4 hours of focused work. The team hours were scheduled as early as possible in the day to accommodate our offshore team members. And we had a rule that if someone reached out to you during team hours and you didn't get a chance to respond, you will before you leave for the day.

Eddie Flaisler: Overall, if something came up in the second half of the day, which doesn't justify the involvement of an on call engineer. I can't think of a reason for it to not wait to the next business day.

Eddie Flaisler: If push comes to shove, you have the manager. As you know, I very much believe that managers should be doing their own form of individual contribution. But the reality is that part of our role is being communication hubs. So that requires more flexibility. And by the way, in the rare event, when there's an incident and the primary plus secondary plus manager are not enough.

Eddie Flaisler: Then sure, bring everyone in. But if that's a recurring and frequent [00:19:00] issue, we have much bigger problems than supporting creativity.

Morgan VanDerLeest: I think the timeliness of response is also a matter of culture. We sometimes talk about the pay for availability malpractice. I once heard a CEO say that he regularly calls one of his top executives after midnight. He feels comfortable doing so because this executive makes a ton of money. In reality, if there was a site issue, or a critical discussion with a customer, or a presentation to an investor happening first thing in the morning, I too would expect from my top executive some flexibility of working late to make sure that we can pull through. But these conversations don't happen every day and engaging in burnout inducing practices on a regular basis, instead of being more mindful about how we structure and prioritize our work to respect our team's personal lives. It's just sloppy. The executive is paid to have an impact that should be clearly defined through OKRs, not to be on call at all times.

Morgan VanDerLeest: And this is true for everyone else as well.

Eddie Flaisler: Snaps for that.

Morgan VanDerLeest: You did mention offshore. It does get kind of rough [00:20:00] when you need to coordinate between the waking hours of everyone though, doesn't it?

Eddie Flaisler: So it's kind of interesting, actually, When you first challenged the idea of team hours, you mentioned availability of other teams as well as availability of offshore team members as constraints. I argue that from a problem solving standpoint, it's actually the same constraint.

Eddie Flaisler: It all boils down to my favorite word.

Eddie Flaisler: Alignment. The practice of team hours is so foundational that you can't do it in a vacuum.

Eddie Flaisler: The entire function needs to be aligned on it. Not only so that the co located teams can coordinate their team hours, but also so you can do org design and hiring accordingly.

Morgan VanDerLeest: I do love me some org design. Talk more about that.

Eddie Flaisler: Well, for Americans, it's very convenient and cheap to hire in Asia and Eastern Europe. But that also means a time difference of anywhere between 7 and 16 hours. Even if your offshore engineers accept having to work late, they still need to sleep to do a good job. And that limits the time they can overlap with the US headquarters.

Eddie Flaisler: That is why I always prefer to put people together in a team or a [00:21:00] joint initiative only if I know that the time difference is sustainable. So, for example, I would be fine with New York working with Kyiv because 9 a. m. EST is 4 p. m. EET, but San Francisco and India are 13 and a half hours apart, and if you really need to work very closely, that's super difficult long term.

Morgan VanDerLeest: You know, it's interesting because I feel like there's also a benefit to not having overlapping time. I mean, what better way to have focus time than if you're one of the few people who actually is going to be working, but that still shouldn't take away from the opportunity to have dedicated time together.

Morgan VanDerLeest: So I guess TLDR, I think this is dependent by team and or company, and you can make either work with good team norms.

Eddie Flaisler: Absolutely. And I think what you said is exactly right. It's about the project or initiative or the team. We want people to have team hours together. When we did the episode on silos, we talked about cases where it's actually the right thing to do for people to work alone. So, if that's the case, sure. If you need to [00:22:00] coordinate, it becomes difficult.

Morgan VanDerLeest: Makes sense. Okay, I think we spent a good chunk of time here talking about blocks of focus work, so let's keep going. Before we do, would love to get your thoughts on No Meetings Day.

Eddie Flaisler: Useless practice.

Morgan VanDerLeest: Okay, that was a bit harsh. Tell me more.

Eddie Flaisler: I mean, look. Obviously, the motivation behind it is exactly what we just discussed, providing people with blocks of uninterrupted focus time. The issue is, I yet to have seen a no meeting day enforced consistently in an organization. It's almost by definition optional. Why is that a problem? Because if the entire organization isn't disciplined about it, then two bad things happen.

Eddie Flaisler: One, some people, including individual contributors, Still schedule and accept meetings. But then, those who insist on protecting their focus time suddenly come across as uncooperative, blocking progress, or even antisocial. I've heard that being said.

Eddie Flaisler: Two is that managers are often excluded from the practice of no meeting day because the nature of their [00:23:00] job, right? But the nature of their job is also talking to people, so they find themselves pestering people who are supposed to be focusing. And now, everyone's frustrated. The person who's being bothered is frustrated because that's still context switching, and the manager who forgot it's no meeting day is frustrated because They don't get why it's so difficult to get hold of the person. By the way, discipline is always key when implementing things related to time management.

Eddie Flaisler: If the team and their leadership aren't consistent about it, even the team hours concept will fail.

Morgan VanDerLeest: That checks out. I think most of the last couple of companies that I've worked with, have all had some notion of no meeting days and I can definitely understand why you would consider it useless practice. Okay. What else would you consider to reduce context switching?

Eddie Flaisler: This one is challenging because it will sound like I'm attacking specific products, but some things need to be acknowledged. Instant messaging is the devil.

Morgan VanDerLeest: You know, that's spicy and I'm here for it. And I a hundred percent agree. Keep going.

Eddie Flaisler: [00:24:00] Oh, I would say don't get me started, but you just did. So, if you remember, it was just the last episode where I told you the story about the engineer who cried and resigned during our first one on one because of work stress. The only signal I could find for them overworking wasn't code or design volume, but slack activity.

Eddie Flaisler: This is a textbook example of how context switching and information overload not only has costs in lost productivity that are disproportionate to the interruption, but also in mental health. The context switching inherent to bad instant messaging practices has been shown to increase stress, increase fatigue, reduce analytical ability, and cause memory loss, which I've personally experienced.

Morgan VanDerLeest: This is something too that I think we've all felt in our personal lives. You get the phantom buzz in your pocket when your phone goes off. You hear it on the desk. And you're like, Ooh, what is that? What's going on there? I have to know. Instant messaging is basically just like legal social media for work. We can do better than that. Come on.[00:25:00]

Eddie Flaisler: I absolutely agree.

Morgan VanDerLeest: So, all right. At least we're on the same page, surprise. But again, if we come to the question of practicality, nobody's going to stop using Slack or discord, Eddie. I mean, they're powerful tools and they technically do get work done, quote unquote. What do we do?



Eddie Flaisler: They get a lot done, a lot. And they really are very powerful tools which have a ton of benefits. But that doesn't mean we cannot have very extensive etiquette in the organization regarding how we deliver and how we consume important messages and ideas.

Morgan VanDerLeest: Yes, I can see that. We often talk about Unnecessary urgency in organizations. It's one of those things that kills me. And I think it's pretty obvious that the careless use of these platforms is absolutely one of the contributions to that sense of that feeling. It also encourages this stream of consciousness communication, right? You blurt something out because it just came to mind. And suddenly it's the whole thing with the other person while you're still trying to figure out what it was you were actually [00:26:00] trying to say.

Eddie Flaisler: Absolutely. And I think that what you're touching on here is even more foundational than the use of the tool itself.

Eddie Flaisler: It's about what we choose to communicate, when and how. When we think of context switching, we often limit the causes in our head to juggling multiple projects or constantly firefighting. But I think people might be surprised by the extent to which most mundane interactions at work can induce excessive context switching.

Eddie Flaisler: These disturbances add up. And assuming they typically occur because someone needs to know or report something, that's a key reason why easily searchable, up to date sources of truth for stuff are so important in an organization, no matter how young it is. You know, if person A relies on person B to get information they need right now, both their productivity suffers.

Eddie Flaisler: If your team isn't disciplined about tools like JIRA or Monday, then you spend your days chasing statuses, and they have to interrupt their focused work to give it to you. If your team doesn't use organizational search tools, like Glean or Stack Overflow for Teams, [00:27:00] then every custom command you guys use is this whole thing to find, and again, they have to interrupt their focused work to give it to each other.

Eddie Flaisler: If requests are improperly documented and queued in this dedicated portal, it's not just making it needlessly difficult to keep track of them, but it also kind of guarantees some will be ignored.

Morgan VanDerLeest: And on the matter of unnecessary urgency, it's also important to remember that God and Ray Tomlinson gave us email. If the message isn't urgent for right now, and especially if it's about something we would like to have people retain and easily refer back to, Then sending it on an instant messaging platform is probably not the right thing to do. We have email for that. I do think that a lot of damage done in terms of context switching doesn't come from one on one chats, actually more from channels where people are constantly active. Would you agree?

Eddie Flaisler: I would definitely agree, and we'll jump into that in a minute, but to kind of close the topic of one on one conversations, I do want to share two final observations.

Morgan VanDerLeest: Awesome. Go for it.

Eddie Flaisler: Okay, so the first one is about [00:28:00] urgency. One thing we tend to do is use urgency inducing expressions. Things like, as soon as possible, ASAP,

Eddie Flaisler: or time is running out.

Eddie Flaisler: We really shouldn't. If you think about it, it's always just one of two options. One is, we have a timeline in mind for what we need, and then we should just state it and briefly justify it. In a trusting relationship, our peers know to respect the specified time.

Eddie Flaisler: Two is we don't have a timeline in mind and then they'll get to it when they get to it. Panic worsens the effect of context switching. Tell me you didn't experience the frustration of someone showing up in your chat with a super urgent request, you drop everything to do it, and then they don't follow up with you for two weeks.

Eddie Flaisler: Terrible.

Morgan VanDerLeest: it is funny that you mentioned that because I just recently had a request in our channel that I thought was going to be quite urgent. And then I was like, Hey, cool. I need a little bit of time to look into this. When do you need an answer by? And they said, Oh, sometime within the next two weeks, which all of a sudden changes when I need to get them this answer and became much less urgent for me. [00:29:00] So excellent call clarify timing, both when you're asking or if you're asked and don't have one, you can always ask and see what that timeline looks like and it will help with the panic a lot.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: What's the other thing?

Eddie Flaisler: Minimize emojis. I see your face. Seriously. The idea is this. I think most of us learned the hard way that intention and tone don't travel well in writing. The lack of clarity on intent is particularly true when using emojis, and it means that the interpretive effort in deciphering the nuances and the emotional cues of what the person was trying to say increases substantially.

Eddie Flaisler: Not to mention, it can leave the person thinking about the conversation longer than they should. For example, when we suffix a critical statement with a smiling emoji, we try to be nice, but the person on the other side can read fakeness and get preoccupied with that. This is definitely a micro improvement compared to what we'll talk about next, but I'm still bringing it up to reemphasize the impact that our communication style at work [00:30:00] has on others.

Morgan VanDerLeest: I hate to admit that you are probably right. And yet I still want to say the problem is that you don't have enough emojis to cover the tone that you're trying to display with your message. absolutely the problem. And slack emojis. com is not my most visited site.

Eddie Flaisler: Yeah well, I agree with you. But here's the thing. All of our modern day human spoken languages have glottographic writing systems so it is essentially a set of visible marks that represent spoken language. This is relevant because it means that if two people write to each other in the same language, there is a good chance they agree on the meaning of a given word.

Eddie Flaisler: Emojis are semasiographic, so they're an independent graphic language that is not tied to anyone's spoken language, and this means there is much less of a guarantee that your emoji would be interpreted as intended.

Eddie Flaisler: No question that what you said is correct. If we had this infinitely large set of emojis to [00:31:00] represent just everything, I'm sure it would have been much, much clearer, given the correct mapping.

Morgan VanDerLeest: Hate that you are right, and I'm going to have to agree to disagree, and I'm not stopping my use of emojis. It one of the things that brings me great joy. Okay. But I'll think about using them less unless it's abundantly clear what that emoji means.

Eddie Flaisler: Thank you for not saying OK, Boomer.

Morgan VanDerLeest: Missed opportunity. Shall we talk about channels?

Eddie Flaisler: Let's. Are you familiar with Basecamp?

Morgan VanDerLeest: I do feel like that is a slightly loaded question. I think, There are a lot of good things about Basecamp. There are a lot of good things about the way that Basecamp works, that if you can adopt them well are very unique things. They've also done some things that are slightly less than kosher, so to speak. But I'm curious what your thoughts on Basecamp are now that you mention them.

Eddie Flaisler: That's absolutely right. Pros and cons. We're definitely not gonna condone or [00:32:00] condemn here the full culture of any company. What I want to talk about is something very specific that Basecamp published several years ago.

Eddie Flaisler: So for those unfamiliar, Basecamp is a project management tool whose very outspoken founders used to be very passionate about engineering culture. Several years ago, they wrote a blog post titled "Group Chat, the best way to totally stress out your team." It's a 17 page document And admittedly, one of my favorite write ups of all times.

Eddie Flaisler: In that blog post, they refer to the group chat as an all day meeting. They bring up a bunch of points I find very true, but the biggest one in my mind is that it induces FOMO. You see, the fear of missing out or not having a say makes you constantly follow the conversation. And the thing is, you can't tell people to stop feeling FOMO because their FOMO is justified. One of the biggest issues with these discussion channels is the implied consensus.

Eddie Flaisler: Because we talked about it in the chat room, everyone who needs to know now [00:33:00] knows. If people are allowed to make that assumption, wouldn't you feel FOMO? This is exactly the type of culture that a manager has to be super strict about preventing. Decision making cannot happen in an instant messaging channel.

Eddie Flaisler: Not only will it be super difficult to find and refer back to how the decision was made, but the larger the group is, the higher the chance is that many people are going to miss this unless they're all glued to the channel instead of working as they follow the conversation of others.

Morgan VanDerLeest: So this is something that I would like to add a little nuance to, and I would actually argue your last point. I think decision making for certain things can happen in instant messaging, but you need good norms around it and you need to document decisions somewhere also. I feel it's almost like saying you can't have decisions in a meeting because there's no record. You still need to notate somewhere what the decision was and why so that others can know about it. And again, I think it's more the context of how this happens, how the teams work together And how teams can continue working together better.

Eddie Flaisler: I am not arguing with that. [00:34:00] The only thing I care about is the existing available source of truth, right?

Eddie Flaisler: As far as I'm concerned, now we have LLMs, talk on Slack, have something translate the conversation, make a document, upload it somewhere. I don't care.

Eddie Flaisler: But if it ends on Slack, if it ends on Matamos, if it ends on Discord, that's a big problem.

Morgan VanDerLeest: Fair point in either case, I think this is a good example of the role of a manager when they're designing team culture. What other helpful advice can we give on the topic of channels?

Eddie Flaisler: I can think of a few. I will just say that for maximum effectiveness, I again have to emphasize the importance of alignment. The more teams in the organization are doing it, the better the outcome.

Eddie Flaisler: So, the rules of thumb are, one, not everyone can create channels. There's a policy for what justifies a channel that includes things like production incidents. Two, if people aren't willing to give a public team channels in favor of something like a service portal or pinging the on call directly please follow the [00:35:00] pattern of keeping only the primary on call, secondary on call, and manager in the channel and remove the rest of the team. Three, you discourage using, or better yet disable, at channel, at here, and at everyone. God, I hate that. People will see your message sooner or later. If the building is on fire, you can send people a group text to their phone. Four, choose carefully who can post on the general channel, Or it becomes a dumpster and a time sink for people.

Morgan VanDerLeest: You know, I do love these, but These seem relatively simple and straightforward, right? But I think these are probably some of the biggest behavior shifts that we can request of folks. It's funny. So I was trying to help show my team that like, you can always communicate in our team channel. It's fine. It doesn't matter who's there. I know there's a hundred people that it shows in the channel. It's not going to make a difference. So I used at here and told people, Hey, by the way, this is how we're going to be using our team channel. So if you don't like that, you can get out and You're not going to get notified about that. I [00:36:00] think I got like 10 different people who emojied and nobody responded. like, team, it's okay. Nobody cares. Nobody's looking. It doesn't matter. Use this as a place to chat and figure out what you need from each other. Still use your focus time, but it's okay to post a question here that you think feels silly. Don't worry about it.

Eddie Flaisler: As always, it's the process that serves the people, not the people who serve the process. So, we're talking here about a list of good practices that I found over the years to be very helpful. Doesn't mean we need to put all of them into work. Staying mindful of what the situation is and adapting is probably the most important thing.

Morgan VanDerLeest: Love that. So Eddie, a lot of our time today, we spent on improving time management communication, all with the goal of reducing context switching before we finish. I wonder if there's anything else. I feel like even the purely technical aspects of our work are very prone to increased context switching.

Eddie Flaisler: Yeah, so, my answer is yes [00:37:00] and. When we first introduced context switching in this episode, we talked about the cost to the human brain every time we context switch. That cost is referred to as cognitive load. And that's essentially the thing we always aspire to minimize so people have more bandwidth to innovate and solve complex problems.

Eddie Flaisler: Choice of tooling or technology or patterns doesn't increase context switching per se in the sense that you experience more interruptions. But there are still two opportunities for improvement that I can think about. One, is quality and automation. It goes without saying that the more an engineer needs to jump in to fix a preventable issue, or perform some manual maintenance operation that could have been automated, that's context switching right there that could have been saved.

Eddie Flaisler: And two, you know I'm definitely not a neuroscientist, but I can only assume from my personal experience that context switching is more taxing The more context there is to switch. So to that end, it's always good to minimize the amount of [00:38:00] tooling, frameworks, patterns being used. So different aspects of the work you juggle are not that different.

Eddie Flaisler: You see what I mean? In one of the migrations to microservices I oversaw, I had to block the design because for each microservice, the data access and network layers were to the discretion of the team implementing it. These layers are usually boilerplate code and I knew for a fact, ownership of services would change.

Eddie Flaisler: So. At some point, people will end up owning different microservices. So I insisted everyone inherits from a common set of components, not just because it's easier to deploy changes and fixes, but also because there is less different code to remember. Hashtag, own less code.

Morgan VanDerLeest: As per usual, could not agree more. That's another reason why I like to recommend consolidating tooling across people and teams, even if people like using different ones. An example, like Notion versus docs versus Basecamp versus Confluence, pick one, even if each does something better than some of the others, pick one and you see gains from the [00:39:00] consistency of tooling. It's just all about having things in the same place that we can all have a relatively shared understanding and knowledge of that works wonders.

Eddie Flaisler: Thank you for your time, Morgan.

Morgan VanDerLeest: Thank you too, Eddie. It's been fun.

Eddie Flaisler: And to the listeners, if you enjoyed this, don't forget to share and subscribe on your podcast player of choice. We'd love to hear your feedback. Did anything resonate with you? More importantly, did we get anything completely wrong?

Eddie Flaisler: Let us know. Share your thoughts on today's conversation to peopledrivendevelopment@gmail.com, that's one word, or you can find us on X or Twitter at PDDpod. Bye everyone.

Morgan VanDerLeest: See y'all.

Morgan VanDerLeest: Well, I started recording,

Eddie Flaisler: you started already? Okay, I'm just trying

Morgan VanDerLeest: Don't worry, I'll keep this part in.

Eddie Flaisler: It's going to be the blooper section.