My strategy to deliver more results
Focusing on the actual delivery and not the illusion of being busy
Get the free AI Agent Building Blocks ebook when you subscribe.
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.