Ask HN: As a team lead how to handle project going off the rails?

This is kind of a banal story. I'm the lead developer on a "modernization" project that's taking a lot longer than anticipated (you see where this is going). The team is great, it's just that the work is way outside their comfort zone. The business has been selling the new version pretty hard and we're not going to make the release (about 3 months to go).

Question is; as a lead how would you handle this? I think my direct manager has a healthy dose of skepticism about the timeline, but the product owner doesn't. At what point should I start sounding the alarm? I'd like to give it a couple of weeks and see if the team picks up pace but I'm not confident.

Set some interim goals, estimate them and measure progress. Take that progress and estimate the remaining work. There's no accounting for the unknown, but IMO it's best to raise the alarm as soon as possible. Just make sure you and the team have the ability to deliver the project, otherwise it's time for a different conversation where you look for outside help.

As much as everyone hates deadlines they are important and try your best to meet them if they're realistic.

Please forgive my generalizing, but there aren't a lot of specifics to work with.

Scope creep is often a major factor in situations like this. In my experience product people usually believe that relatively small feature changes imply relatively small engineering effort, and of course that doesn't hold generally.

Sometimes product people will try to sneak scope creep by as a "clarification" of requirements, which almost always leads to the situation you're in.

So, depending on your environment, it may be constructive to draw attention to this, if it's applicable.

You will not be able to release “everything” in 3 months, but what if you picked the most important parts and focused on getting those out?

Tell the product owner what the situation is and collaboratively come up with either:

a) a new timeline that you believe you can meet or b) a list of tradeoffs that can be made to get the project out the door in time

I have been an engineering lead and a product manager and it is much better for everyone to just be upfront about all of this.

You know what your team can produce and (roughly) how fast they can produce within an order of magnitude time-wise. The product owner should know what stakeholders actually want product-wise and what an acceptable timeline looks like. You should be able to work together to narrow the scope of what is being worked on to a point where your team can accomplish it within the timeframe.

Communication and setting expectations are key. This needs to be done both up front and on an on-going basis. As an engineering manager, you should be able to evaluate, week-to-week, where things stand and which tasks may need to be cut to make a deadline or how far a deadline should be pushed back if things can't be cut. Your product owner should be able to weigh in on this and should already be prepared to pare down requirements if necessary.

It may be painful and embarrassing to start having these conversations now, but it is significantly less painful and embarrassing than having these conversations in 3 months when the product is expected to be delivered.