Ask HN: As a team lead how to handle project going off the rails?
211 comments
This is not going to be like the other advice you get, but I've managed many projects in different organizations and I think it is sound. First and foremost, don't sound any alarms.
Many organizations have common characteristics in this regard. First, they don't expect you to be on time. Sales may think you're going to launch on time, but it's in their financial interest to think so. The rest of the org probably made a schedule they know you can't meet because they think it motivates you to work harder.
Second, unless you're in a startup where everyone's inexperienced, most people probably already know you'll be late, but aren't saying it out loud. They likely have discussed it (up the chain) in meetings you're not in.
Third, people do shoot the bearer of bad news. You can earn a rep as a negative person if you make _true_ predictions out-loud that don't fit the common desire. This is especially true if some of the senior people who know (like your boss) haven't been forthcoming with their bosses.
Have a quiet conversation with your boss over lunch or beers - not a meeting - and tell him/her what you think. Be prepared with details, but if he/she doesn't ask for them, don't provide any. There's a good chance he/she already knows as you suspect.
Even more casually (lunch/beers), express your concerns to the project owner. It's probably not new news to him/her either. Being "positive" is a huge part of the corporate game.: Again, if no details are asked for, don't provide any. Shift the conversation to the weather or the world cup.
You're now down. Go back to work.
Many organizations have common characteristics in this regard. First, they don't expect you to be on time. Sales may think you're going to launch on time, but it's in their financial interest to think so. The rest of the org probably made a schedule they know you can't meet because they think it motivates you to work harder.
Second, unless you're in a startup where everyone's inexperienced, most people probably already know you'll be late, but aren't saying it out loud. They likely have discussed it (up the chain) in meetings you're not in.
Third, people do shoot the bearer of bad news. You can earn a rep as a negative person if you make _true_ predictions out-loud that don't fit the common desire. This is especially true if some of the senior people who know (like your boss) haven't been forthcoming with their bosses.
Have a quiet conversation with your boss over lunch or beers - not a meeting - and tell him/her what you think. Be prepared with details, but if he/she doesn't ask for them, don't provide any. There's a good chance he/she already knows as you suspect.
Even more casually (lunch/beers), express your concerns to the project owner. It's probably not new news to him/her either. Being "positive" is a huge part of the corporate game.: Again, if no details are asked for, don't provide any. Shift the conversation to the weather or the world cup.
You're now down. Go back to work.
Disagree. Just be real. When I joined my current company, they had a project kicking off with a ridiculously short timeline. I asked the product manager to think about how many stories were in the backlog, how many might be added as we went, how many stories they could get through per sprint given the team capacity and then you can put a rough date on it and continue adjusting every sprint as the backlog shrinks and you get a clear picture of velocity. Our first pass put us about 400% over the allotted time (an estimate that has held up pretty well since then).
Next step, is to spell this out to your project team leadership completely unvarnished. Tell them your conclusion and how you got there. Don't let them bargain over your reasoning unless they actually have better evidence. The key is to never say "this is too hard" or "we don't have enough people" or make any other excuses. Not should you be overly emotional. Just give the facts. It's a fait accompli.
Then just ask how they want to deal with it. There is absolutely nothing to be gained from beating around the bush. I've done this more than once and was always taken seriously. One time we had even already signed a fixed-bid contract before I was able to give them an estimate. What you've committed too doesn't change the course of what's actually going to happen.
Next step, is to spell this out to your project team leadership completely unvarnished. Tell them your conclusion and how you got there. Don't let them bargain over your reasoning unless they actually have better evidence. The key is to never say "this is too hard" or "we don't have enough people" or make any other excuses. Not should you be overly emotional. Just give the facts. It's a fait accompli.
Then just ask how they want to deal with it. There is absolutely nothing to be gained from beating around the bush. I've done this more than once and was always taken seriously. One time we had even already signed a fixed-bid contract before I was able to give them an estimate. What you've committed too doesn't change the course of what's actually going to happen.
Oh, hey. You had a fully fleshed out backlog, some initial tracking, with a PO who actually wanted to know rather than just tell the business "everything is okay" and block his ears (knowing that failure to deliver will reflect dev, not him).
You had leaders who were willing to listen to facts rather than prioritize consensus (which brings with it the belief that because you were the dissenting voice in the room demonstrates you're divisive and a problem).
You landed in a really good culture, just one that hadn't faced reality yet. You've yet to plumb the depths of corporate America. :P
You had leaders who were willing to listen to facts rather than prioritize consensus (which brings with it the belief that because you were the dissenting voice in the room demonstrates you're divisive and a problem).
You landed in a really good culture, just one that hadn't faced reality yet. You've yet to plumb the depths of corporate America. :P
> You landed in a really good culture
Here's the crux of the matter. Your approach needs to be tailored to the culture you're in. The higher up in the leadership chain you go, the more important your understanding of the political machinations of your company is.
All corporations have politics, even the smallest startups. Some are just more cutthroat/feudal/kafkaesque than others.
Here's the crux of the matter. Your approach needs to be tailored to the culture you're in. The higher up in the leadership chain you go, the more important your understanding of the political machinations of your company is.
All corporations have politics, even the smallest startups. Some are just more cutthroat/feudal/kafkaesque than others.
Once you realize you are at a company where telling the truth leads to a negative consequence (an incompetent manager hired after the truth told. Their first time managing a department. The department did not previously exist in the enterprise.
The department is specifically to roll out a technology they have never worked with before throughout a large company.
Lets say you were in charge of the project, are intimately familiar with the technology, and had a clear plan that would lead to success but upper management wasn't happy with the timeline. Their goal seems to be to quickly complete this project to display it as a "win".
Now the new manager was brought in, does not understand or care to understand the complexity of the project, and just keeps asking "when will it be done". Then got tired of that and changed to have it done in 2 weeks which is unreasonable, and then gave you an entirely false, negative performance review based on information they apparently forgot to actually verify or they would have known it was already complete and the people who were on the receiving end of the product are incredibly happy.
HR is asking for a meeting to discuss, what do you do? Tell HR about the depth of the incompetence Tell HR you weren't getting support from upper management Tell HR to look into what on earth was the reason this specific manager was selected.
or
GTFO?
This is a real life circumstance I am dealing with. I believe in the technology but unless changes are made it will be a guaranteed failure. Upper management likes the technology and really wants success here, but I know it wont happen unless then changes are made, and the people between the senior executives and me are making it impossible to be a success.
Lets say you were in charge of the project, are intimately familiar with the technology, and had a clear plan that would lead to success but upper management wasn't happy with the timeline. Their goal seems to be to quickly complete this project to display it as a "win".
Now the new manager was brought in, does not understand or care to understand the complexity of the project, and just keeps asking "when will it be done". Then got tired of that and changed to have it done in 2 weeks which is unreasonable, and then gave you an entirely false, negative performance review based on information they apparently forgot to actually verify or they would have known it was already complete and the people who were on the receiving end of the product are incredibly happy.
HR is asking for a meeting to discuss, what do you do? Tell HR about the depth of the incompetence Tell HR you weren't getting support from upper management Tell HR to look into what on earth was the reason this specific manager was selected.
or
GTFO?
This is a real life circumstance I am dealing with. I believe in the technology but unless changes are made it will be a guaranteed failure. Upper management likes the technology and really wants success here, but I know it wont happen unless then changes are made, and the people between the senior executives and me are making it impossible to be a success.
If its gone to HR its already gone pear-shaped. Lay down the facts as you see them, let them know exactly what happened, tell the truth.
If they take it out on you, you know its time to go, but maybe this guy has been pissing other people off and you have no idea about it. Maybe its HR doing due diligence to fire.
Don't make accusations or shit on anyone, you don't know the whole story. Play to your strengths, which is knowing the tech and what it takes to get it to where it needs to be. Make sure you point out your attempts to communicate this fact. Provide any evidence of this- emails, etc. where you're communicating the state of the project and your projections for it. Let them know you've been frustrated with the miscommunication, but make sure that the miscommunication has started with you.
Again, don't shit on anyone. Stick the facts, so that if it blows up in your face it says more about them than it did about you. Its also the kind of resolution I'd I want to see on the interviewer side of "How did you resolve a difficult situation".
If they take it out on you, you know its time to go, but maybe this guy has been pissing other people off and you have no idea about it. Maybe its HR doing due diligence to fire.
Don't make accusations or shit on anyone, you don't know the whole story. Play to your strengths, which is knowing the tech and what it takes to get it to where it needs to be. Make sure you point out your attempts to communicate this fact. Provide any evidence of this- emails, etc. where you're communicating the state of the project and your projections for it. Let them know you've been frustrated with the miscommunication, but make sure that the miscommunication has started with you.
Again, don't shit on anyone. Stick the facts, so that if it blows up in your face it says more about them than it did about you. Its also the kind of resolution I'd I want to see on the interviewer side of "How did you resolve a difficult situation".
Thanks, it is progressing as expected. The only shitting on that was done involved providing repeated examples of attempts to get clarity or schedule meetings that were repeatedly ignored or cancelled at the last minute (which the supervisor for some reason told HR I was the one cancelling). Didn't call into question their competence, just provided support for my side from others, and examples of where the review was completely falsified. Spoke with CLO prior to all of this who is a mentor of mine and is incredibly upset with the treatment I received and says company will provide severance and recommendations if they can't find a suitable location in another department internally.
If you're being made into a fall-guy, then GTFO is likely your only solution.
Be careful with the 'depths of incompetence' stuff. It's assigning judgement and value to the people you're working with. That may be valid (or it may not!), but it doesn't help you professionally. Try not to assume you know why they do what they do, just deal with situation as it is. Telling HR about how bad everyone else is simply won't help you at all.
Your strongest arguments would be:
* The well-documented original plan vs. what has actually happened.
* The factual discrepancy between your performance review and reality. Emphasize positive feedback, and get them to advocate on your behalf if possible.
If someone cares enough to sift through all this, they might figure it out and save you, but chances are good that it won't happen. Having a plan B seems quite prudent.
Be careful with the 'depths of incompetence' stuff. It's assigning judgement and value to the people you're working with. That may be valid (or it may not!), but it doesn't help you professionally. Try not to assume you know why they do what they do, just deal with situation as it is. Telling HR about how bad everyone else is simply won't help you at all.
Your strongest arguments would be:
* The well-documented original plan vs. what has actually happened.
* The factual discrepancy between your performance review and reality. Emphasize positive feedback, and get them to advocate on your behalf if possible.
If someone cares enough to sift through all this, they might figure it out and save you, but chances are good that it won't happen. Having a plan B seems quite prudent.
If you're the tech lead, you have to insist on it. I can give a thumb in the air guess based on an ask, but it's pretty subjective. Step 1 before giving a commitment is to ask for a few weeks of analysis. Get that high-level backlog.
I should say that I've learned this over many years, but have applied it at the highest levels of corporate America and it does work. If you present an estimate _with evidence_ it makes it so much harder for even the most grizzled IT exec to argue against you. Most are still used to thumbs in the air so if you give them something tangible, they will actually love it.
I should say that I've learned this over many years, but have applied it at the highest levels of corporate America and it does work. If you present an estimate _with evidence_ it makes it so much harder for even the most grizzled IT exec to argue against you. Most are still used to thumbs in the air so if you give them something tangible, they will actually love it.
This is how things should run if the work culture was logic based but with rare exceptions it isn't.
As a borderline autistic person I have a very direct communication style and lost account of how many times I burned myself for failing to "beat around the bush".
You can't say "the project is doomed" even if it is true. You can't say it will be so over budget and take so long that it would be better to cut the losses now. Don't expect to go unpunished for saying "the king is nude".
According to my experience both parents are absolutely right, but the first is how most organizations work and the second is an ideal seldom found in the real world.
As a borderline autistic person I have a very direct communication style and lost account of how many times I burned myself for failing to "beat around the bush".
You can't say "the project is doomed" even if it is true. You can't say it will be so over budget and take so long that it would be better to cut the losses now. Don't expect to go unpunished for saying "the king is nude".
According to my experience both parents are absolutely right, but the first is how most organizations work and the second is an ideal seldom found in the real world.
PS: you do get some leeway when you just joined a company, enjoy your honeymoon grace period.
Nope. It will tar you forever amongst anyone you say it to as someone with a bad attitude, divisive, etc. I spent three years at a company where a VP basically viewed me dimly (if, admittedly, necessary) because I delivered bad news early on. It was polite and reasonable, but he was in a difficult place, had people actively whispering "Everything is fine" in his ear, and so when it eventually did blow up (and I was one of the ones who swooped in to fix everything ASAP), it was less "I should have listened" and more "(I) just added to (his) pain".
Attitude is important. Like I said, deliver this news as though it's inescapable objective reality. Akin to saying we can't have a picnic because it's raining. It's nobody's fault and it's not due to anyone's shortcomings. Estimating is hard, building good software takes time. This is how much time this project will take. Let us know evaluate the impact and decide how to cope. It doesn't need to be an argument.
It wasn't an argument. It was a messenger bringing bad news they didn't want to hear. And with other messengers who were actively telling him untruths about reality. And he wasn't sufficiently technical to go evaluate the claims himself; he -had- to decide who to listen to. So, unsurprisingly, he listened to the one that felt better.
You seem to believe that everyone is mature enough to hear bad news, delivered objectively, and accept it without blaming the messenger, and without dismissing it because it doesn't conform to their wishes. I wish I had your luck in bosses.
You seem to believe that everyone is mature enough to hear bad news, delivered objectively, and accept it without blaming the messenger, and without dismissing it because it doesn't conform to their wishes. I wish I had your luck in bosses.
Depends on the circumstances you joined the company.
In some, you actually have to "earn your place" in the company, and most recommendations I've seen are "keep quiet and listen".
In some, you actually have to "earn your place" in the company, and most recommendations I've seen are "keep quiet and listen".
Absolutely.
I'm about 3 months in at a new company and starting to see areas for improvement. I just make a note and keep my mouth shut. In another 3-6 months I'll have earned the right to start diplomatically suggesting some of my ideas. For now i just try to understand the thinking that went into decisions that resulted in our current state.
If you want to go into a new organization and "be disruptive" and you're not a management consultant, be prepared for the likely outcome of failure.
I'm about 3 months in at a new company and starting to see areas for improvement. I just make a note and keep my mouth shut. In another 3-6 months I'll have earned the right to start diplomatically suggesting some of my ideas. For now i just try to understand the thinking that went into decisions that resulted in our current state.
If you want to go into a new organization and "be disruptive" and you're not a management consultant, be prepared for the likely outcome of failure.
I'm not sure if you are talking about the general leeway most new employees get, or if you are saying you get a period of time as a brand new employee to point out everything you think is wrong in a matter of fact way. If the latter, I disagree.
> Just be real.
This works pretty well in smaller companies or startups, but corporate culture is usually political enough that it would be a disaster for your career.
> Then just ask how they want to deal with it.
Disagree. Anytime you find a problem you should come up with at least two solutions before you bring it to leadership. Managers hate people that only come to them with problems. You're closest to the project and you should be the one to know the situation and possible solutions.
This works pretty well in smaller companies or startups, but corporate culture is usually political enough that it would be a disaster for your career.
> Then just ask how they want to deal with it.
Disagree. Anytime you find a problem you should come up with at least two solutions before you bring it to leadership. Managers hate people that only come to them with problems. You're closest to the project and you should be the one to know the situation and possible solutions.
Anytime you find a problem you should come up with at least two solutions before you bring it to leadership.
Yes. I think many people who believe they were punished for delivering bad news were actually punished for not offering ways to solve the problem. It's easy to simply say, "the project is doomed" and leave the problem in management's lap; much harder to come up with creative ways to rescue a bad situation.
Yes. I think many people who believe they were punished for delivering bad news were actually punished for not offering ways to solve the problem. It's easy to simply say, "the project is doomed" and leave the problem in management's lap; much harder to come up with creative ways to rescue a bad situation.
Being real can be a massive mistake when management is more concerned with preserving management than revenue. It's pretty common, and experienced managers are way better at getting you out than at fixing problems. (Well, they see it as one and the same)
> One time we had even already signed a fixed-bid contract before I was able to give them an estimate.
Only one time?? Are you hiring? :)
Only one time?? Are you hiring? :)
So much this it's painful.
You will never be thanked for telling them uncomfortable truths, even if they -don't- know. Even the private conversation is dangerous; as you say, keep it as low key and minimal as possible ("i have some concerns about the timeline" is literally all you should say unless they ask, and your answers to any followup question should be equally circumspect).
Instead, as others have mentioned, just make sure you document what does get done. Ideally have a decent backlog of things that need to get done, but that presumes a PO who does their job (and it sounds like he/she probably isn't). That's your CYA, and your innocent response if they ask why you didn't raise the alarm.
You will never be thanked for telling them uncomfortable truths, even if they -don't- know. Even the private conversation is dangerous; as you say, keep it as low key and minimal as possible ("i have some concerns about the timeline" is literally all you should say unless they ask, and your answers to any followup question should be equally circumspect).
Instead, as others have mentioned, just make sure you document what does get done. Ideally have a decent backlog of things that need to get done, but that presumes a PO who does their job (and it sounds like he/she probably isn't). That's your CYA, and your innocent response if they ask why you didn't raise the alarm.
What's PO?
ProductOwner, may also be ProcessOwner in some companies.
Product Ogre
[deleted]
Product Owner
[deleted]
[deleted]
[deleted]
Project Owner
Well put.
Deadlines often slip. It happens ALL THE TIME, regardless of elaborate and sophisticated project management techniques and skilled contributors. Deadline slippage is also RARELY FATAL, but yeah, leads/PM's can absolutely get themselves metaphorically shot by bearing bad news to the wrong people at the wrong time.
Some orgs hire a ridiculous number of PMP's who pretend like they're making a difference but are really just practicing an elaborate dance of goal-post-moving to appease the deadline-gods. People in such orgs often bullshit about a "track record" of being "always on time and under budget".
Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.
Deadlines often slip. It happens ALL THE TIME, regardless of elaborate and sophisticated project management techniques and skilled contributors. Deadline slippage is also RARELY FATAL, but yeah, leads/PM's can absolutely get themselves metaphorically shot by bearing bad news to the wrong people at the wrong time.
Some orgs hire a ridiculous number of PMP's who pretend like they're making a difference but are really just practicing an elaborate dance of goal-post-moving to appease the deadline-gods. People in such orgs often bullshit about a "track record" of being "always on time and under budget".
Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.
I've been in organizations where people know projects slip and are mature about it but I've also been in places where projects absolutely do not miss their go-live dates without a major impact for the relevant managers and teams.
Always wise to know what the corporate culture is around these kinds of things.
Always wise to know what the corporate culture is around these kinds of things.
Agreed, especially when you're dealing with external clients. I've been in situations where internally we've been fine with a slipped go-live date, only for a CEO at a client to send an email at 4:50pm putting everyone on blast and demanding that all developers stay at the office until it is live, or else (no lie, literally had that email, quote for quote, in my inbox less than a year ago).
Corporate culture includes everyone involved in a project. You can't be calm if you have someone outside of your office going mental over something being a day or a week late.
Corporate culture includes everyone involved in a project. You can't be calm if you have someone outside of your office going mental over something being a day or a week late.
> practicing an elaborate dance of goal-post-moving to appease the deadline-gods
I've seen this so many times, it's like why even bother attempting to describe what we'll deliver. Just put the date down.
I've seen this so many times, it's like why even bother attempting to describe what we'll deliver. Just put the date down.
> Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.
How do you know deadlines are going to slip when planning the project? Makes no sense.
How do you know deadlines are going to slip when planning the project? Makes no sense.
After you gain experience from previous slipped deadlines, you can see patterns that lead to slippage and, more importantly, get wise to the smell of unrealistic expectations. That's how you know that deadlines are going to slip.
you're assuming that deadlines are set based on the amount of time the work requires. Not often true. Generally deadlines are set before anyone knows how much work is required.
That's one of the patterns.
Take your estimation of the work to do, multiply it by 2.
Surprisingly, it works relatively well to estimate how long the project will actually take.
Surprisingly, it works relatively well to estimate how long the project will actually take.
Those multiply by whatever factor estimates are perhaps defensible if you're talking about a few person-hours for a small no-bid project.
It falls apart if you're talking about 10's to 100's of people working for weeks/months/years, or wherever you need to compete with other vendors for the contract.
It falls apart if you're talking about 10's to 100's of people working for weeks/months/years, or wherever you need to compete with other vendors for the contract.
For those projects, everybody is over-optimistic in their respective bids (some could say they are basically lying...). But that's part of the game unfortunately.
However sometimes, it can be a calculated risk, for most projects, something is provided by the client, and generally they are also late on their parts. If played correctly it can hide delays on your side.
Also, being over-optimistic in a bid doesn't mean you have to be over-optimistic internally, you could set realistic expectations internally and "manage" properly the delays on the customer front.
Just to be clear, this is a cynic view of things. Every time I see something like that, I cringe inside (and even outside).
However the 2x rule can be quite limited in big projects as it doesn't account for the overhead induced by the size. In a team of hundreds, 30, 40 or 50% of the efforts can be lost due to difficulties in communication, management layers, heterogeneous set of competencies and skills, etc. It's harder to identify what this overhead could be. They can be huge differences between relatively well integrated teams and a complete mess.
However sometimes, it can be a calculated risk, for most projects, something is provided by the client, and generally they are also late on their parts. If played correctly it can hide delays on your side.
Also, being over-optimistic in a bid doesn't mean you have to be over-optimistic internally, you could set realistic expectations internally and "manage" properly the delays on the customer front.
Just to be clear, this is a cynic view of things. Every time I see something like that, I cringe inside (and even outside).
However the 2x rule can be quite limited in big projects as it doesn't account for the overhead induced by the size. In a team of hundreds, 30, 40 or 50% of the efforts can be lost due to difficulties in communication, management layers, heterogeneous set of competencies and skills, etc. It's harder to identify what this overhead could be. They can be huge differences between relatively well integrated teams and a complete mess.
My business sponsor claimed to always take my estimate, double it and bump the units.
3 hrs => 6 days
2 days => 4 weeks
3 hrs => 6 days
2 days => 4 weeks
So how would he estimate 1 year project?
How to do you know? Because they almost always slip.
Take the original estimate, which is always optimistic, double it, add another 50% "just in case", and you're a lot closer.
This advice is a good first read on the political elements before you make a real move, but it’s not a plan, and it sounds like a recipe for mediocrity. (Not that there is anything wrong with that)
If you actually want to have some integrity when you talk about deadlines before it eats up your insides and you lose sleep you will need to have these beer / lunch conversations to gauge the level of appetite for change and then start talking about how to get something shipped on time as well as the consequences for not shipping on time.
Sounds like you already have this dialog with your manager. Keep talking about how best to manage expectations up the chain.
You’ll want to get buy-in to reduce scope or make whatever other changes you need, otherwise you’ll have to lie to keep up the facade that things will ship on time. It will burn you out.
If the read in the parent comment is bad for your org and it’s NOT normal to BS deadlines and ship late then no paper trail or written warnings, risks, and issues brings with it some badness as well - judge for your organization. I’m guessing you may already know the answer.
This is probably not the best career ladder advice at some firms, but at all costs make sure you never lie for anybody. Keep your integrity. Be honest. Sleep at night.
Of course sometimes “honest” is an excuse to be pessimistic. Look hard to make sure your dire warnings are not “chicken little” pessimism, then talk it out with your management, but don’t lie for them and be honest about your engineering and your team.
If you actually want to have some integrity when you talk about deadlines before it eats up your insides and you lose sleep you will need to have these beer / lunch conversations to gauge the level of appetite for change and then start talking about how to get something shipped on time as well as the consequences for not shipping on time.
Sounds like you already have this dialog with your manager. Keep talking about how best to manage expectations up the chain.
You’ll want to get buy-in to reduce scope or make whatever other changes you need, otherwise you’ll have to lie to keep up the facade that things will ship on time. It will burn you out.
If the read in the parent comment is bad for your org and it’s NOT normal to BS deadlines and ship late then no paper trail or written warnings, risks, and issues brings with it some badness as well - judge for your organization. I’m guessing you may already know the answer.
This is probably not the best career ladder advice at some firms, but at all costs make sure you never lie for anybody. Keep your integrity. Be honest. Sleep at night.
Of course sometimes “honest” is an excuse to be pessimistic. Look hard to make sure your dire warnings are not “chicken little” pessimism, then talk it out with your management, but don’t lie for them and be honest about your engineering and your team.
> Third, people do shoot the bearer of bad news. You can earn
> a rep as a negative person if you make _true_ predictions
> out-loud that don't fit the common desire.
I've heard this very often, both as advise, complaint and even in an intimidating manner. And yes, I've seen this, people who stay kind of positive stay in their position even if they screw up a project completely so it has to be "rebooted". In fact I've also observed a super negative person, being a colleague of mine for 2.5 years and staying good with everybody despite one screwed up project.
On the other hand people have put me in various settings under high pressure to keep my mouth shut both internally and externally. (That was only in the startup/co-founding setting though.)
My conclusion: I'd take this advice with a biiiiiiig grain of salt. In my experience people get away with everything as long as they stay confident and keep their shit together.
Disclaimer: I'm not a team lead
> a rep as a negative person if you make _true_ predictions
> out-loud that don't fit the common desire.
I've heard this very often, both as advise, complaint and even in an intimidating manner. And yes, I've seen this, people who stay kind of positive stay in their position even if they screw up a project completely so it has to be "rebooted". In fact I've also observed a super negative person, being a colleague of mine for 2.5 years and staying good with everybody despite one screwed up project.
On the other hand people have put me in various settings under high pressure to keep my mouth shut both internally and externally. (That was only in the startup/co-founding setting though.)
My conclusion: I'd take this advice with a biiiiiiig grain of salt. In my experience people get away with everything as long as they stay confident and keep their shit together.
Disclaimer: I'm not a team lead
"Perception is reality"
You can be a negative/realist as long as your perceived value outweighs your "bad" attitude. The problem with this is that people are really bad at placing value on soft skills and all it takes is one clueless manager to sandbag you.
Everything op said above is spot on
You can be a negative/realist as long as your perceived value outweighs your "bad" attitude. The problem with this is that people are really bad at placing value on soft skills and all it takes is one clueless manager to sandbag you.
Everything op said above is spot on
I get the point for an Engineer. There the chances to endless promotions are far higher if you stay nice and calm all the time. Hard earned experience, never got a promotion but always more money and "crazier" jobs over time.
But I mean for anyone with team responsibility: staying silent is bad for you, which is okay if you're in for the career. I totally respect that, people should be ambitious if they want to. But this is the recipe to make workplaces toxic and bad for the whole team.
But I mean for anyone with team responsibility: staying silent is bad for you, which is okay if you're in for the career. I totally respect that, people should be ambitious if they want to. But this is the recipe to make workplaces toxic and bad for the whole team.
I'm not saying you have to a Bright Ray of Sunshine all the time. But it might not work out so well of you are the office grouch because it wears people out.
(On the other hand...maybe the place is that bad then)
I can agree to that ;)
This is a good advice and all three points are spot on (on time deliveries are unusual; management likely knows you are late; messengers often get shot).
You do need to figure out for yourself a realistic, pretty safe time when you will be ready: an extra month? three months? never? You say the work is outside your team's comfort zone. This is potentially a much bigger red flag than being late. Will the team learn and deliver, or it just cannot execute at the speed requirements are changing or will soon be? Be brutally honest with yourself.
If you think you can safely deliver the product in, say, three extra months, then keep working but be ready with good estimates when the time comes to redo the schedule. When that discussion comes (usually suddenly), having a clear plan and realistic estimates that you can confidently present will likely give you (most of) what you ask for. IME really bad options are either agreeing to fix everything in a week (if you know it will take three months) or not having an estimate at all "we are burning midnight oil and I cannot tell you when we will be done". Either could lead to quick problems.
IME when "what do we do with this crap" time comes, senior management does not care why you are late (everyone is at least some of the time). They want to know if you have a plan and look ready to execute it. Just my 2c. Good luck!
You do need to figure out for yourself a realistic, pretty safe time when you will be ready: an extra month? three months? never? You say the work is outside your team's comfort zone. This is potentially a much bigger red flag than being late. Will the team learn and deliver, or it just cannot execute at the speed requirements are changing or will soon be? Be brutally honest with yourself.
If you think you can safely deliver the product in, say, three extra months, then keep working but be ready with good estimates when the time comes to redo the schedule. When that discussion comes (usually suddenly), having a clear plan and realistic estimates that you can confidently present will likely give you (most of) what you ask for. IME really bad options are either agreeing to fix everything in a week (if you know it will take three months) or not having an estimate at all "we are burning midnight oil and I cannot tell you when we will be done". Either could lead to quick problems.
IME when "what do we do with this crap" time comes, senior management does not care why you are late (everyone is at least some of the time). They want to know if you have a plan and look ready to execute it. Just my 2c. Good luck!
Strongly disagree. I think this is the cynical view, and I'm sure is valid in many companies, but raising potential issues early is really important - other people can't fix problems if they don't know about them. It sounds like you have visibility into a problem that others may not, tell them! Don't assume people already know.
Like some of the other posts said - be real. If people don't respond well to this then the company has a bigger problem than a slipped schedule.
Like some of the other posts said - be real. If people don't respond well to this then the company has a bigger problem than a slipped schedule.
You could be right, but in my experience it is extremely unlikely that the lead is the only person who realizes that the project is going to be late.
One sign this isn't healthy environment, frankly, is that no one has (apparently) asked the lead how he/she thinks the project is going. This also suggests that they already know and/or don't want to know.
One sign this isn't healthy environment, frankly, is that no one has (apparently) asked the lead how he/she thinks the project is going. This also suggests that they already know and/or don't want to know.
This is the only really true, non-theoretical advice in the thread.
OP's description is generally how every project at every company has ever worked, forever.
OP's description is generally how every project at every company has ever worked, forever.
> "Third, people do shoot the bearer of bad news."
True. But under such circumstances chances are pretty good someone(s) is going to be shot anyway.
I think the answer is solid. But if going this route I would update my resume and reach out to my network.
If this ends badly you want to be prepared.
True. But under such circumstances chances are pretty good someone(s) is going to be shot anyway.
I think the answer is solid. But if going this route I would update my resume and reach out to my network.
If this ends badly you want to be prepared.
Always be prepared. At the end of the day you are just a resource to a company. Someone who implements some spec for a bit of dough.
> Third, people do shoot the bearer of bad news.
As someone who has been a bearer of bad news, this is a sound advice. Most of the time you are told - "At least give it a try". And even if you tell them - "I did try but still likely we will miss the deadline". They will ask you to check again.
It is mind-numbing when it happens the first time. And most of the time you get disillusioned and think - "I need to look for another job". Guess what? Every corporate works like this. All about positivity and "You can do this" messages. And most importantly people setting up super-aggressive timelines knowing well that you are going to fail.
> Second, unless you're in a startup where everyone's inexperienced,
Curious about this though. So, as per you startups are run by people who don't know how to run projects?
As someone who has been a bearer of bad news, this is a sound advice. Most of the time you are told - "At least give it a try". And even if you tell them - "I did try but still likely we will miss the deadline". They will ask you to check again.
It is mind-numbing when it happens the first time. And most of the time you get disillusioned and think - "I need to look for another job". Guess what? Every corporate works like this. All about positivity and "You can do this" messages. And most importantly people setting up super-aggressive timelines knowing well that you are going to fail.
> Second, unless you're in a startup where everyone's inexperienced,
Curious about this though. So, as per you startups are run by people who don't know how to run projects?
Caveat, this seems to play out fine if the project slips 10-20%, which is sort of within expectation, and your competitors may be slipping the same amount as we speak.
If however the project is due to slip 200%, or 400%- I guess I don't have specific advice, but that kind of project is the sort of project that can sink a company. Of course, you only really get to that point if vice-bigwigs are lying severely to the bigwigs, in which case there may be nothing a team lead can do about it.
If however the project is due to slip 200%, or 400%- I guess I don't have specific advice, but that kind of project is the sort of project that can sink a company. Of course, you only really get to that point if vice-bigwigs are lying severely to the bigwigs, in which case there may be nothing a team lead can do about it.
> Be prepared with details, but if he/she doesn't ask for them, don't provide any.
Also be prepared with solutions. Any decent manager or product owner is going to ask things like: "What's a realistic timeline?" or "What could be cut to get closer to the timeline?"
It would worry me more if they didn't ask details. In my experience that means they sent you on a fools errand expecting you to fail and take the heat for it.
Also be prepared with solutions. Any decent manager or product owner is going to ask things like: "What's a realistic timeline?" or "What could be cut to get closer to the timeline?"
It would worry me more if they didn't ask details. In my experience that means they sent you on a fools errand expecting you to fail and take the heat for it.
I agree with much of your premise but one problem I run into: If you have these off-the-record meetings, where is your documentation if they say, 'I didn't know it would be late'? In my experience, people not only dislike bad news, they ignore it:
First they hear what they want to hear, i.e., what is not threatening to them. 'Project delivery will certainly be late' is heard as 'the next milestone will be late' or 'we're a little behind schedule and will catch up' or 'it's making another project late', etc. It's truly incredible what people will construct in their minds. What's the saying? 'Don't expect people to understand what their salary depends on them not understanding'?
Second, like everyone, they ignore or put off dealing with bad news. (Probably, that's a temptation of the OP.) Then they say, 'I didn't know.'
It depends on the people and the organization, of course, but you do you protect yourself from being thrown under the bus?
First they hear what they want to hear, i.e., what is not threatening to them. 'Project delivery will certainly be late' is heard as 'the next milestone will be late' or 'we're a little behind schedule and will catch up' or 'it's making another project late', etc. It's truly incredible what people will construct in their minds. What's the saying? 'Don't expect people to understand what their salary depends on them not understanding'?
Second, like everyone, they ignore or put off dealing with bad news. (Probably, that's a temptation of the OP.) Then they say, 'I didn't know.'
It depends on the people and the organization, of course, but you do you protect yourself from being thrown under the bus?
Documentation won't save you if the shit truly hits the fan. What will save you, if anything, it's that the leadership considers you one of them.
I agree in general; 'I told you so and it's your fault' doesn't help a relationship in crisis. But ...
It can compel some attention and provide an opportunity for extra thought. An unwanted verbal message over lunch is easily forgotten or misremembered, intentionally or not, weeks or months later. A written one is harder to ignore and provides something the recipient can re-read and ponder later.
Also, there are circumstances where documentation is good to have. For example, it may help in a company with more layers; your email to the guy 2 layers up may help when the guy 4 layers up gets involved.
It can compel some attention and provide an opportunity for extra thought. An unwanted verbal message over lunch is easily forgotten or misremembered, intentionally or not, weeks or months later. A written one is harder to ignore and provides something the recipient can re-read and ponder later.
Also, there are circumstances where documentation is good to have. For example, it may help in a company with more layers; your email to the guy 2 layers up may help when the guy 4 layers up gets involved.
This advice is spot on. I would add one thing: make sure you don't surprise your manager. Talk to her. You and she should be on the same page about your project's progress.
It's her responsibility to help the rest of your business do the best they can with reality. If sales of your existing product have dried up because prospects are waiting for the modernized one, that's a big problem (been there). But it's a problem belonging to product and sales management, not you. Unless you are a founder.
Renovating software is hard, much harder than greenfield software. All the best to you.
It's her responsibility to help the rest of your business do the best they can with reality. If sales of your existing product have dried up because prospects are waiting for the modernized one, that's a big problem (been there). But it's a problem belonging to product and sales management, not you. Unless you are a founder.
Renovating software is hard, much harder than greenfield software. All the best to you.
This is the right path if you're a lead on one team of many in a larger org, you don't want to risk needing to find another job, and you don't have a burning desire to make a difference and build a track record of change.
If you're in a smaller company, and you have clout due to being closer to the top of the food chain, and you have a vested interest in the success of the operation, to the point that it's worthwhile cutting your losses and moving elsewhere if the outcome isn't positive, then the higher risk strategy of pushing for change makes more sense.
If you're in a smaller company, and you have clout due to being closer to the top of the food chain, and you have a vested interest in the success of the operation, to the point that it's worthwhile cutting your losses and moving elsewhere if the outcome isn't positive, then the higher risk strategy of pushing for change makes more sense.
OP needs to be concerned about the blame game if the project is a big deal. The manager won’t want to take blame, same for everyone else in the chain. The best thing OP can do is raise it quietly with the manager, and not terribly forcefully, note that this was raised. I also think going to anyone other than the direct manager is a bad idea. Then take some actions that can be used in retrospect as evidence that OP was trying to ameliorate the situation. Fundamentally this is a management issue, don’t let it become a game of blaming engineering for management’s flaws.
This isn’t fundamentally a management issue. Lead roles should be able to give them a better idea of how long a project will take. if they expect delays, it should’ve been brought up way before. There’s little to no room for change without a dent in the company’s reputation at this point.
However, these things happen time to time and when you have a stubborn PO like that from the beginning, you should have started looking elsewhere way before as a lead role. I’ve never heard of situations where a manager takes the blame. It always falls to the engineers.
However, these things happen time to time and when you have a stubborn PO like that from the beginning, you should have started looking elsewhere way before as a lead role. I’ve never heard of situations where a manager takes the blame. It always falls to the engineers.
Often, if you 'stay positive' and don't make too many waves no-one will get blamed. Like all cultures groups of managers like to see problems as being with external groups or things outside their control, and become more tight-knit as a result.
If you do too much boat-rocking, though, you may find yourself looked on as "external" to the other responsible people, which is not a good place to be.
If you do too much boat-rocking, though, you may find yourself looked on as "external" to the other responsible people, which is not a good place to be.
I hate to agree with you. This honesty/positivity dilemma is something I'm struggling with.
Occasionally people talk about the "compliment sandwich".
1. Focus on something going well. 2. By the way, could you fix this little thing? 3. Return to positive stuff.
This formula can be applied to delivering honesty amid positivity. Ideally whoever you're communicating is mature enough to just take honest feedback straight, but if they aren't then this can be a safe(r) way to deliver it.
1. Focus on something going well. 2. By the way, could you fix this little thing? 3. Return to positive stuff.
This formula can be applied to delivering honesty amid positivity. Ideally whoever you're communicating is mature enough to just take honest feedback straight, but if they aren't then this can be a safe(r) way to deliver it.
This seemingly simple tactic, WORKS. It works even with mature folks. It is just harder to be angry when someone pads your ego or your mood even just a little bit.
The 'compliment' does not even have to be direct or a compliment per se, it can even be something positive like news/results about the initiant or a third party. You are just pulling out some positive endorphin mojo, to slow down the angry mojo.
My old boss had a phrase, "bad news doesn't age well". I have followed this throughout my career and it's served me well. I have not found it to be bad to be the bearer of bad news. I have found that it makes me perceived as transparent and honest about expectations.
Bearers of bad news are frowned upon when the bad news is their fault and not presented when its determined to exist. I think this is a distinction that should be made with your phrase.
Bearers of bad news are frowned upon when the bad news is their fault and not presented when its determined to exist. I think this is a distinction that should be made with your phrase.
This is basically the opposite of what I would advise. Count the number of “probably” and “good chance” in that reply!
1. A small course correction can work wonders early on, but if you wait until the ship is seconds from the iceberg there’s nothing anyone can do. Or use the cancer analogy: early detection can be the difference between life and death.
2. Yes, sometimes deadlines are padded and you’re silently expected to miss a little. Sometimes they are not and you’re not. How do you know which one applies to you and your project?
3. Having private conversations is fine but private conversations can be denied and privately made decisions do not become the broadly understood plan of record, leading to confusion and ambiguity, which are risk multipliers.
4. A positive attitude is good and hiding real problems, evading responsibility, and playing corporate games might work in the short term. However if that becomes what you are known for, it will limit your career long term.
1. A small course correction can work wonders early on, but if you wait until the ship is seconds from the iceberg there’s nothing anyone can do. Or use the cancer analogy: early detection can be the difference between life and death.
2. Yes, sometimes deadlines are padded and you’re silently expected to miss a little. Sometimes they are not and you’re not. How do you know which one applies to you and your project?
3. Having private conversations is fine but private conversations can be denied and privately made decisions do not become the broadly understood plan of record, leading to confusion and ambiguity, which are risk multipliers.
4. A positive attitude is good and hiding real problems, evading responsibility, and playing corporate games might work in the short term. However if that becomes what you are known for, it will limit your career long term.
I really agree with this advice. I would add that during those quiet conversations the best leads usually say, "we can make this deadline, but we'll need to do x/y/z", where x is increasing resources by a %, y is decreasing scope by some feature(s), and z is increasing time alotted by some days.
That constructive feedback is actionable and adds value. If your manager (or the business) chooses to ignore it, don't be frustrated, but when it's constructive, finite and actionable, you'll be surprised how often they'll make the changes.
That constructive feedback is actionable and adds value. If your manager (or the business) chooses to ignore it, don't be frustrated, but when it's constructive, finite and actionable, you'll be surprised how often they'll make the changes.
There's no reason you can't have an off-the-books meeting and discuss this (separately) with your boss and the PO. No need to go to the extra step of setting up a lunch or having a drink with them, especially if it's not something you do regularly.
If you've been there for 3 years and never had a drink socially with the PO (who presumably OP doesn't report to other than in this status report context) then you suggest it just so you can talk about how you're not hitting the schedule, it's possible they don't take it well.
If you've been there for 3 years and never had a drink socially with the PO (who presumably OP doesn't report to other than in this status report context) then you suggest it just so you can talk about how you're not hitting the schedule, it's possible they don't take it well.
I was really upset at this comment at first. After thinking about it some more I like that it questions fundamental assumptions about the original question namely,
“What happens if the deadline slips?”
If the project is late, does the company go out of business? Do people get fired? Is the overall deliverable unusable within the org? Is the deal lost?
If the answer to these is a big “no” then totally agreed with OP to not sound an alarm.
However configuring a skilled team and leading it to do excellent work and constantly improve should be something most people strive for.
“What happens if the deadline slips?”
If the project is late, does the company go out of business? Do people get fired? Is the overall deliverable unusable within the org? Is the deal lost?
If the answer to these is a big “no” then totally agreed with OP to not sound an alarm.
However configuring a skilled team and leading it to do excellent work and constantly improve should be something most people strive for.
Or worse, an executive misses getting some of their bonus...
NB Based on one fairly large project I was involved in for a large company where there was a huge drive to get the system delivered on time then.... nothing. Nobody used it for months.
Eventually we found out about the real reason.
NB Based on one fairly large project I was involved in for a large company where there was a huge drive to get the system delivered on time then.... nothing. Nobody used it for months.
Eventually we found out about the real reason.
Honestly if this is true in your organization you should probably be looking for another job anyways. Even if this is common that doesn't mean it isn't dysfunctional.
From personal experience, I would endorse the above advice. I'm all for being honest, but organizations are strange beasts, and I once got fired for something just like this.
As long as you are sure you will eventually succeed, ignore the problem and keep going. Being late is no big deal; it's actually a confirmation of how amazing and innovative your product is.
If someone senior brings up the issue, don't flinch, and be ready with an alternative timeline.
As long as you are sure you will eventually succeed, ignore the problem and keep going. Being late is no big deal; it's actually a confirmation of how amazing and innovative your product is.
If someone senior brings up the issue, don't flinch, and be ready with an alternative timeline.
There are a LOT of assumptions here.
> The rest of the org probably made a schedule they know you can't meet
> Most people probably already know you'll be late, but aren't saying it out loud
> There's a good chance <your boss> already knows as you suspect.
> It's probably not new news to <the project owner> either.
Doesn't take much for one, if not all of those to be untrue. And by the time it unravels, it's too late.
> The rest of the org probably made a schedule they know you can't meet
> Most people probably already know you'll be late, but aren't saying it out loud
> There's a good chance <your boss> already knows as you suspect.
> It's probably not new news to <the project owner> either.
Doesn't take much for one, if not all of those to be untrue. And by the time it unravels, it's too late.
How should you go about delivering a bad news and solutions for without being termed as a negative influence?
> Have a quiet conversation with your boss over lunch or beers - not a meeting
If you do this, follow it up with an email outlining everything you said so you have a paper trail that you brought it up with your boss.
If you do this, follow it up with an email outlining everything you said so you have a paper trail that you brought it up with your boss.
Agree. Also management above you might have scope-reducing contingency plans which they will slide into place to ensure that something gets released on the schedule.
Is there a better way than this? Or is this just how it has to be?
Sound, practical advice, should be top comment.
I don’t understand why he/she needs to sugercoat things so much and do things over lunch, drinks/beer? Imagine this is a female lead asking her male boss out for drinks so she can be the casual bearer of bad news?
That’s just bull.
If your organization isn’t willing to get real and is blaming people instead of processes, it’s the wrong org to be.
Just say things as they are. I’d just raise this in my 1:1 with boss and boss’s boss. “It’s highly likely that we’ll miss X deadline, because of Y reasons. Here are some options we have. Either cut scope to meet deadline, pull in more resources for Z work, that can be parallelized, or push back the deadline.”.
That’s just bull.
If your organization isn’t willing to get real and is blaming people instead of processes, it’s the wrong org to be.
Just say things as they are. I’d just raise this in my 1:1 with boss and boss’s boss. “It’s highly likely that we’ll miss X deadline, because of Y reasons. Here are some options we have. Either cut scope to meet deadline, pull in more resources for Z work, that can be parallelized, or push back the deadline.”.
Either you're working in an unusually healthy environment, or you haven't done this often enough to see it backfire. If it's the first. You're very fortunate.
You're not technically wrong, but most of us don't have the good fortune to work in an organization where we can "be real". Yet, we still have to put food on the table. You, in the organization you work in, might feel comfortable going to your boss and boss's boss, but as you read in the parent comment, I hope you understand that not every organization is that way.
[deleted]
I suspect that you did not managed expectations. PO was not really working as the proper owner and have no clue about progress and effort being put. Your direct manager does not care as it can always blame everything on you. And the team is not so great if they have problems with "comfort zone".
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.
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.
And if it's an online solution, propose to roll out some features gradually.
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.
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.
The multiply by three approach has also worked for me in the past. People often estimate the time taken to do the task, typically not taking in to consideration the other aspects of their job (eg comms/planning/rework/productionisation/etc) needed to get said task done. I do like the use of pi though, I’ll be adopting this going forwards!
With experience you can account for this. What's hard to account for is some 3rd party vendor blowing you off, or slow rolling you, for weeks. Or management pulling you into another project.
Each integration point with a 3rd party automatically adds an extra 1 week+ to my estimates, depending upon the complexity.
Each integration point with a 3rd party automatically adds an extra 1 week+ to my estimates, depending upon the complexity.
Personally I prefer story points per card, and then calculating the average velocity of the team per sprint vs. the number of story points left in the backlog. This presumes a deadline more than a sprint away, though, since it's a little fuzzier. Mostly it keeps people away from saying "Hey, we said this card would only take X hours!"
This is the best advice here.
I would work for you.
I would work for you.
Assess the product delivery in terms of risks. Look at what's on the roadmap and build a 2x2 matrix of the intended features.
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.
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.
> Organized on the 2x2 with these axes X: "risk/complexity" Y:"desirability" (that's business & customer desirability.)
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?
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?
What's being described is an X-Y scatter plot:
Necessary
^
|
Simple <---+---> Complex
|
V
Nice to haveThis makes the most sense to me.
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.
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.
Exactly.
The X axis would go from low risk+complexity to high risk+complexity, and the y axis from low biz+cus desirability to high biz+cus desirability.
You are correct that the way you described wouldn't work.
You are correct that the way you described wouldn't work.
Yes it seems like an item would be posted on an axis where theoretically the item could exist on both ends?
Nice to have should really be, not necessary. Problem with that is the product team will be less likely to mark things as not-necessary. So we dub these less needed features as nice to have so there's a higher chance of negotiating about their priority.
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.
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.
[deleted]
It sounds to me as if you're doing a 'big bang' when you should be doing something incremental instead.
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.
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.
Incremental is key here, 'modernization' sounds like a large and blurry goal.
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.
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.
Great point. Given what (little) we know it's fairly safe to say someone (important) on the dev team is looking to leave and will likely do so at the ultimate wrong time.
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.
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.
If you bury it as others suggest, you will lose credibility as a leader even if you have covered yourself. There is no good answer to “Why are we finding out about a 3 month slip the Friday before deployment? If we are 3 months behind shouldn’t we have more than a day of notice?” Execs hate surprises and engineers hate bosses who don’t tell the truth.
The key to surviving this is:
1) Informally let everyone who may look bad know the truth.
2) Gather data. (No metric is perfect but this takes it away from being about people)
3) When it comes time to present formally, list what you are doing about it and what everyone else needs to do. It should be worded as, “To hit this date, we need Jane QA to do X, Joe PM to pick the two most important features, bla bla...”
4) Document #3 in a plain-English follow-up email. List names not orgs.
5) Send weekly updates to number 4 in writing.
If people don’t give you the help you need, you’ve done your part. They also won’t be surprised.
In all of this, be specific, factual and unemotional.
The key to surviving this is:
1) Informally let everyone who may look bad know the truth.
2) Gather data. (No metric is perfect but this takes it away from being about people)
3) When it comes time to present formally, list what you are doing about it and what everyone else needs to do. It should be worded as, “To hit this date, we need Jane QA to do X, Joe PM to pick the two most important features, bla bla...”
4) Document #3 in a plain-English follow-up email. List names not orgs.
5) Send weekly updates to number 4 in writing.
If people don’t give you the help you need, you’ve done your part. They also won’t be surprised.
In all of this, be specific, factual and unemotional.
Never let time pass. Project timeline slips one day at a time. As a lead your role is not to control scope, but if you feel your team will not be able to deliver by deadlines you have to make a case for it and you’ll need:
- 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.
- 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.
Whatever you do, DO NOT ADD new team members to an already delayed project. It will delay it further. Break down the project into simpler tasks that can be assigned to a team member and be tracked. Attach strict responsibility of task to team member. And last and most important, talk to your Management about timelines. Make it very upfront that it will take X number of days and no lesser.
3 months is actually enough time to add people, especially if there's the possibility of a deadline extension. I normally consider 1 month the break even point. You do have to schedule training and all.
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.
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.
Depends on the project. In aerospace (my industry), 3 months is not enough time. There's so much process and bureaucracy that everything moves very slowly. At 3 months, the new person may be just starting to look at source code.
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!"
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!"
Instead of not adding new members, I would suggest to add new members to close out the current team's lack of knowledge. The OP indicated that the team is outside of their comfort zone, I recommend to add an expert domain into the team as a mentor to close out the gap.
That's rather stressful for your team members though. Especially if the tasks are too much outside of everyones comfort zone. At best you will get hacky code that only properly works on first sight, just so they fullfil their task.
It's like telling you that you have 3 months to achieve world peace, otherwise all the wars are your fault.
It's like telling you that you have 3 months to achieve world peace, otherwise all the wars are your fault.
Or hire seniors devs who can make the learning curve shorter.
Words I've used with success before: "I've got some bad news. I've been running the numbers and based on our current progress, it doesn't look like we're going to hit our release schedule. Now, it's possible that we've just hit a slow patch and we will pick up steam later on, but my experience has been that this rarely happens. Everybody on the team is still really optimistic and we're working very hard to hit the release, but I wonder if we should start to make a contingency plan. For example, if we take this part out and plan it for after the release, I think it will help. If we pick up speed again, we can just roll it back into the process. I really don't want to add any more people on the team right now, because we have a really good chemistry at the moment. I don't want to risk losing time by trying to integrate someone new. What do you think?"
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.
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.
If you get the marketing team response, determine what has actually been marketed. You can probably remove some things with noone being the wiser. Create a prioritised backlog. You'll be the only one knowing that feature X probably won't reach the release, but noone will care. I did this recently and everyone were excited about the release, despite pushing for some features that were labeled low pri.
> 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.
This is really fantastic advice, and well said
A company is a company, your manager is in your team, the product owner is in your team, the salesman is in your team, the CEO is in your team. Talk to your manager, and your manager will talk to the stake holders to see what to do about it. Delays happen all the time. No biggie. Just try and understand what went wrong (to make sure the next one doesn't suffer the same) and how much time it will be costing. They'll be asking you anyways...
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 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
Exactly. Managers manage many things, including expectations. Make sure your manager and you are on the same page about schedules. Then let her do her job while you do yours.
If your manager decides to blame you, rather than defend you and your team, it's resume time.
If your manager decides to blame you, rather than defend you and your team, it's resume time.
Managing up is the most important thing a project manager can do ("shit umbrella vs shit funnel") - if they haven't been communicating the actual status of the project then they haven't been doing their job.
If they don't know the actual status of the project then they haven't been doing their job either.
If they don't know the actual status of the project then they haven't been doing their job either.
This contradicts the advice others are giving but in my experience here's what has worked for me.
* Communicate early
* Document the warning signals - have an email thread - this is critical in saving you later
* You will be asked to hustle, have explanations for why hustling won't help reach the deadline
* Have clear reasons why the delay is caused - why wasn't the skill gap known earlier?
Be ready to lose some weekends and burn additional hours - but people will appreciate your being on top of things.
People shoot the messenger - when the messenger is too late in delivering the warning when the rest of the business can't do anything to fix it. Even if management is anticipating delays - it will still look good on you that you are able to foresee problems, and your foresight will be rewarded later on.
People don't like hearing bad news - but if the bad news is delivered early and documented in such a way that it makes them responsible for not acting on warnings, they tend to work on it positively.
If you do the above and still get shot as the carrier of bad news - the work culture is toxic you are better off working elsewhere.
Be ready to lose some weekends and burn additional hours - but people will appreciate your being on top of things.
People shoot the messenger - when the messenger is too late in delivering the warning when the rest of the business can't do anything to fix it. Even if management is anticipating delays - it will still look good on you that you are able to foresee problems, and your foresight will be rewarded later on.
People don't like hearing bad news - but if the bad news is delivered early and documented in such a way that it makes them responsible for not acting on warnings, they tend to work on it positively.
If you do the above and still get shot as the carrier of bad news - the work culture is toxic you are better off working elsewhere.
This is such a hard question because it is intimately intertwined with the culture of the organization in which the activity is occurring.
Bottom line, stay true to your own sense of integrity and be honest with whomever asks for your assessment of the situation.
I agree with the other comments that suggest you have conversations about your management and that you journal your progress and concerns.
The cultural question is around what happens when it is obvious the schedule is going to slip. In some organizations the group looks for someone take the heat and they heap a world of pain on that person. Generally that is the person who doesn't have any record to back up their assertion that they told everyone else it was not going to work. In other groups there will be a great ceremony of replanning and another unrealistic deadline will be pronounced and the cycle will simply repeat. Sometimes organizations will want to figure out how they got the schedule wrong and apply fixes (your journal will be invaluable there).
Bottom line, stay true to your own sense of integrity and be honest with whomever asks for your assessment of the situation.
I agree with the other comments that suggest you have conversations about your management and that you journal your progress and concerns.
The cultural question is around what happens when it is obvious the schedule is going to slip. In some organizations the group looks for someone take the heat and they heap a world of pain on that person. Generally that is the person who doesn't have any record to back up their assertion that they told everyone else it was not going to work. In other groups there will be a great ceremony of replanning and another unrealistic deadline will be pronounced and the cycle will simply repeat. Sometimes organizations will want to figure out how they got the schedule wrong and apply fixes (your journal will be invaluable there).
The most important thing is to show progress. Agile/Scrum/XP are much-maligned these days, and with some good reason, but the one thing they do very well is to get you on a cadence of delivering working, demo-able code on a regular interval. Every situation is different, but in my experience being able to sit in front of stakeholders every couple of weeks and show them what you've just built, talk about what you're building next, and explaining anything that might impact that, gives people a lot more confidence in a team. In my experience, what scares stakeholders is when the nerds disappear for months at a time with only hand-wavey status reports to show how they're doing. Get them in a room on a regular basis, and demo what you've built. If you can't get them all in a room, record screencasts and share them, or demo over Skype/Hangouts/etc.
> we're not going to make the release
> At what point should I start sounding the alarm?
Immediately.
IMMEDIATELY
> At what point should I start sounding the alarm?
Immediately.
IMMEDIATELY
Well, ring the bell NOW so you still have time to act. Make sure you bring all the facts you have that make you think that you will miss the release. Ask your team what they think how much time it will take them, given that new evidence.
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.
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.
Yes, ring it loud. If you think there might not be enough time, there's almost certainly not enough time.
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.
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.
This was also my thought, hah :)
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?
I think ljw100's advice is pretty spot on.
It's very tempting to think that on a practical level, people 'need to know' what's going wrong. Unfortunately it is often very difficult to accurately or objectively assess what the underlying problems are and in many cases, what you perceive as a problem can actually turn out to be a symptom of some other issue.
Project slippage happens all the time - and in and of itself it may not indicate any serious issues. It could just be a case of poor estimation, or scope creep, or some other 'process' related issue which is unlikely to be something any single individual can do anything about.
In my experience, the best way to deal with these kinds of situations is to make sure you're keeping your relevant colleagues up to date. If you feel like some deadline isn't going to be hit - it's probably best to voice your concern about that risk (and only that risk) to your immediate superior. In many cases it's likely that people are well aware of how behind things are - but everyone has a different assessment as to why.
In such situations it's often the case that the most you can do is to tend your own garden. It's important to keep the chain of command - even in small organisations (and especially when dealing with multiple teams / stakeholders), and avoid trying to assign blame (or even identify 'the cause') unless specifically tasked with figuring it out.
Basically: if it's not your job to raise hell about things, then don't. Keep your superiors up to date with progress and let them figure out the implications.
Although it can be intensely boring, project management tools can help to de-politicise these kinds of situations: graphs aren't personal, and the more regularly the relevant people can get a snapshot of progress, the less likely it is that it'll fall to you to point out when things aren't going as expected.
It's very tempting to think that on a practical level, people 'need to know' what's going wrong. Unfortunately it is often very difficult to accurately or objectively assess what the underlying problems are and in many cases, what you perceive as a problem can actually turn out to be a symptom of some other issue.
Project slippage happens all the time - and in and of itself it may not indicate any serious issues. It could just be a case of poor estimation, or scope creep, or some other 'process' related issue which is unlikely to be something any single individual can do anything about.
In my experience, the best way to deal with these kinds of situations is to make sure you're keeping your relevant colleagues up to date. If you feel like some deadline isn't going to be hit - it's probably best to voice your concern about that risk (and only that risk) to your immediate superior. In many cases it's likely that people are well aware of how behind things are - but everyone has a different assessment as to why.
In such situations it's often the case that the most you can do is to tend your own garden. It's important to keep the chain of command - even in small organisations (and especially when dealing with multiple teams / stakeholders), and avoid trying to assign blame (or even identify 'the cause') unless specifically tasked with figuring it out.
Basically: if it's not your job to raise hell about things, then don't. Keep your superiors up to date with progress and let them figure out the implications.
Although it can be intensely boring, project management tools can help to de-politicise these kinds of situations: graphs aren't personal, and the more regularly the relevant people can get a snapshot of progress, the less likely it is that it'll fall to you to point out when things aren't going as expected.
if you're doing it right, its not boring at all. its only boring if the work and the people are meaningless abstractions, which makes moving them around on the board pretty pointless.
if they are your people then there are all sorts of opportunities to reorganize what gets done first, and who is working on what, and how it all fits together.
you can take a unfocussed seemingly infinite amount of work and turn it into 'if we can just get this seed part done, then the rest can hang off that. jane and timmy, since you are both working adjacent to that piece, and I trust you both to sit down and make it happen - please do that'
thats the best part of the job
if they are your people then there are all sorts of opportunities to reorganize what gets done first, and who is working on what, and how it all fits together.
you can take a unfocussed seemingly infinite amount of work and turn it into 'if we can just get this seed part done, then the rest can hang off that. jane and timmy, since you are both working adjacent to that piece, and I trust you both to sit down and make it happen - please do that'
thats the best part of the job
Fair enough - I actually don't mind the PM side of things all that much, it's just not what flips my bits.
* Put a risk database in place - what are the project risks, mitigation strategies, probability the risk will happen and the impact on the project.
Start tracking this risks DB on a weekly basis
Involve your Manager and the product owner in the risk analysis and mitigation task.
It is shared responsibility of management.
Each week update the ETC and show how it has changed as a result of the risk mitigation.
Sit down with the product owner and juggle the features to get to an optimum mix of ETC, features and risk.
He/She has to take responsibility along with you.
Up and Down and sideways...
First: It's difficult to advice on these matters in cyberspace. But as I have been in similar situations, I can give you some general advice:
First, break things up in smaller phases or sprints, setting some milestones based on sensible estimates. Get the team to commit to these estimates and the timeline.
Second, ask the customer/PO to prioritize features (as others have pointed out) in Need to have, nice to have etc.
Third, make the customer/PO prioritze what is most important in the project triangle: Time, scope, quality or price.
If you make a simple plan (eg. a burn down graph), you can follow the progress and adjust the plan if necessary.
You might consider doing a simple risk analysis as well.
Good luck.
The best advice in the comments. You breakup the project into sprints and let the product owner choose priority.
Tell everyone there's a problem. Immediately. Make sure they understand that "working harder" isn't going to fix it.
Reset everything. Massively reduce the scope of the project and make sure everyone knows that's what you're doing and to expect to see something being delivered soon, but that it will be a small and simple component intended to get something out there.
Deliver the smallest useful thing you possibly can as quickly as you can, and show everyone,
Once you've delivered a few parts get a bit of momentum, get everyone together and hash out a slightly bigger next step.
Reset everything. Massively reduce the scope of the project and make sure everyone knows that's what you're doing and to expect to see something being delivered soon, but that it will be a small and simple component intended to get something out there.
Deliver the smallest useful thing you possibly can as quickly as you can, and show everyone,
Once you've delivered a few parts get a bit of momentum, get everyone together and hash out a slightly bigger next step.
For next week, get a list of things you can work on. Spend 30 minutes with the team monday morning deciding what is the most important to work on. Agree with the team these items will be done by Monday (if something can’t be done in a week break it down.) Execute.
Things cannot be* late. You are only on a week timeline. There is no other timeline. Forecasts outside the week are unpredictable and should be ignored.
This will give you a velocity (items done per week) and start quickly building team confidence. Things get done.
Don’t let anyone change or modify the week goals. If some one wants something they pitch for it Monday.
Things cannot be* late. You are only on a week timeline. There is no other timeline. Forecasts outside the week are unpredictable and should be ignored.
This will give you a velocity (items done per week) and start quickly building team confidence. Things get done.
Don’t let anyone change or modify the week goals. If some one wants something they pitch for it Monday.
I do not believe in blindness optimism which seems to be the way things work in Silicon Valley. But That doesn't mean you are not going to achieve it, but you have to strategically plan your features / function.
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. )
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. )
I am no lead, and never will be with my attitude towards these things. But sound the alarm immediately, realize that the business doesn't care because they have deadlines, watch it burn, then leave such a toxic environment. The order of the last two steps is interchangeable.
Sadly, everyone thinks removing yourself from bad environments, especially as a lead, is selfish as though the company isn't. Also, many assume leaving is impossible/difficult, but in our industry at this time, that's rarely true.
Sadly, everyone thinks removing yourself from bad environments, especially as a lead, is selfish as though the company isn't. Also, many assume leaving is impossible/difficult, but in our industry at this time, that's rarely true.
Others have hit on this (so read the discussion: they are right - even when they seem to contradict each other), but I'll say it again because I think it is critical.
You need to find the real needs of the real users and customers. You need these in priority order. Perfect answers are not required, just good enough answers. Now get your team focusing on getting things done in priority order. When your 3 months are up you can then say "we didn't get everything, but we think it is good enough".
If you cannot get someone else to tell you priority, then start asking questions until you can come up with an answer. Sometimes you have to make a decision and hope you are close enough. Sometimes you will find other people (marketing, sales, your boss) who will help. An incomplete team that recognizes that things might not be perfect but they can influence one where the imperfections are is better then going alone, but go alone if you must.
Note that customers and users are not always the same! If it is a customer need you can fake it as it won't be used, so make this look good, but make it obviously useless to users. If it is a user need it needs to work right, but it doesn't need to look as good since the customer has already bought it. Of course for release two you have feedback on what needs to be fixed.
You need to find the real needs of the real users and customers. You need these in priority order. Perfect answers are not required, just good enough answers. Now get your team focusing on getting things done in priority order. When your 3 months are up you can then say "we didn't get everything, but we think it is good enough".
If you cannot get someone else to tell you priority, then start asking questions until you can come up with an answer. Sometimes you have to make a decision and hope you are close enough. Sometimes you will find other people (marketing, sales, your boss) who will help. An incomplete team that recognizes that things might not be perfect but they can influence one where the imperfections are is better then going alone, but go alone if you must.
Note that customers and users are not always the same! If it is a customer need you can fake it as it won't be used, so make this look good, but make it obviously useless to users. If it is a user need it needs to work right, but it doesn't need to look as good since the customer has already bought it. Of course for release two you have feedback on what needs to be fixed.
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.
As much as everyone hates deadlines they are important and try your best to meet them if they're realistic.
1) Tell the manager that "sold" it to the customers
2) Create a clear list of planned features with him (if you haven't already)
3) Priorize the features. I.e. find out the ones that where really promised to the customers (the manager knows). Usually it's just 1-2 key features that sell the product.
4) Focus just on those and code properly. Especially if you are doing a rewrite / modernization. What's the point of having a new product, that is hacked spaghetti code from the beginning?
2) Create a clear list of planned features with him (if you haven't already)
3) Priorize the features. I.e. find out the ones that where really promised to the customers (the manager knows). Usually it's just 1-2 key features that sell the product.
4) Focus just on those and code properly. Especially if you are doing a rewrite / modernization. What's the point of having a new product, that is hacked spaghetti code from the beginning?
One thing to do is to push the knowledge and acceptance of the situation up the management chain, especially to the non-believing Product Owner, lest the Thermocline of Truth[1] be revealed in two months and three weeks.
1. http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...
1. http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...
If you are lead, then you should lead. If you lose faith, they lose faith.
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.
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.
[deleted]
Be prepared for the questions that you will be asked when the alarm is raised.
Q1. Why late? Work is 'outside of comfort zone', thus accurate estimates are impossible.
Q2. When will it be ready? Scope, timescale and quality are interdependent. Ask 'the business' which two are most important to them. The remaining item will need to be revised. My recommendation would be to curtail scope and deliver the rest in phase 2. If they say timescale can be extended the revise estimates based on current velocity, i.e. if you are 30% behind where you expected, add 30% to all outstanding work items. If quality is cut, make sure they are aware of the additional support and maintenance costs that will be incurred.
Either way, do as rinka_singh says and get the PO/PM to establish a risk log accessible to all. I would add that each risk should be assigned to someone who is responsible for tracking it. Review the log each week.
Raise the alarm now because there will be dependencies, and you are probably not aware of all of them.
I would not be worried about how the alarm is percieved, if your intentions are to steer 'the business' away from a cliff it will be recognized.
Q1. Why late? Work is 'outside of comfort zone', thus accurate estimates are impossible.
Q2. When will it be ready? Scope, timescale and quality are interdependent. Ask 'the business' which two are most important to them. The remaining item will need to be revised. My recommendation would be to curtail scope and deliver the rest in phase 2. If they say timescale can be extended the revise estimates based on current velocity, i.e. if you are 30% behind where you expected, add 30% to all outstanding work items. If quality is cut, make sure they are aware of the additional support and maintenance costs that will be incurred.
Either way, do as rinka_singh says and get the PO/PM to establish a risk log accessible to all. I would add that each risk should be assigned to someone who is responsible for tracking it. Review the log each week.
Raise the alarm now because there will be dependencies, and you are probably not aware of all of them.
I would not be worried about how the alarm is percieved, if your intentions are to steer 'the business' away from a cliff it will be recognized.
Setup a meeting with the dev team (only). Go over all the main features required for this release, ideally, they should already be in a form of "user stories". Depends if you're in an Agile env or not... in 2018, I hope you guys are.
Then during this meeting, run a deeper and more detailed estimate for each user story. How long would it take, what work has to be done and is it depending on any other team or future work? etc.
When you get a better understanding and know how off the original estimation/deadline is (compared to this new one), setup another meeting with your PO and your manager to share this information. Obviously you will need material for this meeting. As a lead, that's your job to create that material (slides, etc..)
That's it. As a lead, your job stops here. Any other decisions will have to be made by your PO or manager. Your role is to share that knowledge because these 2 don't have a clue about the actual work that has to be done down to the lines of code.
Good luck (you're not doing anything wrong at the moment, just bubble up the information and let them do their job).
Then during this meeting, run a deeper and more detailed estimate for each user story. How long would it take, what work has to be done and is it depending on any other team or future work? etc.
When you get a better understanding and know how off the original estimation/deadline is (compared to this new one), setup another meeting with your PO and your manager to share this information. Obviously you will need material for this meeting. As a lead, that's your job to create that material (slides, etc..)
That's it. As a lead, your job stops here. Any other decisions will have to be made by your PO or manager. Your role is to share that knowledge because these 2 don't have a clue about the actual work that has to be done down to the lines of code.
Good luck (you're not doing anything wrong at the moment, just bubble up the information and let them do their job).
I wish I had some good takeaways from my first and only experience as a dev lead.
The Good:
- I came in with a blank slate. They had no source control, no CI/CD, and two "database developers" using an ancient platform with only passing knowledge of any modern language - C#. I was able to implement best practices and teach them how to code in C#.
- The developers were eager to learn and were smart.
The Bad
- The company moved the entire project to AWS but to get anything provisioned I had to go through both my manager, the net ops people, a bunch of hired consultants, and an outsourced cloud management company. I never did get access to anything outside of some EC2 instances.
- None of the people involved knew anything about AWS besides how to translate an on prem network to AWS and then wondered why it costed more.
- I had a budget to hire, but only contractors. All of the best developers wanted a full time job with benefits. I never got the cream of the crop.
- When the company was acquired, they decided that they didn't "want to be a software company" and wanted to outsource everything. They did however want me to lead two more projects to completion. I stayed long enough to finish phase 1, but it wasn't the best implemented thing in the world. It was architecturally sound, but didn't leverage anything AWS provided.
- Everyone above me was jockeying for position at the newly merged company and didn't make development a priority.
My solution:
- I left for a job that pays slightly more where from day one I was given AWS admin access (yes I had the qualifications and experience). I'm now "just" a Senior Software Engineer but I am nowhere near as hamstrung when it comes to getting things done.
The Good:
- I came in with a blank slate. They had no source control, no CI/CD, and two "database developers" using an ancient platform with only passing knowledge of any modern language - C#. I was able to implement best practices and teach them how to code in C#.
- The developers were eager to learn and were smart.
The Bad
- The company moved the entire project to AWS but to get anything provisioned I had to go through both my manager, the net ops people, a bunch of hired consultants, and an outsourced cloud management company. I never did get access to anything outside of some EC2 instances.
- None of the people involved knew anything about AWS besides how to translate an on prem network to AWS and then wondered why it costed more.
- I had a budget to hire, but only contractors. All of the best developers wanted a full time job with benefits. I never got the cream of the crop.
- When the company was acquired, they decided that they didn't "want to be a software company" and wanted to outsource everything. They did however want me to lead two more projects to completion. I stayed long enough to finish phase 1, but it wasn't the best implemented thing in the world. It was architecturally sound, but didn't leverage anything AWS provided.
- Everyone above me was jockeying for position at the newly merged company and didn't make development a priority.
My solution:
- I left for a job that pays slightly more where from day one I was given AWS admin access (yes I had the qualifications and experience). I'm now "just" a Senior Software Engineer but I am nowhere near as hamstrung when it comes to getting things done.
There are hints in your question that you might be undergoing some major rewrite/refactoring across the board. If so, that has always failed insofar as I've experienced or seen experienced it.
FWIW a better approach would have been to break the entire thing down into smaller, more immediately achievable milestones. Ideally do so alongside enough exciting new stuff to keep your developers' morale high - be weary that some might already have low morale if they're noticing that the project they're working on is going nowhere.
At any rate, the time to bring up the problem is likely now. Have a candid discussion with your team. Explain what's going on; collect data points you might be less aware of and new ideas as you do. Sketch out a brief but equally candid status of your current situation (in writing) to let your manager and the product owner in the loop, along with an outline of next steps get things back on track.
FWIW a better approach would have been to break the entire thing down into smaller, more immediately achievable milestones. Ideally do so alongside enough exciting new stuff to keep your developers' morale high - be weary that some might already have low morale if they're noticing that the project they're working on is going nowhere.
At any rate, the time to bring up the problem is likely now. Have a candid discussion with your team. Explain what's going on; collect data points you might be less aware of and new ideas as you do. Sketch out a brief but equally candid status of your current situation (in writing) to let your manager and the product owner in the loop, along with an outline of next steps get things back on track.
[deleted]
Read "Getting Real"
http://gettingreal.37signals.com/
Yes sound the alarm. Your heading towards a a million dollar failure.
Instead define a bare minimum feature set for 1 user role, build a mvp with that minimal feature set and get it into the hands of users
then start adding more
http://gettingreal.37signals.com/
Yes sound the alarm. Your heading towards a a million dollar failure.
Instead define a bare minimum feature set for 1 user role, build a mvp with that minimal feature set and get it into the hands of users
then start adding more
It all depends on what kind of company are you in, what kind of people are your superiors, etc. How much politics and backstage dealing is involved?
In an ideal situation I would say call be honest and tell the stakeholders your view.
On the other hand, from my corporate experience, it's not always the best course of action. See - as lwj1001 already said - some companies play sort of meta-game, where certain things are known but never said out loud. If you are in a position to change the environment - great! (But this is not likely the best opportunity to do so). Otherwise... I would still say your opinion to those who need to be informed, or even better - write them an email. The reason is - you might have to cover your ass in the near future. The worst that can happen is that everyone assume everyone know yet there is someone who doesn't.
In an ideal situation I would say call be honest and tell the stakeholders your view.
On the other hand, from my corporate experience, it's not always the best course of action. See - as lwj1001 already said - some companies play sort of meta-game, where certain things are known but never said out loud. If you are in a position to change the environment - great! (But this is not likely the best opportunity to do so). Otherwise... I would still say your opinion to those who need to be informed, or even better - write them an email. The reason is - you might have to cover your ass in the near future. The worst that can happen is that everyone assume everyone know yet there is someone who doesn't.
Not sure if there’s a silver bullet, but there are certainly lead bullets. I found this really helpful:
https://hbr.org/2015/01/what-everyone-should-know-about-mana...
https://hbr.org/2015/01/what-everyone-should-know-about-mana...
Sounds kind of familiar. We started a mvp/prototype that was handed to one guy without that much of a planning. That guy is really good coder but not a product owner/manager, documentor or planner. You see where this is going? This was about empowering team members with responsibility.
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.
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.
> 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.
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.
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.
So, have a plan?
Break things up into milestones (preferably deliverables). Put team-agreed-upon date estimates. Provide regular updates to higher-ups on the status (maybe every week or two). Try green, yellow, red as classifiers on each milestone. Identify potential issues and/or blockers. Communicate those and what your team is doing to mitigate them. Document what does get achieved, and communicate that too. Come up with contingencies and compromises, such as "if we remove freature x, we could shave off 5 days, or if we have extra help testing features a, b, and c, we might be able to push up milestone y.
At least, at my org, these are all considered appropriate.
At least, at my org, these are all considered appropriate.
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.
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.
The Mythical Man-Month, Fred Brooks, 19fucking75.
What has been done is what will be done.
What has been done is what will be done.
Yep. Folks know (or you have bigger problems). Leadership doesn't want FUD nor misleading positivity, they want constructive & predictable leadership... even if late.
The conversation they want is, "As the leader, the risk X has now hit, and to avoid underlying Y happening again and achieving predictability goals Z, I'm leaning to A or B on this timeline with those key delivery+derisking milestones. To get there, can you help with resource/negotiation/decision C, and what are your thoughts on alternatives?"
The conversation they want is, "As the leader, the risk X has now hit, and to avoid underlying Y happening again and achieving predictability goals Z, I'm leaning to A or B on this timeline with those key delivery+derisking milestones. To get there, can you help with resource/negotiation/decision C, and what are your thoughts on alternatives?"
Split the project into sub-tasks and order them on a kanban board (Physical/Digital). Figure out which sub-tasks are most important and work through them. Assign them to people if need be. Take time out to do a standups around this board at the start/end of the day to figure out where you're at. Higher ups will be able to see this too and probably will appreciate the clarity.
Even if you don't hit your full deadlines you'll have a more complete 'product' this way
Even if you don't hit your full deadlines you'll have a more complete 'product' this way
By the way: it's your job to buffer the pressure from upper management towards the team so they can see you have a backbone and to maintain morale. They are _your_ team.
Maybe your org is different, but the way your question is worded you are a lead developer, not a project manager. I'm a believer in flat orgs to some extent, but as a product owner/pm myself, this communication should be coming from the dev project manager, along with revised timeline and/or mitigation plan. The only alarm should be to your project manager, and in the form of objective analysis of the number of items completed against the plan.
To add to this, maybe your PM can help by getting scope reduced, or additional QA resources.
If they suggest more dev resources, be wary; that almost never speeds up project completion
If they suggest more dev resources, be wary; that almost never speeds up project completion
What's funny is, you can armchair quarterback this all you want and it likely won't matter one bit. Toxic organizations gonna be toxic, and healthy organizations (probably) gonna be healthy. From outside, it's nearly impossible to tell which is which and by the time the OP is sure, it'll likely be too late to make any difference.
Maybe they make you the hero, maybe they make you the fall-guy. Very little you can do to influence that. Focus on the work.
Maybe they make you the hero, maybe they make you the fall-guy. Very little you can do to influence that. Focus on the work.
Lots of good advice on prioritization & managing expectations already, but here's one part that jumped out that hasn't seen much attention:
> The team is great, it's just that the work is way outside their comfort zone.
This reads to me like the team doing the implementation literally couldn't have estimated this work at the start. Who in the company committed your team to deliver a fixed set of features in a fixed timeframe with new technology?
> The team is great, it's just that the work is way outside their comfort zone.
This reads to me like the team doing the implementation literally couldn't have estimated this work at the start. Who in the company committed your team to deliver a fixed set of features in a fixed timeframe with new technology?
In addition to all the good advice already given: this question has (at least) three different dimensions:
- what would be best for your company?
- what would be best for your team?
- what would be best for you?
Try to come up with answers for these questions separately. In particular, find out what is important for you personally (making a career, gain trust with your team, being open and honest, etc.). Identify the communication strategy which optimizes the outcome for you, your team, and your company.
- what would be best for your company?
- what would be best for your team?
- what would be best for you?
Try to come up with answers for these questions separately. In particular, find out what is important for you personally (making a career, gain trust with your team, being open and honest, etc.). Identify the communication strategy which optimizes the outcome for you, your team, and your company.
Question : why does it take longer ? Team ? Development process ? Strategy (by modernization, I think "rewrite", which is always hard) ?
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.
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.
[deleted]
[deleted]
The project will either fail or be severely scaled back to launch a minimal version of what was promised. I would hedge bets and try to figure out what the crucial features of that minimal version are. Focus on those, and build extensive testing that will help you when its crunch time. I did just that and was able to launch a project.
Well there is only one way a modernization project could have gotten into that position; You were doing a rewrite.
A modernization project is only a modernization project if it is incremental by design and you have frequent releases (minimally monthly).
Throw out the flag onto the field and get the train stopped before you end up causing the entire group to be fired.
A modernization project is only a modernization project if it is incremental by design and you have frequent releases (minimally monthly).
Throw out the flag onto the field and get the train stopped before you end up causing the entire group to be fired.
This is basically normal. Virtually every software project, except incredibly simple ones, has delays. People, even experienced ones, are very, very bad at estimating.
Just meet with your boss and manager and explain the issues, sooner than later. If the product owner is still in denial, well, you told them... They have to face reality.
Just meet with your boss and manager and explain the issues, sooner than later. If the product owner is still in denial, well, you told them... They have to face reality.
Keep morale of the team high.
Nothing worse than feeling to be on a failing project with lots of pressure to make unrealistic deadlines.
Nothing worse than feeling to be on a failing project with lots of pressure to make unrealistic deadlines.
"The business has been selling the new version.."
But it's not built yet? IANAL, but make sure they're doing this correctly. There's a fine line between selling and outright lying aka fraud especially if the "new version" doesn't exist.
Serious question, are there any adults around that can help your team?
But it's not built yet? IANAL, but make sure they're doing this correctly. There's a fine line between selling and outright lying aka fraud especially if the "new version" doesn't exist.
Serious question, are there any adults around that can help your team?
If you're not on schedule, tell your PO. We estimate tasks to be done as if they were done by even the least experienced teamate.
My PO would rather cut a few features and hit the deadline than deliver nothing because we wern't conservative in our estimates.
It's a lot easier to plan for the worst early & hope for the best
My PO would rather cut a few features and hit the deadline than deliver nothing because we wern't conservative in our estimates.
It's a lot easier to plan for the worst early & hope for the best
> At what point should I start sounding the alarm?
Last week ideally. But now is fine.
> give it a couple of weeks and see if the team picks up pace
They won't if nothing changes.
What do you mean by "outside of their comfort zone"?
Is it a technology that people don't master yet? Do you have experts on that technology already on the team?
Last week ideally. But now is fine.
> give it a couple of weeks and see if the team picks up pace
They won't if nothing changes.
What do you mean by "outside of their comfort zone"?
Is it a technology that people don't master yet? Do you have experts on that technology already on the team?
In addition to the other advice here, regarding how to handle this politically and from a communication perspective, I think you need to quantify to what extent you're not going to make the release.
- You need to write down all the things that need to be done, the granularity of task should be between half a day and two days. (Anything larger than 2 days will be a task like "refactor this system" that hasn't been though through enough, and thus likely to be completely wrong.) Do this in a meeting with all your team members, they will be telling you what they foresee they need to do.
- If you can't estimate things, because e.g. the system design hasn't even been started yet for those things, you need to design them, at least on a very high level. So that you know, at least to some extent, how long you think they're going to take.
- Write down estimates for the aforementioned tasks, in person-days, by getting your team members to estimate these tasks.
- Ideally use some kind of task planning system such as MS Project, LiquidPlanner, manuscript.com or some JIRA plug-ins that can handle this sort of stuff. But even a Google Spreadsheet shared between your colleagues will be better than nothing.
- Now you'll know an end date. How far out is it? 4 months rather than 3? 12 months rather than 3? That makes a difference. If you're going to be late, you management may wish to give you an extension. If the project's going to take another year, management may wish to cancel or change the requirements significantly. You have to provide them with the information to enable them to make that choice.
- If it's decided to continue, then update that spreadsheet all the time. Get your team members to update it, and if they don't do that, then talk to them every few days and get them to tell you what they still need to do. Focus only on the future: remove tasks when they're done, add new tasks as they arise, change estimates on tasks as they're partially completed. So even if you decide to continue, maybe in one month it becomes apparent you haven't made as much progress as you'd like, or there have been unforeseen difficulties resulting in more tasks. Know if it's going off track again as soon as possible.
Estimate will be wrong. Things always take longer. This is a minimum bound. But if your spreadsheet says you need another 12 months on a project that only has 3 months to go, you can be sure that it won't be done in e.g. 2 months, that's useful information to have.
- You need to write down all the things that need to be done, the granularity of task should be between half a day and two days. (Anything larger than 2 days will be a task like "refactor this system" that hasn't been though through enough, and thus likely to be completely wrong.) Do this in a meeting with all your team members, they will be telling you what they foresee they need to do.
- If you can't estimate things, because e.g. the system design hasn't even been started yet for those things, you need to design them, at least on a very high level. So that you know, at least to some extent, how long you think they're going to take.
- Write down estimates for the aforementioned tasks, in person-days, by getting your team members to estimate these tasks.
- Ideally use some kind of task planning system such as MS Project, LiquidPlanner, manuscript.com or some JIRA plug-ins that can handle this sort of stuff. But even a Google Spreadsheet shared between your colleagues will be better than nothing.
- Now you'll know an end date. How far out is it? 4 months rather than 3? 12 months rather than 3? That makes a difference. If you're going to be late, you management may wish to give you an extension. If the project's going to take another year, management may wish to cancel or change the requirements significantly. You have to provide them with the information to enable them to make that choice.
- If it's decided to continue, then update that spreadsheet all the time. Get your team members to update it, and if they don't do that, then talk to them every few days and get them to tell you what they still need to do. Focus only on the future: remove tasks when they're done, add new tasks as they arise, change estimates on tasks as they're partially completed. So even if you decide to continue, maybe in one month it becomes apparent you haven't made as much progress as you'd like, or there have been unforeseen difficulties resulting in more tasks. Know if it's going off track again as soon as possible.
Estimate will be wrong. Things always take longer. This is a minimum bound. But if your spreadsheet says you need another 12 months on a project that only has 3 months to go, you can be sure that it won't be done in e.g. 2 months, that's useful information to have.
[deleted]
You should have the talk with the product owner already. It's always better to be open about these things early. Discuss the possibiltiy of completing only the core features first.
[deleted]
A good customer success team can patch sales up that might have promised features that won't be to spec. But that bandaid only lasts for a short time.
I would send upbeat emails at every milestone listing the accomplishments of your team. Throw in some tech speak to impress non tech people. By the time the deadline comes and passes anyone on the email thread will know how much your team has done and will trust you to finish the job.
I would also assign tasks or busy work as the deadline approaches to anyone who is waiting on you to launch. Have them beta testing, etc. People are a lot more patient when they have things to do and a lot less patient when they are just waiting for you to finish already.
I would also assign tasks or busy work as the deadline approaches to anyone who is waiting on you to launch. Have them beta testing, etc. People are a lot more patient when they have things to do and a lot less patient when they are just waiting for you to finish already.
Best advice I have ever been given (in project management generally) is that it does sometimes go wrong, and when it goes wrong:
STOP. RESET. CONTINUE.
STOP. RESET. CONTINUE.
Lots of great input. I'm still going through them all.
That said, I would update my resume and reach out to my network.
If this ends badly you want to be prepared.
That said, I would update my resume and reach out to my network.
If this ends badly you want to be prepared.
Cut features until it'd make the deadline, even weeks before the deadline. Have something to show. That's my only advice.
I'm firmly in the 'raise the issue with your boss immediately, and let him own the fire alarm decision' camp.
As others have said, key at this point is going to be to prioritize in relation to business needs. As hard as that all will be, the process will only get more difficult the longer you wait. I'd also suggest one thing you prioritize personally for yourself whatever happens is eight hours of sleep every night. :-)
As other have also said, you're also going to have to tailor the way you present the message about the facts (i.e. the "alarm") to your current organization's culture and your specific situation in it. You'll need to keep in mind your own talents/resources and current limitations in developing a message or plan (see also "Dunning–Kruger effect" for risks on that). Talents/resources and limitations include your own ability to present a message and what help you can rely on from the rest of the organization to develop a message and present it based on what your coworkers, manager, and management chain value.
If you eventually want to reflect on the larger issues that may have gotten you to this unfortunate situation and what your company can do better in the mid-term and long-term, here is a reading list I put together that includes multiple books on software engineering management as well as broader surrounding issues -- including a great book by Matthew Walker on the importance of adequate good sleep for everyone in an organization: https://github.com/pdfernhout/High-Performance-Organizations...
One item from there:
"Why Deadlines Need to Drop Dead" by Eric Elliott https://medium.com/javascript-scene/why-deadlines-need-to-dr...
"Deadlines are incredibly destructive to team productivity and morale. The #1 challenge software developers face is unrealistic expectations. Can we motivate & push without arbitrary deadlines? You can lead teams without deadlines. You can still deliver code quickly. You can still ship in time for Christmas. But you’ll be dealing with a different management framework. One that puts the deadline pressure on product managers rather than developers. ... The point here is that instead of trying to build out the CEO’s ideal vision of the product you’re bringing to market, you build out a beautiful stepping stone on the way towards that vision. In place of arbitrary deadlines, you deliver consistent, steady progress."
Eric Elliott advocates for the Marketing department creating each hype cycle for what is already finished and tested.
As other have also said, you're also going to have to tailor the way you present the message about the facts (i.e. the "alarm") to your current organization's culture and your specific situation in it. You'll need to keep in mind your own talents/resources and current limitations in developing a message or plan (see also "Dunning–Kruger effect" for risks on that). Talents/resources and limitations include your own ability to present a message and what help you can rely on from the rest of the organization to develop a message and present it based on what your coworkers, manager, and management chain value.
If you eventually want to reflect on the larger issues that may have gotten you to this unfortunate situation and what your company can do better in the mid-term and long-term, here is a reading list I put together that includes multiple books on software engineering management as well as broader surrounding issues -- including a great book by Matthew Walker on the importance of adequate good sleep for everyone in an organization: https://github.com/pdfernhout/High-Performance-Organizations...
One item from there:
"Why Deadlines Need to Drop Dead" by Eric Elliott https://medium.com/javascript-scene/why-deadlines-need-to-dr...
"Deadlines are incredibly destructive to team productivity and morale. The #1 challenge software developers face is unrealistic expectations. Can we motivate & push without arbitrary deadlines? You can lead teams without deadlines. You can still deliver code quickly. You can still ship in time for Christmas. But you’ll be dealing with a different management framework. One that puts the deadline pressure on product managers rather than developers. ... The point here is that instead of trying to build out the CEO’s ideal vision of the product you’re bringing to market, you build out a beautiful stepping stone on the way towards that vision. In place of arbitrary deadlines, you deliver consistent, steady progress."
Eric Elliott advocates for the Marketing department creating each hype cycle for what is already finished and tested.
Who said it was going to be done in 3 months? Where did that unrealistic number come from?
lawyer up, hit the gym
On a serious side though, perhaps release a beta version in the following days with the current state of the service/product? Maybe even give the customers a preview? That would be a cold shower and wakeup call for all stakeholders.
On a serious side though, perhaps release a beta version in the following days with the current state of the service/product? Maybe even give the customers a preview? That would be a cold shower and wakeup call for all stakeholders.
Note the risks ( non delivery ), inform stakeholders, and plan a roadmap of deliverables.
get some quantitative measure of progress (eg. make some kind of simple burndown chart)
Ruby on rails. /trolling
Cut/Delay a few features so the thing can be launched?
just move to sales / marketing. then you'll be the one making unrealistic promises that noone blames you for when they don't get realised
whatever u do, beware: HR dept is there to protect the company from its employees. NOT the other way around - regardless how much anyone fanfares it..
If it is written in JS,
port it to Elixir.
Otherwise, rewrite it in JS.
Otherwise, rewrite it in JS.
Something > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir >
OutOfTimeException
OutOfTimeException
I think this is funny.
Well done.
Well done.
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.