"Keep it simple." It’s one of the most repeated directives in design, engineering, and product development—and one of the hardest to follow. Why? Because simplicity isn’t the absence of complexity. Instead, it’s the mastery of it. Simplicity is not where we begin; it’s where we arrive, often after traveling through a forest of complexity.

Take SpaceX’s Raptor engine, for example. The progression from Raptor 1 to Raptor 3 shows a clear evolution from a tangled, intricate design to a streamlined, elegant machine. But Raptor 1 wasn’t a failure of simplicity—it was a necessary step. It allowed SpaceX engineers to test, iterate, and refine the design through trial and error. Complexity was the scaffolding on which simplicity was built.

Another reason “Keep it simple” is so difficult is that simplicity doesn’t come from saying “no” or avoiding complexity—it comes from fully embracing complexity and learning from it. Teams naturally want to explore every possibility, solve every problem, and address every use case, and this instinct is vital. By tackling the full scope of challenges head-on, they uncover what truly matters and what can eventually be refined. Simplicity is not about cutting corners or prematurely narrowing the scope; it’s the result of working through the mess, understanding it deeply, and iterating until clarity and elegance naturally emerge.

Consider the early versions of Microsoft Word (queue the haters). They included nearly every feature imaginable—macros, formatting tools, drawing utilities, mail merge, and endless customizations. It was a kitchen-sink approach, not because the team was unfocused, but because they were embracing the unknown. These features were necessary to explore what users truly needed and how they interacted with the software. Over time, through observation, iteration, and learning, Microsoft refined Word into a more focused, streamlined experience. The introduction of features like the Ribbon toolbar in 2007 didn’t come from rejecting complexity but from deeply understanding it. By grappling with everything first, Microsoft arrived at a simplicity that works for both casual users and power users alike.

This principle applies even to physical systems. SpaceX didn’t streamline its Raptor engines by avoiding complexity; it embraced it first, learned what was essential, and ruthlessly cut the rest. If they’d tried to make Raptor 3 from the start, they would’ve failed—because without first embracing the mess, they couldn’t understand what could be simplified. Simplicity demands clarity, and clarity is born from wrestling with complexity. It’s not about making something easy; it’s about making something worth using. Teams that aim to “keep it simple” from the outset often fall into the trap of oversimplification—skipping steps, ignoring nuance, and ultimately creating something that feels shallow or incomplete.

Directing a team to "Keep It Simple" often feels like saying, "Make it perfect." It’s an aspirational target but not where the journey starts. Teams are inclined to add features, solve edge cases, and accommodate more scenarios. And honestly, that’s how it should be. You can’t simplify what you don’t fully understand. Simplicity isn’t the beginning of the process. It’s the endgame—it’s the longest, hardest road to get there. But when you do, the result is something that feels obvious, effortless, and inevitable—like it was simple all along.