What to do when you have one technical expert in a given domain

Imagine the situation, whatever past decisions that have been made, where you were not involved, has resulted in a key product\system\thing, which has one person responsible for it, your one and only expert. Let’s make the scenario a little worse. The product\system\thing is niche, your person is agency, and no-one on the team wants to take it on. Your person is lovely, diligent, fits in the team, all the right things, but you can’t offer them a permanent position for whatever reason. Let’s imagine it could be worse; if they were abrasive, non-communicative, didn’t take direction, were not contactable and did what they wanted, wrote garbage code, caused production outages because issues weren’t identified in lower environments for whatever reason. It could be worse, so much worse «shudder».

PR’s are created, but they receive a cursory look over, receive approval and are merged. At times, issues are discovered whilst testing. Sometimes they’re discovered when deployed to production, resulting in having to roll back, revert, whatever. There’s delay in releasing features, which eats away at your teams’ reputation and trust, which you’ve all worked so hard to build and maintain.

This person is your single point of failure (SPOF) for a system which you’ve struggled to hire someone permanent for. This is not a good position to be in.

Indeed, what to do?

In the short term and day to day

I honestly felt a bit stupid that I hadn’t had this thought before as it’s so obvious. Mob on whatever ticket your SPOF is responsible for. That’s it! So simple!

The idea here is not to cross train the team to be proficient in the product, remember, no one whatsoever wants to take it on. Instead, the intention is for those who are affected by the outcome or results of the ticket are involved to gain an understanding of what, why, and how the SPOF and their product are involved. The mob has eyes on what’s being implemented and can keep track of the requirements and any details. The SPOF will demo the changes as they’re being made.

Now, when the PR is made, the mobbers approve it! They saw what happened. They questioned, checked, clarified, and ensure that the details were met. The PR gets created and there is bit more confidence that this PR won’t fall over, break production, whatever other negative outcome that has been experienced in the past.

The long term

This could be a bit trickier.

Consider whether this product is the most appropriate tool for the job according to supporting your strategy. If it is, you have a hiring problem: hire people that are going to do the job. This is perhaps unlikely.

I think you’re left with having to replace, or remove, the undesirable system out of your architecture.

Begin asking the many questions about what the system does:

  • What does it do?
  • Does this class\type of product still appropriate for what we need?
  • What could I do instead?
  • What else exists that provides similar functionality
  • How might deploy an alternative
  • Do we want to build our own? «careful with this one, ripping up and starting again for commodity functionality isn’t sensible»

You’re starting again to determine what needs to happen for this component in your solution space, which is compounded by existing processes and interfaces with the existing undesirable system, let alone getting to the point of being able to plan the migration.

There are some other options:

  1. You accept it as technical debt. But you’re just kicking the SPOF risk into the future.
  2. Pronounce the system as legacy, cease active development and only apply security patches and minimal upgrades, allowing you to adjust the staffing for it. Which still leads to replaceing the system…
  3. Replace it by organically strangling it out of existence, as opposed to a rigorously investigated and planned change to the architecture. This has the risk of producing a big ball of mud of a solution architecture, though it could also allow a suitable replcement to emmerge.

2025

Getting this site up and running

I’ve wanted to do some writing for a little while and had the thought of writing in markdown with magic (pipelines) that would magically transform markdown i...

Back to Top ↑