4 ms·

I strongly agree: "The mantra of sharing your work and involving everyone in decisions naturally leads to inviting and copying people into things that add no v

I strongly agree: "The mantra of sharing your work and involving everyone in decisions naturally leads to inviting and copying people into things that add no value to them, or you." Fred Brooks, in his book The Design Of Design, includes a section on "The Magic Power of Teams Of Two". In his opinion, large teams cannot get anything done, and most innovation comes from individuals, but Brooks feels that teams of two people are the sweet spot for innovation. You and one other person -- if that other person can challenge you in the right way, offer a different perspective, or fill in holes in your knowledge, then instead of slowing you down, they speed you up. I personally have found that meetings of two people (me and one other person) are where all the most important conversations happen about solving problems or plotting strategy. I wrote about that in "Truly Agile development revolves around one-on-one meetings, not daily standups": http://www.smashcompany.com/business/truly-agile-development-revolves-around-one-on-one-meetings-not-daily-standups http://www.smashcompany.com/business/truly-agile-development...

mach1ne 4y ago
I can attest to this. Furthermore, teams of two make it more difficult to check out of a shared problem and allow the other team members to do the work, thus it improves the overall performance.
usrme 4y ago
I, personally, feel that instead of two it would need to be three to have a more diverse set of opinions and to break any stalemates. I've worked for many years with just one other person and the number of times where we had ideological differences and not enough exposure to alternatives are innumerable.
- layer8 4y ago
  The one-on-one meetings don't always have to be with the same person. And of course, the particular person matters, some can be more of a hindrance than a benefit.
- lkrubner 4y ago
  Yes, to be sure, I need to be more careful how I phrase this. I recently consulted with a VP of engineering who liked to bring 9 engineers together to review a database schema. I suggested more one-on-one meetings. He said, "Yes, I know you like less chefs in the kitchen." But that was not true, so I clarified with him: "I think it is great that you meet with those 9 engineers, but you should consider meeting with them either one at a time or maybe in groups of twos. The problem is that with nine people, on one video call, the conversation will either last 6 hours or some people won't be able to voice their concerns. There is a risk that the comments will remain at a general level. If you want to dive into the details, and surface the real risks of a given model, then hold smaller meetings. And really, the only purpose of those meetings is to surface the risks you face, so there is really no point to those larger meetings. Hold smaller meetings and surface the risk. But I am 100% okay with the idea of meeting with all 9 engineers, if you have the time to do that. Just meet with them in small groups. (And if you don't have the time to hold 7 or 8 or 9 separate meetings, then be strategic about who you meet with --- that is one of the most basic skills of leadership, knowing how to invest your time."
  - lkrubner 4y ago
    For anyone interested, I did write a small book on the theme of personal connections and face-to-face communication, being more important than processes or tools: https://www.amazon.com/meetings-underrated-Group-waste-time-ebook/dp/B09SFRNJKS/ https://www.amazon.com/meetings-underrated-Group-waste-time-...
bstpierre 4y ago
It often feels like “teams” of 1.5 work really well. Basically this is one person doing the work, with one other person who is very much in the loop but not actually on the hook. The worker is getting the job done, and the consultant is offering ideas, questioning some decisions, reviewing WIP, and generally supporting the worker. Having been on both sides of this, I think that the little bit of distance that the consultant has from the immediate problems of the job, while still having awareness of a lot of the context, can really accelerate the work.
- vanderZwan 4y ago
  I think you're onto something - I have a friend with whom I collaborate a lot where it feels like that. We're always working on our own thing, rarely on a truly shared project, so we're basically two "1.5 sized" teams. It's amazing
  - JJMcJ 4y ago
    Someone, I can't remember who, wrote an article where he said that 1.5 is the optimum team size.
- michaelrpeskin 4y ago
  Great insight! I always look back at my high-school internship at a real software company back in the 90's. I spent at least half my day sitting in the cube of the old unix greybeard (literally) just watching him code and once in a while asking what he was doing. It seemed like a waste of time, but 1) I became a really good c programmer from multiple summers of watching an expert, and 2) since I really wasn't in charge of typing, I had a second stack going in my head and when he would ask "what was the query we just sent to the database" or something like that, I'd remember and keep him going. So I think I helped him as much as he helped me. I often try to recreate that with interns and juniors at my current job, but everyone is so anxious about not typing or not submitting commits they don't stay and watch me work. Plus I think I'm less comfortable with silence than my old mentor was. He didn't care if I was sitting beside him for a hour while he was quietly hacking away. I tend to feel the need to explain a bit too much about my thought processes.
