During the last months, I have been working in a couple of different teams in parallel. Getting things done in such a setup needs another kind of organization than working in one team only. One of the most important changes I implemented could be named “The three-project-rule”.
In my experience, there are some unique challenges for the role of a senior software developer / architect / technical team lead like me. I’ll lump together all of these roles in this article because they face similar challenges. That is, experienced developers often work in multiple teams to solve advanced tasks that need a certain level of expertise. On the one hand, they need to switch between different contexts while also maintaining a good level of assistance for each of these teams. This means completing a sufficient number of tasks and meeting the expectations of all the teams. To accomplish this, good communication is important. I have to communicate when I will be able to begin a task as well as when I have other obligations that keep me away from a team. For each of the teams involved, I have to provide reliability in my commitments so they can plan their sprints accordingly.
I noticed that context switches are what drain my energy the most. Well, that has been discovered by countless self management gurus before me, but it really holds true for my current job. The goal should be to reduce context switches and implement deep work as much as possible (see Cal Newports book “Deep Work”. This can only be achieved by working on a small number of projects at once. By projects, I mean a limited number of defined tasks that can be completed within a couple of hours, days or weeks at most. Sometimes, the word “project” references the development of a whole application over the course of many years, including numerous big changes. That is not what I mean here. Examples for projects that can be used with the Three-Project-Rule are performing architectural analysis, implementing a user story, coaching a team about a specific tool, or writing some architectural document.
So, let’s see what the Three-Project-Rule is all about.
For me, a normal working day starts the evening before with setting up my daily task list. That list contains all of the tasks I will be working on during the day as well as references to what I need to know. I will publish an article about this list in the future. For now, it is sufficient to know that the list consists of multiple parts and is reviewed many times over the course of the day. It is my guideline for every action.
The Three-Project-Rule adds the following section to this daily list:
FIX PROJECT SLOT 1/3: ABC
FIX PROJECT SLOT 2/3: article unit vs integration tests
FIX PROJECT SLOT 3/3: project AWSAs you can see, there are three slots for projects I work on in parallel. “In parallel” means that I try to work as long as possible on each of the tasks without interruption. If necessary, for example when slot 2 is getting close to its deadline, I switch to working on this project and try to remain there as long as possible.
It’s important to note that the three slots don’t represent a priority between the three projects. You could start working on project three, switch to project two after a day and then go back to project three without making progress on project one. The main goal is to limit yourself to working on three projects only. Similar advice can be found in Leo Babautas Books Focus and The Power of Less.
I recommend using three slots because the mental load needed to switch between three different problems is manageable. Also, having three problems to work on provides a high chance of having something to do even when one or two projects are blocked, for example by work to be done by others. However, this limitation of projects has to be defended by saying “no” to the fourth project. If you adopt the Three-Project-Rule, prepare for some resistance because you refuse to work on four or even more projects in parallel. Easing that situation is a matter of good communication. You can use a priority list, put the fourth project on place four and communicate to the team that this is the very next project you will be working on after finishing one of the current three. Transparency is key here. Furthermore, it could be of help to argue that concentrating on a small number of projects will accelerate progress because there is less context switching. In a sense, every team benefits from the Three-Project-Rule. Have courage to defend that system.
Reducing cognitive stress is one of the major goals of the Three-Project-Rule. That also includes finishing a project the right way. Because of the Zeigarnik effect, it’s important to really finish a task to get rid of it mentally so it does not cause any stress further on. I achieve this by defining the end conditions of each project as well as celebrating the completion of a task. Defining the end condition is part of the common definition of a project. As I wrote earlier, some “projects” tend to become “enterprises” which means they go on indefinitely. That would clog the Three-Project-Rule because the slots would be blocked by pseudo-projects that are enterprises in reality. Hence it is important to define the end conditions beforehand together with the team involved. Another tool for finishing a task is to celebrate its completion. There does not need to be a huge party for this. Just acknowledging being done with it, checking the box in the list, sending the final mail or presenting the results before the team should do. The important thing is to be aware of having accomplished something.
After happily having completed a project from the list and being fully aware of that accomplishment, it’s time to choose the next project to work on. If you have implemented a priority list for waiting projects, you can choose the next one from that list. In that case, I recommend using the Eisenhower method. It uses the concepts of urgent and important to cluster problems in four categories. Think about each project on your list and put it in the four categories. If there is a project in quadrant 1, which means it is both urgent and important, it’s a great candidate to begin work on immediately. If you do not have a priority list or it is empty, I recommend to not fill it right away. Continue working on project one and two and don’t select a third one. Chances are that this slot will be occupied pretty soon. You don’t have to go run find the work. It will find you. When that happens and a team requests your assistance, you will be able to commit to the new project immediately, which will make you appear responsive and decisive.
I hope the Three-Project-Rule gives you more focus and longer deep work sessions.
Image under public domain, source here.
