Sometimes I complain about fragmentation or silos in organizations. Counterparts are sometimes offended, usually when they feel I’m applying those qualifiers to their own structure. It then becomes hard for me to convey the underlying point:
A certain degree of fragmentation is necessary. Too much of it is bad.
That’s pretty meaningless if you don’t define fragmentation somehow, so here goes:
If you swap the positions of two members of your organization, what are the chances that they will both perform (reasonably) well within a (reasonably) short timespan?
If the answer is close to 0, it likely implies that people are very specialised, and their activity and the tools they rely on are unique to what they do: in a swapped position, any member must re-learn almost everything about their job. Here I’d call the organization pretty fragmented.
On the other hand, an answer close to 1 means that almost everyone knows everything about how things function in your organization: switching seats has no impact on how someone works. This org' would be pretty homogeneous.
Small Or Big
In practice, the answer for any org' will fall somewhere between the extremes, and whether this is good or bad depends on its line of business: you obviously don’t want an expensive PhD to be spending his time on menial operational tasks, so there’s no point in training him do do this.
Additionally, and as my friend Chris says, trying to hire people that are verry proficient in exactly everything your org' does usually amounts to be hunting for a unicorn.
Now, this is not an excuse for letting a structure slip towards the fragmented side:
Healthy Adaptability
Our line of business, software, is characterized by an ever changing environment. Adaptability of an organization in this environment can make a huge difference.
Thus, I believe that being closer to the adaptable side is better, but not at any price. My interest in the last few years has been in finding ways to shift an engineering structure closer to homogeneity – as defined above – at reasonable cost, without attempting to train or find unicorns.
Ideally, it should be possible to re-allocate certain team members for reasonably short periods with only a minimal amount of friction when the business inevitably requires it.
One of the possibilities involves your toolchain, for example.