Suck it up or respectfully push back, as a junior dev?
I’m a few months into a new job as a junior backend dev. I'm comfortable with my team as I was here as an intern and I've been working doing pretty well and taking on various things.
My manager suggested I look into this "data research" type thing that some of the frontend devs need. I honestly think it was to get it off his back because they've been bugging him. I consulted with a Staff backend engineer on my team and he said it took him months to complete something similar, when my manager and the frontend folks think it's a simple query and analysis. It's something that's way too complex for me, both in the domain and methodology, and would involve not much coding. I'm worried that my manager doesn't have my growth in his interest, he just wants to get it off his back so the frontend team doesn't bother him.
I know communication is key, so I plan on talking to him and various stakeholders about it, but can I and how can I respectfully push back? What if he just doesn't do the work of assigning it to someone else? (He's kind of a weak manager).
Or do I just suck it up and work on this, instead of working on actual coding? I could do a bit of both but this seems seriously something way too complex and murky for a junior like myself, and it would definitely be stressful because there are so many different things I'd need to do a deep dive on before working on it. I already have other actual coding tickets I'm supposed to work on.
Discussion
(2 comments)- 24 months agoTech Lead/Manager at Meta, Pinterest, Kosei
The best way to push back is to provide evidence that the project is either:
- Much more complicated than initially anticipated OR
- Not worth the time it will take
(These two are often related, since if something takes much longer, the impact/time ratio becomes worse.)
My recommendation is to create a document that shows you looked at the project in good faith. A few things it can include:
- Deeper analysis on the impact of the work, and why it matters.
- Prior related work (bring up the experience of the Staff eng)
- Rough milestones and sequencing of the project
- Feedback from stakeholders about scope
If the project takes 3 months of time, spending 2 days on the above exercise is a very good use of time. Tell your manager you're working on this, and if you both could chat with your findings in a few days.
Without some thoughtfulness around the project, any discussion of whether to work on this (or not) will feel premature. You don't want to make it seem as though you're shirking hard problems.
You could also make the argument that this project is not aligned with your strengths and career goals, but that is tricky. As a manager, I want people who are willing to dive into new areas and quickly deliver on what the team needs. If the project is partially unaligned, I'd recommend working on 1 or 2 more projects concurrently so you have a "portfolio of bets".
I would not phrase the reason for avoiding the project as "it's too complicated". Instead, talk about how you're unfamiliar with the query language/technology of this, and therefore it'll take you X amount of time.
A great related discussion about early career advice here: How can I work better as a junior dev?
- 2
4 months agoFounding ML Engineer @ Lancey (YC S22)Rahuls advice is great. Generally I try to approach disagreements as a "Hey I dont think Im understanding this, can you help me understand it better? I have done XYZ so far but I think I'm missing the gap on this"
In doing so 2 options come up
- I misunderstood whats being asked and its actually not bad task
- The manager realizes that they were mistaken
And this comes off as less conflictive because you're not disagreeing, youre just asking for help. To put it bluntly dont frame it as a "youre wrong, here's why" frame it as "I see what youre saying, I think its this but can you help me understand where I'm wrong"
