Working like an Amazonian: Leadership Principles Explained — 3. Invent and Simplify

Quick links to the previous articles in this series:

Invent and Simplify

Personal note: I’m always a simple person, and I shoot for technical excellence and simplicity. I truly believe in “do one thing and do it right” and “less is more.” That’s why this is my personal favorite. In a world where the entropy is increasing all the time, I do my best to reduce complexity. If O(n) could do it, I wouldn’t stop at O(n log n) only because it’s “good enough.”

Amazon’s definition goes as follows:

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here.” As we do new things, we accept that we may be misunderstood for long periods of time.

I’ll admit that the 2020 AWS re:Invent keynote from Andy Jassy is so long that I didn’t finish watching it. But if there is anything I learned from that talk, it is: don’t wait too long to reinvent.

Of all the Fortune 500 companies in 2000, now only 50% remains. If we look back 50 years instead of 20 years, the ratio is 17%. It’s hard for any company to sustain itself for a long period of time.

Andy made a metaphor that inventing too late is like borrowing money because everyone will tell you that you should not be borrowing money when the business is in bad shape. After all, you may not get the rate you want, or you may not get the money at all. Invent in desperate time is already too late. That’s why invent and reinvent are key to any business.

This leadership principle’s definition is long, but really it has only two keywords that are already in the title: invent and simplify.

Invent

You may think that only big companies like AWS and Apple and something like these has the power to invent. They invented the cloud; they reinvented touch screen devices. But we, too, can invent. It’s not something only the big names can do; inventions are everywhere. No matter how small that Jira ticket is, or maybe it’s not even a technical problem, there may be space for you to invent.

Sometimes, there is a complex problem to solve, but if you take a deeper look, you probably will find a solution, often an automated one, which can simplify the process and achieve the goal. This is an invention.

Invent doesn’t need to be from scratch or the ground up. Sometimes, there is already an existing product or process, but maybe it’s not good enough. You find the place to improve, and that is invention.

Maybe the team is not happy with what’s going on, and the morale is low. Coming up with an idea to solve issues within the team and making everybody happier is also an invention.

We can literally invent anywhere we want. We are only limited by our imagination.

Simplify

Sometimes, there is a straightforward task to do, and there is the quickest way to do it, but that way is maybe a little bit complicated. So there is space to simplify.

Or maybe a solution already exists in your team, but the solution is maybe too cumbersome, takes manual input, requires redundant human labor, etc. This might also be simplified.

Project Stories

Once I was on a project migrating on-premise VMs into the Cloud. The team decided to use Packer to build the images, then Ansible to provision the VMs in the cloud. But after a closer look at the setup, I discovered that we only used Packer’s most simple functionality, which Ansible could totally do. Why bother maintaining two technologies when one should already suffice? I kicked packer out of the picture, implemented everything with Ansible only, and the team liked it.

Another time, I was on a project which was to build a platform around Kubernetes. The team wanted to use AWS eksctl to provision the cluster and Terraform to automate the infrastructure. It countered my intuition because Terraform can do cluster provisioning. Maybe Terraform could even do a better job (it was more than 1.5 years ago when eksctl it lacked many functionalities.) So why maintaining two technologies? Again, I kicked one out of the picture and implemented everything under one framework, and the team liked it quite a lot.

Yet another time, I was working on some integration that required using an old Python script to do some templating. I looked into it and found out that it was created 3 years ago without any maintenance thereafter. There had been a bug before, so there was a nasty fix in the code that nobody could understand. The bug had been fixed, but the script still contained that nasty fix. The code was not flexible enough, so the code also needs to change when the template changes. It drove me crazy. After discussion with my colleague, we rewrote the code in a Golang with generic templates, reduced the codebase to less than 1/3 of the original, and open-sourced it. Since then, the new code was used in hundreds of pipelines, and we got no complaints at all.

I have more examples from real-world projects more than I would like to admit. You may think these examples are so insignificant that they don’t mean anything at all. But I think the opposite. It’s exactly simplicity like these in every small step that counts. For example, refactor some bad code when you saw it doesn’t take much time. But in the long run, it improves the quality, testability, and readability of the code. After all, code refractor is all about “do one thing and do it right.”

If at every point you tolerated a slightly more complicated solution, in the end, the system would be so complicated that nobody could maintain it at all.

How to Invent and Simplify

To be able to invent, first, you need to be able to identify a gap. You need to be able to see the areas which require improvement.

Then, you need to collect ideas and data. Not only from your team internally, but maybe externally or even publicly from the internet.

Maybe you collected some data from your customers, and based on the data, you can infer where the customers need more help so that you can invent a new service or a tool or a feature to make it better.

Maybe you are trying to solve a problem, but chances are, the problem you are trying to solve has already been solved multiple times by others. So, you may find a quick and simple solution by collecting data externally and from multiple sources. If you stay isolated and try to invent everything yourself, you are reinventing the wheels.

Dangerous Signs

If you tolerate a complicated piece of code with thousands of lines in one file or hundreds of lines in one function, this is dangerous. If you settle for an existing process even though there can be room to improve, this is dangerous. When you want to finish something quickly but do it with some copy-paste without trying to refactor or find a better solution, this is a dangerous sign.

Oftentimes, we may try to find a “standard solution” that could be reused at multiple different places, which can be dangerous. Because more often than not, this “one-size-fits-all” solution will probably not work perfectly in all those places.

I was in a project where one teammate wants to build a unified solution to scan possible security issues in Terraform and CloudFormation code.

There are already tools for that, for Terraform and CloudFormation, respectively. Still, he wanted to build a unified system so that no matter which you use, this system can verify it, and you can access the system by API calls.

To me, this is complexity. This might even be building something nobody wants or trying to find a perfect solution to a problem that doesn’t even exist. Because let’s face it, the chances that a team is using both isn’t that high. Even if some team really uses both, it’s much simpler just to add one simple tool in the respective pipeline instead of inventing a complicated system to handle both and requires API calls from within the CI pipeline.

Luckily, this project was never finished — less garbage (forgive my language) in the world.

Do not invent for the sake of inventing. Invent to solve a real-world problem.

Mock Interviews

Since the principle itself is simple enough, the questions are simple, too. There are probably no hard questions on this leadership principle.

On the “invent” side, I could ask: tell me about a solution you invented that solved a real problem. Or, tell me about an improvement you made in your team. Or, tell me about a technical refactor which greatly improved something.

On the “simplify” side, I could ask: tell me about a time when you saw a complicated product or process and simplified it. Or, tell me about a project where you changed the team’s mind by suggesting a simpler solution.

In the next chapter of this series, we will talk about the 4th leadership principle: are right, a lot. Spoil alert: this is probably the most misunderstood principle.