What are good strategies to push back when the deadline is not realistic?

Profile picture
Senior Software Engineer at Twitter9 months ago

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?



  • Alex Chiou
    Robinhood, Meta, Course Hero, PayPal
    9 months ago
    • You are 100% correct in that data and communication play a major role - I actually think those 2 angles are the most important! That was definitely the case at Meta, a super metrics-driven company, haha.
    • In terms of how to generate the data, I recommend writing things down into a tech spec. The important thing to do with large projects is to break them down into a bunch of smaller tasks. Make sure the data is structured - I like making a timeline table where it shows all the broken up tasks, and then I count point at it and be like, "In order for us to hit the original goal, we need to do like 15 tasks per week, which is really rough."
    • Get other people's thoughts and build an alliance if applicable - If you are truly correct about the timeline being too crazy, a bunch of other smart people are going to agree with you, and I'm sure your team at Twitter and Twitter overall are full of them! Get public buy-ins to make your case. Conversely, never make these big arguments with only yourself supporting it - That's a recipe for disaster. This is a big reason why being able to build social capital is crucial for senior SWEs!
    • Propose trade-offs - Nobody likes someone who just goes in and is like, "We can't just do this". It's true that you are technically are proposing a trade-off in delaying the timeline for execution, but that's a very basic one and the parties you mentioned are generally more deadline sensitive. Have empathy for them and try to propose other ways of dealing with these types of projects - I feel like cutting scope is the main thing to suggest here.

    Related resources:

  • Senior Software Engineer
    Senior Software Engineer [OP]
    9 months ago

    Appreciate the advice! Some follow-up questions:

    • What if managers/PMs disagree and feel that these targets can be achieved?
    • As a senior engineer what different behaviors are expected to be acquired to keep growing into the next level with regard to this area?
    • 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?
  • Alex Chiou
    Robinhood, Meta, Course Hero, PayPal
    9 months ago
    • 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:
      • Keep the conversation going. Just because they disagree initially doesn't mean they can't come around later.
      • Come up with other angles of attack. Cutting scope is often more acceptable than just shifting back dates. And when pitching this, don't just propose axing things; commit to doing them as a fast follow.
      • Politely put the ball in their court. Ask them what it would take for the requirements to change, whether it's reducing scope or pushing back the timeline. From there, you can create a better plan to persuade them. Maybe they just want more Staff engineers or something to say that the current plan isn't feasible - Whatever it is, you can actually start pursuing it vs. stabbing in the dark.
    • 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:
      • Building a stronger case for adjusting the project with more detail and foresight, especially around how the project could be flaky/buggy due to the current circumstances.
      • Having deeper relationships with relevant parties, especially non-eng
      • Running these alignment meetings more efficiently and with greater control
    • 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.