How do you deal with the explosion of features and ensure that the knowledge is widely distributed/discoverable by the team?
In fast-paced organisations that launch a lot of features on a quarterly basis and teams with large sizes, how should a tech lead or team members ensure that everyone knows about everything or is enabled to get to know about it?
Quite often, whenever a new feature comes in, it could be repurposing technology built for other features as well. But, given the pace at which these are developed, it is often hard to know what everyone is working on. Sometimes, each of these features may have idiosyncracies that may be getting missed out by new joiners, especially due to the volume of information, especially for teams that have been in existence since a long time.
I recall once when changes for a new feature done by a developer reverted some conditionals for an older feature, thus causing an outage. How do you prevent this and ensure knowledge of everything is available to all, especially to people new to an organisation?
Also, are there some general practices to ensure that these are easily discoverable? Video recordings are time consuming to go through, and wikis though they exist, are sometimes difficult to navigate, when you don't know what you are searching for? I am thinking of something like a mind map could help here, but what are your thoughts?
Discussion
(3 comments)- 42 years agoSenior Software Engineer [OP]Grab
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.
- 112 years agoTech Lead @ Robinhood, Meta, Course Hero
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's the best way to carry out an end-to-end (E2E) testing effort?"
- Invest more in automated tests
- 6a year agoTech Lead @ Robinhood, Meta, Course Hero
...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:
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. 😊
