Hypergrowing & over hiring

The COVID-19 epidemic has had a significant influence on the worldwide economy and corporate operations. One of the most noticeable developments has been the quick move to remote work, which has caused many organizations to overhire people in order to guarantee that they have the personnel required to maintain operations. However, as the epidemic drags on and economic uncertainty lingers, many of these businesses are now faced with the painful reality of having to lay off a considerable amount of their personnel in order to return to pre-pandemic levels.

Companies overhiring and subsequently laying off people has been a source of worry for some time, well before the epidemic. In reality, I’ve seen numerous firms in my area raise financing, increase their personnel, and then lay off the bulk of their employees within a few years. The present tendency of layoffs in the aftermath of the epidemic is thus unsurprising, since it fits with this pattern of corporate budget mismanagement.

How this affect your tech?

When developing a digital product, adding additional programmers to your team will have long-term consequences and minimal short-term benefit. Software developers are a costly resource, and effectively onboarding them takes time. The intricacy of the choice rises with each new person added to the organization, making it one that should be avoided as much as feasible.

In the software business, it is typical to find sophisticated solutions to basic issues, dragging organizations back in delivering new functionalities. After many years of experience, it is apparent that an over-engineered system is a prevalent problem.

The author of A Philosophy of Software Design describes one sort of complexity known as change amplification in his book. This happens when a change in code necessitates adjustments to other parts of the code. There are times when delivering a feature takes months, not because it is difficult to do, but because of the complexity of integrating it with all other systems and collaborating with other teams.

Complexity is tough to manage, and businesses frequently feel that adding additional employees and rearranging teams would help them deal with the burden. However, increasing the workforce will ultimately add to the entire system’s complexity.

Some common pain points for companies include:

• Flaky deployments
• Lack of tests
• High complexity in systems
• Poor communication structures within teams

Engineers like to work on intriguing projects, and if they can’t find one, they make one. This frequently results in the creation of additional services when they are not required, or in the undertaking of the next major refactoring or redesign. The complexity of the entire system grows with each additional component added.

Complex organisation structures

Different expertise is required in a project, but does this necessitate the formation of separate teams for each specialty? Finally, it is the same product, development lifecycle, and goals. So, why are there 50 engineers and 12 teams?

The Spotify model is one example of this, which is unfortunately extensively exploited in the business. This concept enables enterprises to extend their workforce and form highly autonomous teams with extensive interaction on their work and the authority to alter any system. However, this necessitates a high level of governance, control, and discipline over the technologies being developed, which many startups lack in their engineering teams.

No matter how much effort you put into designing an organizational structure that aligns with your ideal vision for the company, people will inevitably deviate from it. Human interactions are inherently complex and dynamic, and when two teams that rely heavily on each other are separated by poor communication, they will find ways to maintain a connection, which will be reflected in the architecture of the system.

According to Conway’s Law, the structure of a system will reflect the structure of the organization that produced it. The law is named after Melvin Conway, a computer scientist from the United States who suggested it in 1968.

People will inevitably diverge from an organizational structure that is designed to coincide with your ideal vision for the firm, no matter how much work you put into it. Human relationships are naturally complex and dynamic, and when two teams who rely heavily on one another are separated by bad communication, they will develop methods to stay connected, which will be mirrored in the system’s design.

The hidden cost of new team members

Increasing team capacity always has a cost. Eight programmers will not produce twice as quickly as four. So, how do we compute this?

• It depends on the team seniority distribution, a team with only seniors will be less affected than a team with 1 senior and many juniors.

• Keep in mind that every new joiner will require help for 3 to 6 months and you allocate 3/4 person time on onboarding and that time will change over time.

  1. 1st month 3/4 time allocated on onboarding for 2 person
  2. 2nd month 1/2 time allocated
  3. 3rd month 1/3 time allocated
  4. 4th month 1/4 time allocated
  5. 5th month 1/4 time allocated

  Those numbers can change depending on how good is the person onboarding new colleges and/or how experienced is the new joiner.

• If the project is late, adding more people is going to be even more just by adding one single person.

What to do instead?

Expanding the development team may not always be the ideal choice for maintaining a consistent pace of product development while keeping clients pleased. Rather of adding new members to the system, another strategy may be to focus on developing a more linked network within the present team.

Scale-free networks, which allow for more effective communication and cooperation within the team, can be a valuable tool for attaining this sort of scalability.

However, it should be highlighted that there is no simple answer to this problem. When it comes to scaling the team, my advice is to approach with care and focus on one area at a time. It can also be useful to have strong governance and empower teams to lead and pick their own methods of working and interacting.

If it is decided to extend the team, the choice should be made with a clear architecture in mind, and the teams should be built in such a manner that their communication patterns correspond with the system as a whole.

Many organizations and open-source initiatives have successfully expanded to millions of users without significantly expanding their internal organization.