Learn

👨‍🏫 [Story or Principle]

My last post titled “Stop Starting, Stop Finishing” had an overwhelmingly positive reaction.

At one point in that post I invited readers to reply to me directly if they were interested in diving deeper. I received way more responses than anticipated!

So here we go, a follow up to “Stop Starting, Stop Finishing”.

But wait, are we talking about personal productivity? Or organizational productivity?

In this post, I’ll be focusing on general strategies without specific scope. The application of these strategies to personal scope or an organizational scope look very different. I’ll allow you, the reader, to apply these strategies to your own context.

In most of these sections I will simply tell stories from my past experience.

Let’s dive into some of my favorite strategies to manage WIP.

Overview: A 10,000ft Look

• Visualize Work: Build a source of truth with quantitative transparency for yourself and others so the true magnitude and breadth of work can be appreciated and planned for.

• Define a Clear “Definition of Done”: Understand what it means to be “done”, and in some cases determine what is “enough”.

• Regularly Review WIP and Backlog: Keep priorities fresh and aligned.

• Ruthless Prioritization (and deprioritization): As important as it is to say “yes” to some work, it’s crucial to say “no” to more work.

A Closer Look at the 4 Strategies

Visualize Work

I remember at time at ExxonMobil where our team steadily became overwhelmed.

When we started, the work was manageable in loosely formatted team conversations. But after 1 year, our team was completely under water. None of enjoyed our work any longer.

What happened?

Ultimately, we weren’t aligned on what work was in our backlog.

We were operating an internal web-based platform for text-based competitive intelligence analysis. Our customers were all internal: sales, traders, marketers, etc.

At first, our task was to merely operate the tool and ensure it was available. This gradually transitioned into high-level consultations. Unsurprisingly, this escalated to building customized solutions for various personas.

The problem is that our team wasn’t organized well enough to handle the variety of work that sneakily expanded. And to make matters worse, this work was basically invisible, randomly tracked across each team member.

We accidentally lived the backwards mantra of stop stopping, start starting. Very obviously unsustainable.

(I know! I know! This was bad!)

How did we fix this?

I was the most junior member of the team. Either despite that or in-spite of that, I was eager to solve this problem.

I was convinced that our team needed to operate under the guiding principles of Kanban. More specifically, we needed to visualize our workflows and actual requested work. Without doing that, it would be impossible to manage work.

With encouragement from my manager, I led our global team through a value stream mapping exercise to begin modeling the operations of our team.

With our value stream map visualized, we could more easily classify the types of work coming to our team. This led to us creating a Kanban Backlog with proper classification of work type.

Now pause and look at what we have:

1. We understand our team’s operating model

2. We understand the type of work coming to our team

3. We’re aligned on #1 and #2 with common language

4. We built a visual backlog of work that was understood

Suddenly, we reduced the amount of concurrent work. We could divide and conquer effectively. Customers were happier with better transparency. We were happy to objectively set expectations.

Most importantly, we felt that we were in the driver’s seat again.

All this was made possible because of visualizing work. It was especially powerful because we combined value stream mapping with a meaningful backlog of work.

Define a Clear “Definition of Done”

The worst race is the race with no finish line.

Visualizing work is great. But if that work doesn’t have a finish line, you can never finish it. Your WIP runs the risk of perpetually growing. There will be constant confusion when to move onto the next thing.

The definition of done has some standard rules when it applies to engineering work.

But this principle of defining “done” is applicable to any type of work that needs to be broken down into smaller, manageable chunks.

Defining the definition of “enough”

Sometimes it is useful to define the definition of “enough”.

I’ll give a personal example that is very much not software engineering related.

My grandpa (passed away several years ago) was a master wood worker. He could build anything. Not only that, but he could create beautiful artistic carvings. He had the skills of both form and function nailed down.

I remember working with him in shop as a young boy. I cherish those brief memories.

He inspired me to learn wood working.

The only problem is….time.

I’ve got 3 young kids to be with, a wonderful marriage to nurture, a busy career to grow, and local volunteering to be a part of.

I need to manage my WIP across all these areas of my life. Ambitions don’t quite line up with energy and time.

Now I’ve got some options given those conditions:

1. Give up

2. Delay any effort to learn wood working

3. Define what is “enough” for this season of life

It probably isn’t hard to guess which one I’ve landed on: #3, defining “enough”.

• This is too much: Learn all the wood working possible!

• This is enough: Learn how to whittle small animals and people.

By defining my current definition of “enough” (or a soft measure of “done”), I can manage my life’s WIP while also including this new hobby on a semi-regular basis.

Regularly Review WIP and Backlog

Managing WIP is not a one-and-one job.

Managing WIP is the art building artifacts and designing processes to regularly monitor the pulse of your WIP at regular intervals.

The concept of a sprint and commercial Agile doesn’t always work out well, but the principles behind a scrum sprint. Managing WIP was one of the original ideas behind having sprints for engineering teams in the first place.

Every two weeks check-in on the team WIP and strategic alignment. Reset. Calibrate. Move forward.

You can apply this at a personal level with a weekly check-in for yourself.

This is also commonly applied at an organizational level, with varying levels of success. Although quarterly planning is the common rhythm of a business, I’m actually a growing fan of the 6-week Cycle from Basecamp.

Ruthless Prioritization (and de-prioritization)

When I was at Twitter, I was dedicated to a subsidiary of the company called MoPub.

It was a small organization relative to the number of customers it was serving. The constant challenge with this organization, which consisted of about 7 engineering teams and about 4 product managers, was slow throughput.

It seemed like we could never deliver fast enough.

Of course we could hire more to attempt an increase in shipping speed, but that doesn’t always work and it shouldn’t be the first answer.

My role as a TPM was to partner with the Engineering Director and Product Director to figure out how we can operate better and deliver faster.

After interviewing all the Engineering Managers and Product Managers (and most of the IC Engineers), it became obvious that there was a problem with prioritization and managing WIP.

Strategic Prioritization was a fairly overcomplicated process of scoring multiple ambiguous factors. (The spreadsheet would intimidate even the most senior Product Managers).

The process of prioritization was heavy. By the end of it, the teams didn’t feel any more confident because it was rare that anything was ever strictly moved to the “no” list. Instead, it was just given a lower score.

All the teams felt like they were chasing 20 different priorities at a time, with insufficient time to deliver on any of them.

What did we end up doing to fix this problem?

Product. Their goal: simplify.

The Product organization dove deeper on strategic prioritization methods to give engineering better clarity on our biggest and best opportunities.

We shifted from a heavy, overcomplicated process to a straight forward stack-rank based on cost of delay.

Engineering. Their goal: say no with quantitative data.

The next step was for engineering to pick up this list and run it through a hard capacity check. Across all teams and potential dependent teams, capacity was evaluated for these strategic priorities.

Eventually, engineering produced initiatives that were above-the-line vs below-the-line.

Said another way, a yes-list and a no-list.

The yes-list was always shorter than the no-list. The engineering and product organizations got better at saying no, which is more than half the battle when managing WIP.

If you’re able to ruthlessly prioritize (and deprioritize) in a unified way, that can be an organizational superpower.

TLDR

This follow-up to “Stop Starting, Start Finishing” introduces practical strategies to manage WIP, applicable at both personal and organizational levels.

Key strategies include visualizing work for clarity, defining a clear “definition of done,” regularly reviewing WIP and backlog, and ruthlessly prioritizing (and deprioritizing) tasks.

This post shares personal stories to highlight how these principles have driven productivity improvements in both personal projects and large organizations.

Mastering WIP management is the key to unlocking consistent progress and preventing the chaos of multitasking from derailing success.

A word from our sponsor…

Receive Honest News Today

Join over 4 million Americans who start their day with 1440 – your daily digest for unbiased, fact-centric news. From politics to sports, we cover it all by analyzing over 100 sources. Our concise, 5-minute read lands in your inbox each morning at no cost. Experience news without the noise; let 1440 help you make up your own mind. Sign up now and invite your friends and family to be part of the informed.

Sign up today!

Event

🎉 Speaking at the TPM Summit in October!

Excited to come back to share some thoughts on the intersection of Generative AI Prompting and TPM life! Get your tickets here.

If you’re attending, reply to this email and let me know so we can make sure to meet up! Connecting with people is a major reason why I started this newsletter in the first place.