Have you ever experienced that moment of panic when something breaks, and you have to track down “Bob” while he’s out of the office?

“Bob” is the only person who knows how to fix “that thing” that’s broken (again).

It’s not a fun experience, and unfortunately, it happens way too often.

Bob is what we affectionately call a “Knowledge Silo” in your company. The important information that is needed to run, fix, or update your application is not-so-safely stored inside Bob’s head.

Bob has probably worked there forever — he’s a permanent fixture in the company and will never leave - so it’s not that bad… or is it?

You may be confident that Bob will always be there to save you, but life is unpredictable and loves to throw you lemons (and there’s only so much lemonade you can stomach).

Let me show you how to identify and break down Knowledge Silos at your company so Bob can vacation in peace and you can stabilize your software.

‍

Step 1: Identify Knowledge Silos

I’m going to walk you through a triage-style approach to documenting your system. First, we need to “stop the bleeding” that happens when only one or two people know how to support and maintain your application.

‍

This starts with identifying who they are and what they know.

Investigate Support Tickets

Your support tickets are a great place to start. You can review any requests that were escalated to the development team for further investigation or fixes.

‍

First, look for any requests that were manually re-routed to specific people. This indicates that your team is aware that someone on the staff is better equipped to handle this request than anyone else. That’s a red flag.

‍

Second, if you have a system in place that routes certain requests to specific people each time, you may be  creating Knowledge Silos unintentionally. Those individuals will steadily become the only people who know how to solve that problem.

‍

In both scenarios, you’ll want to look for repetition. Make a list of similar support tickets that  keep going to the same person.

‍

Your list should also include anything that strikes you as odd. For example, maybe you notice that “any time someone has a request related to XYZ, it seems to go to Bob when I thought it would go to Jim.”

Talk to Your Team

Your team members are probably already aware of these Knowledge Silos, so take the time to talk to them and investigate. They might be the person everyone turns to when there’s a problem in a certain area, or they can identify someone that they call anytime something specific breaks.

‍

You can also ask questions like “which person would have the biggest impact on operations if they got sick or left the company?” Essentially, you’re looking for the people that would be the hardest to replace.

Assess Your Team Structure

If you have your workload broken up where certain people always attend to certain areas of the program, then you’re creating Knowledge Silos. Those people will be the most knowledgeable people in the company on that one part of the program, and it will be much harder for someone else to come in and make changes.

‍

You’ll also want to assess the different seniority levels and see if you have any scenarios where lower-level or newer employees are told “not to touch” certain things because they break easily. Senior members of the team will often try to keep new members out of things that only they know how to fix or that are more fragile because they don’t want to create extra work for themselves.

Step 2: Document the Repairs that “Bob” Is Making

The next step in the triage-style approach is to have “Bob” start documenting what he’s doing.

‍

By documenting Bob's work, you can create a playbook that enables other team members to more quickly and effectively fix issues that arise in the future, thereby reducing downtime and improving the overall efficiency of the team.

‍

Also, as the system evolves and changes over time, having a clear record of how it has been patched or modified can be useful if you decide to modernize your system in the future.

‍

But how do you go about getting that documentation from Bob?

‍

Identify the key areas of the system that Bob is responsible for maintaining and fixing. These might include specific components or subsystems, or processes for handling certain types of issues.

1. Set up a system for documenting Bob's work. This could be as simple as a shared folder or document library, or you might consider using a more formal documentation tool like a knowledge management system.
2. Work with Bob to identify the types of information that should be documented. This might include details about the specific issues he is working on, the steps he takes to fix them, and any lessons learned or best practices he has developed.
3. Encourage Bob to document his work as he goes. This could involve asking him to take notes or create documents as he works, or setting aside dedicated time for him to document his work.
4. Review and revise the documentation regularly. Make sure that the documentation is accurate and up to date, and consider incorporating feedback from other team members or stakeholders.
5. Communicate the importance of documentation to the rest of the team. Make sure everyone understands the value of documenting Bob's work and the role they can play in helping to maintain and update the documentation.

‍

It might take some time to document everything Bob knows about the system, but you won’t regret it. That documentation is your safety net and your first step toward breaking down the knowledge silos in your organization.

‍

Next, you’ll want to start looking at the rest of your system and getting it documented as well.

Step 3: Document Only the Critical Workflows

Now that you’ve triaged the immediate situation with “Bob,” it’s time to make some changes so you don’t create more Bobs in the future. The first thing you need to do is create or update documentation for the rest of the system — starting with critical workflows.

‍

A critical workflow is just a fancy way of saying the important steps that need to happen for a business or organization to keep running smoothly. Basically, it's like a choreographed dance where each step depends on the other. These workflows are so crucial that if anything goes wrong, it can seriously affect the business.

‍

If you don’t currently have documentation, you will likely be reverse engineering it by having your team click through the various screens. It can be time consuming, but it’s well worth the effort.

‍

Here are some steps you can take to create or update documentation for the critical workflows in your system:

