Video Summary and Transcription
The Talk discusses the challenges faced by engineering leaders in their daily work and offers strategies to manage chaos and improve productivity. It emphasizes the importance of organizing, prioritizing, and delegating tasks, as well as maintaining focus and managing overload. Delegation is presented as a way to scale as a leader and promote growth within the team. The Talk also suggests using techniques like the Eisenhower matrix and protecting focus time to enhance productivity.
1. Introduction
I'm delighted to present at TechLeague Conf today. I'm going to be talking about the tiny things that threw us engineering leaders into chaos and will describe a way out of this daily havoc. I work as an engineering director at Canonical in the store team. As an engineering leader, I mentor and coach other engineering leaders. I'm also a father and a fan of mountain skiing and hiking.
Hey, everyone. Thank you for having me. I'm delighted to present at TechLeague Conf 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 will describe a way out of this daily havoc.
A little bit about me first. I'm Anton. I work as an engineering 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 Chum Hub backend if you've heard these keywords. And 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 would 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. And with that, let's get cracking on the topic.
2. Daily Chaos
Our engineering manager wakes up late and rushes to work. They find their inbox flooded with unread messages and a calendar full of meetings. They discover an urgent issue they missed, a massive pull request, and an overdue form. They feel overwhelmed and confused.
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. So 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 and 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 thousand 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.
Then 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 the 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 chaos of an 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 engineer manager, right? They have to look at the pull request their team is creating. Certainly, so they click on the link and see a 2000 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 engineer 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 via messenger saying that our engineering manager owes them a form about a new start 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 engineer manager starts working on that form because the 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.
3. End of the Chaos
After a chaotic day filled with missed tasks and angry messages, our engineering manager finally wraps up and heads home for a quick dinner and some relaxation before the next day begins.
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 didn't, 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 engineer 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. So, but in two and a half hours after that, our engineer 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.
4. Challenges Faced by the Engineering Manager
Our fictional engineering manager is dealing with unstructured information streams, chaotic inbox, notifications breaking context, tasks recorded everywhere, bad calendar management, and lack of focus and task prioritization.
And I have a question to you all. 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. But there's bad calendar management involved as well. The entire day booped 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.
5. Taming the Daily Havoc
The engineering manager is overwhelmed with tasks and lacks work time discipline. The recipe to tame the daily havoc consists of organizing, prioritizing, delegating, and focusing. The main idea is reducing noise and putting all tasks into a single pipe. This can be achieved by using email folders, auto sorting rules, and separate channels for important notifications. Tagging should not be overused, and all tasks should be consolidated in a to-do application.
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 an engineering leader, 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.
6. Managing Tasks and Delegation
To manage tasks effectively, create to-dos for both Jira tickets and general tasks. Prioritize tasks using techniques like the Eisenhower matrix, which distinguishes urgency and importance. Apply your own understanding of urgency and importance and schedule tasks accordingly. Delegation is often underused by engineering leaders, but it is essential to distribute tasks and avoid becoming the sole focal point for the team.
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 one. Some people have less fragile contexts and their brains can sustain more context breakage so they can have X equals three or something.
OK, 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. So there can be an urgent but not important task and an important but not urgent task. And depending on the values of these two bits, so to say, a different strategy needs to be chosen. So 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.
Okay, 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. Why do we delegate? Why do we want to delegate? 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.
7. Delegating for Scaling and Growth
Delegation is about scaling and freeing up your agenda. It removes bottlenecks, shares knowledge, and creates redundancy. Delegating tasks allows others to have more impact, motivation, and growth. It is not tossing work onto others, but a way to scale as a leader.
And they are 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 are very efficient engineer, right? And they end up doing a lot of this, which is really not scalable. So, delegation is about scaling. How does it enable scaling? Well, it frees up your agenda if you delegate, even if it's only kind of a longer term thing. And at first, delegating a task takes more time than actually doing the task, because you need to explain, you need to share knowledge, you need to establish control points, you need to do the control points, and so on and so forth. Delegation technique is probably a topic for a different talk. But yeah, 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 actually, frankly, sometimes the only way. 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. 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. It's about scaling as a leader.
8. Delegating, Focusing, and Flow Time
Delegate everything, starting with urgent and not important tasks. Schedule delegating the whole class of context-breaking tasks. Delegate not urgent and important tasks. Focus on flow time by taming your calendar and protecting your focus time slots.
So, okay, what to delegate then? The answer is very simple and somewhat terrifying. Everything. It is important to know that it's 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 there's probably 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. 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.
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 Michaj Csikszentmihalyi several decades ago. I 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-dos 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.
Comments