Software engineering teams define the lottery factor (aka bus factor) as “the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel. (View Highlight)
However, a lot of the siloed knowledge in data teams comes not from how to build something in progress, but rather existing systems, historical analyses, decisions, and events. If one person from the data team defined a key metric or designed a dashboard, they accumulated a lot of context in that process. (View Highlight)
The activities we suggest starting with for small teams continue to add value over time, so if your team is bigger and not doing these things yet, it’s not too late to begin. (View Highlight)
First data hire — get a head start on documentation
When you’re a team of one, there’s naturally a lottery factor. While it is unrealistic to eradicate the lottery factor entirely, there are still a few steps you can take to get started. But naturally, all of these are asynchronous (View Highlight)
If you are at this stage, you have enough on your plate as is. We are not going to lecture you on how important it is to build things elegantly or efficiently, or having perfect documentation. You want to get things done, quickly. But it is still possible to balance having some code comments. (View Highlight)
Whether or not you have consciously thought about it, you probably have a knowledge base. It can be in Google Drive, Confluence, Notion, or many other tools — but a central location for many different pieces of information is a valuable resource. (View Highlight)
Additionally, the knowledge base has greater and greater utility as more team members join and more notable, documentable things happen. (View Highlight)
The benefit of the knowledge base is contingent upon actually populating it with analyses, style guides, meeting notes, handy queries, and anything else relevant to your team members. (View Highlight)
Even just a date and a quick note about what happened is enough to be a big help to anyone who’s wondering a year into the future why sales spiked on a certain day, or why there were no signups for a three-day span. (View Highlight)
The changelog is valuable at any team size, so teams of one or larger would benefit from starting to capture knowledge today. It has been a huge value-add to our team at Future (data team of five, 40 data consumers), where there are frequent feature releases to our app and adjustments to our digital marketing strategy. (View Highlight)
Your team has just doubled in size from one to two members. Congrats! You are excited to have much more capacity once your new teammate is fully up to speed. (View Highlight)
you probably don’t yet have the documentation of your dreams built out. This places the burden of knowledge sharing on both of you — your new teammate needs to be proactive in asking questions and reading through existing codebases and data products, and you will need to spend a lot of face time with them demonstrating best practices and providing feedback on their initial work. (View Highlight)
Most data practitioners live out of a few tables in the data warehouse and know them well. However, if there are tables that only one or two people on the team work with, you carry some risk. Forcing team members to actually think about a query just once helps build familiarity. (View Highlight)
We gave team members about a week to complete it, and then conducted a screen-share to present results, and provide a venue for them to ask clarifying questions (View Highlight)
Pair programming is when two team members will screenshare or sit at the same computer and work together through a coding exercise (View Highlight)
Even if the new team members have adequate technical skills, it may take some time to assimilate into your team’s specific workflows and ways of doing things (View Highlight)
Whether it’s a pull request on a version-controlled codebase, a draft of a dashboard, or an analysis about to go out, having a peer review process is likely to improve many different types of deliverables (View Highlight)
This may be the stage where you consider structurally building knowledge redundancy via cross-training. If only one person works on a specific part of the codebase, others on the team should know the basics (View Highlight)
One practice that’s great for both onboarding and cross-training is recording videos for your knowledge base. (View Highlight)
Additionally, you can sit down in front of a key dashboard or piece of code, press record on Loom, and casually explain some of the design choices you made and anything else that seems notable. (View Highlight)
