The KISS principle , Keep It Simple, Stupid , originated as a design philosophy, most often attributed to Kelly Johnson at Lockheed’s Skunk Works. The idea was that a jet aircraft should be repairable by an average mechanic in field conditions with basic tools. If the design was too complex for that, it had failed regardless of how elegant it looked on paper. I’ve found that this framing is far more useful than people give it credit for, and not just in software architecture or product design. The principle applies with equal force to how we structure organizations, communicate strategy, and decompose business problems. In fact, I’d argue that the ability to simplify is one of the most underrated skills a technology executive can develop.
There’s a reason simplicity is hard, though. It requires a deeper understanding of the problem than complexity does. Anyone can add layers : more process, more roles, more abstractions, more slides in the deck. Removing layers demands that you truly understand what’s essential and what’s incidental. I’ve seen this play out dozens of times: a leadership team confronted with a messy business problem will instinctively add structure to manage the mess, when what’s actually needed is the courage to cut through it. The best executives I’ve worked with share a common trait : they can take a sprawling, ambiguous situation and reduce it to a small number of things that actually matter. That’s not oversimplification. That’s clarity.
Simplicity in Organizational Design
Org design is one of the areas where the KISS principle pays the highest dividends and is most frequently ignored. When companies grow, they accumulate organizational complexity the way a ship accumulates barnacles : slowly, one reasonable decision at a time, until the drag becomes significant. Every dotted-line reporting relationship, every matrix structure, every committee that exists to coordinate between other committees adds cognitive overhead for the people doing the actual work. I’ve found it useful to periodically ask a brutally simple question: can every person in the organization explain who they report to, what they’re responsible for, and how their work connects to the company’s goals? If the answer is no, your org design has become too complex.
This doesn’t mean org structures should be naive or flat for the sake of flatness. There are legitimate reasons for complexity : regulatory requirements, geographic distribution, the need to balance functional expertise with product alignment. The point isn’t to avoid all complexity but to ensure that every layer of complexity is earning its keep. Some practical ways I’ve applied this:
- When adding a new team or role, articulate what specific problem it solves that cannot be solved by an existing team or role. If you can’t do this in one or two sentences, that’s a signal.
- Favor clear ownership over shared ownership. Shared ownership sounds collaborative but in practice it often means no one is truly accountable, and accountability gaps create more organizational complexity down the road as people try to compensate.
- Revisit org structures at least annually with fresh eyes. What made sense eighteen months ago during a rapid scaling phase may be adding unnecessary friction now.
- Be wary of creating coordination roles to manage the complexity caused by other coordination roles. This is a classic sign that the underlying structure needs to be simplified rather than managed.
Communicating Strategy with Clarity
The second area where simplicity proves essential is communication, particularly when rolling out new strategies or plans. I’ve observed a pattern throughout my career: the leaders who have the deepest understanding of a strategy are the ones who can explain it most simply. Conversely, when a strategy presentation requires forty-five minutes and thirty slides to convey, it’s often because the thinking behind it hasn’t been fully resolved. Complexity in communication frequently masks uncertainty in thought. This is worth being honest with yourself about : if you can’t explain your plan simply, you may not understand it well enough yet.
There’s a practical dimension to this as well. When you communicate a plan to your organization, every person who hears it will interpret it through the lens of their own role, their own concerns, their own priorities. The more complex the message, the more surface area there is for misinterpretation. I’ve found that the most effective strategic communications share a few characteristics:
- They can be summarized in a single sentence that captures the why, not just the what. “We’re consolidating from three platforms to one because our customers need a unified experience and our engineers need to stop maintaining redundant systems” is far more useful than a detailed migration roadmap.
- They use concrete language rather than abstract terminology. “We’re going to reduce our time-to-deploy from two weeks to two days” lands harder and more clearly than “we’re investing in operational excellence.”
- They acknowledge what’s not changing alongside what is. People absorb change more effectively when they have stable reference points.
- They’re short enough that a manager three levels down can relay them accurately without a script.
Decomposing Problems to Their Essence
Perhaps the most valuable application of the KISS principle is in problem decomposition. The business problems that land on a CTO’s desk are almost never simple on their surface : they involve competing priorities, technical constraints, organizational dynamics, and market pressures all tangled together. The instinct in these moments is to try to solve the whole thing at once, to build a comprehensive plan that addresses every dimension simultaneously. I’ve learned, sometimes painfully, that this instinct is almost always wrong. The better approach is to break the problem down until you find the smallest meaningful pieces, then solve those pieces in sequence.
This is where the word “stupid” in KISS actually earns its place. It’s a reminder that our tendency toward complexity is often an ego-driven behavior : we want to demonstrate that we understand how complicated things are, that we can hold all the variables in our heads at once. But the mark of genuine expertise isn’t the ability to manage complexity; it’s the ability to eliminate it. When I encounter a problem that feels overwhelmingly complex, I force myself to answer three questions: What is the single most important outcome we need? What is the smallest action that moves us toward that outcome? What can we explicitly choose to ignore for now? Those three questions have saved me from building elaborate solutions to problems that didn’t require them more times than I can count.
Simplicity is not a destination you arrive at ; it’s a discipline you practice. Systems, organizations, and strategies all tend toward complexity over time because every individual decision to add something feels reasonable in isolation. The accumulated weight of all those reasonable decisions is what eventually slows companies down. The executives who keep things simple aren’t the ones who avoid complexity; they’re the ones who are vigilant about pruning it, who understand that every layer they add creates a maintenance burden that extends far beyond the immediate problem it was meant to solve. In my experience, the best technology leaders treat simplicity not as a nice-to-have but as a responsibility : to their teams, their customers, and to the future version of the organization that will have to live with today’s decisions.