Pairing, staggering, inversing, iterating
Yeah, that was at least part of the idea. Also, a conversation between 2 is run differently than between 3 - and my gut feel is that it may be helpful in this case. If I remember correctly the Netherlands have a law that says (in some sectors) you are not allowed to work alone (for safety reasons). But it may pay off in other places as well. Overhead is to a large degree a question of effective management (unfortunately seems to be at least partially sucked into the (academic) economics clusterf***). In other words, I don’t want anyone to picture clean handed, tie wearing, people external to the process, who claim to be managers or consultants.
Another advantage for groups of 3 is that with two connections you are more likely to get a linear info spread which is very fragile (weakest link). If the info spreads through a highly branched and connected structure - (some of) it is more likely to get to point B. Also it’ll morph differently along different routes - both a blessing and a curse. But if the raw data is kept, it is mostly helpful and enlightening. Thus my preference of groups of 3, one junior (most active), one senior (moderates junior, and encourages:), one (or two) beginners (helps with simple stuff, asks questions about complex stuff, makes sure documentation is there and useful, and substitutes for junior if one is needed). That way you can build a (widening) talent pipeline, and spread work and info effectively.
Ideally I managed/supported multiple projects to have them complement each other in different phases and have people inverse roles when contributing to such a related project (senior in mature project → hops into beginner role in a supporting or sequel-project). If possible I liked to split projects into a couple of self similar phases with different scale and emphasis. Each phase would typically break down ino: dream, work, triage & assess. For advanced technology demonstrator type work I liked a relatively intensive dream-stage (experts & beginners separate, then mixed, borrow some people) that would also be relatively detailed in the end - to be able to forecast requirements for the critical backbone. If time is short I would start the alpha version (the fast, sloppy, and a the edges) staggered but essentially parallel to the first beta version (balanced performance with reliability). In the alpha version you do “dump-documentation” that has a lot of data but little structure. Alpha is half expected to fail/burst into flames before assessment is fully completed to see how-low-can-you-go (la-la-lalala-lala) on error margins. This informs the progressive elaboration of the beta version. If things work well in the first iteration, you do a second one to see if it was luck, and focus on documentation - cause you’re probably onto a good solution. If you kind of missed your aims, you check if it is possible to dream up good aims that fit what you made. Usually though you will feel that you’re on the right path, but it just needs more work. A lot more work. If that doesn’t seem to help you probably need to ramp up assessment and spread it throughout the project. Each new iteration is a good opportunity to bring in new people (and also let a few go). I would not want to make a lot of strict rules though. I’d rather welcome the opportunity to point out the difference between an “excuse” and a “good excuse”. This all however is based on technical projects that are probably some of the easiest to handle in principle. If you have strong outside influences (seasons) or complex living things (social aspects) to consider, this shoe would probably not fit on every hand…