An E6 and I recently joined an existing team and are working with an E6 who has all the historical context on the project's requirements/limitations in his head. The PM is brand new to the team and the company. The EM and designer are also fairly new. The newer E6 often proposes architectural directions that the more tenured E6 shoots down due to this context. Is there a good way to extract all this context from the more tenured E6? I feel like we're often throwing things on the wall and just seeing what doesn't get shot down -- things get shot down more often than not, unfortunately. The more tenured E6 said it'll take too long to document all the context.
I feel like the burden is on the more tenured E6 to share that knowledge, rather than it being a guessing game of "let's see what the senior engineer approves of".
Can you encourage the established E6 to share their knowledge, and setup some system to track progress? Sometimes writing down the knowledge is daunting, perhaps there could be another format? Just a brownbag or 1:1 session. Doing this also sets a soft deadline for them to put their knowledge in one place (whether that's a wiki, verbal conversation, or set of slides).
At the same time, I wouldn't make this E6 engineer a SPOF. Can you talk to other engineers, read wikis, or do your own digging to get a better understanding of what the codebase?
I have had a similar situation where a very senior engineer worked in the same team and in the same role for some time(like 20 years). Consequently, he was SPOF for 10-15 critical projects/microservices. Everyone else who may have worked on these had already left.
He would be hesitant to share their knowledge and, when asked, would draw circles around the concepts.
They often derail themselves when explaining things, making it extremely hard for the other person to understand.
This is what I have seen to have worked.
* try solving more minor relevant bugs related to it.