4 ms·

> The main issue is that it does require good, empathetic management, long-term retention of experienced, capable people, and an "apprenticeship" model. To me

> The main issue is that it does require good, empathetic management, long-term retention of experienced, capable people, and an "apprenticeship" model. To me this sounds like an idealistic environment. I doubt this environment could fail with any sort of process (or lack thereof). Documents don't have to be "incredibly detailed, formal, approved-by-everyone-including-the-mens-room-attendant". Those are probably the worst kind. I do think that OP's/Googles design docs does seem to lean towards that, unfortunately. I wonder if that's how it is in practice? Especially given the length -- 10 to 20 pages sounds like it's too detailed for me. Though I suppose on bigger projects the sum of all the implementations of the moving parts can get quite large. One criticism I especially have of OP's "Review" section is they mention opening it up to a large audience. I am skeptical whether that is how it actually goes down. In my experience, opening something up to review by many people just ends up being a too-many-cooks situation. Pretty much what you're afraid of with "approved-by-everyone-including-the-mens-room-attendant". Those situations just turn into bikeshedding. In reality, I bet it gets opened up to everyone but only a couple people are actually expected to be the ones who give feedback on it. I still think I'd take the over-formalized process over tribal knowledge. What you don't see behind the scenes of tribal knowledge are people with a lot of it who constantly get interrupted to answer those questions. It ends up being very inefficient at scale. Not to mention the overhead that comes with the person trying to answer the question -- like finding old breadcrumbs about the problem like code or emails. Along with the worst enemy of work for a developer: context switching. I've been the person with tribal knowledge and it basically becomes your full time job. It was great for job security but I lament the amount of time I lost because I wasn't more proactive about writing documentation.

ChrisMarshallNY 6y ago
> What you don't see behind the scenes of tribal knowledge are people with a lot of it who constantly get interrupted to answer those questions. It ends up being very inefficient at scale. Not to mention the overhead that comes with the person trying to answer the question -- like finding old breadcrumbs about the problem like code or emails. Absolutely correct, which is where that "good management" comes in. I managed the team that I mentioned, earlier, and I'd like to think that I did it well. My single biggest task was to shield people from corporate shenanigans, take on as much of the structural overhead as possible, and be a "gatekeeper." I managed the team for 25 years. We got a lot done, in that time, but also suffered a lot of "lessons learned." I certainly made my share of mistakes; most of which were about me deprecating my "management shield" responsibilities, in misguided attempts to be a working team member. I kept my tech chops up in extracurricular open-source work. No one wanted to pay me for my tech skills.

ChrisMarshallNY 6y ago

> What you don't see behind the scenes of tribal knowledge are people with a lot of it who constantly get interrupted to answer those questions. It ends up being very inefficient at scale. Not to mention the overhead that comes with the person trying to answer the question -- like finding old breadcrumbs about the problem like code or emails. Absolutely correct, which is where that "good management" comes in. I managed the team that I mentioned, earlier, and I'd like to think that I did it well. My single biggest task was to shield people from corporate shenanigans, take on as much of the structural overhead as possible, and be a "gatekeeper." I managed the team for 25 years. We got a lot done, in that time, but also suffered a lot of "lessons learned." I certainly made my share of mistakes; most of which were about me deprecating my "management shield" responsibilities, in misguided attempts to be a working team member. I kept my tech chops up in extracurricular open-source work. No one wanted to pay me for my tech skills.