Ruthless Prioritization

May 17th, 2021, by Michael Nadel, Director of Product Engineering

Our product manager, Alisa, pulled the andon cord. “We aren’t going to ship this on time if we don’t change something.” She was right — the single most important thing we should be working on wasn’t getting the attention it needed. In our decentralized organization it can be challenging to remain focused. Folks need to contend with many signals and competing priorities.

Yet, we knew the team was capable of shipping this important feature. Alisa’s insight was that daily distractions were keeping us from our goal. We hypothesized that with hyper-focus and ruthless prioritization we could ship this feature on time.

That evening Alisa drafted a plan. What were our distractions? How can we create the space needed for folks to focus on our one true priority? We collaborated on a document that we’d present to the team. The next day we got the team together for a reset.

What follows is the agenda from that meeting, along with some fresh commentary. The indented quotes are taken nearly verbatim from the document we discussed with the team.

The Situation

We wanted folks to have the full context of why we needed a reset. We noted that what we were currently working on was important…but not the most important. We discussed the risk to our business if we were unable to ship this particular new feature by that July.

Challenges

We shared observations of things that were contributing to dragging down velocity. It was clear that the team was busy doing valuable things, but we were not making progress on our highest-priority initiative.

• Our team gets pulled into a bunch of small tasks unrelated to our one true priority.
• Some Jira tickets are BIG but don’t have to be. There were times when Product would have been fine with a smaller — but still valuable — solution.
• For the thing we are currently working on, we painted ourselves into a corner by being unable to release it incrementally. Mike takes full responsibility for this.

The Road Ahead

We need to finish alpha, beta, and 1.0 to get this important feature to all customers in 33 working days. Time is fixed. Scope is variable.

Next we discussed what we needed to accomplish. “Alpha” referred to shipping the work in progress. The next feature — the most important thing for us to be working on — would be built on top of alpha’s foundation. We defined “beta” as an MVP release of our one true priority. It would be released to a handful of customers who opted in. And, finally, the “1.0” release would incorporate feedback from beta into a release for general availability.

We Got This!

We can do this! In general, all we need is razor-sharp focus and ruthless scope management. This hyper-focus period is what being in a startup is all about! It’s invigorating as we push to deliver something super valuable.

This reset was a rallying cry around the priority, not an incrimination of anyone or anything. We wanted to encourage the team and empower them to be successful. We knew the goal was within reach with hyper-focus and ruthless prioritization.

The Plan

Our instincts told us that the most valuable thing we could do for the team was to create the space they needed to achieve deep focus and to be able to deliver incrementally. Alisa and I presented some ideas to seed a discussion.

• A TICKET ISN’T A SPEC. A DESIGN ISN’T A REQUIREMENT. Every time a ticket is picked up, talk it through with Product. Let’s figure out the minimum amount of work to deliver value.
• If a ticket looks like it’s going to take more than 0.5 days…talk to Product! See above…maybe we can simplify even more!
• Full team Zoom calls from 1pm-5pm everyday. There could be breakout rooms for anyone who is pairing. This would allow for continued conversations between team members and product.
• Leave distracting Slack channels. PLEASE ignore (better: leave!) channels where we get pulled into bugs/issues/functionality questions. Mike will monitor Slack and you’ll be @’d and rejoined if something’s more urgent/important than our one true priority.
• Push all extraneous work to Mike. If someone asks for help on something, tell them you are heads-down on something and refer them to Mike.
• Effectively immediately you are all relieved of your on-call duties; Mike will be the permanent on-call until we release 1.0.

A Sense of Purpose

To illustrate how important this feature is: not even site outages should distract us from working on the one most important thing we need to be working on: this feature.

We needed folks to be vigilant about things that could distract us from our priority. The goal, to quote Kimber Lockhart, wasn’t to create a sense of urgency, but rather foster a sense of purpose. Ruthless prioritization is hard work. Urgency might let you sprint, but great teams run marathons together.

It’s worth noting that Drip takes uptime (and site operations, more generally) very seriously. We have five on-calls at all times: four engineers and a senior/executive-level engineering leader. This statement was communicating to the team that should something as critical as a site outage occur, the rest of the engineering team has got their back.

We Definitely Got This!

We wanted to end on a high note. We knew the work would be intense, but also knew that with hyper-focus and ruthless prioritization we could accomplish the impossible.

This will be fun! We’re gonna turn the dial to 11, and there’s nothing better than being in the zone, doing what you do best. We’ll also come up with milestones (i.e. alpha, beta, 1.0) that will be celebrated w/ either food or gift cards — your choice.

Outcome

Ruthlessly prioritizing and remaining hyper-focused isn’t easy. Drip’s culture is one that values extreme ownership. Ruthless prioritization, however, means there was a whole host of important things that we explicitly chose to not do or to defer. Creating space for the team to focus also meant buying them the social capital to not feel guilty or be ostracized for making those hard choices. It takes a village, and we needed the entire organization to understand the tradeoffs we were making. Alisa and I worked with Success, Marketing, Product, and Engineering to help everyone understand why the team was focusing on keeping a single ball in the air.

So? Where did we land?

Well, a week into executing this new plan, one of the developers on the team took a month off for paternity leave. The team has only four developers, so we were down to 75% capacity. Additionally, this reset occurred a few weeks before Memorial Day. We all had the day off, which meant another week operating below our ideal capacity.

Given the circumstances, it would have been understandable if we missed the goal. In fact, in many organizations, it’d have been a miracle to hit it.

But here’s the thing. Not only did we hit it … we crushed it! We landed 1.0 two weeks early. And then shipped version 2.0 in that same original timeframe! Those 33 days were intense, but we didn’t work a single hour of overtime. As Lee Iacocca once said, “I hire people brighter than me and then I get out of their way.”

back