Many core values of tech companies include some idea of simplicity. After all, everyone knows “Keep It Simple, Stupid”. But the nature of simplicity is often misunderstood in many engineering organizations. Many mistake “Keep It Simple” for avoiding complexity altogether, rather than recognizing simplicity is a work product achieved through navigating complexity with skill and discernment.

Perhaps this is better expressed with another, perhaps less well-known quote…

“For every complex problem, there’s a solution that is simple, neat, and wrong.”

— H.L. Mencken

The critical distinction here is between problem and solution.

“Keep it Simple” is often a warning (rant?) against premature optimization that can lead to complex and over-engineered systems. That said, over time and if you are lucky, the number of product features, engineering teams, and customers will grow. At that point, simply keeping it simple lands oneself in a world of complexity.

When faced with complexity, keeping it simple encourages wrong answers. It may have you to stick with the monolith or just wrap the database in another layer of caching infrastructure. This also applies to non-technical aspects of engineering, such as organizational structures and execution management. Keeping it simple may encourage you to simply expect “two-pizza teams” will operate independently and with speed. Or may have you simply asking everyone to email “what you did last week”, resulting in confusion and disruption. To be clear, small, effective teams and transparent accountability are good things. But ignoring the natural complexity of scale will result in a solution that is simple, neat, and wrong.

That’s when getting to simple is key.

Simple is an outcome

Throughout my career, I’ve learned that true simplicity isn’t about avoiding complexity but about putting in the work to achieve “simple”. At Dropbox, the problem of synchronizing file content across many devices with uncontrollable connectivity, onboard capabilities, and storage models is, by its nature, complex. Mix in various permission and access models, file types, and user roles, and the complexity explodes. Yet, a big portion ofDropbox’s success can be attributed to its apparent simplicity. From a customer’s point of view, “it just works.” That took many long, hard, and smart decisions and work.

In fact, it was a conversation I recently had with a very tenured Dropboxer that inspired this post. Dropbox’s company values include…

Keep It Simple

Simple things work better — and make more sense. So we build products that do a few things really well. And we don’t overcomplicate life at Dropbox, whether it’s a plan or a process. Getting to simple isn’t always easy, but it’s worth the effort.

That language speaks to both avoiding premature complexity (“Keep”) and putting in the work to achieve simplicity (“Getting”). (…and our conversation was specifically about whether we needed to emphasize the “getting to simple” part within the team more strongly.) Amazon has a leadership principle it names “Invent and Simplify,” which does two things. It frames simplicity as a verb, an action to do, and it couples that with “the how” through invention and innovation. To me, that’s correct.

Tech has a number of fabled examples where Getting to Simple led to legendary outcomes.

• Google’s early Page Rank concept and Spartan UI are often attributed to their initial success. The engineering achievement wasn’t in avoiding complexity, but in creating simplicity as a result of deeply understanding and addressing that complexity.
• Toyota’s production processes, including their kanban systems for just-in-time production, address the complex challenge of inventory management by developing a sophisticated but elegant methodology that appears simple in implementation but requires a deep understanding of production dynamics to create.
• Apple’s Product Design Philosophy. Jobs famously said, “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple.” Examples of Apple products that demonstrate this don’t need to be mentioned here.
• The Unix operating system design philosophy embodies this principle with its famous axiom: “Do one thing and do it well.” Unix isn’t simplistic — it’s a sophisticated operating system — but it achieves simplicity through modular design. Each tool handles one specific task exceptionally well, and these tools can be combined through pipes to perform complex operations.

Leading to Simple

Leading teams to “Get to Simple” rather than merely avoiding complexity requires deliberate leadership. Here are some approaches I’ve used to help leaders navigate their teams through complexity toward meaningful simplicity.

1. Be strategic in what complexity you take on… and clear in what you won’t

Build and maintain a prioritized set of strategic technology investments over the next one to three years. Focus on the top two or three, and have a list of “non-strategic / won’t do” investments that feel painful and a bit controversial. Be realistic about the engineering costs for those to invest in and those not to invest in. Align with your team and cross-functional partners. Get crisp. Then communicate the plan decisively and actively manage to it.

At Dropbox, sync was our business and our competitive advantage. It was strategically vital for us to invest in secure, reliable, and scalable file storage and sharing. So we invested deeply in that. Similarly, rich content organization, search, access controls, and document understanding was essential. For some technical subcomponents, we simply used open-source solutions. For others, we made the strategic decision to build our own solution. Not all of those decisions were perfect, but when they were made decisively, strong execution followed.

