Most start-ups have a tower of knowledge. They are typically employee 3 and the one who helped build the system from the ground up. They understand every line of code better than even the CEO and, if they ever leave, the entire company would be scrambling.
Sometimes, when the Tower of Knowledge knows they are the Tower of Knowledge, it can lead to a power imbalance as they ask for more salary/perks. If they feel like they aren’t recognized enough, they can exhibit asshole behaviours. When this happens, it affects the entire company and lead to culture troubles. Once you have a Tower of Knowledge, they might be reluctant to share their knowledge with others since knowledge can be perceived as power. And if they ever leave, depending on the size of the start-up, it can lead to big trouble.
So how do you avoid having a Tower of Knowledge? There is no easy solution. It’s far easier to let someone become a Tower of Knowledge or have multiple Towers of Knowledge in different silos. Cross-functional teams can help to have more than one person up to speed on where a product is but it isn’t a perfect solution since each person still knows their piece of the puzzle the best.
Here are some ways to help avoid or reverse a Tower of Knowledge.
Try Peer Coding
This means that everyone works in a team of two from developers to marketers. No one completes their work alone. The result is that two people know every line of code written and it reduces errors since two people must agree to the code as it is written. While this can increase labour costs, the savings by having fewer errors creating a product with fewer bugs and crashes makes up for this cost. Menlo Innovation uses the peer system and has its developers switch partners every sprint to continue to share and spread the knowledge. They never have to worry about sick days cause someone knows what the sick person knows and can do what the sick person does. If peer coding isn’t an option, try having people cycle through different responsibilities on the team.
Standardize Code Commenting
On a smaller team, having a standardize method to comment on code is one way to avoid messy code that is hard to follow and ensures that everyone can follow along the thought process of other developers. Good comments are ones that clarify the intent and logic, and do not simply restate the code. It’s also important to use descriptive variable names. This might mean as the founder/CEO in the early days, you review the code daily to ensure that it is being properly commented and to enforce commenting. While it might seem like a waste of time when you are just starting out, you and your investors will be thankful for the savings in time and money down the line when you have multiple developers working. Having this process from the beginning will make it easier to enforce as the team grows.
While this method can take the longest, it’s a good way to have the Tower of Knowledge share everything they know. This applies not only to the tech team but across the organization. If there are round about ways of getting things done, that no one would know if that person leaves, have them document it. Just listing what they do without knowing how they get it done, can leave their replacement with a much longer and steeper learning curve. Others may not understand why they aren’t getting up to speed faster. In the documentation, it should not become a tool to criticize how someone is getting their work done. Remember the designer who made a winding path through the park, and the trail of dead grass that users created to get through the park faster. You want your processes to follow that user-generated route so if you notice in the documentation that processes aren’t being followed as designed, it’s time to redesign them. Once a process is documented, you can institute weekly lunch and learns so that knowledge is shared across the team and the presentation is saved as part of the onboarding package for new employees.
If your organization doesn’t have a Tower of Knowledge, how do you avoid having a Tower of Knowledge?