In the same way, season changes are inevitable so are major re-architecture in my productivity system. Significant changes in a system can be a good thing when done for the right reasons and not too often. That’s what happened to me very recently with my system. I just completed a massive re-structure, and since I took notes and documented the steps, I figured I would share them. Before going thru the methods and techniques I took, we first need to look at the changes themselves.

One of the core reasons for the change this time around was some of the big internal shifts we’re currently doing at work. Things are changing on multiple levels in a good way, which means it’s time to review and adapt my system. The new way we’re working created a lot more friction with my previous planning method, which is never a good thing. Another big reason for the re-architecture was my growing disconnect between what I was doing and planning and what was happening day-to-day. That sort of disconnect is a big bright red flag that something broke down in the system. If you were to decide not to address it and leave it, the gap would probably become a lot worse and most likely end up breaking everything. Because a broken-down system is neither fun nor practical, I decided to take it up front and change it right now instead of broken.

One of the things I changed in my system planning this time was expanding and building on my idea of note-taking and experiments, which I wrote about here and did it experimentally. Instead of starting from “things I did before” or “things others are doing” or “good practice,” I decided to start blank and experiment my way forward. So one night, I sat down with my notes and a whiteboard (which turned out to be very useful, highly recommended) and went to work; four hours later, I had a working system. The resulting design is a lot more slim and versatile, yet it fits all my needs and requirements. While four hours might seems a lot to some people, to put it in perspective, the last massive change like this often took between a weekend to a whole week to get setup. In both cases, it still took me another week to fine-tune everything, but the total time cost then is one week and four hours versus two weeks. Now, what sort of magic happened in those hours to create such a drastic change? Let’s find out step by step, starting with the basics as I did.

Needs and requirements

The core of the re-architecture and how to build things, in general, are the needs and requirements. What do you need out of it? It may look evident at first glance, you want to more productive and stop forgetting tasks, but it’s not the whole story. Do you plan to use it for work? Is it for your personal use only? From that one question, a lot of things will drastically change already. If you use it for your work tasks, you will most likely have special requirements related to that. Do you need to track the time? Do you need to follow up with someone? On the flip side, if you’re using it for personal use only, you might not need all of those, but you might have other requirements. You probably also have workflows in place for various parts of your system, are those still valid? What do you love in the way things are going now that you want to keep going? All those questions and probably more you could think of should help you go deeper and see the core needs for this system. Knowing and writing those is and should be the first step because everything else will flow from there.

Doing that digging is how I ultimately found out I have two very different sets of needs in my system. I have the “active/executing” part, which is action and tasks I do during the day. The other set is the “planning” part, where I need a higher-level look into how things are going. That realization alone was the first significant change in how I work with my system, and it influenced the remainder of the re-architecture. From that point forward, I had to take into account both facets in my design. Was this requirement only for the “active/executing,” or was it for “planning” or both? If I do things this way, will it negatively influence either of those facets? Another significant need that came up during that process was around intentionality. I realized I needed to be more intentional around my workflows and planning to prevent that disconnect from happening and be more “on top of things.” That realization affected most of the workflows and the flow of information in my new system and pushed me to do things I didn’t do before.

As an example, the requirements for the “active/executing” part of my system were: Being able to log time for tasks, being able to time-block, being able to plan the next day at the end of the previous one, and knowing which project a task was coming from. As you can tell already, there weren’t very many of them, which is a good thing for this exercise. You want to have the bare minimum needs and requirements because each new one increases the system complexity. On the “planning” side of things, my requirements were a bit more numerous: Being able to see a project current state (active, paused, backlog, review), being able to see tasks related to a project, being able to see the current/upcoming/overdue projects, being able to link those projects in the various time perspective (month, quarter, year). As you can see, the requirements are a bit more numerous and vastly different from the other part. That duality can make system designing complicated if you don’t take time to step back and define things before jumping into the next step.

Workflow and experimentation

Now that we have the complete set of needs and requirements, it’s time to look into how those will happen. That part is where I spent most of the time trying to get right since it’s crucial. Workflows here are processes and mechanisms that the tasks will go thru in the system. Like in most systems, there’s an entry point for a task, and it goes through workflows to reach its final destination and get done, dropped, or archived. In my case, because I already had some workflow I liked covering many of my needs, I decided not to reinvent the wheel and use those as the base. I focused mainly on things that would need to change to fit in the new redesign. That part is the first part where we flex our imagination; how do tasks get in your system? Does it matter where that tasks came from? How do you plan your day? How do you plan your week?

There are a lot of possible workflows to handle here, and it can get overwhelming at times. How granular do you need to get? How many workflows are too many workflows? The answer will vary from person to person, but there are ways to help find your answer. You can try to run a “simulation” of your day to identify how things work. Think back to a typical day last week and imagine how you would handle tasks with the new system. Where do they come from, and where do they go not to get lost. Now try the same thing again on the worst day you had recently. Things are coming at you from every angle; you barely slept and are getting overwhelmed. Does your workflow still work in this situation? If everything is still fine, it’s just a bit harder; then you have a good workflow. If things fell into the void or you can’t imagine yourself doing it, then try something else. Usually, reducing the steps, complexity, or length it takes are good places to start. Doing this exercise, you might also realize some exceptions happen from time to time. Things “out of nowhere” that usually comes from other peoples or emergencies. That sort of exception can also warrant a workflow in itself if it’s something you see happening often.

To keep up with intentionality in my case, the biggest changes in my workflows were around daily planning. Daily tasks used to be added every week during my last weekly review, each day having its own small to-do list. From that point, each day, I tried to do them as best I could. When new things appeared, just like most lists, I added it to the top, it pushed the rest below, and leftovers got sent tomorrow. That flow and way of doing things while working was the reason for my disconnect and the problem I was facing. In my case, the fix was to use tools I already had experimented with and double down on them: end-of-the-day routine and time blocking. Now at the end of each day (work or personal), I take a little bit of time to plan tomorrow’s tasks using time blocking. Each block of time in the day gets assigned one task or one block of tasks to do. That way, each morning, I have everything I need to do today and at what time; it’s also a lot easier to move things around in case of change. A new task inserted in the day means I have to push something else out to tomorrow or reduce the time I can give it. That simple change means I’m a lot more intentional with what/how I plan, and also it gives me a better view of how I spent my time.

Implementation and iterations

Now that workflow has been made and you fulfill your requirements, it’s time for the system to reach the final stage and get hit by real life. Because a system is only perfect before it gets used, it’s time to look into implementation. Here with the implementation we want to look precisely “how will you do X” in your application of choice. You want to run all the various workflow you found out and designed with your apps to see what works. That’s the point where you get to know what was missing and what were extra unneeded things. Does your current application break in a particular workflow or require certain things you don’t need? Try to implement as much of the workflow as possible since that is where problems usually arise.

One possibility here is that your current application cannot make a workflow happens because of a lack of feature or it requires too much work. In that case, it might be time to consider moving to another application instead. The good news, in that case, is that you now know what you need and want out of an app, so the selection should be pretty small. Knowing everything you do, there’s no point in looking into the app with tons of extra bells and whistles at this stage. You want to take something that fits your needs with as few additional features as possible. If you decide to move, please make sure you still keep the old system around as a fallback because the process is not over yet.

The ultimate and final step here is iteration. Using the system day to day for a week or two will make you realize things you forgot. There are always things new things you forgot no matter how much you thought about; it’s part of life. That’s why when new things happen, it’s time to iterate on the new system to integrate those elements. Did you forget a need? Add it back and see which workflow needs adjustment or if there is a new one. Got a new workflow you forgot about? Add it to the list and see how to implement it in your app. Repeat this until you’re satisfied and there are no more obvious things to change. Congratulation, you now have a new productivity system that works for you, not against you; now it’s time to enjoy life.