Ask HN: How can I work with OG engineers?
I have recently joined a company that has been around for a while but is still in startup mode. The team is fairly entrenched in its ways and has a handful of engineers who are "super effective" because they built every thread of complexity.
Besides finding the work incredibly unfulfilling, I'm concerned that this entrenchment will prevent growth of the company in the mid to long term. I am also concerned that as a fairly senior person (and having held a senior position prior), will be unable to meet what I consider the correct level of effectiveness for someone working at that level.
Onboarding besides the basic company introductions was very thin. The OG's don't have a team building mindset. I think it's probably more of a nuisance to them and they expect information to flow through question polling and osmosis.
I want to find a way to become an effective contributor to this team and someone who can lead and contribute a wealth of knowledge, but I feel that the OG's have reached a knowledge escape velocity that I will never be able to catch up with. Suggestions? Your framing is a bit off. How effective can these people really be if they can't transfer their knowledge to someone else? Fundamentally it does not matter how effective they are if they can't onboard new people and make them just as effective. Whatever company they're at has made them single points of failure and they will eventually hit scaling limits and be forced to actually externalize their knowledge and by that point it will probably be too late. If they don't understand all this then I recommend moving somewhere else. What you've described is not an effective engineering team. I have worked at a few places where the "OG"s as you say had left (and in one case a team member had actually died) and the part of the codebases they had worked on were essentially derelicts that no one dared touch. The knowledge was lost and there was no way to recover it because the initial engineering team did not plan for scalable practices for knowledge transfer. Fred Brooks said that programming is theory building and he was correct. A codebase is a theory that requires human understanding and requires practices that allow for the semantic maintenance of the theory across the engineering team. Gently bring up the issue of onboarding and effectiveness of new team members with management and see what they think. If they also don't see any problems then I doubt there is much you can do to rectify the situation. I understand what you're saying. What I was trying to illustrate was that by virtue of knowing the ins and outs of the codebase, it's easy for them to make changes (hence the quotes around "super effective"). It would be impossible to conceive or design a non-trivial feature without their input. For me it feels absolutely necessary to get to the point where I could effectively design end to end features without their input. I'm not convinced that leaving right now is the only solution, hence the question. If your answer to the question is "you don't, just leave" then that's fine, but I am hoping there are other strategies that I can personally bring to the table to make this team more effective. My answer isn't "you don't, just leave". My answer is that programming and effective engineering is a team sport. Not asking for input and feedback is counter-intuitive for me and frankly is a form of machismo that I would rather avoid. I'm not an effective engineer because I can ship code 24 / 7, I'm an effective engineer because I can transfer and translate business requirements into code and effectively communicate the semantics of the code to others contextualized with the business requirements that lead to the creation of the code.