Tiny Things That Throw You Into Chaos: Engineering Leader’s Way Out of Daily Havoc

Hey, everyone. Thank you for having me. I'm delighted to present at TechLeadConf today and in the next 20 something minutes, I'm going to be talking about the tiny things that threw us, engineering leaders, into chaos, and we'll describe a way out of this daily halo.

A little bit about me first. I'm Anton. I work as an engineer and director at Canonical in the store team. We're the publisher of Ubuntu. You may have heard of this operating system, and my team is responsible for the Snap Store and JamHub backend if you've heard these keywords. By the way, we're hiring at Canonical, so do go ahead and check out our opportunities on canonical.com.

As an engineering leader, I mentor and coach other engineering leaders, so, yes, if you have any questions that you'd like my input on, do reach out by all means. I do that strictly pro bono right now, so let's chat if you want. I'm also a father and a fan of mountain skiing and hiking. With that, let's get cracking on the topic, and let's start with a story about a fictional engineering manager, and, as usual, all similarities with real-life characters and events are totally accidental.

Our engineering manager wakes up, not really feeling well-rested, because they've slept, but it didn't quite help, as it often happens in their life, unfortunately. They look at the time, and, oh gosh, they're late.

It's time to put together a sloppy sandwich for breakfast, throw it directly into the furnace, so to say, and set off to their workplace, where, first things first, they find the biggest available mug and fill it with coffee to get through the morning, but they just blink and the mug is empty. Oh, God, so they need to make more coffee and be more mindful about drinking it, and all of that to actually not go and check their inbox, because it's dreadful.

They dread checking their inbox. Every time they do that in the morning, there's plus 1,000 unread messages in total chaos, unreadable, but they check it this time, and there's just plus 700 since yesterday's evening, so maybe the day is going to be a little better today, and they check their calendar and realize that, no, it's not going to be better, because their calendar is painful to look at, because their entire day is booked with meetings, so no real time to do real work.

Well, it is what it is. They sigh, and the day begins. Halfway through their first meeting, they get an angry message from their CTO, who says that they missed an urgent issue from sales department. Unfortunately, our engineering manager has no idea what they're talking about, so they do some digging in their K07 inbox, and there it is. Five days ago, there apparently was an email thread with URGENT in caps in the subject, and they didn't quite react to this email thread, unfortunately, so they sigh again and go investigate what the issue might be and receive a notification from the corporate messenger saying, at channel, look at my new pull request, someone.

Well, they are the engineering manager, right? They have to look at the pull requests their team is creating, certainly, so they click on the link and see a 2,000 line monster. Well, they're terrified, of course. They think, first thing, that, like, how many times do they have to tell their team that pull request must not be that big. It should be tops 200 lines or 300 lines or something, but they're the engineering manager. They have to do it, so they go and check the pull request.

Well, halfway through the pull request, an HR person also reaches out to them by a messenger saying that our engineering manager owes them a form about a new starter starting tomorrow, and this form was due a week ago, and guess what? There was an email notification about it. Well, yeah, it's also urgent, so our engineering manager starts working on that form because a new starter starts tomorrow. It needs to be filled.

At this point, someone mentions their name in the meeting that they're in, and they have no idea what the context was and why someone mentioned their name, but luckily, it didn't sound like a question, so they may be able to just sit it out and not need to embarrass themselves saying that they weren't paying attention. So yeah, finally, the meeting is over. The HR form is done. The first achievement of the day. Yay.

Unfortunately, there's an even angrier message from the CTO because the sales issue is still there, and our engineering manager hasn't responded to any of the requests about it. So yeah, they start investigating again, and the day just goes on like that. At last, it is over, about two, two and a half hours after the official end of the working day, but in two and a half hours after that, our engineering manager can finally go home and arrive there just in time for a very quick dinner and to crawl into bed and binge some TV show before they switch off, and then the next Groundhog Day actually begins. So yeah, that's the end of the story.

Does any of it look familiar? Because a lot of it looks familiar to me, and I hope a lot of it looks familiar to you as well because you're listening to this talk.

So let's list the errors our fictional engineering manager made. First of all, their information streams are very unstructured. There's a chaos of an inbox they're dealing with. There are notifications breaking context all over the place. The tasks are recorded everywhere. Many of them are in the email. Some of them are probably in the corporate messenger. Some of them are in wherever they do code reviews. There's certainly an issue tracker involved somewhere, I hope, because without an issue tracker it would be even more chaos. So yeah, the tasks are recorded everywhere. It's hard to juggle them.

Now there's bad calendar management involved as well. The entire day booked with meetings is not healthy, right? And it's no surprise that meeting participation is therefore affected. There's lack of focus. There's also lack of task prioritization. So what we've seen was a simple stack processing algorithm, right? Last in first out, whatever comes last gets their attention. So nothing gets discarded. The stack actually doesn't quite get any overflow. So there's clearly overload. The engineer manager is trying to do everything which is too much. And it all leads to lack of work time discipline eventually, right? Working overtime regularly, burning themselves out, not taking enough time to unwind and disconnect and burning themselves out even more via that.

