Most of us will be thrilled to be described as critical to a project’s success. You see, one of these engineers in your team where they are the go-to person for certain problems. He or she is usually the tech lead or the managers who have participated in most design decisions and know the projects’ history. They might usually be the one that wrote the large swatch of the codebase on the system.
We aspire to be the key engineer to who people go with questions and problems. Companies do mark that factor in their leadership principles - especially on promotions. “The junior engineers who demonstrate that they can be the sole engineer responsible for key project areas are often more likely to get promoted.”
At first, it can be great to be the go-to person on the team. This makes sense in human nature. We tend to have a scarcity mindset that we want to be the one that people need. However, this creates lots of burden in your careers in the long-term.
When I realize that I often get pings during any of the on-call people because I was the main developer for that system and knows how the internal system works, I realized that I was the critical person for this project. I felt so important and needed, but I was also annoyed that I am the only one out of 20 other engineers to resolve these issues. I realized that I have to create a better runbook for on-call engineers, create better tooling for on-call engineers to resolve problems to solve the problem and resolve it without me.
Why
With great visibility, it comes with great responsibility. When you are the sole engineer on how the system operates, you are also incurring a hidden tax.
The problem with having this kind of mindset is when you enter a critical path when you have too many projects, and you become the only person that people consult for a growing number of problems. You lose the flexibility on what you can do with your time.
If there are high incidents, you might be the one who gets pinged. If there are any questions regarding how the feature works, you might be the first want to get notified.
This incident often happens at the beginning of the development cycle. This happens very often when you start off building new projects on your own, and you become the sole engineers with the knowledge about that system. Engineers usually get to learn a lot by building the system from scratch on their own, and they sometimes love and enjoy the experience so much that they want that responsibility.
However, suppose you didn’t share your knowledge with other fellow engineers. In that case, you are holding that liability for yourself that you will need to solve any future problems that rely on that system and that knowledge.
You cannot control your schedule because it gets dictated by the external factor, and it limits the problems and other important projects you are trying to create.
This happens to many engineers as you grow more seniority in your experience and in the company. The more senior you are, the more you will be involved with the initial phase of the projects, and the more you know and understand each and every system in the projects.
This is where burnout can happen. Even though you might think that someone who knows the company’s majority tech stack may be given some high-impact projects. Keeping everything to yourself or being the critical person creates a burden to yourself that you always have to get bombarded with extinguishing urgent fires.
What if you want to learn something different and want to take on some greenfield projects in the company that has a high impact value? Solving high-priority bugs and resolving any customer request can restrict you from focusing on other high-value tasks.
How To Be Valuable
Being valuable doesn’t mean you know the most knowledge in the team. Being valuable is how you can give value to the team and be extremely useful and important.
How do you contribute value to your team?
There are numerous ways to create value for your team. One easy way is too involved in helping your teammates grow. If you help your company develop talent, it creates value.
You get to help your team see around corners even when they’re not there. For instance, if you noticed a certain operation has been done manually repeatedly, you can create a script to improve the team’s efficiency.
Volunteering to speak at social events and tech talks helps create value in the company by attracting future talents.
Another one to create value in the company, in general, is to take on high-value projects. High-value projects are projects that have a direct impact on the business of your company. If that system fails, it will cause a huge catastrophe to the company’s business line. For instance, new projects that create a fraud engine for the internal payment processing system count as a high-value project because the system is critical to ensure the overall application’s security.
Here is the mindset - become valuable that your manager and your colleagues should think about you when they want to kick-start a project or do something out-of-the-box.
How to be less critical
Constantly share your knowledge with your teammates. Have a knowledge-sharing session each time when a new feature is built. Spread your knowledge and the domain expertise to your team so that they know as much as you know.
Start to observe any pain points from an on-call person. These help you construct your runbook clearly or create more internal tools to help automate certain useless alarms. When I realized the kind of questions I got from the on-call person about the notification system, I realized that I miss a section in the runbook that clarify those questions for the on-call person.
Trust your teammates and delegate new development to them on your project. We, as engineers, love having ownership. Sometimes, ownership can be a good indicator that you care about what you are building to write code in a maintainable way. However, sharing ownership with another teammate can alleviate any bottleneck on your end and create value for your colleagues.
Notice any part of the software development process where you are the bottleneck. If everyone needs to go through you on certain decisions or technical operations, try to find a way to remove yourself from that situation by automation or to be flexible. For instance, if you are the sole engineers that enable to trigger the PROD CD pipeline, you might want to add another engineer or two so that you can delegate the responsibility to them. If you realized that you have to do the same operation every week to maintain your servers, try using some sort of script to automate it, so no one needs to manually do it.
Avoid any one team project. I usually suggest two product owners. That way, there isn’t only one person that can answer all those questions and be the bottleneck. Working on a project with the other person can also help you alleviate future issues’ burdens.
Create as much documentation as possible so that other new engineers and teammates can learn all those knowledge asynchronously. When you update certain features in your application, take the time to go to the documentation section and update the documents—one of the things that we often oversee as software engineers are the importance of pure documentation. Sometimes when the projects are long and features are constantly changing, the documentation tends to get obsolete, and no one is looking at it.
Closing
Being the key engineers in the team sounds like a role model that engineers thrive. However, being critical doesn’t mean that you are valuable. Being critical can put engineers in stressful situations that engineers sometimes get burnt out - or they think that the only way to get their times back is to move teams or company.
Start sharing your knowledge as early as possible. Teach your teammates how to get the right mindset and principles to do things well independently. Start automating operational tasks that are redundant, empty more time to do that interesting projects, or learn the new skills you always wanted.