Ask HN: How to deal with last-minute changes by team lead derailing deadlines?
- We have a hard deadline for a feature.
- Early attempts to define the API were repeatedly dismissed ("too soon").
- Team proactively built API proposals (with docs, examples, OpenAPI spec).
- Two weeks before deadline, TL finally agreed to our approach.
- Two PRs in, while reviewing the final PR, TL changed their mind entirely. Wants to change the approach but is unable to express exactly what they want.
- Meeting is scheduled to discuss tomorrow afternoon, we're almost certainly going to miss the deadline.
How can I constructively handle this and avoid similar issues in the future?
12 comments
[ 3.0 ms ] story [ 38.9 ms ] threadA junior or mid-level dev may often think that coding is progress and having more and more complex or craftsman-like solutions is the goal, because they think development is all about coding.
In reality, having less to maintain while still providing what’s needed is what’s best. This is the way.
Sometimes solutions aren’t obvious. You’re right that a decision should have been made, but maybe the decision was to wait and see.
Maybe your TL is too indecisive and not timely enough, or maybe they aren’t the problem.
If it continues and you think that it’s an ongoing problem that isn’t benefiting your organization, talk about it with the TL directly. Listen to them.
Finally, if that doesn’t work, talk to their supervisor. Tell them a lot of dev time is being wasted. But only after you do the rest and think through it.
Remember what Douglas Adams said: “I love deadlines. I like the whooshing sound they make as they fly by.” If it’s contractual, it may be important, though, in which case you should bring it up with the TL.
Finally, could this have been designed better and more comprehensively up front? Or does your team not do that well?
The frustrating part for me is why wait till the last possible minute? why avoid talking about this until it's too late? I would have loved to have the chance to design it better upfront, or at least have a conversation about it.
It's possible they're overwhelmed with work, it's also possible that I'm making the deadline a bigger deal than it should be.
Your response was super helpful to think about this, thank you.
Unless TL been recently promoted, they would know what they have to do to get better results, your deadlines might be extended if they're able to convince their superiors about the benefits of the new approach or drawbacks (enough) of the current one.
As previously stated TL has had a different role + goals than a dev, if you're still in limbo about the situation, you can still put the current work you did in your review cycle.
However, there could be more to the situation. For example, you may be missing what they are saying! That’s on both of you.
Also, some details are missing. Like is this 50 weeks in and due in two? Or two weeks in and due in two?
And sometimes you need to iterate to get proper understanding of the problem space.
At lastly… they could have given you lots of rope to do it the right way, and the TL was hoping you would have seen the error of your ways by now and finally feels like intervening.
what doesn't make sense about your last theory, why don't chime in when the multiple specs/documents where defined? why now?
After thinking this through with the answers in here, my current guess is that this is something that just occurred to them, which is totally fine and I shouldn't be frustrated about it, these things happen.
Based on that, I feel like the blame won't be on the TL, which is what worries me, but that's probably unfunded/unfair.
Don’t forget to document and escalate if that is appropriate, to product management or otherwise. Manage expectations.
However - I would document everything.
"TL - just make a our note of our conversation earlier. You want us to pause API approach A, whilst you decide on a new design. We flagged that this would put Milestone X at risk, but you decided that it was worth the delay to improve the design. In the meantime, you want us to work on Module Z."