In pairing, a bi-directional pathway is established between Person A and Person B. This means that, during the activity of pairing, Person A's influence is exclusively dedicated to Person B, and vice versa. If everyone working solo is the baseline, meaning everyone only has the "1x influence" of their own work, then switching to pairing (if it works) increases this to 2x -- yourself and the pair partner.
In a traditional meeting where Person A is the speaker and there are N-1 audience members, Person A's influence is equally effective (ideally) across all N-1 unidirectional communication channels. If Person A is a really great engineer, from whom the other N-1 can all learn a lot, then leveraging just Person A at a factor of N-1 could be vastly more powerful than leveraging everyone but only at a factor of 2.
When you say things like:
> Nothing about pairing changes the number of people in a project, or the number of potential pathways between them (some might argue that it halves the paths, but that would be twisting the meaning of pathways).
it makes me think you misunderstood me, because I never claimed that pairing changes the number in a project or anything else.
However, you can't deny that in an environment where pairing is the expected modality for collaborative work, there truly is an emphasis on precisely the N=2 case, and other forms of communication necessarily have to be reduced to allow for pairing time and consistency in the act of pairing. It's not possible to do all other modes of communication and also pairing, because when you're pairing, you're necessarily not doing the other modes of communication.
My statements are about inherent limits to pairing. You can't extend the concept of pairing (based on 2 people) to triples, 4-tuples, and so on, without it leading to O(n^2) communication problems (e.g. if you tried to put 25 people together in one "mega pair-like group" it would be a big mess).
This is a bad property of pairing; exactly equivalent to saying that it does not scale.
I think the better way of phrasing it from my earlier remark was this:
When Person A is pairing with Person B, Person A is necessarily limited to only helping 1 person. If Person A is your best engineer, this is really bad. Telling Person A to stop doing pairing and to instead do all the same advice/Q&A tasks that would have been done during pairing and do them in some other way that scales (like user guides and SO) would immediately be better.
You can't have it both ways. At a certain moment in time when your best person is engaged in pairing, it necessarily means your best person is being wasted by having merely a 2x impact, instead of being pulled out of pairing and placed into some other activity that has a much higher factor of impact.
In real life, you'll never do any of these things perfectly, pairing or not pairing. But the point is that pairing is inherently not scalable, not even in principle.
It has nothing at all to do with whether your team also writes user guides or also answers questions on an internal SO site when they are not in the act of pairing. It's about the opportunity cost when they are in the act of pairing.
In pairing, a bi-directional pathway is established between Person A and Person B. This means that, during the activity of pairing, Person A's influence is exclusively dedicated to Person B, and vice versa. If everyone working solo is the baseline, meaning everyone only has the "1x influence" of their own work, then switching to pairing (if it works) increases this to 2x -- yourself and the pair partner.
In a traditional meeting where Person A is the speaker and there are N-1 audience members, Person A's influence is equally effective (ideally) across all N-1 unidirectional communication channels. If Person A is a really great engineer, from whom the other N-1 can all learn a lot, then leveraging just Person A at a factor of N-1 could be vastly more powerful than leveraging everyone but only at a factor of 2.
When you say things like:
> Nothing about pairing changes the number of people in a project, or the number of potential pathways between them (some might argue that it halves the paths, but that would be twisting the meaning of pathways).
it makes me think you misunderstood me, because I never claimed that pairing changes the number in a project or anything else.
However, you can't deny that in an environment where pairing is the expected modality for collaborative work, there truly is an emphasis on precisely the N=2 case, and other forms of communication necessarily have to be reduced to allow for pairing time and consistency in the act of pairing. It's not possible to do all other modes of communication and also pairing, because when you're pairing, you're necessarily not doing the other modes of communication.
My statements are about inherent limits to pairing. You can't extend the concept of pairing (based on 2 people) to triples, 4-tuples, and so on, without it leading to O(n^2) communication problems (e.g. if you tried to put 25 people together in one "mega pair-like group" it would be a big mess).
This is a bad property of pairing; exactly equivalent to saying that it does not scale.
I think the better way of phrasing it from my earlier remark was this:
When Person A is pairing with Person B, Person A is necessarily limited to only helping 1 person. If Person A is your best engineer, this is really bad. Telling Person A to stop doing pairing and to instead do all the same advice/Q&A tasks that would have been done during pairing and do them in some other way that scales (like user guides and SO) would immediately be better.
You can't have it both ways. At a certain moment in time when your best person is engaged in pairing, it necessarily means your best person is being wasted by having merely a 2x impact, instead of being pulled out of pairing and placed into some other activity that has a much higher factor of impact.
In real life, you'll never do any of these things perfectly, pairing or not pairing. But the point is that pairing is inherently not scalable, not even in principle.
It has nothing at all to do with whether your team also writes user guides or also answers questions on an internal SO site when they are not in the act of pairing. It's about the opportunity cost when they are in the act of pairing.