How do you deal with the explosion of features and ensure that the knowledge is widely distributed/discoverable by the team?

This is such a classic growing big company problem. I dealt with this all the time back when I was at Instagram Ads, and to be honest, we could have handled it way better. I hope the following advice allows you and your team to be better than us 😅

• Invest more in automated tests
  • Start off with unit tests as those are the simplest and can catch a lot of low hanging fruit. If you're on web/mobile, I recommend moving on to snapshot tests next, and finally end-to-end tests.
  • This is something we did at Instagram Ads mobile too late. As soon as the classic "new thing broke important old thing" bugs started really cropping up, we should have super prioritized a massive test coverage workstream. We didn't, and we embarrassingly caused the same SEV multiple times sometimes.
  • Testing workstreams are a great way to create scope as a senior engineer and huge impact if things are already breaking a lot.
• Make your code self-documenting
  • Documentation is the best and most scalable when it's naturally embedded in the workflow. I am skeptical of efforts like creating a separate wiki to maintain information. It will be hard to keep them up to date.
  • In the code, have descriptive headers at the top of classes and leave comments on complex blocks.
  • Make sure that the "dressing" around your commits is top-notch. After the commit message, this mainly manifests in the code review. Have great titles for your code review, attach sufficient context, and add a detailed demo video to the test plan. This is covered more in the resources linked below. When done properly, this is such a blessing. I remember that I would edit a lot of legacy code back at Instagram and be very afraid of breaking it. I would blame the code to find the code review that landed the commit and then go through the demo video in the code review to make sure I didn't break this old code.
• Every New Project Should Leave A Massive Paper Trail
  • When you're small, you can ship things fast, often after just a single meeting and maybe a ticket with some context. That quickly becomes not enough as the team scales.
  • As the Instagram Ads org grew (and I grew), I got into the habit of creating a detailed "master spec" for every new project I picked up. This covered the product requirements in-depth and usually had a section covering edge cases. After the project shipped, I could easily just point newbies to these documents when they wanted to learn about this old feature I shipped.
• Plan More Before Coding Anything
  • Another habit I picked up back at Instagram was having a tech review meeting for any non-trivial feature. This was a meeting where I would gather tech leads, senior/staff engineers, and sometimes engineering managers, so all of us could discuss my approach to building the project.
  • I always allocated a portion of the meeting to discuss what could go wrong. This can be as easy as asking the lead engineer behind a component you're modifying, "What should I make sure doesn't break?" or "What part of your component is more error prone?".

Related resources:

• Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta
• [Masterclass] How To Do Amazing Code Review - This video is 1.5 hours long though, so if you're short on time, I recommend checking out these highlights:
  • What A Test Plan Is And Why Every Code Review Needs One
  • The Most Common Mistake Made When Authoring Code Reviews
  • The #1 Principle To Remember When Authoring A Code Review
• "What's the best way to carry out an end-to-end (E2E) testing effort?"

...how does one ensure that there are no pockets of knowledge or subject matter experts that exist within the team, but knowledge is decentralised, given that people can be on leaves or be unavailable sometime.

On top of the methods I described above, a very powerful tool here is good ol' fashioned mentorship. Here's some great resources to help with that:

• Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta
• "How can I help juniors?"

A less direct but more scalable way of distributing expertise is through office hours, which I talk about more here: "How can I teach and onboard other engineers faster?"

The sign of a good senior engineer/tech lead is that they're always striving to make themselves replaceable. Since you're a senior engineer, I hope some of those tactics help you uplift the team and make it more resilient while scaling yourself. 😊

To add on to the above, how does one ensure that there are no pockets of knowledge or subject matter experts that exist within the team, but knowledge is decentralised, given that people can be on leaves or be unavailable sometime.