I was curious to learn your take on strategies to push back when the expectations are not realistic. I want to expand my scope and feel that there is lot more scope for me to learn and navigate better. According to me, data and communication plays a major role here.
More specifically in my case, I am wondering how to account for me not being well versed with tech stack and constant context switching between clarifying requirements as they keep changing with each question of mine. How to politely and effectively communicate that although this may seem like a small increase of scope, given that I have to figure tech stuff it will be stretch.
Adding more context: It's trickier as I'm pretty new to the team and tech stack. I feel like I'm discovering a new requirement with every question I ask. I've set up recurring pair programming sessions to increase my velocity, but I'm not sure if that's enough.
Follow-up question: What research should be done before establishing the conclusion that expectations are not realistic?
What if managers/PMs disagree and feel that these targets can be achieved?
If managers/PMs disagree, that's expected, especially initially. It's important to understand that they're more deadline-sensitive as they'll spend a lot of time talking about delivery with execs. The important things to do here are:
As a senior engineer what different behaviors are expected to be acquired to keep growing into the next level with regard to this area?
The big delta between a senior engineer and a mid-level engineer is that I would expect a senior engineer to surface these concerns at all and play a big role in this conversation. Mid-level engineers often times just "suck it up" and try to do the work (often failing). The difference between a staff engineer and a senior engineer is that the staff engineer will raise these concerns more proactively and handle it with more smoothness. This includes:
Does it make sense to suggest that other folks work on the project in parallel or does that take away an opportunity to drive and implement independently?
It makes 100% sense to try and break up this project so others can work on it! As a senior engineer, you should definitely learn how to work through others. Of course, you shouldn't try to hand off 90%+ of the work, but trying to do too many things yourself is a common failure mode I see. Scaling yourself is a sign of true seniority, not weakness.
Here's a great thread about how to scale yourself and why it's important: "Why would a senior make themselves replaceable?"
Related resources:
Appreciate the advice! Some follow-up questions: