Enterprise Strategy

Shipping under constraint.

During COVID, the obvious move was to build our own contact-tracing app. We didn't. On deciding what not to build, and why coaching teams beat building expertise.

Brandon Harris · Essay · 5 min read

Share
Two neighbors cutting up a storm-felled oak across the street while a man on the curb holds a hand-drawn map and points down the block

After a storm, a big oak comes down across the street. Two neighbors already have their chainsaws going. A third neighbor doesn't own one, and he has a choice. He can drive to the hardware store, buy a saw, read the manual on the curb and start cutting. Or he can walk the block. Find out who else has a saw. Who has a truck to haul the wood. Which driveway has to be cleared first, because the nurse who lives there has a shift at six.

The second choice gets the street open faster. It also means he never cuts a single branch, and nobody takes his picture. That part is hard to accept, especially for people who like to build.

During COVID I was on the partner track at Guidehouse, where I'd evolved the innovation lab into an incubator and a rapid-response capability. The CDC used that capability to create contact-tracing app guidelines (how those got written in about a week is its own story, in "A week to write the rules"). Alongside that work, a very tempting question landed on the table. Should we build the app ourselves?

The app we didn't build

We talked about it a lot, internally. Should we build an app? Build technology at all? How should we get involved? What would be helpful and impactful, and what could we actually excel at?

We decided not to build it.

Distribution settled most of it. The infrastructure for getting software into people's pockets quickly already lived with the companies that had it: Apple, and Salesforce on the software side. A brand new app from us would have needed people to find it, trust it and get familiar with it, in the middle of a pandemic. The companies that already had distribution could skip all of that.

Then time. We had none to ramp up. You don't hire and train a mobile team while the thing you're responding to is moving every day.

And then honesty about what we were good at. The firm didn't have deep expertise in building mobile apps, or in integrating with a phone's physical systems, to move quickly and decisively. Could we have learned? Probably. Not that month.

So our place was making connections, finding ways to get it done and defining what should be done. Other people would build. The guidelines went on to be used by Apple, Samsung, Salesforce and many others. An app of ours would have been one more icon on a crowded home screen.

Saying no is a product decision

Under pressure, most teams pick the work that feels like progress, and building feels like progress. You can point at it. You can demo it. Defining the work and connecting the right people feels like talking, right up until you notice it's the reason the builders are building the right thing.

The question that did the most work for us was the last one on that list: what could we excel at? Asked honestly, it rules a lot out. If someone else already has distribution, your build starts from behind. If your team needs months to ramp, the moment may be over before you ship. If the core skill isn't in the building today, you're betting on learning it under a deadline.

You see the same pull far from any pandemic: the platform team that wants to build its own analytics stack, or the startup writing its own billing system instead of shipping the product people pay for. The neighbor with the new chainsaw feels busy. The street stays closed.

Smaller, focused, outcome-driven

The same habit sat under the biggest number from that practice, which also carried U.S. Army and Department of Defense innovation programs worth more than $100M, with many vendors involved. Across the practice, zero-to-one launches got 70% faster.

Nobody got smarter overnight. We built smaller, focused, outcome-driven value. Experiments were part of it. The bigger part was a better way of finding the key opportunities and the key risks, getting clear on what we were trying to accomplish, and getting a lean picture of what was valuable and could be done in a short time. Then building from there.

The bigger shift was in what we thought our job was. The usual consulting move is to find someone, build up a lot of context and expertise, and then build what the experts think matters. We went the other way. We focused on becoming a great incubator as opposed to just a great innovator: getting really good at coaching teams to quickly identify what's important and build what matters.

That's the neighbor with the map again. Expertise you have to build before you can help is a ramp, and a ramp is exactly what a crisis won't give you. Coaching a team to find the key risk and build around it works the first week, and it keeps working after you've moved on to the next street. "An innovation lab is not an incubator" goes further into why those are different jobs, and why they need different people.

Where the metaphor breaks

A storm ends, and the neighbor with the map goes back to his own yard. In a company, the decision not to build keeps costing you something. The team that builds gets the launch, the logo and often the revenue. The team that defined the work and made the connections has to be comfortable being less visible, and leadership has to know how to count what it did. If leadership can't, people learn the lesson and go buy chainsaws.

And sometimes you should buy the saw. If storms keep coming and clearing trees is going to be your work for years, learn it. Saying no was right for us because mobile apps weren't the firm's core work and the moment couldn't wait. A capability you'll need for the long run is a different decision. Ask both questions: who already does this better, and is this something we need to own?

Try this

  1. Take the biggest thing your team plans to build next. Write down who already has the distribution to put it in front of people.
  2. Write how long your team would need to ramp up to build it well. Put that next to how long the opportunity will last.
  3. Name the core skill it needs. Be honest about whether you have it today, not next year.
  4. If those answers go against you, write what your team would do if someone else built it: who you'd connect, and what you'd define for them.
  5. Pick one team and spend a month coaching them to name the key opportunity and the key risk before they build anything.
GovernmentHealthcare250 to 1,000 people1,000+ peopleProductStrategyOperationsDecisionsFocusPlatforms

Share

Under a deadline and tempted to build it all yourself? Tell me what you're deciding not to do.

Read next

All writing