• Prioritize the critical workflows in your system. These are the processes or sequences of tasks that are most important to the operation and success of your system. You will want to engage business stakeholders to help you identify and prioritize which critical workflows need to be documented.
• Review and assess any current documentation for these workflows. This might include process flows, user manuals, technical documentation, or other types of documentation. Determine what information is missing or out of date, and identify any areas where the documentation could be improved.
• Determine the appropriate level of detail for the documentation. Consider the audience for the documentation and the level of technical expertise they have.
• Create or update the documentation as needed. This might involve writing new documentation from scratch or updating existing documentation to reflect changes in the system.
• Review and test the documentation to ensure that it is accurate and easy to follow.
• Communicate the availability and importance of the documentation to the rest of the team and stakeholders. Make sure everyone knows where to find the documentation and understands how it can be used.

‍

Overall, the goal of creating or updating documentation for the critical workflows in your system is to ensure that everyone who needs to use or work on the system has the information they need to do so effectively and efficiently.

Step 4: Document the Entire Tech Stack

To continue the process of preventing future knowledge silos, you probably want to document other aspects of your system, such as the underlying technologies and any integrated applications.

‍

Documenting your entire tech stack is about more than just making a list of the different parts of the system. It’s a more in-depth process that’s all about making sure the system runs smoothly and stays up to date. The goal is making sure everyone knows what’s going on so if they need to make changes or updates, they can do them quickly, easily, and with predictable results.

‍

This can be especially important if you are behind on version updates or if you have made significant changes to your system recently and things aren’t running as smoothly as they used to.

‍

Here are some steps you can take to document your tech stack:

• Review and assess any current documentation. Determine what information is missing or out of date, and identify any areas where the documentation could be improved.
• Identify all components that make up your system. This includes programming languages, frameworks, databases, front-end tools, back-end tools, and any integrated applications. You’ll also want to document what versions of these systems you’re using and if they are up-to-date or behind.
• Engage with internal engineering and product stakeholders. Talk with stakeholders within your organization to ensure that you have a complete understanding of all the technologies and integrations that make up your system. This can help you identify any gaps in your documentation and ensure that you are capturing all the necessary information.
• Create or update the documentation as needed. This might involve writing new documentation from scratch or updating existing documentation to reflect changes in the system.
• Review and test the documentation to ensure that it is accurate and easy to follow.
• Communicate the availability and importance of the documentation to the rest of the team. Make sure everyone knows where to find the documentation and understands how it can be used.

‍

Overall, the goal of documenting your tech stack is to ensure that everyone who needs to update or modify these components has the information they need to do so effectively and efficiently. This can help improve the overall stability and reliability of your system and prepare you for being able to modernize it in the future.

Step 5: Assess The Advantages of Modernizing

Upgrading to a modernized system has several advantages in terms of preventing the creation of future "Bobs".

‍

Basically, when you upgrade to a modern system, you're making things easier for everyone. You don't want to be stuck relying on one person who's been there forever to keep everything running. With a modern system, you'll have things like clear instructions, a wider base of trained programmers, and easy-to-use tools, so anyone on the team can help maintain and update the system.

‍

This way, you don't have to worry about "Bob" being the only one who knows what's going on. The system will be more accessible, and you'll have less of a chance of having everything ride on one person's shoulders. A modern system not only helps to prevent the creation of a single point of failure (i.e. a "Bob"), but also reduces the workload and improves your overall efficiency.

‍

Here are some steps you can take to assess whether it is time to modernize your legacy systems:

1. Evaluate the current state of your system. Consider factors such as the age of the tech stack and any issues or challenges you have encountered while maintaining and supporting it.
2. Identify the business objectives and goals that your system needs to support. This might include things like increased efficiency, improved customer experience, or enhanced security.
3. Review customer satisfaction. Consider whether the current state of your system is meeting the needs and expectations of your customers, and whether it is contributing to their satisfaction and loyalty. You may want to gather feedback from customers through surveys or other means to get a better understanding of their experience with your system. If you find that customer satisfaction is low or that the system is not meeting their needs, this could be a sign that it is time to modernize.
4. Determine the gap between the current state of your system and your business objectives and goals. Consider how well your system is meeting these objectives and whether any changes or upgrades are needed to further your goals.
5. Assess the cost and benefits of modernizing your system. Consider factors such as the cost of implementing changes or upgrades, the potential return on investment, and the impact on your team and stakeholders.
6. Develop a plan for modernizing your system. This might involve identifying specific changes or upgrades, establishing a timeline and budget, and identifying any resources or support that will be needed.

‍

Overall, the goal of assessing whether it is time to modernize your legacy systems is to determine whether changes or upgrades are needed and to develop a plan for making those changes in a cost-effective and practical way.

Bonus: Get Outside Help

You’re probably familiar with the phrase “You can’t see the forest for the trees.” Basically, it’s much harder to see what needs to be done when you’re too close to the problem.

‍

If you know that your documentation is in shambles — especially if you’re considering a legacy modernization project and don’t have a complete set of requirements — then this might be a great time to bring in outside help.

‍

We can help you reverse engineer your legacy system and make it through the documentation process, as well as help you address any problems that are costing you customers or creating security concerns. Our experts can help you prepare for upgrading while balancing maintenance on your old system.

‍

Schedule a Free Consultation with our experts today to see how we can help you.

‍