What general framework can I use to evaluate if a project is mid-level or senior scope?
I know the general advice if one does not know is to ask their manager but sometimes an inexperienced manager might not know themself. Can anyone provide an example to make these concepts clear?
A few criteria I came up with that can be included in the framework involve
- Number of stakeholders (across how many dev teams does the project span)
- Roadmap vs. feature level ambiguity (Designing a service vs. designing an API in that service)
- Technical complexity (How many different services are talking to each other, etc)
For reference, when I talk about mid-level vs. senior-level I am referring to the leveling system across big tech (L4/L5 for Amazon, E4/E5 for Meta, etc.). Thanks!
Discussion
(2 comments)- 17 months agoTech Lead @ Robinhood, Meta, Course Hero
At a very high-level, which is based on full-stack product teams (pretty much all of my experience):
- Mid-level - Owning an entire stack-specific slice of the overall project
- Senior - Owning the entire project (make sure all stacks are good, manage timeline, communicate with XFN)
There's a ton of nuance to this though. At a company like Amazon/Meta, you will have entire teams that are like "Android Video Performance Infra". My definition is impossible to apply there as everyone on the team works on 1 stack.
Also, as I have said many times before, there is more to a project than its intrinsic technical/people scope: Your quality of execution matters a lot as well. I go super deep into that here: "How to identify projects that are more suitable for senior engineers?"
I recommend these too:
- 9
7 months agoTech Lead, Manager at GoogleI'll share some things I've heard about in manager circles recently about how to think about projects complexity/difficulty/ambiguity with regards to levels.
- L3: Bowling with gutters.
- L4: Bowling, without gutters.
- L5: Golfing instead of bowling.
The interesting bits to highlight for me is that L4 projects aren't particularly more complex or difficult than L3 projects, but the most important distinction is actually the fact that you need to do it without anyone else explicit looking over your shoulder to make sure you do all the right things. The goals and success paths for both L3 and L4 projects are likely similar - the difference is more in your own execution.
L5 projects are different from L4 projects in that it's often not clear what the right path / solution is. Likely there are varying proposals but no clear winner. You need to genuinely weigh different options, whether that's balancing different stakeholders and understanding where they are coming from, or different consider technical approaches, etc. I have found this this LinkedIn post pretty helpful in visualizing this.
And to continue the metaphor... (maybe...)
- L6: What's new sports can we invent with a ball?
