Oh great, another article explaining how to be a turbocharged productivity monster...

No.

In this article, you won't learn how to become the proverbial 10X developer, or how to be the fastest DevOps of the planet earth.

Because the secret to efficient time management is not doing more, it's actually doing less (and if you don't want to read this long form article, you can skip to the 'wrap up section' ;) ).

As a tech person, your activities usually can be split in 3:

• Build: Adding new things to your stack, software, infrastructure, team
• Run: Fixing bugs, Running your software, keep things updated
• Learn: Grow your expertise, in order to solve new classes of problems

This is true for devs, DevOps, SREs, engineering managers, and probably most of the jobs you can imagine in tech.

Considering this, efficient time management boils down to two things:

1. Be pragmatic and don't waste time by doing useless tasks
2. Preserve the balance of your investment between Run, Build and Learn

A time for building

Happily write pragmatic software

Software is immaterial, so how can I be pragmatic while crafting it?

My answer to this is dead simple: challenge the why and the impact of the project

Why am I building this?

If the answer to this is not serving the company's mission, you are wasting your time.

When you answered to this question, if you still don't know if your company need this, use the 5 whys method. If your answers don't climb up to the company strategy after 5 steps, you are most probably doing something useless.

And killing useless tasks is the easiest way to free up time for more relevant tasks.

Estimate project impact

Software is a tool, and not a end goal in itself.

Identify your end-user. Measure what you are willing to change and estimate impact.

A common bias is seeing problems closer to us as more important than problems that don't impact us. Challenge that inclination by estimating business impact of fixing both.

In one of my teams, there was 2 competing productivity problems to solve:

• The test suite of the CI was running in 40 minutes, which was painful and frustrating for developers (they had to wait 40 minutes to know if the CI was green and if their work was finished)
• The Customer Success Manager team had no proper tools, and were wasting time on brainless tasks

The CI problem was raised at almost all developers' retrospective meetings, and was considered by most of the team as the most pressing problem to solve.
Nobody ever spoke of adding admin tooling for CSMs people.

I taught my team to do a reality-check when setting up priorities by adding numbers:

• I opened GitHub in front of them: Each dev was producing one or two PR per week. There was six devs in the team. In a month, that makes 36 opportunities for the whole dev team to tackle another subject (self-training, small bugfixes, quickwins, etc) while the CI runs. This is 24 hours, where devs had to work on "something else than my current task" (easily fixed by giving each of them backlog of tiny tasks to juggle with)
• Each people of the CSM team was doing between 200 and 500 phone calls a month. There was 3 of them, which makes around 1000 calls per month. Each call needed to be prepared a couple of minutes ahead (for full context) and could last from a few seconds (if the user does not answer) up to half an hour. Each time a user does not answer the CSM person, it means 2 minutes and 30 seconds have been just lost by that CSM. And conversion rate was very low (less than 1/3 of the users were answering). Each month, CSMs were losing more than 40 hours working on users that never answered calls

The farthest problem, was deemed the less important by the team, but was costing way more to the company than the closest problem.

Ultimately, we found a way to provide a properly ordered list of people to reach out for the CSMs (the most likely to answer at the top of this list), and this led to a tremendous decrease in time spent waiting for users to answer.

Understand exactly what you have to build and deliver

Spending time on something that will not be used is a waste of your time. If you spent a day working on something "that we are going to need in the future", I can guarantee you that you could have more fun and have pretty much the same impact by going to the park.

Things that we build "because we may use it at some point" are useless today, and will probably stay useless forever.

Don't build for the future. Solve your actual problems instead of your probable future problems.

Also be sure to double check your understanding of what needs to be built with your stakeholders. You don't want to spend time on something that nobody is waiting for.

Before climbing a mountain, prepare for mountain climbing

To go for a short 1 hour walk in the city, you only need a handful of things: your keys, some change and you are good to go!

But it would be foolish to climb the Everest with only your keys and a few coins.

It's pretty much the same things with tasks: If you start a huge task with no preparation, it's going to end up badly.

As a preliminary task to your huge task, split your huge task in more manageable tasks, and schedule them. If your split tasks are still huge, do it again!

