Squishy vs. Load-Bearing Projects (or: How Not to Flatten Innovation)

A tragic experience at work is to share an idea you're excited about, get a genuinely enthusiastic response from your team, and then look on in horror as folks gather around to bludgeon it to death with The Process™.

The idea never has a chance to gain momentum or make any meaningful progress — it's dead before it starts because it collapsed under the weight of a full team's worth of process.

Establishing vocabulary: the squishy-to-load-bearing project spectrum

Projects happen on a spectrum, with mature, well-established work at one extreme that we'll label "load-bearing" and the Galaxy Brain wouldn't-it-be-cool-if ideas at the other extreme, which we'll label "squishy".

Projects that affect critical areas are load-bearing.

A load-bearing project has tons of context, research, preexisting requirements, and non-negotiable contracts that need to be accounted for and handled properly. They're much less likely to shift drastically as new information comes in.

At Netlify, when we want to roll out a new feature to our build system, we have to be extremely careful not to introduce bugs for existing workflows — we have dozens of coworkers and over a million developers counting on Netlify being stable.

Load-bearing projects need thorough, cross-team processes. Shipping changes to something that lots of people rely on needs to happen safely, and safety is created by adding lots of checks to the process. Each involved team has checklists, and all of those checklists need to be signed off at each stage before the project moves forward.

Exploratory projects are squishy.

At the other extreme are squishy projects that still need a lot of fleshing out. For example: I have a project I want to tackle for Learn With Jason that will allow live viewers to move a tiny submarine with my face on it around the screen. That's the entirety of my progress on this project so far.

Squishy projects don't always have a clear path forward. These are the projects born out of hunches, something we heard a customer say, or a question that we think it would be valuable to answer.

At its squishiest, a project can be an effort to define what we meant when we took a screenshot of a tweet thread and said, "I think there's something important in here". It's necessarily ambiguous because the bulk of the work of a squishy project is to try and desquishify it with definitions and direction.

Squishy ideas are too fluid to survive rigid processes, and that can lead to them being dismissed — but skipping squishy ideas is a huge, costly mistake.

Processes are not one-size-fits-all

As teams and projects grow, the need for process grows as well. More and more projects become load-bearing, more people are working on them, and it becomes extremely important that everyone follows a process to ensure that nothing slips through the cracks.

However, even the largest teams will have squishy projects. And when a squishy project gets hit with a load-bearing process, it tends to get flattened entirely.

Sometimes we need to go slow to go fast.

By putting solid processes in place for load-bearing projects, we gain confidence that the work we're doing will be shipped safely and without creating more work to clean up accidental messes. Despite feeling like the process adds time to a project, the net effect is that projects get completed faster because we're not losing time to mistakes, reworking to handle things we forgot, and other sneaky time thieves that solid processes help avoid.

But sometimes we need to go fast to go fast.

