Should I delegate technically challenging work or take it on myself?
I'm slated to work on a pretty big project, and because of this, there are 2 other engineers to help out on it, both of them more senior than me. I've broken up the project, and at a very high-level, there's 2 types of work:
- More straightforward work that I know exactly how to do
- More technically complex and ambiguous work that I'm not entirely sure how to do
This leaves me with the following crossroads as a lead on this project:
- Do the work from #2 myself to show senior engineer behavior, but it may slow down the overall delivery of the project as it will me more time.
- Delegate the work from #2 to the more senior engineers, so we can get it done faster and preserve high velocity on project delivery.
Any thoughts on which of the 2 paths I should take?
Discussion
(1 comment)- 32 years agoRobinhood, Meta, Course Hero, PayPal
My advice is work backwards from what you need to do and figure out the priorities accordingly. For example, let's say this is a mission-critical project with a tight deadline - It's probably better to do option #2 and delegate the work to de-risk the project and increase velocity. However, if the timeline is more flexible, then it's possible doing option #1 makes more sense.
That being said, I do want to push back a little bit on the mentality with option #1 since it's something I've seen with many mid-level engineers in particular looking for a senior promotion. There are ways to show senior engineer behavior besides technical scope. I have also found that focusing a lot on technical scope leads to this more "zero-sum" mentality, which can be counterproductive as your mentality now isn't as well geared towards expanding/creating scope, treating scope as this finite resource that needs to be "claimed" instead.
As a senior engineer, you are responsible for the overall delivery of a project. This means that your mentality should always be to "fill in the gaps", doing whatever it takes to make sure that the project crosses the finish line. This will often times involve non-coding work like:
- Defining the project requirements
- Sharpening the designs
- Giving project updates and making sure stakeholders are aligned in general
- Creating a high-fidelity timeline with a set of clear milestones
- Making clear swim lanes and delegating work
You can also add a lot of technical value (i.e. show a lot of senior engineer technical depth) if you were to delegate these tasks away and not code them yourself. Here's some ideas on how to that:
- Make very thorough tasks for this work, including relevant context, code pointers, and thoughts on high-level approaches and trade-offs
- Driving the system design/technical review process for this body of work, figuring out the high-level approach and then handing off the concrete coding to someone else
- Being a very active code reviewer on the code for these tasks, reading them in-depth and leaving very clear and deep feedback
All that being said, I always recommend talking to your manager about situations like these. I have never worked at Twitter, so I don't have a deep understanding of what it values in a senior engineer (and this will often times vary by orgs within the same company). Your manager should have this context and give a well-informed recommendation accordingly.
Related resources:
- Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta - In this case study, I break down how I added a lot of value immediately to the team after joining Robinhood, which involved a lot of non-technical behaviors.
- "How can I better proactively account for risks in my projects?" - Some thoughts around how you can set up your project for success!
