- 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?
A 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?
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.
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."
Don’t forget to document and escalate if that is appropriate, to product management or otherwise. Manage expectations.