Three time management methods I adopted to boost my productivity

Intended Audience and Expectations

The intended audience for this article is anyone responsible for projects that require your time. I discuss various project and time management solutions that I tried over the years. I explain what parts of these solutions worked for me and why they ultimately did not meet my needs as I transitioned to new roles. I also detail why my current solution gives me the most satisfaction in the quality and quantity of my deliverables. 

By the end of this article, you will understand the time management methods I have attempted well enough to adapt them to your specific scenarios. 

Time for a change

In my previous article, I talked exclusively about remote work. Part of becoming a remote worker was figuring out how to have proper time and project management. If a remote worker cannot produce deliverables, they will not be a remote worker long. I had just become a remote worker and was used to things like core hours and daily accountability conducted via badging in and out of a compound. My new schedule was different. I was no longer bound by badging in and out, and neither were the other engineers on my team. My peers and my calendars would randomly sync during the day while being expected to produce results consistently.  

The transition from working in an office to working from home thrust me into a different kind of production cadence than I had ever known. I tried my best to apply the project and time management skills I had learned while in school, the military, and working for the government. It was daunting and utterly confusing, and I was throwing any production method at the wall to see if I could get it to stick. 

Block Scheduling (Goal Oriented) 

After a few months of not having any robust time management techniques, I realized I needed to adapt and overcome. Having a weak plan was better than having no plan. I read a few articles on time management and decided to try what I call the "block scheduling" method.

In "block scheduling," I break my day up into 45-minute blocks. I chose 45 minutes because if I joined two blocks together, I would get a solid 1.5 hours to work on something. At the end of two blocks, I took a break. I added blocks to my daily schedule, which lived in a One-Note document. I filled up the One-Note table until I had the required hours for my day. 

Block Scheduling: What I liked

I used the block scheduling method for three years, so in that regard, I can say that it works. 

Block scheduling let me set out the day ahead of me. I knew what I was going to be doing that day and for how long. I knew the exact time of my breaks, lunch, scheduled gym time (important for remote workers), what I was researching that day, and for how long. 

Block scheduling made me feel like I was 100% in control of my day, which is why I used it for so long. 

Block Scheduling: What I disliked

I was not in control of my day, not like I needed it. 

I wrote a schedule for my day that was for me: nobody else was beholden to that schedule. I placed artificial constraints on my day that only applied to me. Random meeting invites that came in the middle of my coding blocks forced a context switch without prejudice. 

I also had to make my schedule every single morning. The first 15 minutes of my day would be to run through any meetings or planned events and annotate them first. I filled in the gaps around those requirements with things that I wanted and needed to do. 

Fifteen minutes daily, all to figure out what to do, adds up over time. The DevOps part of me cringes at that repetitive manual labor.  

Block Scheduling: Application 

Those individuals that can dedicate specific segments of time to research or productivity will find the block schedule useful. Having the ability to control your public schedule allows the block scheduler to hone in on the particular needs for their projects in an intelligent and structured manner. 

Task-Specific (Goal Oriented) 

I got to a point in my career where I could no longer effectively juke meetings. My block scheduling method that had worked well for years no longer allowed me to produce quality deliverables in the manner I wanted. Both inside and outside parties scheduled meetings during my peak brain-time, the time where I could make significant leaps in productivity and creativity. Or quite often, an impromptu conference would pop up when I was attempting to complete a task, forcing a catastrophic context switch. 

Block scheduling worked until it did not. My schedule for how I wanted to proceed throughout the day became more of a general guide than a concrete plan. "I should try to do X," or "I would like to get Y completed today" started occurring more and more. I adapted to the interruptions of my productivity schedule by thinking of specific goals that I needed to complete. Contrary to Block Scheduling, how much time I allocated to achieve my goals became significantly less important. 

Task-Specific: What I liked

Something became apparent when I adapted to this method: a general goal is much easier to document than detailed timelines. I always had a good idea of what I needed to get done that day. I worked on that item until I finished, interruptions, and all. I gauged my productivity on this question alone: did I complete my goal for the day? 

Task-Specific: What I disliked 

The human mind is a complicated thing. I can sum up my personal experience using Task-Specific time management with one of my favorite quotes:

"A mind without purpose walks in dark places."

The problem with my implementation of goal-oriented time management was that I was hitting my goals. My mind would say, "You completed your goal today: good job!" and I would start to power down mentally. I thought, "Should I make a new goal for the day and start again? No! That's for tomorrow." 

Setting long term goals didn't work as well as anticipated. If I set the goal too lofty, then it was hard for me to judge exactly how much I should be producing daily toward that goal. If I set the goal too small, I lost motivation upon completion. I needed to feel excited that I had completed my goal, not guilty that I should be doing more. By setting the goal too large, I was effectively having no time management at all. There was not anything detailed to keep me on track daily. 

The stress of figuring out the right size goals to complete and track them without the feeling of guilt was quite burdensome, mentally, and emotionally. It began to sap the joy out of my job and the work I was conducting. This burden was a direct result of constant interruptions due to meetings or impromptu conferences. I was not in the right place, personally, with this specific time-management platform. 

If someone had given the team some lessons in AGILE, how to create and track Epics, and how to support those Epics via smaller tasks, these problems would have been much less severe. At the time, I did not know that these methodologies even existed, but I should have researched harder. I failed to fix the situation. 

But nobody gave us that training. And we as a team did not know any better. I think we would have figured out to use the Epic/Task methods eventually, but the crew did not make it that long. People started leaving, and our team just fell apart. Or so I'm told: I was not there to see it, I had already left. 

Task-Specific: Application

Goal-oriented time management is excellent if you have an adequate way to track your goals, e.g., JIRA and Kanban, Epics, and Sub-tasks. Task-specific is excellent if you know that your day is going to have interruptions. By preparing for the unknown, you are budgeting your willpower and saving your sanity in the process. 

One specific example of where task-specific time management is almost required is in the public sector. The military or government civilian culture is by and large "stop what you are doing and direct your attention to me immediately." Often, you are in the wrong for not doing so. 

I paint this sweeping generalization because I have spent time in both the public and private sectors. The public sector engineer is going to be hard-pressed to tell their supervisor to come back later when they are not as busy. By building their day around the possibility of interruptions and focusing on a specific goal to complete, people find a new way to take back command of their time. Having a sense of control makes a person feel more motivated in my experience, which is why the block schedule worked so well for me until my situation evolved. 

Productive Hours (Time-Bound)

The final (and my current) time management technique is all about X, where X equals an amount of time measured in hours. With block scheduling, I set up goals for the day and tried to hit as many of them as I could before I got off track. With the task-oriented approach, I would complete my goal for the day and lose all motivation to continue. Or my goal was set so lofty that I was often misguided with my efforts to achieve the goal. In both situations, I was attempting to compensate for interference from the outside (meetings, life, illnesses). Enter what I call "Productive Hours."

The Productive Hours method works like this: 

• At the start of my day, I set a countdown timer on my watch, usually 4 hours. 
• Every time that I am 100% laser-focused on my work like I would be if I were conducting a red team operation, the timer starts
• If what I am doing doesn't require as much of my mental CPU as being active on a live target, I do not start the timer
• Every time I am not "on target," I stop the clock
• I try to hit the timer every day. Sometimes I go over, sometimes stay under

That's it. It is a stopwatch method with teeth. Here is the crucial part: I get more done in those hours of productivity than I ever did with the block method; I am free to float from topic to topic as needed. I complete a significant amount more than task-oriented because my goal is productive time, not the production of an object. At the end of those four hours, I feel proud of all of the work that I accomplished. I am emotionally and mentally whole.

Productive Hours: What I like