As frustrating as they can be, squishy projects are a necessary part of learning. Chasing down a hunch is an important way for teams to innovate. Asking a question and setting out to find an answer is valuable work that helps identify new opportunities (and, perhaps more importantly, enables us to say no to things because we explored them enough to know they're not a good match).

If we try to apply rigid processes to squishy projects, we end up spending a lot of energy trying to fit ambiguous work into unambiguous boxes. Processes only work when we have a clear path between where we want to go and where we are now. The more question marks that exist in a project, the more likely it becomes that we'll end up changing direction, reimagining part of the plan, or otherwise altering the project in ways that grind processes to a halt.

So, what? Squishy projects are just "no parents no rules"?

My argument to this point makes it sound like I'm advocating for a free-for-all when it comes to squishy projects. That's not the case — I'm arguing for minimal in-flight process to make it easier to explore and adapt, balanced out by much larger guard rails around what a squishy project can affect.

In the broadest possible strokes, squishy projects should make a trade-off: the amount of formal process is limited to allow for exploration and rapid change, and risk is minimized by limiting the audience that will see it. Squishy projects become a research tool to inform load-bearing project planning.

Fewer stakeholders and less process — but also a short leash.

Put another way, a squishy project doesn't end up widely shipping to customers. Instead, a squishy project explores a potential product direction to validate it with a small test group. The research and feedback provided by the small test inform a largely desquishified next project that can be built with more process and the intention of shipping much more widely.

A squishy project is less restricted by in-flight process and (ideally) has significantly fewer stakeholders — in a perfect world, only one or two — to allow for rapid exploration, iteration, and execution. By restricting it to only a small test group, risks are contained and the team doesn't need to worry that a squishy project will create technical debt, pager duty, or other expensive, stressful problems.

Desquishing becomes part of the process.

You may have picked up on this already, but restricting squishy projects to small tests that are used to informed more structured projects is, in fact, a process. But an important distinction is that it's a process that supports squishy ideas instead of flattening them.

And, just as importantly, this process wouldn't be very successful if applied to a load-bearing project.

Does this matter? Why is this valuable?

Shaking up processes to accommodate squishy projects is a significant effort, so why should we bother at all? It can be tricky to draw a direct line between this kind of work and value, profits, growth, or whatever metric drives decisions at the leadership level. However, creating the space to not only allow, but nurture squishy projects has a huge impact on the bottom line.

Squishy projects are where innovation comes from

Having the space to chase down a hunch, implement a long-standing, hard-to-prioritize customer request, or validate a big idea is how companies create value. There's a reason that there's a stigma attached to "design by committee" — it's extremely hard to create new things in large groups. By giving squishy projects to small teams and reducing the amount of process hurdles they have to clear, they're given the space and freedom that helps them shape a new idea into something that can withstand a more formal process.

Without support for squishy projects, your company might be suffocating innovation.

Squishy projects save time and money

Building something is expensive. It costs time, attention, and money. How much does it cost to have a team of 15 people work on something full time for a month? And if that project doesn't work out, how much did it cost to not be working on the thing that was the right idea?

Squishy projects remove a ton of cost by reducing the scope and the team size required to validate an idea. A team of two or three can quickly prototype something that's at least 80% of what the full team could create, and they can likely build it significantly faster.

Rolling that prototype out to a small test group provides actual research data that tells you whether or not this project is going to pay off. If it turns out to be a good idea, the squishy project provided inexpensive validation of a good idea and makes it easier to justify putting the full team on it. If it doesn't work, you're only out a week or two of time from two or three team members vs. a month from the full team.

Squishy projects provide valuable data, avoid expensive mistakes, and lower production costs.

Squishy projects declutter the product roadmap

A huge challenge in every company I've come into contact with has been prioritization. How does something get on the roadmap? How do things get prioritized?

Squishy projects help provide concrete data to inform roadmap design. By quickly launching prototypes to small test groups, the company is able to get actual data from actual customers that shows the impact of a given project. This can simplify the roadmap process, because the projects with the highest impact on the most critical areas of the product can be prioritized easily: there's data to back up those decisions!

Additionally, this helps avoid the problem where every idea gets put on the high-priority list, because all unvalidated ideas can be put on the squishy list to be prototyped and validated.

Use the right process for the current project

Our goal is always to get things done as quickly as possible with as little duplicate work and risk as we can manage. To do that effectively, we need to balance our need to innovate and explore squishy ideas with keeping the load-bearing parts of the company healthy.

This means adapting our processes to support projects at both ends of the spectrum: less process, fewer stakeholders, and smaller test groups for squishy projects, and more stringent processes and stakeholder checkpoints for load-bearing projects that will reach general availability.

By letting squishy projects quickly prototype ideas and gather feedback, we can make better choices about which projects get prioritized for the heavier investment that goes into bringing the full team and process onboard.

Embracing the full spectrum of squishy to load-bearing projects enables the company as a whole to move faster without losing the ability to experiment and innovate.