How to scale yourself
One of the clearest signs you have reached seniority at your team/company is that your feedback is always sought after.
In fact, it is a prerequisite.
In an office environment, it will be someone almost always at your desk. In a remote one, it will be continuous internal messages on Slack/Team.
So how can you support everyone and at the same time deliver on your deliverables? How can you scale yourself?
Well, the most obvious one, and not the one I am recommending is to work two shifts. One for the company and one for you. This is directly inspired by Paul Graham's classic essay: Maker's Schedule, Manager's Schedule. A must-read.
To more realistic options, one easy win is to pack all the requests into weekly or twice-a-week office hours. You can redirect all requests to the prescheduled time slots and address them during this time.
Another option that will pay off long term is to direct all questions to a wiki. You can automate this in a Slack/Team channel. StackOverflow for Teams is a good solution I have used in the past (not an ad). With time, you can encourage people to start searching there first and this will create a good knowledge base for everyone at the company.
Taking this option further, investing in a good internal search that will surface wikis, docs at various locations, slack messages, etc. will pay up a premium in time.
At one point, you will have to delegate. This is the only way to be able to scale. First, I recommend you do not delegate high leverage activities such as interviewing (minus initial screening maybe). Another thing I recommend you do not skip doing is 1:1s. You want to keep a pulse on the organization especially now that you are focusing more and have less visibility on the overall picture. A third area that I also recommend you do not delegate is whatever gives you a pulse of the business and allows you to get product feedback. These are still important to get and are really valuable.
How/what to do delegate?
If you have on your team a solid engineer II or senior engineer that you respect, give them more responsibility and start directing all requests to a certain area to them. They will be the first point of contact and you will be the second tier of support. This should free up a lot of your time. As an example, if you are owning a full stack, start sending all front-end (or back-end) requests to another engineer on your team or if you own two areas, start sending all requests related to one of the areas to someone else.
You can also delegate to your manager or counter part in other disciplines. A good manager will gladly take some your responsibilities to allow you to focus more on critical initiatives. These could be things like capacity planning, budgeting, nudging different teams to do something like upgrading to the latest library, etc.
This is hard to do especially for individual contributors. Managers are more experienced in this and can do it better. You have to resist the urge to be the first to respond and allow the new owners to assume their responsibilities. This being said, delegating this way has multiple values for the organization. First, it frees your time to be strategic on how to make an impact or have a better work/life balance, it removes you from always being a bottleneck, and provides more opportunities for junior engineers to grow and make an impact of their own.
Mastering Software Engineering Course on Maven
If you liked this article, I will be teaching a “Mastering Software Engineering” course on Maven where I will teach similar hard-learned lessons I acquired developing large-scale products at companies such as Uber, Airbnb, and Microsoft.