So what to do? My recipe to taming fragmented work agenda and getting such an engineering leader out of their daily havoc consists of four parts or four steps, if you will. Organize, prioritize, delegate and focus. Let's talk about every single one of them. Starting with organize, the main idea is reducing the noise and putting all your tasks into a single pipe. How? First, we need to acknowledge that not all messages are the same. So there can be email notifications that are automatically created, right? Some robots. There can be email notifications from some, I don't know, forms that are submitted to a distribution list. And people submitting this form, their request via this form, actually expect that someone will respond in several days.

So those can be grouped into some groups. And these groups usually are folders. So email folders help a lot. Email folders plus auto sorting rules for them so that everything that needs to be put away into its own group and not processed immediately gets an email folder. And the no folder folder, so the default inbox folder, should only remain for people who want input from you like soon. And very important things like a notification about production being done.

Now notifications in messengers also need order. So one should be notificated only when tagged and for direct messages. Plus some channels about alerts like production is down. And by the way, these channels should be separate from the channels about other stuff that you don't need to react to immediately. And also about tagging, people mustn't overuse tagging. So that thing like, add channel, look at my new pull request is completely not okay because yeah, that's clearly overusing tagging. That should have been a one person tag or no tag at all. And finally, very importantly, all tasks must be in one place. And my approach to this is choosing a to-do application and piping all to-dos there from emails you get whenever you need to follow up on something from the messenger, whenever someone wants something from you. From meetings, action points created in meetings need to also end up in the to-do application. And even from Jira. Yes, there are tickets in Jira. But if there are tickets in Jira and to-dos in your to-do application, you can't do cross prioritization really. So it very much helps if you create to-dos for Jira tickets as well.

Then you can prioritize them against other things. So once you have all to-dos in one place, go asynchronous with all you can by recording a to-do, scheduling it to a particular date that you choose and getting back to what you were doing before you needed to record a to-do. This way your context actually bends but doesn't break. Or at least doesn't break so much. The only exception to this rule is if a to-do takes no more than X minutes to do, do it right away. Where X varies depending on how fragile your personal context is. So my personal context is usually very fragile. So for me, X equals 1. Some people have less fragile contexts and their brains can sustain more context breakage so they can have X equals 3 or something.

Okay, so we've organized the incoming stream of tasks.

Now it's time to prioritize it. There are several prioritization techniques. One of the most popular is the Eisenhower matrix. I've linked down below the description of the fundamentals of the Eisenhower matrix. Coincidentally, that's also the website of my favorite to-do application which I'm endorsing completely for free. Or not really completely for free. I've taken a picture from their website. But Todoist is a really good to-do application I can recommend. This picture describes the idea of the Eisenhower matrix. The idea is one needs to distinguish between the notion of urgency and the notion of importance. So those are two parameters of a task. There can be an urgent but not important task and an important but not urgent task. Depending on the values of these two bits, so to say, a different strategy needs to be chosen. Because the notions of urgency and importance are prone to interpretation, so you need to have your own, or everyone has their own understanding of those, you will need to figure out your own way of applying the concepts of Eisenhower matrix to your work. But it's important to apply them somehow and do the prioritization steps so that you schedule your tasks with their priority in mind.

After we've prioritized our tasks, it's time to delegate. And because delegation is a thing or a step that is very often underused by engineering leaders, I want to specifically talk about why delegating. Usually engineering leaders are promoted to their roles as very efficient engineers with leadership potential. Now they become a focal point of the incoming tasks for the entire team, usually. And they're also very pragmatic, they're engineers, right? And as a focal point, they look at every task and think, okay, who would be the most optimal person to do this? Oh, I guess that's me, because they're a very efficient engineer, right? And they end up doing a lot of this, which is really not scalable. So delegation is about scaling. It enables scaling by freeing up your agenda, removing bottlenecks, creating more redundancy on tasks, and giving others more impact and motivation. Delegation allows others to have a feeling of impact and therefore more motivation. Delegation technique is probably a topic for a different talk, but it doesn't mean that you shouldn't go for freeing up your agenda eventually. This is the right way to free up your agenda and remove yourself as the bottleneck.

This is the right way to free up your agenda and actually, frankly, sometimes the only way. So it also removes bottlenecks, not only by freeing up your agenda, but also by sharing knowledge and skills required to do the tasks, creating more redundancy on tasks. And guess what, you won't need to work from your vacation anymore, because you've delegated the tasks and someone else who is not on vacation can do them.

So especially it removes you as the bottleneck, because you as the bottleneck is the scope of the current talk. On top of that, delegation gives others more impact and more motivation, more feeling of impact and therefore more motivation, because if the delegation of a task is done well, people will like doing what you've delegated to them. They will feel that they are delivering more impact, that they are taking on more responsibility and that's good for their growth.

