Pigeonholed

Consider the plight of this hypothetical employee: for years, they have worked for the same employer, and for most of that time they have been tasked with operating and maintaining an important, if unloved, system. Perhaps that system is necessary for compliance, or maybe customer support, but certainly not a growth area of the company, one that might warrant investment. To remain effective, this system requires regular updates made by someone with skillful knowledge of that system, and after years of customizations, there's no one other than this particular employee qualified to do this work. Sure, there's job security for them, but overall, the employee is stuck, too valuable to ever be moved to another project. In short, they have been pigeonholed.

You know someone like this, right? Perhaps several? Some fellow employees might not even recall their name, but just know them by the system they maintain, such as "Email girl" or "JIRA guy". Some folks might be content with the job security, but I've certainly seen people, sometimes very smart people, get frustrated at being stuck maintaining a legacy system, feeling like their career is stagnating because of it.

For someone to get pigeonholed into owning a system, it's not enough for that system to be old or unglamourous. The system must also require arcane knowledge to operate, and need updates on a regular basis. If the system were easy to operate, finding someone else to do it would be simple, and if it didn't need regular updates, the expert employee could do other things, and only find themselves pulled off to update the legacy system occasionally. But if you have both conditions, you'll find one of two things: either someone gets stuck with the project long-term, or a succession of employees are tasked with the system, only to leave once they get bored and it's clear they've been pigeonholed.

However, if you find yourself stuck on such a system, understanding these conditions gives you a couple lines of attack. If possible, you can work to make the system easier to understand and operate. Strip out complexity, put simplifying interfaces in front of the system, or as a last resort, document the heck out of it. Anything you can manage to lower the barrier for a new person to be able to manage routine tasks will give you space to work on something, anything else. You may still be the Subject Matter Expert for that system, but your involvement can be scaled back to answering questions and supervising the work of others, rather than being hands-on all the time.

The other option to explore is to automate away routine tasks, so that further updates are only needed infrequently. Software is great for this, whether it involves configuring third-party software or writing your own. Such automation isn't always worth the effort, especially on legacy systems that aren't being currently invested in, but if you find yourself making frequent updates to any system, I'd say you have a strong argument to spend additional time automating those tasks once and for all. If you can manage to automate the drudgery out of operating a system, you may still be stuck with that system, but it will no longer be your primary responsibility.

Sometimes systems are important and complex enough that they shouldn't pigeonhole any one person, but the current expert on the system can't seem to help themselves. Multiple people may work on that system, but only the expert is able to do anything remotely complex or interesting. The expert knows the importance of this system, and when requests for critical fixes or updates come in, they jump on them. They are thus rewarded for being the "hero" who saves the day, but in doing so, they monopolize every opportunity to truly learn the system. Getting to the point where one can deeply understand a complex system requires exploration, and it can be difficult, slow work, requiring a steady series of "ah-ha!" moments as layers, interconnections, and abstract concepts come into focus. By far the best way to do this work is to solve real problems, attempting to truly grasp the current structure and behavior in order to correctly make the necessary modifications.

In monopolizing this work, an expert who plays the hero can undermine any long-term efforts to diversify system expertise. Over time, experts may find it frustrating that no one else has developed the system knowledge that they have, and that they're stuck with every significant problem that crops up, but really, it's often their own fault. What they need to do is step back a bit and let someone else take the lead in tackling a significant challenge. They can and should answer questions and provide guidance, but the expert (and the business) needs to have the patience to let someone else take a little bit longer resolving an issue, building up their own expertise in the process. Long-term, it's likely the expert will be happier, having gained the freedom to take on different challenges, rather than being pigeonholed on this one system. More important than this, however, is that the business will now be more sustainable, as multiple experts on a complex system remove a critical single point of failure.

Critically, when diversifying the expertise on a system, it's important to choose the right people to bring on. You first want someone who seems committed to the organization, someone who is unlikely to take their hard-won expertise out the door in six months. You can never know for sure how likely an employee is to stick around, but it's worth your time to take your best guess. Secondarily, you need to select someone who is capable of gaining sufficient expertise. They do not necessarily need to become a Subject Matter Expert themselves, but they do need the skills and intelligence to be able to take on regular operations without much supervision. Lacking that, the system expert will remain stuck, splitting their time between hand-holding team members who can only accomplish basic, routine tasks, and being hands-on with the critical tasks that their team members could not hope to complete on their own.

Getting stuck owning a system can stall a career, but it doesn't have to be a dead-end. In comparing senior software developers that I know, some of whom have gotten pigeonholed and others who never seem to, I think the difference between them is neither intelligence nor ability. Rather, the developers who never seem to get stuck on a system, despite a track record of building systems that would be likely candidates, tend to build complex things that appear simple. They leave behind significant software that can be maintained and updated by those who are much less experienced than they are. Their contributions are usually well-documented and have tooling in place that makes them easy to operate. In short, their approach to system design is to avoid being clever in favor of being obvious. If you ever find yourself stuck maintaining a legacy system, my recommended approach would be to consider how to move that system further along down the "clever/obvious" axis.