This is what I do when I write a long form article. I split it into several manageable task that I can do under an hour. For example, for this article, I went:

• Brainstorm: Collect ideas and tips about time management
• Structure: identify my main messages and the plan of the article
• Write: Write each section of the article
• Edit: Review and edit the article once it's fully written
• Publish: Success!

A great side effect of having planned the execution of this task was the ability to pause/resume. Since the plan is written down, I can work on something else without forgetting about what I wanted to write next.

Which leads us to my next advice: Always go from abstract to concrete

If you notice that you are already deep down in the implementation details without having yet figured out the global plan of execution, you need to take a step back.

Don't start the work on the architecture if you are not 100% clear on the requirements. And don't work on the code if you are not 100% clear about your architecture.

A time for operations

Run this software without blasting your productivity

Writing code is cool, but it's nothing if you don't end up with users.

It's OK to build things that are not meant to be deployed as a production environment, as long are you are aware that you are just "practicing".

And as soon as you have end users, you have to keep the pot boiling.

Let's see what we can do to avoid spending too much time on this pot.

Measure operations time costs and optimize your run

While keeping a production up, some things are significative time sinks.

When facing such situation, I ask myself the following questions:

• Is this task useless? (kill it)
• Can somebody else do it? (delegate it)
• Can something else do it? (automate it)

Example: If your support team is asking quite often your tech team to investigate why some users can't use some features of your product, you can either delegate (teach your support team to understand your product configuration and workflows) or automate (build a technical diagnostic page).

Batch small mindless operations to save your deep work time

One underestimated time thief is the context switching. It's commonly accepted that you need between 15 to 30 minutes to be properly focused on a topic while doing deep work (coding or writing for example).

Assuming you worked on 8 different topics on a single day, that's between 2 and 4 hours of concentration time gone with the wind.

If you need to achieve deep work, don't multitask, and avoid context switching.

But wait, there is more!

Let's say that you decided to dedicate your whole day to a deep work task.

Breaking news: you need to refocus even after the most trivial mundane interruption.

Your coworker ask you a question about a technical detail? at least 15 minutes were just tossed into the bin. Your support team ask you to start some jobs in production 8 times in a day? Again, that's between 2 and 4 hours of time lost in refocusing.

The easy solution is to batch non-urgent but important & trivial tasks that don't require deep focus. This way, you limit the interruptions of your deepwork, and you'll get more done at the end of the day (or you will be able to get home earlier, which is a nice bonus, innit?).

A time for learning

Don't let run and build tasks preventing you from growing, for yourself and your company

While working in tech, you will have to work with lots of different stakeholders:

• Your project or product manager want you to build tons of things, as fast as possible
• Your end users want to use a reliable and nice tool
• Your manager want you to reach the goals he gave you
• And yourself as well are a stakeholder, since you want to grow and be successful in this company and in your career

The trap is, while trying to meet expectations of all your other stakeholders, you end up being quite the busy person, and you probably forgot to be the own stakeholder of your personal development.

Don't do that! Reserve time for your growth.

Also, be sure to have a sensible training plan: curiosity is not a purpose. Make the better out of your learning time by investing it into something that will serve you, not something shiny.

Learning about a cool tech that nobody heard about 1 year ago is a bet. Sometime you can win and be one of the first to be fluent in an interesting emerging technology, but if can also be a major waste of time.

So before learning about cool tech, learn about plain old boring ones ;)

Understand your ecosystem

Some company value a lot personal learning time, especially if it serves the company mission. Some other don't. and expect you to grow on your own personal time.

Be sure to understand for which of those two you work for.

And once you know, reserve, formally, some time for learning. Your internal stakeholder will thank you later.

Wrap up

Here is a digest of the time management principles I use on a daily basis:

• Understand the why
• Challenge tasks usefulness
• Set priorities based on impact
• Do a reality-check from time to time
• Reserve time for deep work
• Reserve time for batch of brainless tasks
• Reserve time for learning
• Split big tasks in smaller tasks
• Eat the frog in the morning

What are yours?