Are you frustrated by how slow, problematic and stressful delivering a new feature for your application has become? 

You may even think that this is a normal state of affairs, that there is supposed to be a constant and grinding battle between management and tech to get anything delivered. 

Well, it’s not, nor is it helpful to frame the problem as a dichotomy between departments in a company that is supposed to work together to achieve a common objective. 

However, that being said, there are an increasing number of companies that end up being hostage of their tech team. Typically, there will be one person that is the ‘oracle’, someone who has been in the company’s tech department for a long time, perhaps even from the beginning. A person that is always referred to for any knowledge about the intricate system workings and yet no one else seems to know what is going on.

However, as the company has changed and grown, the ‘oracle’ has not and they have merely solidified and entrenched their position by making themselves seemingly indispensable, to do this they may have: 

You may already be painfully aware of the situation and have concluded that there is nothing you can do about it. There is a way out.

I will stipulate now, the process of undoing this will be bumpy, frustrating and at times demoralizing, but by far and away and without a shadow of doubt, worth it. 

The ‘oracle’ was just a symptom of the problem and not the cause. Removing them won’t solve everything, because at this point the damage is already done. This situation often stems from broader company culture issues, though that’s beyond this article’s scope.

Regarding the tech team, as with any problem, first you have to admit you have one, then we must quantify it.  Seriously, the question you need to ask is “How f%@#ed are we from zero to ten? ” 

With regards to the application this requires analysis of your codebase as it currently stands and you may find that the reality of the situation is terminal and nothing can be done, in which case cut your losses and start from scratch with some fresh blood and strict standards. 

However, if your application is in the realms of resurrecting, you can check this by using the Refactor Calculator, which assists in making an informed business decision about whether to refactor an existing software application or completely rebuild it, without in depth technical knowledge. 

We must not replace action with endless quantification and measuring, falling into the trap of procrastination. Get the in depth analysis and get moving, a lot of the time this will involve breaking things, hold fast, this is normal.

It’s good to be reminded that at this point all applications will inevitably spiral into chaos, the only factor that we can significantly influence is how long that process takes. So if that is the based line assumption, any noteworthy deviation from chaos that improves our productivity, team morale and maintainability is worth it. 

So if resurrection is possible, how can we practically get all the application knowledge from the ‘oracle’ into the application? 

Well first thing first, set realistic priorities. These priorities will be clearly revealed in the analysis of your codebase, which is ultimately a list of shortcomings of the project and if it has been neglected for years there will be many issues. 

However, an unrealistic priority would be for example feature delivery at this point. It’s like trying to run on a broken leg, sure it’s theoretically possible, but it might create complications to say the least. 

Realistically, if you can stay functionality wise exactly the same for the next 6 months, but end up with a highly organized, efficient and standards compliant system that any developer can (and probably would want to) work on, then that would be worth it, right? 

The process is simple, from the analysis report, look at the list of required improvements, choose the smallest and easiest possible improvement that can be done now and do it. Then merge it into production and repeat. 

Of course there will be some more challenging issues or even large architectural problems that need solving. This is true and we must not shy away from these problems, however, we need change and we need it now, no matter how small. We are building the way in which we mean to continue, fast, light and adaptable. 

Technical solutions to larger problems can be found, the know-how is not the issue, the problem is having the will to improve and implement consistently and safely.

As these small fixes mount up and the application starts to be understandable, you may notice the shift in knowledge. It used to be tied up in one person, which made them appear to be busy all the time. This was an intentionally created bottleneck to make them seem indispensable to the business. But now you may see other team members contributing and engaging, because the application knowledge is in the application, not in a single developer. 

Breaking free from the grip of a single developer or a dysfunctional tech team is challenging, but entirely achievable. By recognizing the issue, thoroughly analyzing your codebase, and setting realistic priorities, you can start making incremental changes that lead to significant improvements.

Remember, the goal is to create a collaborative environment where knowledge is shared, and the application is maintainable by any developer. This process requires patience and perseverance, but each small step forward brings you closer to a robust, efficient, and agile tech ecosystem.

As your team begins to share the load and your application becomes more transparent, you’ll see a shift in productivity and morale. No longer will you be held hostage by your tech team. Instead, you'll cultivate a culture of cooperation and continuous improvement, paving the way for innovation and growth.

The journey may be tough, but the reward – a harmonious and high-functioning tech team – is worth every effort. Start today, stay committed, and watch as your company transforms into a well-oiled machine ready to tackle any challenge that comes its way.