Sharing is Caring (Bus Factor)
You can do so much on your own! And, you can do much more with a team!
Regardless of your position on the team, have you ever wondered what would happen if the key person were no longer available? Let's say, what if they got hit by a bus? Win the lottery? Today? Tomorrow? Next week?
Bus factor - is a minimum number of key people that have to disappear before the project collapses. This idea highlights an important question: Are you truly working as a team, or is your project in sharp decline due to over-reliance on very specific individuals?
Of course, there is no need for all team members to equally know everything or being absolutely replaceable at any time. And, at the same time, do people feel confident to go on vacation? To take a sick day? Delegate code review at busy times? Trust others to represent the team on some meeting?
Do you have documentation people can use in case of absence of the key person? Playbooks? Do they frequently share and explain their technical decisions and vision? Do you have an architect who is not very good at written or verbal communications and is not capable of explaining the "why" behind their requests?
Do you have a person who is really proud they've built the entire system? All by themselves! And even more proud to single-handedly and heroically support it on Sunday morning? What happens to the project and the managers when that person goes on vacation? Do they grab the laptop w/ them because they think that no one is capable of handling anything?
How good is your manager? What would happen if they go on vacation? Change the job? How do you onboard new teammates? DO you board new teammates or just throw them at the code?
What happens when the code owner is unavailable for a day or two? Are the people blocked? Can they be unblocked? What if it is a 3-week vacation?
When a single point of knowledge has a bus factor of less than 2 you might find the team in a very peculiar situation. Not only it can lead to a disaster when the person is unavailable, but it can also drastically reduce the productivity of your team in the long term.
What can you do?
Accept people's opinions. Not everybody is the same. Having alternative perspectives is a strength and the power of working as a team.
Make quality code reviews your team habit - both genuinely asking for people's opinion and providing clear explanations of your feedback to them.
Documentation - Write things down, ask for review, and own it.
Pair program - The forum where questions can find answers in their depths and as early as possible.
Delegate - Can't? Why not? Don't you trust your teammates to handle the situation?
Navigate - Don't know the answer? Do you know someone else who DOES know the answer?
Simplify - is your code and documentation easy to read and accessible to everyone?
Explain your decisions - Explain the "why" behind your choices to help others understand your point of view and learn from your thought process.
Teach and Learn - don't let people miss out on the learning opportunities even if it slows things down in the short term.
Share the knowledge, encourage solving unknowns, and foster collaboration! Be a good teammate and a good person.
Further reading: Bus Factor on Wikipedia.