I promised myself never again. Never again would I call a code-yellow. Code-yellows suck, drain team morale, and they leave a lingering distaste amongst all those involved. Yet, during my 8-years at Instacart, they were our most effective and consistent weapon in ensuring we made meaningful progress on our hairiest problems.

Yet, within the first year of Beacon’s life – I found myself sitting at my kids Tae Kwon Do competition (which was running 3.5 hours late!) on a Saturday writing an email to the team saying I wanted to meet immediately to call a code yellow regarding a major transition project we were working on with one of our first acquisitions.

What Is a Code-Yellow?

Code-yellow’s are thought to have originated at Google. During a code-yellow, a leader can escalate a project/situation to a war room situation, pulling people out of their day-to-day work to focus entirely on the problem at hand. It is alluring because it allows for existing plans to be deprioritized, removes any/all ambiguity around what is most important at the moment, and strongly encourages the team to sacrifice the ‘L’ and ‘B’ from Work-Life-Balance.

At Instacart, despite our best efforts to not have this be the case, we leaned on Code Yellow’s so aggressively that they became part of our standard operating cadence. We used this framework successfully to solve our seemingly existential problems:

• 2014: Fixing lagging growth when we experienced our first ‘slow down’ from hockey stick type (the infamous and expensive ‘Growth Initiative’ which likely warrants its own full post in the future)
• 2015: Going from losing ~$15/order to unit economic breakeven when we almost ran out of money
• 2016: Launching our initial advertising business to prove our path to profitability and catalyze an equity capital raise
• 2017: Signing the majority of major North American grocers onto our platform after Whole Foods Market, our biggest customer, was purchased by Amazon
• 2018: Scaling our infrastructure to keep the site up on Sunday’s (we were having constant outages every week)
• 2019: Building our fourth senior executive team in six years to lead us to the next plateau of scale
• 2020: Scaling from 100K shoppers to 600K shoppers in a 2-3 week period during the onslaught of COVID so that we meet the 5x surge in demand as the world went into lock-down

Why Code-Yellow’s Work?

As I reflected on why code-yellow’s had worked for us, and whether it would make sense to call one now at Beacon I decided to actually think, for the first time, why they work in the first place. And why they particularly work at startups. I realized that what we needed at Beacon was not the fear induced by a Code-yellow, but instead the motivation to Sweat The Problem Harder.

Code-yellow’s are effective because they force teams to sweat the problem harder. And if there is one reason startups make it, it is because they sweat the problem harder than anyone else. While incumbents rest easy on legacy momentum, startups don’t have that luxury. Survival means breaking down problems, attacking them from every angle, and turning what seems like chaos into rapid, gritty progress.

Sweating The Problem

Sweating the problem is not glamorous work, and it does not always feel like progress. It looks like relentless determination, a sharp focus, and the willingness to look downright foolish sometimes.

Here’s what it looks like when a team truly sweats the problem.

1) Removing The ‘Keep The Lights On’ Constraint

Constraints are the guardrails which are important to understand, but should not be viewed as fixed or permanent. They are like ice-bergs, there are the constraints we think we are imposing on a project (i.e. it will have 5 FTEs, it will get done in 3 months) but those are not the ones that are actually preventing a breakthrough. Under the surface constraints, the ones which are imposed almost unconsciously, are the most pernicious.

The biggest constraint I have seen teams imposing unconsciously is the ‘keeping the lights on’ fallacy. This manifests as the project team giving the project/goal 25-50% of their attention (although saying it is their main priority) because they feel that they need to continue ‘keeping the lights on’ with other work activities or projects. There are very few things at any startup that should be viewed as not immediately stoppable.

2) Running Multiple Paths in Parallel

Often, it is not the first or even the tenth idea that cracks the problem; it is a combination of tactics. Yet, I find that experiments to solve problems are often handled in sequential order.

The conversation goes something like this: We will try [solution A] because we think it will work. After we see if it works, we will try our next best idea, [solution B]. We have thought this through and have come with a decisive sequence of idea’s to solve this.

“Can we try doing both at the same time and see what sticks?”

Running solutions in parallel is not about indecision; it is about speed. The faster you can discard what doesn’t work, the sooner you uncover what does. It is about maximizing optionality in the shortest time possible.

3) Not Worrying About Scale

It is easy to worry about scale too early, but solving the immediate problem is often more valuable than trying to engineer a solution for 100x capacity right away. A founder friend used to say, “Let’s get to a point where scaling is a problem.” The logic? When you solve at today’s scale, you are nimble, faster, and less bogged down by premature processes. Scaling can always come later.

Worrying about scale too early is like a new startup worrying about being so successful that they would irk the FTC antitrust regulators. It is a problem that you need to earn the right to solve later.

4) Ignoring Whose Job It ‘Should’ Be

Working at a startup is not about staying in your lanes. Utilization is lumpy, and often, the best person to tackle a challenge is not the one with the traditional background for it. I remember when a finance team member took on writing a sales deck for a major retailer pitch (on a redeye flight to visit that retailer!) because he understood our fulfilment costs like no one else on the team did. If it is the most important thing, anyone who can solve it, should.

Why Is Sweating The Problem Hard In Practice?

The truth is, it’s uncomfortable.

• It requires hearing “no” and possibly looking out of your depth
• It requires asking basic questions, exposing yourself to looking stupid
• It demands client conversations before you feel “ready” — showing up in front of a customer without the perfect solution (or even a solution) can be daunting
• It requires challenging your day-to-day activities – and often realizing they are a waste of time
• And, there’s the ever-present lure of instant gratification — pivoting to small, easy wins instead of tackling the big/meaty problem which feels intractable

The discomfort, though, is part of the process. Working the problem isn’t just about getting the immediate result; it is about developing the muscle to tackle the next challenge, and the one after that. It builds grit, hones focus, and teaches resilience. When you solve problems this way, you don’t just walk away with a solution; you walk away with the confidence that you can handle whatever comes next.

I decided on that uncomfortable bench we didn’t need code-yellow’s at Beacon to make us sufficiently uncomfortable to solve our hard problems. At Beacon, we are not going to wait for the next crisis to sweat our biggest challenges; we will build a culture that makes Sweating The Problem our default.