Minimum Main Member Principle

Summary

• Sensitive to performance and pay-as-you-go cloud costs, but not to communication costs
• However, communication is complex and difficult to reduce
  • That's why I wanted a straightforward principle
• Created the Minimum Main Member Principle
  • Introduces its basis and main patterns

Background

Sensitive to Performance and Cloud Costs, but Not to Communication Costs

As engineers, we are likely sensitive to performance. Additionally, we are probably sensitive to pay-as-you-go cloud costs such as API usage fees and infrastructure operation. (Another aspect is technical debt, but it's more dependent on the individual and the project, so we'll skip it here.)

There is another aspect that cannot be ignored. Communication costs. Unfortunately, this seems to be as underrated as, if not more than, technical debt. Here, I pose a question.

Can you secure more than three hours a day to focus on work or discussions alone, without interruptions?

If you answer Yes, or even No but "Yes about once every two days," you're fine. In other cases, you're probably incurring too much communication cost.

Need for a Principle to Reduce Communication Costs

As you can easily imagine, improving communication is very complex and difficult (that's why I started Soft Skills Engineering).

To move towards improvement, especially reduction, it would be good to have a simple and understandable principle. So I created one.

Minimum Main Member Principle

Minimum Main Member Principle is a principle that suggests keeping the main members to a minimum.

• Main refers to someone who both "undertakes the primary work" and "has decision-making authority"
  • In culturally challenging cases, either one will suffice
• Minimum means as few as possible, but at most four including yourself

I initially intended to call it Minimum Core Member, but I chose Main to stick with the 3M acronym.

Why is the 3M Principle Necessary?

To prevent the bloating of communication costs.

Ideally, one person would suffice, but having only one person can lead to biases and uneven capabilities and authority. However, more people mean more time-consuming communication. Many of you might have experienced being overwhelmed by meetings, document creation, or onboarding and mentoring.

A more relatable example is writing novels, blog posts, or other documents. It's a challenging task even alone, so imagine doing it with two people. What about three or four? Just thinking about it is daunting. While the logical world of software is less creative yet still creative, a style where one person creates and others review is essential.

Thus, having slightly more than one person but as few as possible is the best balance.

Main Patterns of the 3M Principle

Teams that adhere to the 3M Principle follow several patterns.

Seek the optimal pattern yourself. We'll introduce some here.

1: Worker and Reviewer

• Worker: Creates
• Reviewer: Reviews what's created

This is the simplest and most straightforward pattern, but it's unclear who does what after a review (post-review).

Typically, the reviewer is the superior and handles the post-review. However, just like the advisory process in teal organizations (where the superior advises but does not have decision-making power), the style can be left to the worker. Yet, post-review requires exercising influence, and often, influence cannot be exerted without authority, making it difficult for the worker.

2: Engineering, Design, Management

• Engineer: Creates
• Designer: Handles UI, UX, and other visuals
• Manager: Manages

This is a role-based distribution. Since it's difficult for one person to handle more than two fields (if possible, one can become independent), each role is assigned to one person.

Each role is challenging. Engineers require full-stack knowledge, including front-end, back-end, and SRE. Designers need to learn engineering tools like GitHub and CSS (otherwise, the 3M burden on engineers becomes too great, leading to a breakdown). Managers must handle both project management and product management—yes, each role is challenging, isn't it?

If you adopt this pattern, it would be better to limit it to a PoC level rather than a full-fledged project.

3: Worker, Helper, Advisor

• Worker: Performs actual work
• Helper: Directly supports the Worker, including management but not limited to it
• Advisor: Conducts research and examination for improving or transforming the Worker, and coordinates with the Helper

This is a pattern I call the Worker Triangle.

The most important role is the working Worker, who is given the utmost respect. However, since the Worker can't cover everything alone, a Helper is placed. Simply put, the Worker handles direct tasks, while the Helper handles indirect tasks. Traditionally, everyone handles both direct and indirect tasks, but here it's more about entrusting only the capable Worker with these tasks, with the Helper taking care of the indirect ones.

Next, since improvement or transformation can't happen with just these two, one more role is placed. This is the Advisor. As the name suggests, they provide advice, but it's directed to the Helper, not the Worker. This is because the Worker is specialized in direct tasks, being less focused on improvement or transformation (like engineers disliking soft skills). However, nothing can be done without it, so it's channeled through the Helper.

 Worker <--> Helper <--> Advisor

Thus, the Helper is often the most important. They need to understand the Worker's circumstances and communicate them to the Advisor, as well as grasp the Advisor's advanced offerings and convey them to the Worker. In this sense, the Helper might even be called a Translator.