Wes Kim (Unyoung)

How I define simplifier & complicator

There are two archetypes of people and I call them simplifiers and complicators. This shows up in all contexts, but in engineering specifically, simplifiers are the people who break down complicated problems and present elegant, minimal, but robust solutions. They tend to explain things in ways that are easy to understand and they avoid unnecessary jargon. They focus on the problem, build solutions from the ground up, and think from first principles.

On the other end of the spectrum are complicators. These are people who overcomplicate topics and enjoy using complex, hard to understand words, often as a way to show how much they know. Their attention is on the fancy concepts and tools they are familiar with, not on the problem itself. These people are solution first, problem next.

When do we need each?

Simplifiers are valuable and hard to find. While there could be many versions of the definition of intelligence, I view it as "the ability to simplify complex ideas and topics." They are especially needed in startups where the balance of velocity and stability is key. Simple things do not break as easily, and simplifiers bring most startups to the early promised land very quickly by focusing on the problem, reducing tech debt, and removing all the fluff.

However, there are times when the trait of a complicator is required. This happens when you need to take a system beyond the 80 percent capability mark. There are different types of startups. Some create value by building something entirely new, while others create value by making solutions more performant than the status quo.

In the early stages, it is usually best to follow the 80/20 rule. You spend 20 percent of your effort to build 80 percent of the system and keep moving forward that way. At that stage, spending 80 percent of your time to perfect the remaining 20 percent is often not ideal. In the second category of startups, complicators can be especially valuable. Examples include building a JavaScript runtime that cuts cold start from 50 ms to 40 ms, or an optimization engine that reduces tail latency by a few percent on large production workloads. In these cases, people purchase your tool for the additional few percentage points of performance or accuracy. To gain a competitive edge, you need to invest the extra 80 percent of effort for marginal but important improvements. Differentiation comes from doing better, and complicators tend to thrive in these types of tasks, but often perform worse in situations where they have to interact with non technical groups.

In the end, this is a spectrum and not a set of buckets. It is important to know where you fall on the spectrum, to understand what is required at any given stage, and to work with people who have complementary skills.