2

When there is a situation that 2 small teams merge to form a bigger one, in the start there will be within the team two different sets of domain experts.

This situation has the advantage that specific topics can be resolved very fast when handled by a person from the corresponding expert subset. The disadvantage is having bus factor in the team.

So is the most beneficial setup to have a balanced knowledge in the team i.e., people knowing enough about a topic without being experts, and what would be a good way to migrate to such a situation? Would it be people picking up tickets from the other domain with the explicit understanding that the velocity will be lower for a while till the team catches up?

Are there any other alternatives?

Improve this question
1
  • Do you mean having a low bus factor? Every team everywhere has "a bus factor", but you need to decide what an acceptable value is for that factor for your team.
    – brhans
    Jul 22 at 20:27

2 Answers 2

Reset to default
3

Specialization is a benefit, not a problem

Specialization is what drives productivity. Everyone cannot know everything. A thousand years ago, one could not be a smith, builder, farmer, miller, mason, tailor, etc. at the same time. These tasks turned into full-time professions, and everyone benefitted. This is only exacerbated in modern times.

I'm not clear how merging teams affects the "bus effect." All roles should have backups, and people with unique skills should be treated as gifts, not expected commodities. This is true no matter how large or small a team is.

You tag the question with software development, but all teams function the same basic way. Do you really want your DBA learning UX just to diversify your team? Similarly, you wouldn't have a mechanical engineer design an electrical substation and an electrical engineer do steam piping just to build redundancy. I suggest that better is understanding the skills required to run the business (or implement the project), staffing the effort appropriately, and then ensuring that there are backup plans for everyone in case of your hypothetical bus. Put in place knowledge management practices to document the things that only a few know how to do. But I feel that having people who are highly experienced in certain tasks is a good thing, not a problem to be avoided.

Improve this answer
1
  • What you say is a good point. This case though is not about such roles. It is about set A of developers owning a set of services/apis supporting business functionality D,E,F and set B of developers owning a set of services/apis supporting business functionality X,Y,Z and now they are one team supporting DEFXYZ
    – smith
    Jul 21 at 7:33
2

I think that the situation you described is correct: at first the two sets are quite disjoint, and with time those differences start to diminish until the two sets become one.

You are asking how to carry on with that process of becoming less disjoint.

Would it be people picking up tickets from the other domain with the explicit understanding that the velocity will be lower for a while till the team catches up?

Yes, that seems like an option. Assign some (or all) of the tickets to "opposite" set of experts, so they can start getting up-to-speed.

Naturally, the time to solve those tickets will be greater or equal to the time it would have taken to someone who is an expert. To balance things (expectations and knowledge gaining, mostly) you can decide which and how much of those tasks to be given to the other expert team (more tasks, slower delivery, faster learning... less tasks, faster delivery, slower learning).

Are there any other alternatives?

One I can think of is to pair one expert from one set with an expert from the other set, and have them work as a team/couple. That way you can balance delivery time with learning time, as now all team/couples are experts on both topics.

This also enables agile practices, like pair programming, test driven development, etc..

Improve this answer
3
  • 1
    Do you think there is any situation that keeping distinct subsets of experts advantageous?
    – smith
    Jul 20 at 20:49
  • 1
    I can think of one: when the tickets/development involved on subject A and B are balanced. That is, if you get 10 tickets weekly, if ~50% of those are about subject A (thus, more "fit" for one of the expert teams), then keeping them separate would make sense... all tickets of topic A go to their team, and the same for topic B... if such ratio A/B is not predictable or varies considerably, then "merging" the teams could make more sense, so everybody is an expert on A and B and anyone can handle any ticket.
    – DarkCygnus ♦
    Jul 20 at 21:11
  • 1
    @smith however, if you say that the team was merged, I suppose that A and B are not so different from each other, and that it is logical to expect that everyone can eventually be experts on A and B. When both are merged and everyone is now A and B expert, your bus factor will go down.
    – DarkCygnus ♦
    Jul 20 at 21:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .