Before anything, you will need to figure out the interval window for your work tracking. In a professional work context, this is referred to as a sprint. If your team already follows sprints, each of your sprints already have a time window - most likely weekly, bi-weekly or monthly. If that's the case, you are all set. If your team does not use sprints, then you can create your own and track it yourself. Start by following a monthly sprint, which basically means you will start each month by doing a few task management things and end each month by doing some more task management things. You evaluate your performance each month, figure out pointers to improve and repeat the process the next month.

Once you have your sprint length figured out, you can follow four important steps to ensure that you are making the best use of your time.

Decomposition

As a software engineer, the things you need to get done are usually vague. If you try to tackle the entire task or project as a whole, you will not only find yourself wasting a lot of time trying out various implementations that lead to dead ends, but this backtracking is also frustrating. So before you begin any work, break down your tasks into a bunch of smaller subtasks. Let's pick a simple example and use it throughout the video so you can get a good sense of how to manage your project. Let's say your task is to create an internal polling system for your team. This polling system will be used by your team to decide on various things like voting for a framework to use on a project, voting on a place to eat for a morale event, basically any time where there are multiple options and your team will need to vote on their choices. Ok, so you have a high-level task, but you can't just say, "Ok, I am going to start building this." Spend some time thinking about the sub-parts of this project, how you will go about implementing it, what are the parts you will tackle?

A good rule-of-thumb is to decompose your high-level tasks into subtasks that each take roughly 3 days or less to finish. If a task takes longer than that, it needs to be broken down into further subtasks. But how do you decide how long something takes before you actually do it? Well, that's the next step.

Estimation

As you decompose your tasks, you will need to make an educated estimation on how long it will likely take you to complete. If it's a project that is new to you, your estimations may be inaccurate. And that's okay, even if you are wildly guessing, you should still estimate. Because when you finish a task, you will also record how long it actually took you to complete the task. At that moment, three things can happen: you estimated correctly, you thought it would take you way longer than it actually took or it took you way longer than you actually thought. If you estimated correctly, great job! If you were off, at the end of every sprint, you should spend time reflecting on why you were off. The goal here is to learn what you can do to improve your estimations and avoid doing things that throw you off. For example, let's say that one of your tasks for your polling system was to create a continuous integration pipeline so that any code changes in the future can automatically go through the build, test and deployment process. And you thought it would be relatively simple and take you a day to implement. However, it takes you 3 days! Figure out why? What did you think was easy? Maybe you got stuck on something for 1 whole day? Maybe next time, you should ask someone the moment you are stuck for 1-2 hours instead of wasting more time. Maybe you thought the pipeline was based on JSON and it used YAML instead and you had to pick up the YAML format. These are all great learnings ... and the more you do this estimation-reflection process, the better your anticipation becomes and as a result, your estimations get very accurate. Task decomposition lets you figure out what exactly you need to do at a very granular level. Estimation lets you know exactly how long each of those tasks will take you.

In an ideal world, the amount of time you have and the amount of work you have to do are exactly the same. However, in the real world, you will always have more work compared to the amount of time you have. So even though you have your tasks decomposed and estimated, you will still need to prioritize them. Which takes me to step number three: Prioritization

Prioritization

When we think about priority, we generally think of severity, as in: Low, Medium, High. That works for general bucketing, but in terms of proper task and time management, every single one of your tasks should have a rank. Rank not only helps you prioritize your work, but also quickly visualize the dependency. For example, the task to create a deployment pipeline for your polling system cannot be rank 1, because you will need to essentially finish enough tasks that give you at least some code to deploy. So your ranking would ideally be a bunch of critical features for the polling system and then when you have a MVP, you would have the deployment pipeline come in. A good idea is to start by ranking every task in intervals of 10. For example, the first task you should do should be rank 1, 2nd task should be rank 10, third should be rank 30, so on and so forth. That way, you have enough space so insert tasks in between or move them around. There is no hard and fast rule here, the idea is to have an ordering that describes the priority and the dependency of your work.

Okay, so you have decomposed your tasks, estimated them and prioritized them. The only thing left to do is to organize them, which is step number 4.

Organization

Organization is the simplest step. Open your calendar and block out the times where you won't be able to work on these tasks — meetings, lunch, workout, your personal or family time, vacation, times where you want to disconnect from work, dentist appointments or whatever else that is. Now start at the beginning of your sprint, and start filling in the empty spaces (or the time you can dedicate to working on your tasks) beginning with your highest ranked tasks and moving down the list. Every few tasks, leave some buffer of free time so that you have time to adapt and adjust should things not go according to plan.

And that's it. The day before beginning a new sprint, spend 30 minutes doing your decomposition, estimation, prioritization and organization. Once you have done that, for the rest of the sprint, you just follow the calendar and don't have to spend a minute thinking about managing your time. Because you have put in the effort in the beginning to do that. All you need to do is pick up a task that your calendar says, on the times that your calendar says. The key takeaway here is that the best way to manage time is by not trying to manage your time all the time!

But do remember to reflect on what you did at the end of your sprint so that you can figure out things that worked and things that did not work. You want to learn and continually improve your process. That way, your decomposition gets better, your estimations get better, your prioritization gets better and your organization gets better. And guess what happens when all four things align perfectly? You get the most out of your time. And that's what effective time management is.