CTO – CTO Mindset

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.

One of the most destructive mental patterns I’ve observed in technology leaders, and one I’ve fallen into myself more times than I’d like to admit, is the belief that relief is just around the corner. If I can just get through this launch. If I can just close this quarter. If I can just navigate this reorg, hire this key person, resolve this production incident, get past this board meeting. Then things will calm down and I can finally breathe.

This thinking feels rational in the moment. It’s a coping mechanism, a way to endure difficulty by promising ourselves a future reward. But it’s fundamentally flawed because it’s built on a premise that almost never holds: that the current pressure is an aberration, and that normalcy, some sustained period of calm, is waiting on the other side.

The Treadmill of Relief That Never Comes

In my experience, the work never ends. Not in any role worth having, and certainly not in technology leadership. The nature of our work is that we’re building things that don’t exist yet, solving problems that haven’t been solved before, and operating in markets that shift constantly. There is no steady state. The moment one major effort concludes, another emerges to take its place. Sometimes it’s already been waiting in the wings; sometimes it materializes from nowhere.

When you orient your entire mental and emotional framework around the idea that you just need to survive until the current crisis passes, several harmful things happen:

You give yourself permission to operate in an unsustainable way, burning reserves you’ll need later
You defer recovery, relationships, health, and reflection to a future that keeps receding
You experience the completion of each effort not as satisfaction but as brief respite before the next wave of anxiety
You train yourself to associate your work with suffering rather than meaning

I’ve watched executives operate this way for years, always on the verge of a breakthrough to some calmer existence. They become brittle. Their judgment suffers because they’re perpetually depleted. And perhaps most tragically, they miss the actual experience of their professional lives because they’re always looking past the present moment to some imagined future relief.

Finding Satisfaction in the Process Itself

The alternative is not to pretend the work is easy or that every day is enjoyable. Some days are genuinely hard. Some problems are genuinely draining. The alternative is to recognize that the texture of difficulty is the texture of the work itself, and that meaning has to be found within it rather than after it.

This requires a fundamental reorientation. Instead of asking “when will this be over?” you have to ask “how can I be present in this?” Instead of treating each challenge as an obstacle between you and some peaceful future, you have to see the challenge as the thing itself: the actual substance of what you’ve chosen to do with your professional life.

I’ve found that this shift becomes easier when I focus on smaller units of time. A quarter, a month, even a week can feel overwhelming when viewed as a block to be endured. But an hour? A single conversation? A specific decision? Those can be engaged with fully. Those can be satisfying in their own right, even when they’re part of a larger effort that’s stressful.

The satisfaction of helping someone think through a hard problem clearly
The small pleasure of writing something well, even if it’s just an internal memo
The engagement of debugging a complex issue with your team
The connection that comes from being honest with a colleague about a difficult situation

These moments are available constantly, but only if you’re actually present for them rather than mentally fast-forwarding to some future state.

Sustainability as a Practice, Not a Destination

I think many of us treat sustainability as a condition we’ll achieve once external circumstances allow it. We’ll exercise regularly once this project ships. We’ll spend more time with family once we’ve hired the right team. We’ll read more, think more, rest more, later. But later never comes, or when it does, new demands have already filled the space.

Sustainability has to be built into how you operate now, not deferred to some future configuration of your life. This doesn’t mean working less hard or caring less about outcomes. It means recognizing that you’re playing a long game, measured in decades, not quarters, and that how you engage with the work today is how you’ll engage with it for years to come.

The leaders I most admire have figured this out. They’re fully engaged with their work, often in demanding and high-pressure situations, but they’re not waiting for it to end. They’ve made peace with the reality that the work is the thing, and they’ve found ways to be present for it rather than enduring it. They’re not martyrs grinding through until some reward arrives. They’re practitioners who have found meaning in the practice itself.

Every day, every hour, every conversation can be satisfying in its own right if you’re actually there for it. But you have to give up the fantasy that the pressure is temporary and that relief is coming. The pressure is the job. The question is whether you can find a way to be fully alive within it.

Tag: CTO

Simplicity Is a Leadership Discipline, Not Just a Design Principle