Feature requests, bug reports, support calls, and an onslaught of customer requests. Is this what your typical day looks like? You are reacting to other people’s demands and needs, fighting battle after battle after battle. You spend the whole day on shallow, urgent tasks while losing track of important ones. Could there be a better way?
This post is for developers who are struggling to keep their work under control, unorganized at best and disorganized at worst in managing the requests from their managers, clients, or customers. Some have been in this overloaded state for so long they don’t know there is any other way.
In this post, I want to describe a simple task management system I have started using that has been a game-changer; in terms of effectively managing my workload.
Work In Progress
The term work in progress comes from operations science. It describes customer requests plus all the other tasks you need, want, or have to do, whether planned or unplanned. The term customer request is loosely defined, including anything and everything you have to think about and act to solve a problem.
In the world of software development, customer requests can come in the form of feature requests, questions from team members, new initiatives, product crashes or bug reports. They also include questions you get asked from your colleagues or customers about the products or the features you built.
Without a system to manage them, the requests are lost, forgotten, or confused. A customer is left wondering what the status is, and the only way to find out is to bug the developer, which distracts them from trying to get the actual work done.
When you are overloaded with too much work, you panic and deal with the requests from the top, or whoever complains the loudest, neglecting the critical tasks. Your customers or clients (including managers) have no way of knowing the status of their requests, so they spend much time asking, “Is it done yet?” on a repeat - or, even worse, they think that you are incompetent.
Have a system for collecting requests, organizing them, tracking them, and seeing them through completion.
Here is how the system works. You start with making a list of all the pending work and store it in a repository where it can be prioritized and tracked. This repository can be on the computer or on your notepad. I use Basecamp. Use any software that fits you.
As you work on the request, update the task with notes and information. This task also records communication between the customer and the developer as the request is discussed or clarified.
Here is a screenshot of my Basecamp, where I track all the ongoing tasks that I am working on. These are simple to-do lists. I have one list for each project that I am involved in right now. Tasks that don’t belong to any project go in the ‘Other’ list. In addition, I have a ‘Plan for the Day’ list.
I start my workday by reviewing the other lists and deciding which tasks I will work on that day. Then I add those tasks to my daily plan list. As each task is resolved, I check-off the item. At the end of the workday, I have a clear idea of what progress I made that day.
If I click one of the projects, Basecamp opens that list and shows all its tasks. Here’s what that looks like.
You may have noticed a tiny note icon next to the task. This icon indicates that there are some notes attached to this to-do item. To view these notes, click the task, which brings the following view.
You can see that this task is due on March 26. It’s assigned to me. There are also a few notes attached to it. There is also a way to have more discussion, right below the task. As I work on it and get more information, I can add it in the notes or discuss the task under the Discussion section instead of over email or chat. This keeps all the context related to this particular task in itself, and I don’t have to search it in emails or scroll endlessly to find it in the chat.
If you implement this system in a team, it allows you to share the work better. Team members can see the history, making it easier to hand-off the task from one developer to another. When a new developer joins and is assigned an ongoing issue, they don’t have to start from scratch. They have all the context they will need.
A solo developer benefits from a task system because it reduces the cognitive load involved. Since the task system keeps each task’s history, you can return to a request and quickly pick up where you left off. You can examine the queue and re-organize it to get the critical tasks done when you are most productive and have fewer interruptions. You can reject requests that are out of scope or not needed anymore and prioritize the ones that need attention.
This allows you to solve problems proactively than waiting for them to blow up. Instead of being in the daily onslaught of requests, this system enables you to see things from a distance—with objectivity and detachment.
Credits: Tom Limoncelli’s book for sysadmins, The Practice of System and Network Administration. I took his ideas from the world of system administration and applied them to software development.