At first, it appears that I am only working four hours per day, which is not accurate. I work as much as I need to work. I make sure that I have four solid hours of work that hit a standard I know to be rigorous. Sometimes I have to go to a meeting that could have been an email, or coworkers want to talk about work or life. Answering a question and helping my coworker is excellent, and I love helping them. However, mentorship doesn't start the clock. Assisting my coworker with a problem is not me conducting actions toward a deliverable. It is me helping them deliver that for which they are responsible. I can quickly glance at my watch to know how much of a detour I can afford while assisting them. Having that stopwatch on me helps pull me out of quagmires while I am trying to produce on my own time. 

I also mentioned pride in my work. I know how much I can accomplish with a four-hour red team operation. By being rigorous in the standard I set to start the countdown, I get the same sense of pride when I hear my timer expire. I know that I have produced that day, be it another policy, project charter, or code development for an upcoming operation. I had four hours of total production time throughout the day, working on one or as many projects as needed. 

The last thing I like about this method is a bit of personal preference. As mentioned many times in this article, I talk about how disruptive meetings are to the worker. And I am not currently in a position where meetings ARE the deliverable (e.g., CISOs, VPs, Executive level). Every time I get pulled into a meeting, I start the timer. I do this for two reasons: first, because I have no option in the matter, I have to be at this meeting. The choice of how I wanted to spend my work time for the day was taken from me by someone else. Second, because the timer is running, I am now bound to have the same level of mental CPU throughput as I would if I was coding or writing. Starting the timer during meetings is a way to force me to be 100% present at the meeting and less resentful that I am there. This meeting is how I am spending my time. I will pay attention, give it my all, and try to wring as much production out of this assemblage as I can. I am paying for the meeting with my budgeted time, and I will ensure that I make it a valuable use of that time. 

I have found that my naysaying during meetings has significantly dropped while practicing this method. 

Productive Hours: What I dislike

I dislike that I don't have more energy or hours in the day.

That's the only thing I don't like about this method. Seriously. I wish I could do more without tiring out. But I am getting older. 

Productive Hours: Application

First and most important: set your standards. Find out what is considered productive work in your field and what is not. I am genuinely interested in discovering if other areas outside of Cyber/IT can use this method. Adapting time-management methods to different career fields could be a method for those professionals to find (additional) value in what they produce. 

The second way to apply the Productive Hours method is to ask yourself this: what have you done in your life that required a substantial amount of your mental CPU? Figure out what that is and then apply that standard here; it will be your barometer to discern when it is time to start or stop the clock. For me, it was conducting operations on a live target. 

As I progressed with this method, I realized that I needed a way to keep track of all my tasks. I eventually settled on an awesome Kanban board that I created for my specific needs. I can see every JIRA ticket assigned to me, mentions me, or was created by me. I can filter that further with a toggled to see all tickets or just those within the past two weeks. The more critical work filters up, and those tickets that are not as important hit the backlog as time progresses. Finishing a task in the Productive Hours method means that I just select another ticket from my board. I am running for time, not distance. 

Conclusion

I have tried many time management techniques since I started working remotely. I knew that any plan was better than having no plan at all. Trial and error only took me so far. Life and work regularly changed, and I adapted when I needed to adapt. 

By starting with Block Scheduling, I was able to take control of my day precisely. I was able to do this because I was in an individual contributor position. When I moved to a role that required some project management, Block Scheduling was no longer valid: I was no longer entirely in control of my day. 

Task-Specific scheduling was a good adaptation for a role with some embedded management. While I was able to complete some tasks, I lost motivation to complete more tasks when I finished doing what I had set out to do. I chalk this up as a personal failure. 

In a role that requires consistent high performance, like the role I am in now, Task-Scheduling just was not the right answer. By swapping to Productive Hours, I ensure that a certain amount of quality work is delivered every day. Because a specific goal does not bound me, my motivation for work is not affected by completing tasks. Because I know that I need to deliver a certain amount of quality work, I limit things that would prevent me from doing so. I also know that at the end of the week, I kicked ass and can enjoy my weekend guilt-free. 

If you found this article helpful, please feel welcome to share and send me a connection request.