Ever since I’ve taken on the role as a full-time devops in my new team, the amount of tasks that I have to juggle in a workday has exploded exponentially. I’ve written/complained about it nearly 2 months ago on organizing chaotic information.
It is now time to share what I’ve tried, what worked and what didn’t.
Every morning, I open up my Microsoft Todo app to create/add items into my “Today” list. These are the tasks that I am focusing on today, ranked by the order of execution. The task should be small as possible and doable within a day. An example of what it might look like could be something like this.
- Reply emails
- Reply to Matthew about that bug in UAT
- Whitelist IP for Magic Agency
- Explore a NAME tool that will help us in config maintenance
- and more…
The list could be really long, or it could be really short depending on what I have left over from the previous day. The goal isn’t to complete every thing on the list (that’s a bonus), the goal is that I am working on whatever is the highest priority to me/team right now.
Something that I’ve made an effort in my planning is to prioritize responding/helping people as fast as my priority lets me. Reason being that for my role, it is rather common that I am one of the few people with context/access to an ops-related problem that the developers are facing. When my response is delayed, I am effectively blocking another person from being able progress in their work.
Life doesn’t always work out in the way that you plan, ad hoc requests/queries always come in throughout the day. However, my list of tasks is already full, should I reject the request?
Nope, I add it to my task list, and prioritize it right there and there. Which brings me to my next point, “How do I prioritize the tasks?”. For the most part, I rely on the Eisenhower Decision Matrix.
It makes it really easy for me to prioritize on the list. If it’s putting out fires in production, it’s definitely a do now, and everything else doesn’t really matter. Most other requests are important but not urgent. For example, how urgent can whitelisting someone’s IP address be? How urgent is it to grant someone access to a certain resource? More often than not, I schedule these tasks based on how much damage it’ll cause if it’s delayed. (i.e. if Dev A don’t get access right now, does it stop him from doing something else?)
However, and this is the most important point, if you are going to delay/schedule your task, and someone is waiting, reply, set expectations.
- “Let me get back to you on this in N mins”
- “Hmm I need N mins/hours, is this blocking you right now?”
- “Sorry, can’t get to it now, let you know when I’m working on it”
- “Ping me if I haven’t get back in N mins”
This is something that I’ve learnt from my previous boss about customer service and I still find it extremely relevant and useful today; because a simple gesture like this greatly improves the working experience for everyone around you.
Long running tasks
As much as I try, not all tasks can be completed within a day. An example could be migrating a specific service. Yes, I could split them into subtasks but there is usually contextual information, code snippets that I need to keep around which can’t fit reasonably into my todo list. This is when I rely on a notes app that acts as my temporary storage for the task I am working on; the app I’m using is
Drafts as the whole concept behind the app is about temporary notes.
Note that Temporary is a keyword here, when I am done with this task, I will remove this note, this makes it extremely clear what long running tasks is ongoing.
What happens to those useful code snippets or information that I’ve uncovered during the long running task? This gets filed into my Second Brain, helping me to grow my knowledge base overtime. Speaking of which, I’ll probably be writing an update on the second brain at the end of the year to show how it has grown over 4 months.
The keen eye amongst you might’ve noticed that if I were to do all these things about responding to adhoc tasks, a good portion of my time would’ve been taken up in the day. And you’re right. This is a classic example of maker’s vs manager’s time. There have been many days where the entire day is taken up by putting out fires and helping people.
I believe this is why most of the DevOps people I know in my department have experienced this sentiment very often, “I want to do this thing to improve the system, but I just can’t find the time to do it”.
This is what I’m trying to challenge head-on with the long running tasks. Has it worked yet? Not yet at least, becuse I cannot really think of a specific tool/process that I have introduced to the team in the past 2 months. All I can say is that, they are all work-in-progress. I am hopeful that this workflow will pay off in the long run and I am constantly refining it as I go along.
- Prioritise the tasks you have to do every single day
- use the eisenhower decision matrix
- Prioritise any new task in existing list
- set expectations about scheduled tasks
- Long running tasks goes to a temporary note app
- remove note once task is over
- store important bits into second brain
This workflow is heavily inspired by the scrum/agile framework; because it leans heavily on prioritization and transparency about the work done/left.