Moving fast

Have you ever seen colleagues who seemingly do more in a day of work, not once but consistently? Have you ever wondered how do these people do it?

I have seen quite a few engineers like this throughout my career and at some point it got me thinking - is there some pattern common to all of them, something that can be understood and applied by others as well?

After working with a lot of folks over the years and observing their behavior, I have concluded that there is no secret sauce to time management, no one technique that you can leverage and become better at this.

It might seem like a pretty dry conclusion, but here's the good news - "making" more time for yourself at work is done by many micro-optimizations and we're going to be discussing some of them in this article.

Think of it like losing weight - it might not seem that giving up that slice of bread every morning could make a significant difference, but we all know it does.

1. Know your priorities

It's hard to optimize your time if you don't know what are your priorities.

I've been there, you've been there, we've all been there - starting a new day at work and having absolutely no clue about what to do, or at least what to do first. It's normal that this happens from time to time, but if it happens on a regular basis then it's a problem - one you can fix.

A powerful tool that you can use to get clarity on priorities is setting goals. If you have well-defined goals and objectives, knowing what to focus on should never be an issue. Spend time defining and aligning on goals and your priorities should derive directly from there. For a much more detailed discussion on this subject, see my article on Goal setting.

Asking your manager and other folks what needs to be done can only work in the short term. You need a clear vision of what's coming in the next few months so that you can plan for it. Use the regular 1:1 meetings with your manager to get this clarity and get into detail if something is not obvious. Have a weekly or bi-weekly conversation with product managers, sales engineers, support folks etc. - whatever it takes to paint a picture of what's important and what's not.

2. Keep a TO-DO list

This is directly tied to the point above - use a TO-DO list!

It's something that I've used for a long time and it might seem trivial at first, but I assure you - don't underestimate its power. It helps you to:

• Keeps you focused. You always know in detail what you need to do next and the next thing after that.
• Keep track of tasks as they come up. How often did you forget to do something because you didn't note it down and figured you would surely remember to do it?
• Make a note of the progress for each task. Sometimes it takes a while to finish something and having a log of the progress helps you to stay on track.
• Get feedback. If you're unsure of the priorities, you can always show the list to your manager or peers and get feedback.

For many years I used a plain notebook as my TO-DO list. I feel like writing it down on actual paper has more impact than just typing it on a keyboard, so I still use paper to this day for some things. But in the past couple of years, I've transitioned to using tools like Asana, just because it makes it so much easier to organize things and have them available on all devices.

It doesn't really matter what you use though, what matters is that you use this list to keep you focused on what matters most. Speaking of which, there is one more tool that I employ to make sense of my TO-DO list - the Eisenhower matrix.

Without a TO-DO list, it's impossible to create this matrix. I'm sure most of you know of this matrix by now, so I just want to give you a few tips that I personally use:

• Start with DO. This should be easy, as things in this category are usually obvious - the release of an important product, production alert, finishing a presentation for quarterly call etc. A trap I see engineers fall into here is not thinking of the larger scope. If a peer sends you a pull-request for something that needs to be finished this week, think it through - is that work important for the team or group? How likely it is that this review might take a while? These like these might not be critical for you, but could be very important in the bigger context. Don't do anything else besides these until you can no longer make progress. Don't postpone any of the tasks here, as it's unlikely things will get any easier.
• Learn to DELEGATE. Usually the reason folks get swamped with work is because they're poor delegators. They feel that they need to do every piece of work themselves, not realizing other peers can do just as good of a job, if not better. Even if you're the best man for this job, consider delegating as a way to grow your peers and empower them. Sure, it might take longer in the beginning, but it might pay big dividends in the long run. One way to ensure this works is to allocate time for it explicitly - reserve some bandwidth for these mentoring/training sessions as part of your regular planning.
• SCHEDULE the right things. The trick to not getting overloaded with urgent and important work is to decide what are the important things in the mid-to-long term and schedule time for them. This means explicitly carving out time for stuff that you know is coming and will become urgent at some point. Know what your team's roadmap is for the next 6-12 months and review it on a regular basis. Do you foresee a big refactoring will be needed? A new component that your team needs to develop? A new team member that starts in 2 months? These are just examples of important things that you need to plan for in advance. This is one of the keys to people who are good at time management.
• Always DELETE some things. Don't underestimate the effect of getting rid of tasks that are cluttering your board and you know deep down that nobody will do them. Keep your backlog clean and it's going to have a compound effect. Oh and also don't go to meetings with no agenda.

3. Speed and Quality

There's often the misconception that you need to choose between the speed and quality of your products. If you care about speed, the quality suffers and if you want quality you're going to have to move at a slower pace. Just to be clear, when I'm talking about quality, I don't just mean software quality, but also the quality of the final product itself - how well it works, how useful it is to customers, how easy it is to add new features etc.

After thinking about this for a long time, I realized that from a big-picture view, this is simply not true.