JJMcJ 4y ago
Not Brooks, but someone estimated productivity goes up about as the 0.7 power of team size. Using that exponent, two people can do 1.6 times as much work as one person so each is about 80% as productive. Ten people can do 5 times as much work as one person, so each is half as productive. Twenty five people can do 9.5 times as much work, and each member is 38% as productive as single person. Split those twenty five into five non-interacting teams of five people, and they can do 15.4 times as much work as one person. Obviously real life isn't as precise as these formulas, but they provide some guidance. This book https://www.microsoftpressstore.com/store/rapid-development-9781556159008 https://www.microsoftpressstore.com/store/rapid-development-... has tables about the limits of what can be done. The biggest takeaway is that some projects simply can't be done faster than a certain way limit. The only way around those limits is to find a way to reduce the size of the project. Either cut scope, or find a way to write less code, typically with a more powerful programming environment.

mach1ne 4y ago

I can attest to this. Furthermore, teams of two make it more difficult to check out of a shared problem and allow the other team members to do the work, thus it improves the overall performance.

usrme 4y ago

I, personally, feel that instead of two it would need to be three to have a more diverse set of opinions and to break any stalemates. I've worked for many years with just one other person and the number of times where we had ideological differences and not enough exposure to alternatives are innumerable.

layer8 4y ago
The one-on-one meetings don't always have to be with the same person. And of course, the particular person matters, some can be more of a hindrance than a benefit.
lkrubner 4y ago
Yes, to be sure, I need to be more careful how I phrase this. I recently consulted with a VP of engineering who liked to bring 9 engineers together to review a database schema. I suggested more one-on-one meetings. He said, "Yes, I know you like less chefs in the kitchen." But that was not true, so I clarified with him: "I think it is great that you meet with those 9 engineers, but you should consider meeting with them either one at a time or maybe in groups of twos. The problem is that with nine people, on one video call, the conversation will either last 6 hours or some people won't be able to voice their concerns. There is a risk that the comments will remain at a general level. If you want to dive into the details, and surface the real risks of a given model, then hold smaller meetings. And really, the only purpose of those meetings is to surface the risks you face, so there is really no point to those larger meetings. Hold smaller meetings and surface the risk. But I am 100% okay with the idea of meeting with all 9 engineers, if you have the time to do that. Just meet with them in small groups. (And if you don't have the time to hold 7 or 8 or 9 separate meetings, then be strategic about who you meet with --- that is one of the most basic skills of leadership, knowing how to invest your time."
- lkrubner 4y ago
  For anyone interested, I did write a small book on the theme of personal connections and face-to-face communication, being more important than processes or tools: https://www.amazon.com/meetings-underrated-Group-waste-time-ebook/dp/B09SFRNJKS/ https://www.amazon.com/meetings-underrated-Group-waste-time-...

bstpierre 4y ago

It often feels like “teams” of 1.5 work really well. Basically this is one person doing the work, with one other person who is very much in the loop but not actually on the hook. The worker is getting the job done, and the consultant is offering ideas, questioning some decisions, reviewing WIP, and generally supporting the worker. Having been on both sides of this, I think that the little bit of distance that the consultant has from the immediate problems of the job, while still having awareness of a lot of the context, can really accelerate the work.

vanderZwan 4y ago
I think you're onto something - I have a friend with whom I collaborate a lot where it feels like that. We're always working on our own thing, rarely on a truly shared project, so we're basically two "1.5 sized" teams. It's amazing
- JJMcJ 4y ago
  Someone, I can't remember who, wrote an article where he said that 1.5 is the optimum team size.
michaelrpeskin 4y ago
Great insight! I always look back at my high-school internship at a real software company back in the 90's. I spent at least half my day sitting in the cube of the old unix greybeard (literally) just watching him code and once in a while asking what he was doing. It seemed like a waste of time, but 1) I became a really good c programmer from multiple summers of watching an expert, and 2) since I really wasn't in charge of typing, I had a second stack going in my head and when he would ask "what was the query we just sent to the database" or something like that, I'd remember and keep him going. So I think I helped him as much as he helped me. I often try to recreate that with interns and juniors at my current job, but everyone is so anxious about not typing or not submitting commits they don't stay and watch me work. Plus I think I'm less comfortable with silence than my old mentor was. He didn't care if I was sitting beside him for a hour while he was quietly hacking away. I tend to feel the need to explain a bit too much about my thought processes.

JJMcJ 4y ago

Not Brooks, but someone estimated productivity goes up about as the 0.7 power of team size. Using that exponent, two people can do 1.6 times as much work as one person so each is about 80% as productive. Ten people can do 5 times as much work as one person, so each is half as productive. Twenty five people can do 9.5 times as much work, and each member is 38% as productive as single person. Split those twenty five into five non-interacting teams of five people, and they can do 15.4 times as much work as one person. Obviously real life isn't as precise as these formulas, but they provide some guidance. This book https://www.microsoftpressstore.com/store/rapid-development-9781556159008 https://www.microsoftpressstore.com/store/rapid-development-... has tables about the limits of what can be done. The biggest takeaway is that some projects simply can't be done faster than a certain way limit. The only way around those limits is to find a way to reduce the size of the project. Either cut scope, or find a way to write less code, typically with a more powerful programming environment.