As we gain experience and grow our skill set, the scope of our capabilities increases. That means there are more and more ways we can contribute. For example, maybe two years ago, your primary way of contributing was by writing and reviewing code. Two years later, you are also capable of breaking big projects into small stories, designing large systems, and onboarding new engineers.
But the amount of time we have stays the same - 24 hours a day and 7 days a week. Since the kinds and amount of work we can do continue to increase while our time stays limited, doing the right thing becomes more and more important.
This post covers:
- why you should stop doing everything;
- how to decide what to work on
Why you should stop doing everything
First of all, it’s impossible to do everything by yourself. As your skillset grows, gradually it becomes impossible to do everything you can do. As your skillset grows, the scope of tasks you are able to work on grows, but the amount of time you have stays the same.
Secondly, you doing everything is not good for strengthening your team. For example, there is task A which you are familiar with because you have done similar tasks before. But Kim, the new engineer that just joined the team, is not so familiar with the task. If you take the task because you think you need to do everything you can do, you take away the opportunity for Kim to learn about the domain, which essentially delays Kim to become a fully productive engineer. In most cases, building out the team is more important than finishing the current project.
Last but not least, some tasks don’t make sense for you to work on from a financial standpoint. If task A yields the company $X while task B yields $Y where Y is significantly less than X, you working on task B instead of task A doesn’t make sense from a financial standpoint. You working on task B is actually causing the company losses because it takes away the time you could have worked on task A. Moreover, if you are capable of handling task A, your company probably pays you more than people who can only work on task A but not task B. It’s in the company’s best interest for you to work on task A.
In short, instead of doing everything you can do, you should do tasks that are more valued with your skillset.
How to decide what to work on
Do the following to decide what to work on.
1. Identify the most important tasks.
These are the kind of tasks that push the project forward the most. Sometimes it’s to talk to stakeholders to clarify the deliverables for the project. Sometimes it’s to convince partner teams to invest in the project. Sometimes it’s to talk to everyone and make sure everyone is on the same page.
A lot of time, the most impactful tasks are vague. The outcome of these tasks might not be as well-defined as “fix that bug“ or “get that test passed”. They also tend to involve interacting with other humans. These two characteristics make engineers uncomfortable. That’s why we tend to run away from them. We would rather do things we are more comfortable with, such as refactoring some messy code, than work on tasks that are most needed by the project. If we want to maximize our impact and help the project move forward, we need to spend more time on things that matter the most than things that make us feel good.
2. Identify where you can provide the most value.
Similar to not everything that comes to our way should be worked on, not all important tasks should be worked on by us. For example, maybe currently the most important task for the project is to create the mockup for the design of the user interface. If there’s a designer on the team, the designer is probably more suited for the task then you.
You should have a clear understanding about where everyone on your team, including yourself, can provide the most value and the roles everyone plays. For example, maybe the product manager is responsible for communicating with external stakeholders, and the tech lead is responsible for communicating with engineers on the team and making big technical decisions.
You also want to know the strengths of everyone on the team. Maybe engineer A is most familiar with the ins-and-outs of the system. When introducing a change, you might want to run it by A in case the new change breaks other parts of the system. Maybe engineer B has experience working with similar systems at other companies. When coming up with a new architectural design for the system, you might want to get B’s opinion to see if there is anything you can learn from her past experience.
The clearer you understand each person’s role and strengths, the better you can align the right person for the job. Remember, you don’t have to do everything. Sometimes the best thing for you to do is to find the right person for the task.
3. Identify the areas you want to grow in.
You are ultimately responsible for advancing your career. Always keep in mind the areas you want to grow, so when relevant opportunities come up, you can recognize and seize them quickly. It’s even better if you can let your manager and peers know that you are looking for opportunities in these areas.
You might not always be the right person to work on tasks related to the areas you want to grow. If that’s the case, you can always shadow the person that works on them and learn from them.
4. Identify the things you enjoy doing.
It’s important that we work on things we enjoy to keep ourselves happy.
For example, there was a while where I spent most of my time onboarding new engineers, communicating with external teams, and planning for projects. All these were important for my team and projects. But gradually, I stopped enjoying working even though I was pushing things forward. I realized I missed coding. So I started to allocate some time to fix things I always wanted to fix. Those things were not as important as other work I was doing. But they recharged me and gave me the fuel to continue working on other important tasks.
Balance is the key. You don’t want to only work on things you are comfortable with, although they make you feel good about yourself. You also don’t want to only work on things that are important for the team but ignore your feelings, because you might risk burning out yourself.
Some might argue we should only work on things we enjoy working. I would say some tasks are acquired tastes. There are things we don’t enjoy yet simply because we haven’t built up the muscle to handle them. By pushing ourselves outside of our comfort zones, we gradually build up those muscles and expand our comfort zones. Growing our skills is also the process of acquiring the ability to enjoy things we didn’t enjoy before.
You might think you prefer coding than talking to stakeholders. But once you see how a simple conversation can avoid miscommunication and save many lines of code, you might start looking forward to those conversations.
Of course, there are things that will never fit our palates. But we should give them a fair try before jumping to conclusions.
If you enjoy this post, you might also find this article useful: Never feel overwhelmed at work again- the M.I.T. technique.
My career plan for the year is to grow into a tech lead. I’m excited about all the learnings ahead and would love to share this journey with you in a brutally honest fashion. I will be sharing my weekly learning on the blog.
In the next few months, I will focus on growing in the following areas. You can expect to see posts related to them:
- focusing on the big picture of the project instead of near-term implementation details;
- balancing my efforts between leading projects and coding;
- work-life balance for long-term productivity;
- the human side of software development: making sure everyone riding with me enjoys the ride and feels fulfilled and inspired.
My best content on Career in Tech and Software Development. Delivered weekly.Enjoyed the article?
Very good article for to-be senior developers
Thanks for writing 🙂