Jackson is a go-to person when it comes to MongoDB. You have a problem – you go to Jackson.
Jackson is a go-to person when it comes to MongoDB.
You have a problem — you go to Jackson. He’s an expert. Of course, you can go to anyone else – it’s a free world. You can go to Molly if you want. But you know what Molly would recommend, don’t you? She’ll tell you to ask Jackson, that overworked guy with a giant todo list.
Let’s talk about what to do if you ended up being a Jackson and need a way out.
What kind of a bottleneck are you?
There are two different kinds of overworked Jacksons: knowledge bottlenecks and expertise bottlenecks.
Knowledge bottlenecks are the ones who answer questions.
“Who owns Payment API?”
”Which database has client emails?”
”When is our next release?”
If you're one of those, write documentation. Sorry for such trivial advice, but boring problems need boring solutions.
It's worth writing docs even if people don't read them. Sounds stupid, but it will serve as your second brain from where you can quickly copy answers.
Watch out for an urge to share your screen and demonstrate something. It's always better to record a video (or a gif) and share it instead – this way, you will be able to reuse it later.
That was all about knowledge bottlenecks.
Expertise bottlenecks are trickier. They don't just answer questions — they solve problems.
“This program crashes for Netherlands users.”
”My DB query is slow.”
”Our photo gallery page leaks memory.”
This situation is much more complicated because you need more experts to share the load. But unfortunately, there are no books or tutorials you could give to somebody and turn them into an expert – they need to build the expertise themselves. And it takes time.
But how to accelerate the process?
Limited opportunities
If someone wants to learn how to play the guitar, they need to practice playing the guitar. Likewise, if one wants to learn how to fix memory leaks, they need to fix memory leaks.
The tricky part is there are much more opportunities to play the guitar than memory leaks to fix. They don't happen every day.
Zoom out now and look where you ended up: people call you whenever a challenging problem arises because nobody else has a similar experience. And nobody else has a similar experience because you solve all the challenging problems. A chicken and egg situation.
Growing new experts
The naive advice would be to stop doing what you're doing so that others can practice and build necessary expertise in time. But, unfortunately, it's overly utopian – a few companies have the luxury of accumulating unsolved problems while their best specialist sits idle and waits for new experts to emerge.
But I'm not saying it's impossible – there is a way to grow new experts without slowing down the process. Here it is:
- Pick one successor to mentor.
Learning opportunities are scarce resource, so resist the temptation to pick more than one. - Redirect all requests to this person.
Need help? Ping Nelson, he knows this stuff. - Be available for this person.
Answer all their questions as soon as possible, pair program or pair debug when necessary.
It works because:
- The company will not slow down in critical situations – if the time is tight, the mentoree can ask you for help.
- You can tune your involvement depending on the circumstances to manage risks and guide the learning.
- This person starts earning credibility from day one, solving real problems with your invisible help.
In the beginning, be prepared to play broken telephone answering proxied questions:
It may look like a waste of time, but it's far from it. Yes, the future expert acts as a proxy, but they learn about the domain. Even if it's a proxy, it's a caching proxy:
As their experience grows, they will start asking more complex questions:
This is the point where you can return to your expert's duties, which you now can split with another person:
