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?
thanks! appreciate the response. I do think they probably have valid concerns, and I absolutely trust them.
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.
There are times when things truly change last minute, or new intel pops up. State that the new changes will require pushing the deadline, and if curious ask if they can tell more about how the changed requirements came about so that you have all the right context for the next iteration.
You should probably have a sit down with TL and try to understand their perspective. And bring up questions you have while *not* sounding uninterested in new API spec.
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.
Well, it could be the TL is incompetent. The inability to communicate is a possible sign.
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.
fwiw, I don't think they're incompetent! it was a ~4 month project that's due in two weeks now
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.
The TL may be right - better to deliver the right product late rather than something broken on time.
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."
Who's deadline? What happens if you miss it? Sometimes getting it right is the sensible solution even if it doesn't fit the requestors timeline. In the end your team leader will get the blame anyways so have faith or expect a new team leader
Yes, I think you make a good point about the deadline. It's an internal deadline, but I do feel like this team was formed to build this particular feature, so missing it would be a big fail.
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.
Maybe the TL has a valid concern?
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?
thanks! appreciate the response. I do think they probably have valid concerns, and I absolutely trust them.
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.
There are times when things truly change last minute, or new intel pops up. State that the new changes will require pushing the deadline, and if curious ask if they can tell more about how the changed requirements came about so that you have all the right context for the next iteration.
Thanks, I think this is good advice. Planning to do something around those lines.
You should probably have a sit down with TL and try to understand their perspective. And bring up questions you have while *not* sounding uninterested in new API spec.
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.
Well, it could be the TL is incompetent. The inability to communicate is a possible sign.
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.
fwiw, I don't think they're incompetent! it was a ~4 month project that's due in two weeks now
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.
The TL may be right - better to deliver the right product late rather than something broken on time.
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."
The meeting sounds like it’s too late. Consider asking the TL to just get the team together to smash through the issue, concerns and a path forward.
Don’t forget to document and escalate if that is appropriate, to product management or otherwise. Manage expectations.
Who's deadline? What happens if you miss it? Sometimes getting it right is the sensible solution even if it doesn't fit the requestors timeline. In the end your team leader will get the blame anyways so have faith or expect a new team leader
Yes, I think you make a good point about the deadline. It's an internal deadline, but I do feel like this team was formed to build this particular feature, so missing it would be a big fail.
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.