If you want quality, you need to be able to quickly build small increments of the product, test them, understand their impact, get feedback about actual customer value etc. I've worked on quite a few projects where we spent a lot of time building something that was scrapped because it didn't have any real-world use. It might have been a cool piece of software, but it didn't matter because nobody used it. On other occasions I spent months polishing up a big deliverable, only to find out that it didn't play well with other internal services, or the performance was poor when deployed in a production-like environment. In both cases, if we would have moved quickly and evaluated after each milestone, things would have turned out very differently.

Vice-versa, if you want to move fast, you need to maintain a high level of quality. There's no point in being very fast if every time you deploy a significant change, you constantly have to go back and fix bugs that you had no clue can happen. You need to maintain a good level of quality such that you always move forward. Of course, this varies from project to project. If you're working on medical devices or airplane software, you'll need to be much more thorough. But the majority of the software that we write has some tolerance for errors, which needs to be balanced by the time to market. The trick is to understand how the project that you're working on sits on that range.

A requirement for moving fast is knowing well your and your team's priorities, otherwise you will end up just quickly building the wrong thing.

Dave Farley has a great talk on this subject, highly recommend it:

4. Avoid context switching

We all know context switching is bad, but how often do you really factor it into your overall productivity?

Numerous studies tell us that we achieve less when multitasking and context switching, not more. Similar to how an operating system works, context switching takes a toll on our overall efficiency. But unlike an operating system, we can't context switch in a fraction of a second - it takes us a significant amount of time and energy to properly context switch between multiple activities.

Here are a few ways to reduce context switching:

• Say yes, but not right now. It's often hard to refuse someone who is asking for help, but sometimes it's necessary. No one likes friction in life, especially at the workplace. But if you take care of every request made to you right away, you will be soon overwhelmed with tasks that are not on your priority list.
• Batch related work together. When you have multiple things on your plate, try to group similar tasks. Don't mix code with testing or design work, if possible. Focus just on one activity at a time and your mind will work at maximum capacity.
• Do less, coach more. You don't need to personally solve everything when someone asks for your help. You can still help folks by consulting and coaching them through the process. The added benefit is that you're helping them grow as opposed to just doing it for them.
• Schedule what's next. Even if you do everything right, you will have multiple things going at the same time. Instead of constantly having to worry about them, schedule dedicated time for each. This will force you to prioritize the really important stuff and also think strategically about the sequence of tasks.

5. Keep an eye on meetings

You've heard this one before, but I'll say it again - reduce the time you spend in meetings and make it a habit to schedule them only when necessary.

Easier said than done, right? One powerful tool that I've used for years is color coding your meeting calendar. By color coding, I mean marking each of your meetings with a color to indicate its category. Is it a recurring call? Maybe a very important meeting that you need to prepare for? Or simply blocking some time that you need outside of work? Color coding helps with all of that.

Let's look at an example of how to do it:

There is no right way to pick these colors, just do whatever works for you. You can have as many or as few as you need.

But how does this help you move fast? Here's how:

• Aggressively cut down on the recurring meetings. These tend to eat a lot of your time and oftentimes they're not really needed. Not only that, it forces you to context switch, which has a lingering impact on the rest of your day. Figure out what meetings are really important, re-assess their cadence and audience and remove all the rest.
• Block time in your calendar. It's well known that engineers need focus time to do their best work, so use the calendar as a tool for that. If you know you have a deadline next week, block off at least 4 hours in the day so that you can work on what's important.
• Avoid back-to-back important meetings. This goes without saying, but you need to prepare for those. If you have multiple of these back-to-back, the meeting might not be productive and you'll have to schedule another one, which is even worse.

6. Be politely persistent

In her book Radical Candor, Kim Scott speaks about challenging directly. One of the teams she managed in Tokyo had trouble with this approach because of the different culture of Japanese people. That's why she rephrased it to being "politely persistent" to denote the characteristic politeness of Japanese people in the context of challenging other people.

I particularly like this definition because it summarizes something that I truly believe in - be polite and humble with your peers but be persistent in moving things forward.

Here are a few ways in which you can apply this concept in your day-to-day life:

• Get early feedback. Have you ever sent something to review only for it to take a few days until you got some feedback? Fast feedback is critical for fast cycle times, so gently remind folks to take some time for the important reviews.
• Get timely help. Don't wait to get completely stuck on something. If you feel that you're out of ideas on something or reaching a dead-end, ping one of your peers who might know more about it. Don't abuse this though, other engineers have their own work that needs to be finished.
• Reach out to PMs. Oftentimes your first point of contact for product questions is someone in product management. Make a habit of chatting with them about engineering decisions that can impact the product and vice-versa. This ensures that you're always building the right thing.
• Get clarity. Is something not clear when it comes to priority or next steps? Reach out to the relevant stakeholders and get that clarity early and often. It might be your manager, a peer from another team, a support engineer, etc. Be proactive in getting the information you need.

Conclusion

At the end of the day, moving fast is a combination of pro-activeness and structure. Everyone gets the same time in a workday, but it's up to you to make the most out of it.

Find out what are your priorities, work with a singular focus and use fast feedback loops - this is the key to moving fast.