Building Teams = Understand people

Rather than seeking a definitive formula for assembling an ideal team and becoming fixated on specific quantities of product and engineering managers or ratios of senior to junior members, anticipate that you will develop a deeper understanding of people.

Project Types

Before you begin searching for personnel, it’s essential to comprehend the nature of your project. I identify three main categories.

R&D, MVP, Custom Build, Early Stage

We are discussing the initial phases, often associated with startups. This is a period of experimentation, discovery, and innovation, where new ideas are forged and ventures take shape. Success is not guaranteed, and setbacks are commonplace. In fact, failures are often viewed as valuable learning opportunities by skilled R&D personnel. They are eager to tackle fresh challenges and push the boundaries of what’s possible and that usually means a lot of failures.
Do something and fail and then again and again. And R&D people really like it. They love to fail. They love to start something new. It’s like mana for their lives. I really love them. But you usually don’t want their code in production. It’s often like a mess. They don’t like strict rules and processes. They require a lightweight approach that aligns with their preference for flexibility and creativity.

Product

TV and cloud are both examples of products. Developing such products is not a new concept, and most people possess the knowledge to create them, particularly if they are not too complex. The key is to follow a precise method to construct the same product. A clear product vision is highly valued by those working on these types of projects. Their primary motivation is to deliver the best possible product, and they are motivated by processes since they help to minimize failures. In fact, failing is not something they enjoy, and it can be disheartening for them. Repeated failures may cause them to become dissatisfied and ultimately leave the company.

They generally don’t prefer code from R&D teams since it tends to be less efficient and less stable. Stability is a top priority for them, and they take pride in delivering reliable code that can be used in production.

Commodity

Electricity is an excellent example of a mature product with high pressure on margins. To optimize the product and avoid failures, it’s essential to be highly efficient. People working on these types of products have a low tolerance for failure and consider it unacceptable. However, they highly value stability, and a product that remains the same for years is god’s music to their ears. They are typically interested in maintaining the product and come up with ideas for optimizing processes. They are detail-oriented and like to dive deep into the product. They generally do not appreciate code from people working on product development, as it’s often considered ineffective.

Once, a team member shared a story with me about how he created a patch for GCC to improve output ASM code. He had found a mistake in the instruction under certain conditions, which was causing too many CPU ticks and patch saved a few of them. Just a few.

Real world = real people

The real world consists of real people, and it’s important to keep in mind that people are constantly changing. Based on my experience, R&D spaces typically attract younger people. However, it’s crucial to understand and classify people into the appropriate category. It’s important to note that these categories are not absolute, but rather a spectrum. It’s not simply a matter of being in R&D or having no product at all.

Conclusions

I once witnessed real animosity between two groups within a large company. People in the product category blamed the R&D team for producing poor quality code, while the R&D team argued that it was necessary to move quickly and they didn’t have time to rewrite the code. I don’t think it’s necessary to separate them, though. Sometimes it’s necessary to have R&D people working alongside those in the product category. So what to do with that?

I believe that people simply need to understand each other better. That’s my conclusion. If they know who is working beside them and what motivates them, they’re less likely to point fingers. This is where engineering managers and team leads can play an important role by regularly talking to team members and explaining what drives their colleagues.