Ad-hoc team design sounds excellent for solving a problem or delivering a specific project part. However, in this situation, many things appear as an afterthought. Because each team builds tech debt and tries to solve it after some time. When people leave the team, and a few people are destined to maintain all systems somehow, the team’s delivery gets a huge hit, and morale swiftly decreases. The remaining team cannot handle the workload, and it becomes more and more challenging to maintain the whole system.
Shuffling team members is often called team fluidity—teams change once in a while—while expecting people to learn different parts of the project and tech stack quickly. This is often an anti-pattern because it demands individual and system fundamentals to be strong. When someone moves from Team A to Team B, the onboarding has to be smooth and easy, the tech stack, frameworks, and infrastructure must be built in the same way, documentation has to be strong, and domain knowledge shouldn’t be a significant problem to learn. Also, once a person leaves a team, they leave behind a system to maintain, often taking their knowledge. Getting all this stuff right is difficult.
- Related Note(s):
- Source(s): Team Topologies by Matthew Skelton and Manuel Pais;
Preview: