Ode to Simplicity
We will reflect on the importance of simplicity and discuss ways you can help your organization embrace simplicity.
Hi, this is Peter with the next edition of the Professional Manager newsletter. I publish this newsletter to illustrate what decent, seasoned, professional engineering management could look like.
In this edition, we will reflect on the importance of simplicity and discuss ways you can help your organization embrace simplicity.
Value Simplicity
Since the 2010s through 2022, software engineering has grown increasingly more complicated. Some of the newfound complexity is warranted and is a genuine sign of innovation. Some of it is unnecessary and is a fad that we software engineers fell in love with because we read one too many HackerNews articles. The tendency to value engineering complexity without proven business value is a dangerous, slippery slope for many reasons. A few that come to mind
The org will be attracted to complexity, and you will create an environment focused on technical marvels rather than business value.
Those who are deep in the weeds of engineering will never be able to explain what the engineering organization is up to.
Your engineering teams will consist only of senior talent because junior engineers will not grok your systems.
Onboarding a new team member will be difficult.
We previously established that we all want an engineering organization that values innovation and great technology. You must also always remember that you are hired to realize business value through the power of technology. You are not here to create great technology for technology’s sake!
Help your org appreciate simplicity
Great! We like things to be simple. You should work to weave simplicity into the fabric of your organization. We will discuss a few, primarily engineering-focused, tactics to do so.
Explain in plain English first
“If you cannot explain it in plain language, how could you possibly code a system around it?” is something I used to ask teams I have been part of. I strongly advocate for design documents - aka, Architecture Decision Record (ADR) or Request for Comments (RFCs). A well-written software design document will help teams build consensus and understanding across the organization. We won’t dive deep into the mechanics of a great design document. Suffice it to say that a great design document should cover alternative options and answers to “what if we didn’t do this?”. Both of these angles will help drive simplicity. These design documents will also help the engineers “measure 3x and only cut once.” Evolving or throwing away a design document is far less emotional than throwing away code you worked on for months.
Moreover, a good design document always touches on how the business benefits. If your executive team understands in very basic terms what the engineering team is up to, you are on the right track!
Think holistically
The software we build must consider the entire ecosystem at your company. A microservice in isolation will never produce business value. A gorgeous frontend, written on the most modern stack, on its own is not going to grow your company. Coherence is one of the critical characteristics of simple architectures. Without coherence, complexity proliferates.
Non-existent code is the best code
Engineers worth their salt understand that non-existent code takes the least effort to maintain. If your business can thrive without more code, you should celebrate the lucky position you are in! You can reward the removal of unnecessary components both socially with the teams, as well as during performance reviews. If your org’s mindset is not quite there yet, help them understand. Good software is straightforward software. The most straightforward is when code does not even exist.
Maintain only a few well-known languages and tools
A proliferation of powerful languages and tools emerged in the past decade. We, engineers, are notorious for chasing the next shiny object - whether that be programming language, event bus, observability tool, etc. - and for getting excited about reading one too many HackerNews articles advocating for the shiny object. Keeping your technical landscape as simple as possible will benefit the company long-term. You must realize that your startup is not Google, Amazon, or LinkedIn - you will likely never deal with the scale those companies deal with.
Working software
Operate in terms of working software. Your OKR process will improve when you can precisely define KRs around
What are we shipping?
What are we demoing en route to our final product?
What API endpoints will be deployed?
If you cannot show progress via working software, you are exposing yourself to an unchecked team building a Rube Goldberg that will never serve the business.
Prioritize running production
The first 80% of any project is all fun and games. The remaining 20% is kind of like a death march. And then it is fractal complexity from there. It will simplify everyone’s life to set the expectations across all engineering ranks that running production, including First To Know capabilities (i.e. monitoring and alerting), is our responsibility, and nobody is exempt.
Do not invent acronyms or clever shorthands
To close this Ode to Simplicity, I wanted to offer a cautionary tale about how such a simple thing as individuals creating clever acronyms at their whim can backfire. TLA’s have their place, there is no debate. However, they can also unnecessarily complicate things when people invent acronyms and start using them for no good reason. Often it is best to spell things out!
I once encountered a situation where engineers cleverly shortened authentication and authorization as authn and authz. They sometimes even got so clever that they would just use auth. You may already see the problem here. It would have spared all of us a lot of unnecessary confusion if everyone had just spelled out authentication and authorization all along.
Another fun one was at this other company where the founder’s name was Brandon Olson. One of our principal engineers was named Bo. When a clever engineering manager started to refer to the founder as BO, you can imagine all the confusion he caused.
Sometimes, it is simplest to spell things out!
Summary
This was an Ode to Simplicity. I am a simple person, I love simple things. I strive to bring my advocacy for simplicity to work, and I invite you to do the same. Your business will be better off for it.
I sincerely thank you for reading my newsletter. I’m always open to your feedback. I would also love for you to share The Professional Manager with your friend!