Gaining Expertise
Over the course of your career as a software engineer (or any career, really), you build up an encyclopedia of knowledge in your head. When you first start out with an empty encyclopedia, you may get to experience some of that lovely impostor syndrome stuff folks are always talking about. But then each time you work on something, you learn bits and pieces of knowledge that will help you perform your next task faster or better. This translates into becoming a higher and higher performer. It also means that you become the go-to person for more and more topics.
This is a great thing! It makes you feel valuable and it makes other people think you’re valuable because you know “The Thing” that they need to know more about. This is also generally good for your career. But one day, you may find that your productivity starts trending the other direction. If you enjoy writing and reviewing code (managers call this being an individual contributor aka an IC), this may be an unwelcome change. You’ll hear signs of this occurring when a senior developer gives their update at stand up lamenting the time they didn’t get to do “actual work” yesterday.
I have a couple of solutions to help manage that downward trend that will also make you a better developer, a better leader, and also increase the strength of your team.
Side note: the things those devs say are preventing them from doing “actual work” are, in fact, actual work. Consulting with other developers, “just” thinking, and even meetings (sometimes! gasp!) are actual work. Ours jobs certainly include more tasks than what was covered in our job descriptions or in the Software Engineering courses from college.
Increasing your bandwidth via Documentation
If you are the only holder of a specific set of knowledge, the simplest way to change that is to create an artifact that has all of this knowledge. You’ll also want to make people aware of this artifact, that will vary a lot by team but it might be adding it to a shared location in Google Drive Wdesk, adding an entry to your team wiki, or updating a markdown file in a repo. I really like adding documentation to the repos your team works on because it makes it easy to find and encourages others to update it.
The hardest thing about documentation, in my opinion, is taking the time to do it. Remind yourself that writing documentation or creating diagrams may not feel like “real work” but it most certainly is. Great documentation is one of those things that can easily “10x” a team, particularly when onboarding new developers or having developers work on an area that is new to them.
More on documentation in a future blog post… probably.
Increasing your bandwidth via Delegation
To me, the less obvious tactic to take here is delegation. It can feel bad, like you’re taking the easy way out or not being a team player. Or perhaps you just don’t want to give up the reins of a specific area. The function of becoming less and less productive eventually forced me to delegate more deliberately and the effects I observed have made me realize the value to be gained.
When a question comes up that “only you” know the answer to, or someone says you’re the ideal person for a ticket, what you’re witnessing is an opportunity to delegate. It’s important to point out that you can, and at times should, delegate a task to someone that may not yet be capable of handling it completely on their own. They may even end up coming back to you for help and that is perfectly okay. By making them responsible for it, they will be forced to internalize the knowledge in a way that they wouldn’t if you had just answered the question or done the thing for them. The best part about doing this is when folks surprise you by stepping up to the plate and knocking it out of the park.
You have a few ways to grow as a leader in the midst of delegating a task. One aspect that I’ve always considered very important is that when you delegate to a teammate and they deliver like a boss, make sure they get the kudos for it. On the flip side is knowing how much to let them fail which will vary by person and by experience. On the front end, you don’t want to micromanage the execution of the task you delegated them to. On the back end, in my opinion, it is often on you to publicly take responsibility for failure, and privately discuss it with them.
Another thing that may feel bad when delegating is that you’ll get the feeling that you’re making yourself replaceable. Well, in some ways you are. This is valuable for Workiva because it decreases your hit-by-a-bus cost, but it is also valuable for you because it means you can move upwards (or sideways) and start to master new or more complex areas. And never fear, as soon as you start delegating and increasing your bandwidth, you’ll find that you start filling your encyclopedia with new entries thus repeating the cycle.