David Ruttka

Engineering | Gaming | Improv | Storytelling | Music

FAQs on Airlines and Delivering Value

| Comments

I’ve gotten some interesting questions about the airline and grocer metaphor and my thoughts on delivering value rather than features.

Here I’ll try to fill in some of the gaps in how I wrote those posts. All along the way, in case I haven’t said this clearly before, remember that all teams are different. I’ve curated these thoughts across several teams and almost two decades, but even for me, it didn’t fit everywhere.

I’ll also update this post if additional questions come in, and I’ll put a log of updates in this spot whenever that happens.

Isn’t That More Work?

I can see how keeping the next right thing for the business on the top of the board optimizes for devs to self-serve when they need more work. Isn’t it a lot more work for project managers, though?

I’d ask two questions in return:

  1. Have you ever finished a bowl of oatmeal and left it next to the sink all day?
  2. Have you ever finished a bowl of oatmeal and rinsed it immediately?

One feels like less work in the moment, but you’re going to have a much harder time later. The other invests 10 seconds now to save a lot of friction (both figurative and literal scraping) later.

I am not proposing this methodology only from the perspective of a software engineer. I’ve also been in the tech lead and project manager seats, and this took roughly five minutes a day, often a no-op if the business needs had not changed.

Knowing exactly what work sits ahead of the team and letting devs self-serve by pulling from the top proved dramatically more efficient than pre-assigning days or weeks worth of work to individuals. It also gave us an immediate, realistic signal when communicating with customers about what’s Now, Next, or Later, and allowed us to effortlessly change the order if the customer provided feedback that a Later should actually be Next.

Let’s also get real about the time you’re already spending planning, replanning, re-replanning, doing math to balance work across the team, doing it again when reality didn’t fit your assumptions, shuffling work items between people, running bespoke queries to determine what to give a dev who says they’re out of work…

How or When Would We Even Start?

I can see how this works if we’ve already got the order established and we’re simply maintaining it, but we’ve currently got a real mess and don’t have time to clean it up. The oatmeal is already caked on, and we’re already struggling to keep up!

You’re struggling to carry a couch up ten flights of stairs by yourself. Someone is offering to join you with a dolly, and they’re pointing to the freight elevator. You’re replying, “Ugh, thanks. That looks amazing. Maybe I’ll try that someday, but for now I just really gotta get this done!”

You’re being given a deal through which you can invest $5/month for a $10/day return, and you’re refusing to skip one morning coffee.

What I’m hearing is that you’re too busy to consider improvements that have been proven, if only anecdotally, to yield exponentially greater returns.

And I’ve done that myself. Then I learned that change will always feel hard, often much harder than it truly is. The human brain perceives change as a threat, and will go to great lengths to avoid it. Let’s recognize what our brains are doing and make our best efforts to stay objective about what’s really involved here:

  1. We’re taking the time we spend calculating and pre-assigning today
  2. We’re acknowledging how often those predictions and assumptions are incorrect
  3. We’re taking the time we spend re-calculating and re-assigning each time business needs or team bandwidth changes
  4. We’re exchanging all of the above for simple, continuous adjustments that send clear signals to the entire team re: the truth of Now and Next.

We ultimately expend far less time and far less energy, and we eliminate the stress and urgency of a synchronous wait loop to figure things out in the moment of greatest need.

Too Many Work Items To Put In Order

Are you seriously asking me to constantly re-rank hundreds or thousands of work items?!

No. Sorry if this wasn’t clear, but there’s no need to rank all of the Laters… too much will change by the time we get to them anyway.

The methodology I’m proposing focuses on keeping the team executing on the most immediate needs of the business, and there’s a limit to how much the team can take on at any given time. Once we have enough items ranked to ensure that no one is idly waiting for their next assignment, we’ve gone far enough. Indeed, we’ve saved ourselves the churn of ordering all the things that are destined to be reordered next week, anyway.

There’s magic built into this, too. Work that does not carry sufficient impact automatically disappears from scope! If you don’t care enough to pull it into the ranked list, you don’t care enough to do it. Years ago, a conference speaker told a story in which the customer cut 30% of work from scope because ordering the stories made them realize how much they didn’t really want. I’ve later observed this myself. Order eats priority for breakfast.


My team should do this, but we need to wait until we’re sure we can do it right.

You will never hear me propose a wholesale transition to perfection. Continuous improvement, starting from the now, will always win against the deferred perfection that never comes. With that, each step can be as small or large as you do have time for today. The gains from even the smallest investment will snowball rapidly.

My most successful teams made time for regular retrospectives that went beyond a 15 minute “Mad, Sad, Glad” exercise. This helped us target the right process improvements to make relative to current conditions and committments.

We’ve also found it helpful to take the following approach:

  1. spec out the goal state as bullet points
  2. highlight the bullet points the team already does well in green
  3. highlight the ones the team has started but not perfected in yellow
  4. highlight the ones the team hasn’t touched in red
  5. decide as a team which yellow to turn green, and/or which red to turn yellow
  6. hold each other accountable until that happens
  7. repeat

Save me, SME

Telling the team to pull the next right thing assumes that everyone has the same strengths, context, and experience. In the airline analogy, how you do handle oversized baggage that not all agents can handle?

Fantastic question. On a similar note, Eric Brechner recently posted an insightful take on delegation that made me rethink a lot of my airline versus grocer metaphor.

There is absolutely a place for subject matter expertise, and we do need to consider whether work may be performed more efficiently by a person who has the deepest understanding and context.

Backups and shadows make a lot of sense. Even one backup has doubled your team’s resilience in that subject area, avoiding a disaster if the One True Hero gets sick or leaves the team. But even then, what happens when there’s more urgent work in that area than those two can reasonably take on in a sprint? Is this the bottleneck you signed up for when you chose silos over knowledge share and cross-training?

Here’s how we handled it in the past. If a person doesn’t feel capable of handling the next top item, trust their judgment to take the second instead. Maybe even the third. If they’d need to go to the fourth, heed the smoke alarm! The process screams at you, “You have not enabled your team to carry out the needs of the business!”

It’s at this moment that we intentionally decide to invest in our team’s success to accelerate business impact. Whether that’s pairing, a ramp-up session, or (you tell me some other options), the business slows down until you clear this roadblock. Spoiler: regular pairing and internal tech talks give your team a tremendous head start on these fire drills… but that’s another post.

The other option, for teams or organizations where there truly is deep specialization, is to apply the same “next right thing” approach to each subject area. SMEs pull from the ordered list of work that fits their specialized domain, reverting to the generalists’ queue if that runs dry.