An important aspect of being a leader is understanding the difference between inherent and artificial complexity. The problems you’re solving are full of complexity. Much of it is the complexity that we as humans bring to the problem. Only some is the actual complexity of the problem. Which leads to the dreaded words “how hard can that be?"

When you understand the core of the inherent complexity of a problem, you begin to have an answer to anyone who doesn’t understand why what you’re doing is hard. If you’ve been doing software development for any length of time, you’ve worked with someone who asked you “how hard can that be?” So many times, this simple phrase captures the essence of artificial complexity.

Problems are often like icebergs, with more hidden beneath the surface than visible to the naked eye. If we can distinguish the pieces that make a problem hard - for example, data from many different systems in different formats. We can start to ask ourselves “does it have to be that way, or can we simplify that complexity?” Even better, we can explain to others why the problem is hard.

I recall once talking to my boss about his desire to pull procedure-level statistics from a system we built to manage a hospital operating room. It sounded straightforward; a query no harder than other queries we had run. However, we had pulled the data from the source systems and aggregated it. We no longer had the original procedure level data. Suddenly the problem was much harder because we would have to re-acquire the data at a different granularity. And I could explain why it was so much harder to my boss.

Anyone looking at the problem from the outside is going to assume the best-case-scenario. The outside person isn’t going to invent roadblocks. They have the benefit of no artificial barriers. They don’t have legacy systems, teams with different points of view, technical decisions made prior to our joining the problem. When we become masters of understanding the complexity, we can become communicators of why things are hard. We can become problem solvers by eliminating complexity.

Take a moment to look at the problem and ask yourself why is it hard? Because of the tools I’m choosing to use? Because of decisions made prior to me? Because of the people involved? Because it has uncertainty? Separate yourself from the lens you’re viewing the problem and consider all angles. Sometimes playing the devil’s advocate and saying “why isn’t this easy” is one of the best ways to strip out complexity that isn’t inherent.

I have found when designing systems, decisions made in order to simplify the coding and maintenance translate into unexpected performance problems. I recall a system that used a framework to quickly take care of the CRUD operations translating in easy maintenance of the code. It performed fine in test. In a production environment with high volumes of data, suddenly performance was a problem. We’ve added artificial complexity.

I recall building a page on a web application. The user expected the page to load in under a second. Sure, it’s only their account information. It’s not actively calculating anything. It’s not performing a transaction like payment processing. Why does it take a long time? The page checked for new messages from the messaging system that lived outside the account information system, and the response time was poor. This hidden complexity stopped me from meeting the user expectation that this was a simple page.

When you ask yourself the question “how hard can that be?” you are taking up the outside point of view that others - your boss, your customers - will undoubtedly have as a starting point. If you understand that point of view, you have an opportunity to simplify or translate more effectively.