How to extract project requirements and historical context?
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.
![Senior Software Engineer [E5] at DoorDash company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fdoordash_logo.png%3Falt%3Dmedia%26token%3D63a71c81-266b-463f-ac58-c18d7ee2939d&w=48&q=75){kind=logo}
Discussion
(2 comments)- 22 years agoSenior Software Engineer at Intuit
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.- Record videos of the Knowledge transfer.
- Ask your manager for some time to review the code. Write some unit tests if you can. (In my case, it was hard because the code was written in legacy C++/C/fortran, so one couldn't write unit tests, and there wasn't a debugger too since the services ran over ibm/solaris machines) Hopefully, you have it easier than this.
- Document what that person tells you in confluence or wiki. The more that person's knowledge because commonplace, the more you can extract from them next time.
- 12 years agoMeta, Pinterest, Kosei
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?