What else is good for their growth is the new skills, knowledge and abilities that they get when you delegate tasks to them, right? So yeah, let's just, with this slide, debunk a popular myth that people have about delegation. It is not tossing work onto others, really. It is about scaling, right? It's about scaling as a leader. So, okay, what to delegate then? The answer is very simple and somewhat terrifying, everything. It is important to note that it is unlikely you'll ever get there, but to do enough delegation as an engineering leader, you must try delegating everything. You must think of delegating every single thing you can. And probably end up not delegating everything, really, but having thought about delegating everything.

What to start with? Well, in the Eisenhower matrix terms, start with urgent and not important. That's the default thing that the matrix suggests delegating, because as an engineering leader, you want to work on important issues and not to work on not important issues, especially on the urgent ones that actually break your context as well, right? So go ahead and delegate those. Now, by default, the Eisenhower matrix doesn't suggest anything else to delegate, but I suggest you go ahead and delegate the other part of the most context breaking tasks, like the ones that are urgent and important. You will have to find time to do that, right, and it's not going to be easy to find time to delegate a particular urgent task when you get it. But schedule delegating the whole class of such tasks. Think about it and delegate it as a processing.

And then you can proceed and delegate not urgent and important tasks. The good news is that there's time to delegate these. They're not urgent, so find it. And also think of delegating the whole class of such tasks over just one by one. So you've organized the incoming stream of tasks, you've prioritized it, you've delegated what you could. Now it's time to finally focus. What does focus mean in this context? Well, many of you will have heard of flow, right? What is flow? It's a state of mind when we can very efficiently work on creative tasks. There's a whole book dedicated to it written by Michal Csikszentmihalyi several decades ago I'd totally recommend it. So everyone needs flow time. You need flow time, which is focus time. To get it, tame your calendar.

Namely, join all the meetings that bear value for you and focus on them when you're there so that they bear value for you, actually. Opt for shorter slots. So instead of 30 minutes, schedule 25 minutes. Instead of 60 minutes, maybe 50 or even 45 minutes. And these tiny little remainders of these slots give you time to process the notes from the meeting, to do some small follow-up to-do's and schedule bigger ones, to go to the bathroom, which is also important sometimes. And most importantly, they reduce the fragmentation of your subsequent focus time slots on your calendar so that you don't have to fragment them a lot to do these tiny little things.

And by the way, about the focus time slots, schedule them as well in your calendar and then protect them because people will often want to schedule their meetings over those. So you need to talk to these people and suggest that they should schedule meetings when there's a free slot on your calendar. They can be themed, right? Code review time, CV screening time if you're involved in hiring, people performance review writing time if you're involved in that and it's that season again, and even time to work on a ticket because if there's a ticket assigned to you, you need to work on it and you don't have a slot in the calendar scheduled for it, guess what? Someone will put a meeting in it and when are you getting that time to work on that ticket? Well, I guess after hours or never. So yeah, you will end up like that engineering manager working over time.

And finally, when you're in your focus time, don't get distracted. Avoid procrastination at all costs. To get yourself out of procrastination, many rewards help. Things like, okay, when I'm done with this massive 2009 monster of a pull request, I'm going to go have a snack or take a walk around the block to relax. Snacks, as many rewards are, are a slippery slope. So yeah, use at your own discretion. And then also when in focus time, when you're already not procrastinating but working, it very much helps to avoid distractions when you listen to brown noise or things like that. And even if possible, if you can afford that, toggle on your Do Not Disturb mode on your computer.

So that's how you focus. Let's imagine you've organized your incoming stream of tasks, you've prioritized them, you've delegated what you could, you're focusing properly. What if it's still too much? Well, bad news. Then you're legitimately overloaded. What to do with that? First of all, know your enemy, gather information about your overload. How much time you actually spend on what? How much time would you rather spend on what in your ideal world? And what you've delegated, what you've done about this, what you've delegated and what you cannot delegate and for what reason? Then because you want to maintain a sane working schedule, describe the business impact of current situation. That's okay, you just can't do a certain slice of your incoming stream of tasks. What's the business impact of this? Describe it to yourself because then you need to go to your manager, escalate the situation and describe the business impact to them. And then ask for measures, redistributing tasks to other teams, more people in your team and so on and so forth.

And that's all I have today for you. Let's recap. First of all, four components of an engineering leader's way out of daily hayluck. Organize, inbox folders plus auto-sorting, messenger notification discipline, establishing one list of tasks in one to-do app of your choice and going in sync with everything you have unless it's a very quick to-do. And prioritizing things, Eisenhower matrix, look it up and establish your own way of applying the concepts. Delegate things, delegate everything or at least attempt to. And opt for delegating full classes of tasks over individual tasks. And finally, focus. Turn your calendar, only go to meetings with value for you and focus on them. Use shorter slots, schedule and protect focus blocks and then avoid distractions in your focus blocks using many rewards, brown noise, and don't disturb mode if you can afford it. And if you're still overloaded, track and analyze your overload, describe the impact of it and escalate it to your manager. And with that, thank you very much. I'm available for questions on Discord.