KISS Principle

Lockheed's engineering teams during the mid-20th century worked under a constraint most modern organizations would recognize: build something that works reliably, under pressure, without the luxury of endless refinement. Kelly Johnson, the engineer who led the Skunk Works division and shaped aircraft including the P-80 Shooting Star and the SR-71 Blackbird, set a working standard for his teams that a mechanic with ordinary tools and modest training should be able to repair the aircraft in the field 1 . That standard became shorthand for a broader discipline: design for the actual requirement, not for the impression of thoroughness. The phrase Keep It Simple, Stupid (KISS) followed and it has outlasted the aircraft programs that produced it because the underlying problem, unnecessary complexity, shows up in strategy, process design and product development just as often as it shows up in engineering.

The origin and the discipline behind the acronym

Kelly Johnson's approach at Skunk Works was not a preference for minimalism as an aesthetic choice. It was a response to a specific operating condition: aircraft built for combat needed to survive field repair by technicians without engineering degrees, under time pressure, often without spare parts readily available. Complexity in that context was not a neutral cost; it was a failure risk measured in downed aircraft and delayed missions. Johnson's famous 14 rules for the Skunk Works organization emphasized small teams, few approval layers and direct authority for the chief engineer, structural choices that removed friction from decision-making as much as from the aircraft itself. The lesson that generalized beyond aviation is that simplicity should be judged against a defined requirement, not against an abstract ideal. A design is not simple because it has few parts; it is simple because it has no more parts than the problem demands. That distinction matters because organizations rarely add complexity carelessly. Each additional approval step, feature or reporting line usually has a reasonable justification attached to it. The failure is cumulative, not individual and correcting it requires re-testing the whole system against its actual purpose rather than defending each piece in isolation.

Why complexity accumulates inside organizations

Complexity rarely enters a business through a single bad decision. It enters through many small, defensible ones: a control added after an audit finding, a custom report built for one client, a workaround kept because removing it feels riskier than living with it. Harvard Business School lecturer Ron Ashkenas has documented how large organizations drift into structures where "performance is declining, accountability is unclear, decision rights are muddy", a condition he attributes to accumulated layers rather than any single cause 2 . His research pointed to ConAgra Foods, which by the mid-2000s had grown into a collection of more than 100 semi-autonomous brands without common reporting systems, a structure that made the company harder to govern even though every individual brand decision had made sense at the time it was made. The pattern repeats across industries. A product team adds a configuration option because one customer requested it, then another, until the interface requires a manual to operate. A finance function adds an approval step after a control failure, then never removes it once the immediate risk has passed. None of these additions looks unreasonable on its own. The organization only sees the cumulative cost when someone tallies the total number of steps, options or exceptions and compares that number against what the underlying task actually requires.

Applying KISS to strategy and operating models

Strategy work is particularly prone to complexity because ambiguity feels safer than commitment. A strategy document with many qualified priorities, contingent scenarios and framework layers can look rigorous while giving frontline managers nothing concrete to act on. A useful test is whether a manager two levels removed from the strategy's authors can restate the priority from memory and explain what it rules out. If the answer requires consulting the document, the strategy has grown too complex to function as a decision tool. McKinsey's consumer goods practice has examined this trade-off directly in product portfolios, where companies frequently discover that a large share of complexity, in SKU counts, packaging variants or regional formulations, contributes little to revenue while adding disproportionate cost to manufacturing and supply chains 3 . The finding is not that complexity is always wrong; some variation genuinely serves different customer segments. The finding is that most organizations never test which complexity earns its cost and which persists out of habit. Applying the KISS principle to an operating model means running that test deliberately:

list every variant, exception or approval layer, attach it to the requirement it serves and remove anything that cannot name one

Simplicity as a design filter, not a cutting exercise

A common misreading of the KISS principle treats it as permission to cut features or steps without analysis. That is not simplicity; it is neglect wearing simplicity's reputation. The discipline runs the other direction. Every element in a design, whether a product feature, a process step or a policy clause, should have to justify its presence against a defined requirement before it earns a place. Complexity that survives that test is not the target; complexity that cannot name a requirement is. This distinction traces back further than Kelly Johnson. The medieval principle known as Occam's razor holds that among competing explanations, the one requiring fewest assumptions is generally preferable, not because simple explanations are automatically true but because unnecessary assumptions carry their own cost in error and confusion 4 . The KISS principle applies the same logic to design rather than explanation:

among solutions that meet a requirement, the one with fewest moving parts is generally preferable, because each additional part is a place where something can fail, confuse a user or add cost to train and maintain

Simplicity in product and service design

Product and service design offers some of the clearest examples of the KISS principle in commercial use. Steve Jobs pushed Apple's design teams toward removing buttons, menus and configuration options long before minimalism became a marketing trend, arguing that simplicity required understanding a problem deeply enough to know what could be left out 5 . That discipline showed up in decisions such as the original iPod's click wheel, which replaced a grid of buttons with a single control and in the iPhone's decision to remove the physical keyboard entirely rather than shrink it.

Simple can be harder than complex: you have to work hard to get your thinking clean to make it simple

The same discipline applies to services and internal tools that never reach a customer. A reporting dashboard with forty metrics serves fewer decisions than one with the five metrics a manager actually uses weekly, even though the forty-metric version looks more comprehensive in a demo. A consulting deliverable with a dense framework of quadrants and sub-frameworks can obscure the two or three decisions the client actually needs to make. Judging design quality by apparent thoroughness rather than by decision-usefulness is a common trap and it is the trap the KISS principle is built to catch.

Practical guardrails for applying the principle

Executives who want to apply the KISS principle systematically, rather than as a slogan, need a small number of concrete practices. First, write the actual requirement before designing the solution: what must this process, product or policy accomplish, stated in terms a frontline employee would recognize. Second, treat every addition to a design as a proposal that must name the requirement it serves, not an automatic improvement. Third, periodically audit existing systems against that same standard, since complexity that was justified when added often outlives the condition that justified it. Forbes contributors advising business owners on operational simplicity have made a related point: simplicity has to be designed deliberately because organizations left unmanaged tend to add complexity by default, never subtract it 6 . That asymmetry, where adding requires only a single approval but removing requires someone to argue against the status quo, explains why complexity accumulates even in organizations staffed entirely by capable, well-intentioned people. Counteracting it requires making removal as easy to propose as addition and holding both to the same standard:

does this serve the actual requirement, or does it just look responsible

• 1missions impossible: the skunk works story
• 2simplicity-minded management
• 3simpler is (sometimes) better: managing complexity in consumer goods
• 4what is occam's razor?
• 5how steve jobs' love of simplicity fueled a design revolution
• 6make your business better by applying the kiss principle