Full disclosure before you read any further: I am one of “those” people …the productivity obsessed. I am constantly trying to improve my output and overall workflow – both professionally and personally. I am by no means the most productive person in the world, but I’m constantly trying to work toward some unatainable level of expert efficiency. I’ve read 7 Habits of Highly Effective People and Atomic Habits (which I HIGHLY recommend). I’ve read every Lifehacker “How I Work” post. I’ve gone from vim to emacs back to vim – currently with highly-customized vimrc file. And, I’m currently in the process of trying to reset my sleep schedule to wake up at 4:00am, to reach the pinnacle of productivity!

Take everything below with a grain of salt – there are probably much more scientific and accurate explanations for the information I provide herein. But, to quote the prophet Adam Sandler in his critically acclaimed philosophical sonnet “Wedding Singer”:

I am the one with the Microphone! 

As network engineers, developers, devops practictioners, and overall technologists, we have become accustomed to working in teams. These teams are often organized into functional or cross-functional groups that work together to accomplish a certain set of tasks – deliver an application; design, implement, maintain, augment the infrastructure that supports an application; rinse & repeat. As such, there are many methodologies that define how teams work together to accomplish their set of tasks. A non-exhaustive list would include:

• Agile
• Kanban
• Waterfall
• Scrum (which, I think is Agile?)
• Lean
• Extreme Programming
• GTD
• And many…many…more (so many more)

These methodologies, for better or worse, define how a project is managed. They establish a set of standards and working cadence that facilitates a few expected outcomes: delivery, collaboration, acceptance criteria, estimation, and scheduling. When utilized correctly, these methodolgies can be powerful tools to manage a team toward an efficent and euphoric high-functioning juggernaut!

The question that can often get overlooked, even on these high-functioning championship teams is: How do I manage MY time? How do I prioritize and maximize MY productivity?

With that question in mind, we will take a look at a method of personal productivity management that can be beneficial for anyone working in an engineering/application/devops capacity.

Priority vs Productivity

In all my research, tweaks, failures, and successes, I’ve identified that there is a big distinction to be made between priority and productivity. They work hand in hand, and are equally important toward an efficient workflow. Priorty identifies what to do at a given moment; Productivity is how you do it. Being proficient at both is the key to maximizing our time and potential as engineers.

More often that not, external factors have much influence on prioritization. Deadlines, dependencies, budget contraints, outages, threats, public shamings, etc… can all impact which tasks get pulled into our “hot list”. Often times this is out of our control.

Prioritization can be summed up by using the common computer science analogy of the Stack vs Heap.

In this analogy, “the Stack” involves things that are done quickly, with very little congitive load. This could involve answering an email, documenting a new feature, commenting on a pull-request, reviewing a pull-request (sometimes), and other “quick” tasks. The key here is the cognitive load. A coworker of mine is an all-time champ at answering questions on the Network to Code Slack channel. During downtime he can engage with someone, diagnose their issue, and respond, almost asyncronously from his other tasks. He’ll do this if he has 5 minutes between meetings, waiting on a response from one of his employees, etc… He is able to do this based on experience and muscle memory – most questions require very little research for him. If a question does require additional research or investigation, he may refrain from responding or file it away for a later time …when he has time for “the Heap”.

“The Heap” in computer science refers to operations requiring memory allocations of a non-finite size. As such, it is more flexible, but more expensive than operations involving “the Stack”. As technologists, examples of using “The Heap” could include: reviwing documentation, writing code, debugging, troubleshooting, researching a new topic, reviewing a design request, and code review.

The Stack vs Heap analogy highlights the importance of properly identifying a task or request’s scope, and what is involved in fulfilling/resolving it. A good question to ask is: “Will this take me more than 5 minutes?” If so, it is normally left for an allocated time of focus, where the task can be given the attention it needs. Otherwise, it can be handled immediately, or during a time requiring less focus. Some answer emails and handle other “quick” tasks at pre-allocated times during the day (more on this later); others handle these tasks as they come in, but only for a short period of time, before returning to a more involved task (this is often the case for those in an operations role).

Proper Prioritization Prevents Poor Performance

The biggest takeaway from the Productivity vs Priority distinction is that it is imperitive that we identify our priorities and make a plan to execute on them. Conversely, it is important that we identify secondary responsiblities and potential distractions that can negatively impact our priorities.

If our main job responsibility is to deliver a feature by the end of a sprint, will our team care how many emails we have answered if the release is late? If we are asked to resolve tickets quickly to improve our team’s MTTR, does researching new features contribute to, or detract from that goal?

Though those questions may sound bleak, the good news is that we normally have more time for productivity that we think. This is especially true if we work in an environment with reasonable deadlines and efficient estimation – e.g., Network to Code (shameless plug). Normally, we have time to deliver on our primary, and additional responsiblities and look for ways to improve efficiency – if we improve our productivity.

Pomodoro Technique – Embrace the Tomato

The method I have personally found to be most productive FOR MYSELF is called “Pomodoro”. I have found great success utilizing this method because it forces you to allocate both focused and unfocused time, along with breaks. In short, the Pomodoro Technique consists of the following:

• A “Pomodoro” is a CONSECUTIVE unit of focused time – normally 25 minutes
• Each pomodoro is followed by a short (3-5 minute) or long (15-30 minute) break
• Breaks increase in length as successful pomodoros are completed
• Tasks are handled in a First In First Out method
• If a tasks takes longer than 25 minutes, it can be completed after a break during the next pomodoro
• If a task takes less than 25 minutes the remaining time can be left for unfocused (“Stack”) activities
• WRITE EVERYTHING DOWN!! Take notes on tasks, successful/failed pomodoros, timing, etc…

It also promotes good prioritization, planning, estimation, and self-reflection. At the end of a day, week, or sprint, it is easy to identify where time was spent, and what optimizations are needed.

Here are some things I’ve done to utilize the pomodoro technique effectively:

• Assign every task a due date as you receive it
• At the beginning of the week define the week’s goals and the total time you’re allocating to work (time available minus meetings, appts, personal time, PTO)
• At the beginning of the day write down Things To Do, keeping in mind the time available for that day
• Identify which tasks are most difficult, and/or least desireable, and stagger them with more desireable/easy tasks
• Always start with a desireable/easy task to build momentum
• Schedule long breaks, lunches, and personal time, by adding these things to your calendar
• Mute Slack, email, and other notifications (if possible). Move your phone to another room, or away from your reach
• Have fun & execute

With all of these productivity “tips”, it is important to remember that “to err is human”. Some days I am a productivity machine. Some days I can barely type my own name. However, I can personally attest to the success of the pomodoro method. When I use it effectively, at the end of each day, week, sprint, my output is optimal, and I feel great about it. When everything is “on fire”, time seems to fly by, with little impact.