"The Way of the Essentialist involves doing less, but better, so you can make the highest possible contribution. The Way of the Essentialist isn’t about getting more done in less time. It’s not about getting less done. It’s about getting only the right things done."

• Greg McKeown

Essentialism is a book that I frequently revisit, typically at least once or twice per year. The core idea is to focus all of your energy on one thing and do it well, rather than spreading yourself thin across multiple tasks. This approach differs from the norm, where many of us tend to work on multiple things simultaneously, leading to a dissipation of our energy in different directions.

This might be multi-tasking in the well known sense. Focused work, whilst checking email every couple of minutes and being distracted by constant Slack notifications. Or it might be the multi-tasking that sits slightly under the surface. The kind that has us working on multiple different projects, in multiple different disciplines at the same time.

Having interests in multiple different areas is a great strategy, it allows us to cross-polinate ideas and solve problems in innovative ways. This is discussed at length in the excellent book Range by David Epstein. But a clear seperation helps our brains focus.

I've been particularly guilty of this myself. In the past, I would sign up for any and everything that even remotely related to my interests. Learning to say no or delegate has been a tough lesson that I've had to learn in the last 18 months. While it may work for a little while, and you may achieve some success, it's not a sustainable strategy. Saying yes to everything and attempting to advance multiple projects simultaneously inevitably results in little progress anywhere.

Have one focus, commit fully, then move on to the next thing. The next idea. The next area of interest.

Essentialism in software

You're probably wondering how this relates to software. But there are some interesting ideas we can take from essentialism and apply it to the way we think about software.

This isn't a new idea. In Domain Driven Design, Eric Evans discusses core, generic, and supporting subdomains:

• Core: The unique selling point (USP) of your business, the thing that sets you out from your competitors and delights your custoemrs.
• Supporting: Areas of the system that are required for your core domain, but aren't differentiating with the competition and there aren't any off the shelf solutions available.
• Generic: Areas of the system that are completely undifferentiating.

Already, you can start to see how essentialism fits. As much as possible, the focus of a software organisation should be in the core domain. Improvement in this area, will have the most impact on your customers.

Yet, even with this in mind I see many companies getting lost in supporting and generic subdomains forgetting the value they actually want to deliver to customers. They are expending energy in every possible direction, instead of a single minded focus.

Undifferentiated Heavy Lifting

Werner Vogels, CTO of Amazon, is well known for talking about undifferentiated heavy lifting. The cloud enables you to shovel this work on to the cloud provider leaving you to focus on adding value. This is a big step towards essentilism. Gone are the days of racking servers and crossing your fingers that the backup generator kicks in quickly during a power cut.

But even in the modern, 'cloud native' world, there still seems to be an obsession with continuing to focus on this lifting. On these supporting and generic subdomains that your customers don't care about. Yes, your customers care that your application is always accessible. They don't care if you're doing that with serverless compute or with a container orchestrator.

Let's stick with the container orchestrator idea for a moment. I don't want this next section to feel like I'm shitting on Kubernetes and I fully appreciate there are valid use cases for a container orchestrator. But let's compare and contrast with something like AWS Lambda, or if containers float your boat then AWS AppRunner.

Let's consider this for a startup or early stage organisation trying to launch a new idea.

Even when levearging managed services like Amazon Elastic Kubernetes Service (EKS), there is an awful lot of infrastructure management and configuration needed. This is before you even get the first MVP of your product in front of a customer.

Comparing that with a service like AWS Lambda, where I can write a piece of code that focuses only on my business logic, deploy that to the cloud and be confident it will scale when required. No infrastructure management, no setup beforehand. An unparalleled time to value.

Low Code Applications

There is a step even a beyond Lambda and serverless compute. A step that enables applications to be built without a single line of application code. What application code requires the least amount of heavy lifting? Code that is never written.

AWS Step Functions is my favorite AWS service. It offers direct integration with almost any AWS service through its SDK integrations. By leveraging this capability, you can potentially build out large parts of your supporting and generic subdomains without writing a single line of application code. With no need for infrastructure management, configuration, or even updates to libraries and changes to code, your non-core subdomains become about as low lift as they could possibly be.

If you're interested, I have a repository on GitHub that implements a review translation and sentiment analysis service without a single line of application code. Or if video is your thing, my talk at the AWS Community Summit 2022 where I discuss this repository.

The Essentilist Spectrum

I'm not a purist, and appreciate there are absoloutely scenarios where greater control is required. GPU heavy workloads, developer familiarity, longer running workloads. This isn't a debate about Kubernetes vs Lambda vs native service integrations. That was meant purely as an example.

However, all of these ideas sit along a spectrum of essentialism. At each stage, you choose to introduce an additional pressure on the energy your organisation has to move forwards. To implement features. To delight your customers.

This spectrum fits nicely with a 'serverless first' mindset. My view on serverless first is quite simple. Default to as little undifferentiated heavy lifting as possible and increase as required. I would typically couple this with a view on core vs non-core subdomain.

For example, if I am designing a new feature for a service that exists as a supporting sub domain I would go through:

• Step Functions with native service integrations
• Lambda
• AppRunner
• Fargte on ECS
• EC2

You can apply similar heuristics to areas outside of compute (DynamoDB vs RDS for example).

I realise many decisions are a lot more nuanced, and jumping straight into the implementation details is not typically where I would begin. But once we are down in the weeds, I find this an excellent way to add business value whilst reducing operational overhead.

Our software is essentialist.

Thanks for reading,
James