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.
211 comments
[ 4.5 ms ] story [ 262 ms ] threadAs much as everyone hates deadlines they are important and try your best to meet them if they're realistic.
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.
That being said, faith won't magically fix everything. If you are unable to make it, then figure out what you can deliver and then tell your manager/product owner. Deliver the "bad news" with a constructive alternative. Cut away some features and then going forward be ruthless about scope creep. Urgent thing CAN come, but then others needs to be removed.
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.
Question : how will suffer if you're late ? (no, it's not the end users, it's someone, somwhere who said it was possible, whose career path is tied to the project, etc). Make sure he won't suffer too much, that may give some room on the planning.
https://hbr.org/2015/01/what-everyone-should-know-about-mana...
First get PO on board. Choose the process that will push PO into the central role: Kanban, Scrum, XP(anything really). Work with the PO to create user stories, estimate and calibrate. PO should work with stakeholders to ensure that the timeline is realistic.
Get your team a proper training. Hire someone to do training on the tech you use. Get some courses from Pluralsight/Udemy that will be mandatory for everyone on the team. Extra day in month spend on training is not much but it will up-skill people quickly.
Drag in your manager. Get him into a meeting and ask for a guidance of the senior manager. Make him co-responsible, he might help with funding on the project. Cut features to absolute MVP. If nothing works, escape sinking ship.
I would work for you.
But yeah: 1. Be honest with everyone 2. Invest in online courses for everyone 3. Lay out a simple roadmap for the minimum MVP 4. Hustle
And next time use my recipe for estimating. Spend ~ a day on this.
1. Split up everything into the smallest subtasks 2. Estimate the time all subtasks take. Uncertain? Write down a low and a high. Still uncertain? Split the task into subtasks or confer with someone. 3. Add the times together and multiply by pi. If applicable, do it once for the high and once for the low. 4. Present the high estimate. It is probably closer to the truth. Estimating the low as well is more of a psychological trick.
Don't use the subtasks for the development though. They will be too fine grained.
Each integration point with a 3rd party automatically adds an extra 1 week+ to my estimates, depending upon the complexity.
Great way to lose your people because at some point the only way to make the artificial deadline is to increase the pressure on the team building it to satisfy the manager. Those that can move out will do so, you will be left with the people that do not have much in terms of options to finish the job.
This movie has played 1000's of times in badly managed tech companies.
You need to get this under control as soon as possible, definitely don't "give it a couple of weeks and see if the team picks up pace". Start making lists, what has been done, what needs to be done, prioritize and start tracking that.
Don't create big tasks that are measured in percentages (frombulating the gizmobob is 42% done). Make small tasks that are either done or not done (0 or 1). Small tasks meaning measurable in hours, not days, let the people who will do the work make the estimates. Don't worry, this is not micromanaging, this is properly managing a project, and yes, it will take some of your time keeping track of all of this.
There is also the question whether should you be doing this or should the product owner be doing this? Obviously the PO is not doing this, and you have a leadership position, so I would not hesitate too much.
I think aside from looking up the org chart, you have make sure your teams knows you're there for them. It's likely the have ideas for improving the process in the immediate, as well as the long term. Asking them is probably a wise thing to do.
Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version.
The problems for us was we didn't know status of anything as it was always promised to be ready in 1-2 weeks but feature creep made it bigger and bigger. We tried to help with planning sessions etc but that wasn't enough to get the prototype back to track.
As everybody got a bit too rosy picture of its status, our salesguy started selling the idea forward. The timing seemed to be right etc but we didn't have even proper deml version as the one guy chugged on with his waterfall ad hoc dev style...
After our sales guy confirmed there's lot of demand for this proto and we got the first somewhat working version out and when the next steps were not really sane, we made an intervention which we felt we should've done four months earlier.
First we had a team discussion and decision what should we do together for the situation and then we created concrete plan for the next steps we felt we needed to get first sane version out. Then we made this public to everybody.
The funny thing with this intervention was that the guy who made the feature creep proto felt relieved after this. The biggrst reason why we were so reluctant to intervene was that this guy would get badly demotivated but he had chugged on so long he did get really stressed and frustrated with the situation but didn't know how to get help in the hole he had dug in.
So my advice is to talk out loud and make things visible. Timelines, features bot yet implemented etc. Maybe a gant timeline etc. These helped us to get the project to a sane point shere to continue.
This is interesting. Every example of scope creep I've run into has been a case of too many cooks in the kitchen, or an over-zealous "thinker" (as opposed to a "doer"). If I want to avoid scope creep I limit the scope of the project to as few people as possible and get them as close to the users/market as possible.
It sounds more to me like everyone did get their two cents in, but not in the correct way, and this lone developer was formulating the requirements based on way too many informal channels rather than one structured one.
Get some post-its and write down each feature. Organized on the 2x2 with these axes X: "risk/complexity" Y:"desirability" (that's business & customer desirability.)
Setup a meeting with your products owner and others to try and get a good deal of feedback and communication, reorganize the 2x2 matrix during the meeting to build understanding of risks and priorities.
With everything on the table the big risks should be clear and addressable. The product owner will be able to make some changes to the product plan.
Visibility and transparency is key, don't do an ass covering exercise, and act sooner.
Make sure you understand what has been difficult and outside the teams comfort zone, where improvement could be made etc.
Also be aware of the motivations for the product owner and empathize. Build & strengthen that relationship.
Better feedback loops, better clearer/slicing of feature requirements... I could only generalize, but aim to improve communication and even if all goals aren't met it will be a healthier place and contingency will be easier to work on.
Not to sound like an idiot here or anything, but does that mean something like this: Risk | Complexity ---------------------------------- BiZ desirability | | ---------------------------------- Cus desirability | |
Can't an item be in many of these squares?
You are correct that the way you described wouldn't work.
If I were in the OP's position, I would start discussion with the direct manager as early as possible - and begin by breaking down the remaining scope in terms of where the features are in this diagram.
If the product must be "ready to ship", clearly some corners will need to be cut - especially the bottom right.
A Project or Product are never really finished. There is always a long tail of things to do or remake. In case of the goal being so far ahead, pick three ( or may be just one depending on teams size, but no more then three ) things / function / product features, that it MUST work, start sprinting towards those goals. Make them sound as easy as possible. Make a deadline that they know they could sprint to. My experience has taught me, may be only 1 out of every 10 or 100 person can see the bigger picture. Human are not very good at broad perspective, that is why you must set small enough goals, that is mentally easy to comprehend, and therefore mentally easy to achieve with hard work, but not impossible, damaging morale.
Most of the time, ( if not all the time ), once you prioritise those goals and reach within 80%, of what looks nearly finished project. This is a good time to talk to direct manager, because your last 20% of project will likely take the same amount of time as your first 80%. The higher management will hopefully, having seen the good enough 80% work, decide on which direction to go next. ( Which is another broader set of view on how to jiggle product / project / business/ operation / expenses priorities. )
It's like telling you that you have 3 months to achieve world peace, otherwise all the wars are your fault.
Another way to look at it is that programmers hate death marches. Projects like this could lose people, and sometimes it's good to have some backup.
But of course, they still try it anyway.
Lead: "We're in serious danger of missing our delivery date in 6 months."
Suit: "Egads! Here, have 5 new grads with no experience for your team, get it done!"
> At what point should I start sounding the alarm?
Immediately.
IMMEDIATELY
Then get everybody onboard (your direct manager first). Talk about the problems you have and how you can solve them. Make a plan that everybody believes in and set a new release date together.
In general, modernization projects are not about timing, but about high quality. So cost are the only variable here, making it important to know how much that project is worth for your organization. Is it just nice to have or critical for the development of the next years as it cleans up a lot of technical debt? Keep that in mind as the consideration of stopping a project is always on the table when it leaves its frame.
Start setting up meetings with the project owner ASAP. People are usually more angry if not informed. If they've been informed in advance, there are a lot of options that can be taken, and it lifts a little blame off the dev team.
If the response is, "You'd better hit the dates or heads will roll", then respond with, "Of course we'll do our absolute best!" and start looking for a new job.
If the response is, "That's disappointing, but we can't change anything because all of our marketing/whatever is dependent on you finishing everything on that date." Respond with "Of course we'll do our absolute best! Let's see how it goes for the next 2 weeks and hopefully it will get better". Start poking around under the hood to see if there is any wiggle room for pushing things out (i.e. are you being fed BS, or is it really the case that the company is doomed if you don't deliver). 2 weeks later have the appropriate conversation. One time I had to say, "I completely understand the position we're in, but I'm sorry to tell you that the odds of us completing our part of the work on time is extremely low and I can't think of a way to fix the problem. I think we're going to need to work on a new business plan." Basically its realistically discussing the "we're totally screwed" reality. Try to find the best compromise that you can, while looking for a new job in the background :-)
Otherwise just play it by ear. Unreasonable product owners will be unreasonable no matter what you tell them. You might as well tell them the truth. If they are going to flip out, then let them. If your product owners flipping out bothers you a lot (it bothers me a lot ;-) ), then look for a new job.
However, my experience is that when you are not flipping out yourself and are open to listening to the other person's problems, usually good things happen. I don't often look for new jobs when my projects aren't working out as hoped.
Otherwise, rewrite it in JS.
OutOfTimeException
Well done.
Even if you don't hit your full deadlines you'll have a more complete 'product' this way
If you're in one of these companies where people are not allowed to screw up, then I would recommend you start looking for a healthier work place.
Good luck
If your manager decides to blame you, rather than defend you and your team, it's resume time.
If they don't know the actual status of the project then they haven't been doing their job either.
- A simple summary: we need to deliver by x but current estimate point at y being the delivery date.
- An estimate of delivery for each features you have visibility and their dependencies (not task, features. This email will escalate at some point and you need it be management friendly)
- A backing analysis to defend your task time estimate. Maybe as an external link or attachment.
- A suggestion on a set of feature you feel could be cut or postponed after release to keep the project within deadline.
The fire alarm need to be sounded immediately as you see smoke. Start with your direct manager, but first build consensus between the team: you’ll be squeezing the manager toward the owner, and for him tje path of least resistance will be to put pressure on you and the team.