Let's unpack what your manager meant by delegating more. She wanted to you to spend your time on solving higher-leveraging problems, rather than repeatedly implementing solutions to the category of problems you already know how to solve very well. She is absolutely right. It is not only for the benefit of your own because the increasing impact you will make, but also for the benefit of the team because these problems would serve as training ground for others.
What is an Effective Delegation
You probably already know delegation is not just about simply assigning a task to someone else. Rather, it is taking calculated risk in others to grow their skills and capabilities as part of the talent development strategy. In an effective delegation, you not only assign the responsibility of delivering a certain outcome to the assignee, but also assign an appropriate amount of authority on this task, combined with your dedication of support, to make sure that person could succeed. The outcome of a success delegation would include
1. The successful delivery of the task/project.
2. The person gained meaningful experiences from it which are aligned with her growth goals.
On the other hand, there are occasions when the team needs to do chores / almost-no-brainers, such as cleaning up tech debt, or write an internal API controller by following existing design patterns. Except for new team members, these are hardly valuable training opportunities. But It would still make sense to distribute them among the team to froster a sense of comradeship.
Create Delegation Opportunities
Low hanging fruits are easy to spot: if a non-urgent project which presents little challenge to you but matches someone else's growth goal and is reasonably stretching for that person, then it would be an easy delegation decision to make. However more often, we have projects which are:
1. Really urgent and you don't have time to train others.
2. Technically too challenging for others, because of the skill / experience gaps.
3. Not interesting to others on the team due to its repetitive nature, or working in legacy code.
How do we delegate then?
Different level of Delegation: Execution, Recommendation and Decision
When the skill gap is the blocker, one way to solve it is to tailor the level of authority given to match the skill level of the assignee:
1. Execution: delegate the implementation of solution but you collect options and decide which option to go with. This is helpful when the assignee is fresh to this domain / type of software system and can benefit greatly just by getting their hands dirty.
2. Recommendation: delegate the responsibility of collecting options and giving recommendation, in addition to implementing the solution. This works when the assignee's technical skills largely match what's required but still presents some gap in the breath/depth of their knowledge, or the robustness of their decision making process. By receiving feedback from you, they would benefit from reducing that gap and become more ready to make such decision on their own in the future.
3. Decision: delegate entirely but gets informed of the decision after it is made. This works when the assignee is fully capable of making a sound decision and is self-aware enough to correct their courses. Typically this helps them to build confidence and credibility in the organization, even cultivate their technical leadership.
Redefine the Problem to Make it an Rewarding Opportunity
Engineers like to work on impactful and intellectually-stimulating problems but not every company/team have such projects presented to them on a silver plate. As the tech lead of the team, you are in a unique position to help the team elevate their thinking by seeing through how the problem at hand is connected to the overall business and how it can be really impactful:
1. Solve the root cause rather than the symptom: if the team constantly needs to spend a few days even a week to write no-brainer feature code, it might be the right time to ask why such requirements keep streaming in and why is the marginal cost of implementing a new one so high? Maybe a product or an architectural decision needs to be challenged.
2. Solve the common problem rather than an instance of it: in sizable engineering organizations, there are a decent amount of common (architectural / infrastructural) problems in place which affect multiple teams. It will be much more impactful if you help the team to aim at delivering a solution which benefits multiple teams.
3. Solve the business problem rather than the technical problem: although most technical problems are originated from certain business problems (unlock growth, cutting costs, reducing churns etc), not all engineers have equal opportunities to be equipped with that rich context. It would be a great tool to incentivize product-minded engineers by giving them the context and include them in the process of seeking a solution to the business problem, rather than only the technical part.
Sometimes Better to NOT Delegate
Remember you are still accountable for the project even though someone else might be responsible for executing (part of) it. Thus, if based on your judgement, it will put the project at a significant risk if certain parts are delegated to others, because of the training time needed, or the skill/experience gap, or even lack of motivation, then trust your judgement and communicate that decision to your manager and stakeholders to get them aligned. Ultimately, project delivery (value delivery to customers) comes first and no internal training should be at the expense of that.
Other Tasks To Delegate
Although we have been over-indexing on technical/product problems, there are other tasks you can delegate to your fellow engineers. From an operations perspective, having necessary and up-to-date processes and rituals are critical to the team's coherence and output. Delegating the responsibility of running a team ritual (like scrum or retrospective) to some else can be really effective in building up that person's confidence and presence in the team.
Communicate Your Delegation Decision
Last but not least, keep in mind a delegation decision is also a talent development decision, which is owned by an engineering manager. Thus, it is always good to communicate these decisions to the manager of the person you delegate to and get blessing.