Operational Minimalism
Tags: operations, engineering, startup, management
Published: 2024-01-03 09:09:21

---
title: Operational Minimalism
published: true
date: 2023-04-04 13:30:32 UTC
tags: operations,engineering,startup,management
canonical_url: https://www.engstuff.dev/p/operational-minimalism
---

#### Say no to advanced features, and embrace simplicity on your way to operational bliss.

![](https://cdn-images-1.medium.com/max/1024/0*_uapWyJ-DxPrjxHB.png)
_Credit: Author_

### Who’s it for?

Any organization but mostly for:

This could still be relevant if your organization has more than 20+ engineers but will require a proper structure and low level of dependencies.

### The Era of Mighty Tools

The average seed to Series A startup uses more tools than the number of team members. Every tool has a unique offering and can do some things better. I’m not a huge fan of all-in-one solutions, but a team must find the balance that will help them regain control of their operations.

The ever-going search for the perfect tool will never end. Focus on the tools that make you feel good and help the team be lighter.

### Harder, Better, Faster, Stronger

With every new feature you introduce to your operational stack, you create a more complex interface for your team. The simpler and cleaner interface to more clarity and efficiency for your team members will get. We often think that a full-featured product will increase productivity, but our organization usually needs less than more.

Ask yourself the following questions:

How many buttons do your engineers need to click before they can start writing a system design, writing code, or getting an answer to a blocking question?

Here is a common scenario for a small startup:

![](https://cdn-images-1.medium.com/max/1024/0*yhjcry_4QKZFqRda.png)
_Many jobs, many interfaces_

Pretty crazy, and here we are talking about a small company of no more than 10 people. Each platform has rich features and abstractions; labels, types, templates, automatons, fields, inline comments, and more.

This happens because each team member wants to use a system that’s comfortable for them. Docs should be written in a system that allows rich content and easy to use editor. Projects should be handled with a system that allows a complex dependency system and a beautiful interface to visualize the work. Code review should be managed in a system that allows one to see the changes and make proposals.

All these are unnecessary features that make you feel good but slow down the actual value the team can bring. Your team is so busy with the work of work.

### Minimalism bliss

Your goal is to bring business outcomes while keeping your team happy. Operational clutter is a big issue for both. Let’s look at an alternative operational solution.

1. **Team’s Plans**  — GitHub issues.
2. **Projects definition**  — GitHub issues.
3. **Project’s Plan**  — In the Project’s GitHub issue.
4. **Tech design**  — In the Project’s GitHub issue.
5. **Code**  — GitHub PRs.
6. **RFCs**  — GitHub issues.
7. **Decisions**  — GitHub issues.

_\*You can replace GitHub with any other tool (GitLab, Bitbucket, etc.)_

You probably think this can’t scale, or maybe you think that using “ **_just”_** simple markdown and lacking inline comments will slow you down. I believe that’s not true. The **enforced minimalism** will keep the team more focused on the actual work instead on the meta-work of managing comments and millions of channels.

The truth is that having a simple text-based list of things you need to get done today (or this week) makes it visible to know how things are going. If you need more than that, you probably lack clarity on your goals or what needs to get done.

> “If I had more time, I would have written a shorter letter.”— [Marcus Tullius Cicero](http://en.wikipedia.org/wiki/Cicero).

If you have more time, spend it reducing content and not flooding your team with many processes and documents to fill up. Don’t overload abstraction; keep the team very close to their code.

### Scaling with Minimalism: Addressing Concerns

I found that the greater the need for complex tools and interfaces, the stronger the signal for either.

1. Your organizational structure is not effective, which causes too much friction between teams. I suggest looking at [Team Topologies](https://teamtopologies.com/).
2. Your software has too many dependencies, so you need to decouple your modules (or services).

Introducing “stronger” operational tools will act as a bandage and increase operational clutter so things move incredibly slowly.

### Recommendations

1. Streamlining the toolset: Focus on using a single platform, such as GitHub or GitLab, to manage different aspects of software development, like project planning, tech design, code review, and decision-making.
2. Simplifying processes: Reduce the reliance on inline comments, custom attributes, and complex workflows. Encourage clear and concise communication.
3. Minimizing operational overhead: Limit the number of clicks and tool implementations required to complete tasks, making it easier for team members to get things done.
4. Scaling effectively: Upgrade or merge tools only when they simplify workflows and reduce complexity.

_Originally published at_ [_https://www.engstuff.dev_](https://www.engstuff.dev/p/operational-minimalism) _on April 4, 2023._