My strategy to deliver more results

Focusing on the actual delivery and not the illusion of being busy

Amazon was my first job out of college.

When I joined, a peer gave me this advice: “Move tasks from left to right in the sprint”

The entire purpose of the onboarding is to become one more of the team. Showing you can deliver. It doesn’t mean you won’t ask questions. It means you’ll find your way toward completing the task.

Despite that, I see a lot of well-onboarded people having tons of tasks in a limbo state.

They are open, but they are not making progress on them for days.

In this post, we’ll go back to the basics my peer advised me when I joined the company.

💣 What’s the problem we are trying to solve

The problem I call it administrative tax. Every open piece of work has a cost associated with it.

If you are waiting for reviews, you’ll go back to it little by little as someone new takes a look and drops some comments. For other pieces of work, at the very least you’ll be providing updates in your standup every day.

How to reduce this admin task? By working on fewer things at a time.

This doesn’t mean reducing your delivery throughput in your team. It only means arranging your work so you move tasks to the right of the sprint board. You’ll work with a deeper focus on your tasks to complete them sooner, instead of leaving them in a limbo state.

We’ll achieve this with the flywheel strategy I propose in this post.

We’ll become a finisher

⚽ What’s the point of becoming a finisher?

Don’t trick yourself by closing tickets and creating new ones for the pending action items.

The point of leaving a task solved for good is removing the open loop in your brain topics. These open loops are like browser tabs. They are draining away your brain resources if you keep many of them open.

I see this every day. People keep many tasks open in a sprint.

They would have a few comments to address on a document. A couple of revisions in their code are just pending them to submit a new revision. Some tasks they are currently working on. For other tasks, they are waiting for a response from someone else…

If they jump from one to another, they are not moving the ball forward in any of them.

Working in small blocks of work is inefficient

🔩 Practical examples

We’ll fight against these open loops by doing more work upfront for any of our tasks.

We’ll be so diligent that we’ll make more progress on each of our actions. This will make your actions take more time, but you’ll need fewer actions. Especially less back-and-forth with other people.

• If you need someone else’s input, ask the best question of your life. And if you won’t align via text, ask for a meeting or sign up for office hours if one exists.

• If you are submitting your code for people to review, submit smaller pieces of work. People will review faster and they’ll leave fewer comments. Also, have your code quality checklist to have fewer revisions.

• If you are reviewing code, batch many PRs. Don’t drop everything you are doing every time a new PR lands. Dedicate more time per review to understand it and make meaningful suggestions. When you comment with a question mark at the end, the author will reply with a question asking you to validate it. Instead, explain what you see as a problem and what you'd like as improvement. The author more often than not will address your comment, no need for your input again.

• If you need to provide input in conversations, try to either

  • Make it sync on an agreed time, and finish this thread with that meeting.

  • Batch the async communication. Then, dedicate a block of time to answer them all.

🔁 A flywheel for your work.

The main concern people have is staying idle while waiting on someone else.

This is typical when submitting your code for review. To avoid the discomfort of not “feeling productive”, they’d start the next piece of work. This slows them down on iterating on reviews. They are context-switching between different tasks.

It’s a downward spiral. The more open work, the bigger the administrative tax to pay.

Instead, I propose a flywheel. It has only 2 steps

1. Work with a deep focus on your task until you have no more actions.

During this time, we’ll accumulate all the other work we are not doing. Mostly code reviews, messages, and emails.

1. If you have no more actions because you finished it, then move it to the right!

2. If you have no more actions because you need someone else’s input, do the batches of work you have accumulated.

3. Once you finish your batch work, you’ll probably have an action to take in your previous task. Go back to it.

I represent this with a small personal Kanban board.

At work, I use Obsidian with a plugin. At home I use Notion. I have a sticky for each kind of work I do and only one can be in the work-in-progress column. The rest of the tasks are in a pending column or ready-to-take, but I only dedicate my attention to one.

It also helps to make sure when I do some piece of work, I don't leave it pending in the messy middle. I focus on leaving it finished and moving to the right.

You can achieve the same by time-blocking your calendar. At any moment, you can only have a single block on the calendar.

Writing down what the block is for is a precommitment. It makes you more likely to follow through with it.

🧨 Life is messier than this flywheel

You won’t always achieve this.

I get it.

Sometimes you’ll finish all the batched work and still have no action. Or you’ll have many pieces of work with actions on your side at the same time. They may be so critical that you can’t afford to consume all your actions in one until you take a look at the other.

In all these situations, first identify the actions to take. Second, stop the task with a finished action.

If you can finish all your actions in one task, even better.

In case you can’t, then think of your brain as a computer. Keeping a process running for a long time consumes memory resources. Instead, write the current status down to save it to disk and kill the process.

Once you can dedicate your focus to it, you can resume taking the next action, just exactly where you left off. It’ll take time and resources to load the context back to memory. But it allowed you to dedicate all your focus to something else in the meantime.

🎯 Conclusion

I’ll formalize the two principles of this model:

1/ I focus my attention on the oldest task unless we get a better prioritization.

The more time it’s open, the longer it drains energy and attention. With open tasks, we usually dedicate a big chunk of time at the beginning, and smaller ones later.

An old task is taking a lot of these little blocks. Every time you go back to it, you have to reload the context into your brain. The more time it’s been open, the more consuming this process is.

2/ I don’t pick a new task while I have actions I can take on any other.

People will see your only single task open. But they’ll see all your other tasks stacked in the “done’ column.

This creates an image of being a finisher. Someone who delivers results.

I know I described an ideal productivity scenario in a messy world.

But it’s the ideal scenario the one we should work backward from.

🗞️ Other articles people like

An engineer’s guide to unlimited motivation in a corporate job

🔱 3+1 strategies to track your achievements

😎 My strategy to become a TOP 1% engineer

💀 Grow or die: How to keep innovating in your career

👏 Weekly applause

1. How YouTube Was Able to Support 2.49 Billion Users With MySQL by

   System Design Newsletter
   . A layer on top of MySQL to scale it.

2. How to grow from mid-level to senior Software Engineer by

   Engineering Leadership
   . Relevant for me at this moment in my career and probably relevant for you

3. What is a 10x Software Engineer? by

   The Hustling Engineer
   . 10 abilities to practice for your growth.