Conversely, many years ago, I led the effort to completely rebuild Groupon’s website. By that point, Groupon had massive daily traffic, offering diverse deal types across multiple international acquisitions with independent tech stacks. Despite the complexity and scale we recognized that Groupon’s web architecture was not a strategic business differentiator. We adopted the motto: “We are not building a framework. We are building a website,” inspired by Rich Hickey‘s “Simple Made Easy” talk.

While we still had complex problems to solve, particularly how teams could implement, test, and deploy independently, we focused on making opinionated choices about existing technologies rather than building custom solutions. This “getting to simple” approach allowed us to rebuild the website in months with impressive performance and manageability, proving that strategic simplicity doesn’t mean avoiding all complexity, but rather investing complexity only where it truly matters.

2. Set Expectations

Typically, technology investments are decided in some regular planning cycle, maybe annually or quarterly. However, important technical decisions are made by teams every day. That is why it is essential to set clear expectations about the boundaries and what happens a team wants to cross them. Setting engineering standards is a crisp way to articulate those boundaries. Establishing a technical review process, of appropriate scope and formality, should be done when teams wish to extend them.

It’s also healthy to set expectations for regular code refactoring to help avoid reaching a tipping point of complexity. I’ve also found it essential to build a strong culture of regular and frequent team retrospectives.

“Something is wrong if workers do not look around each day, find things that are tedious or boring, and then rewrite the procedures. Even last month’s manual should be out of date.” 

– Taiichi Ohno, former Toyota executive vice president

3. Maintain situational awareness

Implementing standards, processes, and mechanisms is a great leadership tool. But they require guardrails and ways to detect if something is moving in the wrong direction.

There are some standard measures to detect teams struggling with complexity. They aren’t perfect, but they often provide useful indicators for you to investigate. Fortunately, these are the sort of metrics you should already be measuring, since they attempt to measure how teams are balancing the project management triangle — Quality, Time, Scope, and Cost.

SEVs and Customer Issues: Is a particular team or part of the tech stack seeing a rise in production issues? What are the top categories of inbound customer complaints? Where is the bug backlog the longest?

Bottlenecks: Are there engineering teams that seem to have longer estimates than others? Are there engineering teams that tend to be a bottleneck for project execution?

Engineering Effort Allocations: How much time are engineers spending building new customer value versus fixing bugs or maintaining the system? You may or may not set or enforce allocations across these work categories. However, even vague or anecdotal measurements will often show when a team is struggling.

Simply Ask: I believe in being skeptical when metrics and anecdote differ. Find ways of asking the engineers where complexity is a burden. Do this within a regular planning process, by sending regular surveys or discussing ad hoc with tech leads.

4. Culture

Here is one of the best examples of “Culture eats strategy for breakfast.” You can have the best vision, planning, reviews, and metrics, but if the culture pushes too hard to cut corners, celebrates firefighting over craft, or promotes engineers based on technical or organizational complexity, nothing else will matter.

You must foster a culture that expects the highest level of engineering craft. That includes “Getting to Simple”. Having it a specific company value is a great start, but it’s not enough. I’ve learned repeatedly that cultivating a simplification culture isn’t just about tools or processes. It’s about consistently aligning incentives, recognition, and leadership behaviors around the principle.

Celebrate Simplification Victories: We often celebrate the launch of new features or products, but rarely the removal of unnecessary complexity. Recognize and celebrate key decisions leading to engineering simplicity, speed, and quality.

Connect Simplicity to Business Outcomes: Regularly quantified and communicated the business impact of simplification efforts. Often, simplicity leads to business metrics you can measure, even if indirectly. These examples helped business leaders understand that simplification wasn’t just an engineering concern but a business advantage.

Reward the Invisible Work: Ensure the tangible rewards (i.e., performance reviews and promotions) are aligned with the outcomes you want to achieve. Often, it’s the opposite. Performance reviews and promotion criteria typically focus on building new capabilities and features, with more senior engineer expected to provide more complex solutions. This is backwards. Engineers who significantly reduce technical debt, consolidated duplicative systems, or streamlined complex systems should be highlighted at promotion time.

The journey to simplicity isn’t about avoiding complexity; it’s about embracing it. It’s about developing your team’s capacity to navigate through it skillfully. True simplicity emerges when we have the courage to face complexity head-on, understand it deeply, and find the elegant path through it. This often requires embracing complexity first. But the results are solutions that “just work” for users while enabling sustainable innovation. It’s well worth the effort.