Joe Buhlig’s Task Management Workflow Diagram

Building systems is a borderline addiction of mine. There is something fascinating about building a process for inputs to travel through and the problem solving required to make it happen cleanly and efficiently.

My personal struggle is that I’m not always great at using the systems I’ve built. I love the process of building, but putting it into action is forever a challenge. As I’ve watched my graveyard of systems grow, I’ve learned that if I do the hard work of mapping out the process flow of the system, I’m better at building them in a way that is simple and almost hard to ignore. It also helps me find the areas where I struggle to use it.

As an example, let’s look at task management. I have a love-hate relationship with it. I forget to do things all the time. So I need some kind of system to help me keep track of my commitments. And yet, I often don’t want to do the things on the list — or worse, once I have written it down, it feels like it’s done and I don’t even reference the list at all. (If you’ve been on the receiving end of this, I’m sorry.)

So I need to write things down somewhere, but struggle to know when to work on the items on the list and which ones to work on first. This is where a diagram comes in to help. If I can lay out the process by which tasks come in and out of my system, then I can physically see the flow of my obligations. That, in turn, can help me identify my pain points and lead to the development of further solutions.

Here’s a look at what this particular diagram looks like:

There’s a lot happening here, yet it’s quite simple. Let’s walk through it by starting in the middle at the Task List. This is the central hub to the whole thing and the part that we typically spend the most time on. A quick search for Task Management Software will give you a plethora of options for this one component in this system. And if you’re like me, you’ve spent a lot of time figuring out how to set up this one box and making sure it has all the bells and whistles. But if we look at how much is actually going on here, it’s easy to see that this is a small puzzle piece. It’s an important piece, but only one.

At the left of this diagram we see five different mechanisms for gaining tasks. Again, this is my world, so this is purely my environment.

Meetings, phone calls, and text messages or some other digital communication will often lead to the assignment of a task. Sometimes that’s a clear assignment (“Joe, can you do this?”), but other times it can be implicit (“There should be a way to automate this.”). In both cases, I try my best to capture those as a task that hits the list.

But other times, my race car brain dreams things up. I come up with a cool idea or think of a potential solution to a problem at work. Or I realize that taking on a new project would solve a systemic issue I’ve been dealing with for a while. Or, more often, I develop a fascination with something (lately it’s been the IndieWeb) and come up with a list of tasks I want to do. All these come from my HyperBrain, so it’s important that this is in the diagram.

System Review is just that. It’s not a formal checklist that I follow, but a process that happens organically as I put together daily task lists or when entering data into my PKM. It’s common that doing each of these will trigger a memory of something I need to do.

Finally, we can’t forget email. This is obvious, but I often have tasks assigned to me in email. I’m bad at email, but the process still exists.

Again, let’s ignore the mechanisms for storing these tasks. Instead, let’s look at the states a task can take after it’s on the list. Basically, there are three different actions performed on a task. You can complete the task. You can drop the task due to a change in commitments or mission. Or, you can drop the task due to waiting too long. And those three cases lead to two technical actions: deleting it or completing it.

Sidenote: you can also postpone a task. But as far as moving the data around, nothing happens. It just sits on the task list with risk of being dropped due to waiting too long.

My main “Eureka!” moment here was understanding that in most cases, not all, the process was not finished after a task is deleted or completed. They often need to be communicated. That may mean a communication directly to the person in email or in-person. It may mean sending a tweet. It might lead to a text conversation. Regardless, it leads to some form of communication. In the case of my diagram, I simply point those to the email bucket because that’s my most common method.

Here’s what surprised me in drawing this up, I was rarely following through on the entire process. That’s because I wasn’t communicating at the completion of a task. That was my main revelation.

But I also realized that some of my inputs (Meetings, HyperBrain, etc…) were weighted more than others. Namely, I would capture more tasks from my HyperBrain than I would from meetings. That’s because those are more fun to me. That doesn’t mean I should do those first, but I capture more of them because I like them. This means I have an imbalance I need to correct.

I found this exercise well worth it. If you’d like to give it a try, you can start with mine and build from there. Mine is built using Mermaid inside of Obsidian. Here’s the code behind it:

flowchart LR
email[(Email)]-- Assigned a task -->tasks[(Task List)]
tasks -- Reply to email ---> email
tasks -- Dropped ---> deleted{Deleted}
tasks -- Completed --->done{Success!}
meet[(Meeting)] -- Assigned a task --> tasks
phone[(Phone/Text)] -- Assigned a task --> tasks
random[(HyperBrain)] -- Dreamed up a task --> tasks
review[(System Review)] -- Decided on a task --> tasks
tasks -- Waiting too long ---> deleted
done -- Communicate status? --> email
deleted -- Communicate status? --> email