Ask HN: How does your company handle late running projects?
Currently in a situation where our company is asking us to work weekends and extra hours because of a poorly managed project. There were too many meetings and processes during the early months of the project and now we are way behind, no longer have any of those time wasting meetings as we are now scrambling to deliver on time. It’s created a stressful environment where I am now at a point of looking for a new job.
I really believe that companies should use better strategies then putting more pressure on developers in these situations.
178 comments
Reduce scope, or move the deadline. Taking shortcuts or working overtime in significant amounts just leads to more trouble down the road.
Once the project is delivered, make sure you all sit down and do a retrospective on what went wrong, decide what you’ll change next time, and actually make those changes.
If none of this seems feasible in your organisation any time soon, leave. Don’t waste your time with people who aren’t taking your work seriously.
Once the project is delivered, make sure you all sit down and do a retrospective on what went wrong, decide what you’ll change next time, and actually make those changes.
If none of this seems feasible in your organisation any time soon, leave. Don’t waste your time with people who aren’t taking your work seriously.
> just leads to more trouble down the road.
I used to lean that way, but these days I disagree. Sometimes it's worth it to bolt as fast as you can and don't look back to meet a deadline. It's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.
I'm speaking as the guy that ended up writing most of those missing tests. You don't have a lead for long in some of these spaces and sometimes "strike hard and fast" beats "death in the tarpit of tech debt" in the medium run.
BUT.
YOU NEED TO PAY THAT TECH DEBT OFF AND MOST PEOPLE DON'T THEN THE BUSINESS FAILS ANYWAY.
Sorry for yelling, but that last part is easy to forget.
I used to lean that way, but these days I disagree. Sometimes it's worth it to bolt as fast as you can and don't look back to meet a deadline. It's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.
I'm speaking as the guy that ended up writing most of those missing tests. You don't have a lead for long in some of these spaces and sometimes "strike hard and fast" beats "death in the tarpit of tech debt" in the medium run.
BUT.
YOU NEED TO PAY THAT TECH DEBT OFF AND MOST PEOPLE DON'T THEN THE BUSINESS FAILS ANYWAY.
Sorry for yelling, but that last part is easy to forget.
It's also incredibly important for management to be able to communicate when a team is actually in one of those "200M vs 10M dollar" moments, and when its just like.. "well I sorta told a client we'd try and get this in by this arbitrary date I picked."
I've worked for too many managers where either everything, or too many things were urgent too frequently .. without any urgency gradient to differentiate.
I've worked for too many managers where either everything, or too many things were urgent too frequently .. without any urgency gradient to differentiate.
No place I have ever worked had a "200M vs 10M dollar" moment. The mismanagers might whistle up a tune that sounded like it, but the bonuses vs no-bonuses only applied to the executives, never to anyone who actually wrote code.
The most offensive (to me) was a deadline that government regulations said was 3 years away (EFast2! Due 2009!). The mismanagers involved would not let us start working on meeting those requirements until less than 1 year remained. The product involved went from having 60% market share to under 25%. If they had not been purchased by a large conglomerate, they would have gone out of business from this. All the devs quit. The execs who created the crisis were fired. Some devs were rehired, about half would never go back no matter how much they were paid.
The most offensive (to me) was a deadline that government regulations said was 3 years away (EFast2! Due 2009!). The mismanagers involved would not let us start working on meeting those requirements until less than 1 year remained. The product involved went from having 60% market share to under 25%. If they had not been purchased by a large conglomerate, they would have gone out of business from this. All the devs quit. The execs who created the crisis were fired. Some devs were rehired, about half would never go back no matter how much they were paid.
> I've worked for too many managers where either everything, or too many things were urgent too frequently .. without any urgency gradient to differentiate.
Where I work, we affectionately refer to this as “the dumpster fire” of priorities. I’m lucky that we also work together to both recognize and rectify the dumpster fire blazing out of control.
Where I work, we affectionately refer to this as “the dumpster fire” of priorities. I’m lucky that we also work together to both recognize and rectify the dumpster fire blazing out of control.
> it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.
I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.
Purposefully neglecting the safety of user data for "speed" like this should have your company taken away from you. Why can't adults stop behaving like toddlers?
I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.
Purposefully neglecting the safety of user data for "speed" like this should have your company taken away from you. Why can't adults stop behaving like toddlers?
> > it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.
> I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.
There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing.
I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.
> I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.
There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing.
I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.
Ostensibly based on what I said, yes. But in reality, he was right that untested meant partially insecure. There are real costs to tech debt. But it's hard to argue against a giant raise.
[deleted]
two of our competitors have poor practice around endpoints that have opened their entire user database. What should we do?
CYA by making sure you’re not making the same mistakes. Don’t try to be clever by exposing them.
Tell your clients that you apply best (/better) practice.
Tell your clients that you apply best (/better) practice.
These are called kill points in sales.
For this kind of kill point however, you better make sure not just your own endpoints have cleanly passed scrutiny, but your entire modeling and process around them doesn’t produce insecure endpoints. Otherwise it is best not to let your sales team use such a kill point.
For this kind of kill point however, you better make sure not just your own endpoints have cleanly passed scrutiny, but your entire modeling and process around them doesn’t produce insecure endpoints. Otherwise it is best not to let your sales team use such a kill point.
Tangential, but I always wondered why people don't have a separate class/struct/whatever that's actually used to send out. Might be overkill, but having a separate model to represent incoming request, out going requests, and the actual domain model makes me feel a bit more secure as to what's being sent out. It requires more work to update (adding fields to the outgoing models), but gives a bit of piece of mind.
We do this where I work. It's a lot of extra data types, but they're all extremely simple and better safe than sorry. As a rule, we don't send or receive actual domain objects in our APIs. It doesn't matter if they're currently "safe" - they might not be in the future.
[deleted]
Talk to your lawyers.
> Why can't adults stop behaving like toddlers?
It certainly seems like a very successful strategy.
It certainly seems like a very successful strategy.
I think the important thing here is that there's a clear and obvious reason that the deadline exists, with demonstrable costs for missing that deadline. I think a lot of people can get overly defensive about this because it's incredibly common for deadlines to exist primarily as an accountability / motivation mechanism - nothing really happens if the deadline isn't met, but to keep the team aligned we'll invent a deadline.
Which isn't really a problem in and of itself - but when that's used to justify crunch time, it can lead to taking shortcuts and making sacrifices with real costs that were wholly unnecessary, and it's a huge morale hit to be sacrificing your free time to work for essentially no reason.
Which isn't really a problem in and of itself - but when that's used to justify crunch time, it can lead to taking shortcuts and making sacrifices with real costs that were wholly unnecessary, and it's a huge morale hit to be sacrificing your free time to work for essentially no reason.
100%. The difference between features and hygiene is that features have an end state. You can spend an infinite about of time improving code hygiene... and still have more to improve.
Real devs look for a good balance, and real management understands how to strike that balance in terms of priorities.
Real devs look for a good balance, and real management understands how to strike that balance in terms of priorities.
Terrible way to look at what may be a system, or at least a data structure, you can’t change in a few months. Things become critical and companies pivot.
Lots of teams build code bases with the idea they’ll rewrite and polish it later. This almost always, when it does happen which isn’t a lot over the short term, ends with having to work around the data model that our production data is dependent on and our customers.
Yes you can go in and translate old data models to new ones. You can add a transformer if that doesn’t work to set/get data. Yes you can redesign or you set of view components to account for a nicer frontend layout or data model. These are work around a to tech debt not a proper implementation.
But we could also be honest and admit that >75% of code we “write now and redo later” becomes business critical production code and never gets redone.
Lots of teams build code bases with the idea they’ll rewrite and polish it later. This almost always, when it does happen which isn’t a lot over the short term, ends with having to work around the data model that our production data is dependent on and our customers.
Yes you can go in and translate old data models to new ones. You can add a transformer if that doesn’t work to set/get data. Yes you can redesign or you set of view components to account for a nicer frontend layout or data model. These are work around a to tech debt not a proper implementation.
But we could also be honest and admit that >75% of code we “write now and redo later” becomes business critical production code and never gets redone.
My motto for these situation is, if it doesn't fit, cut it. Pushing deadlines back looks sloppy, and I take enough pride in my work that I want to take the time to make a quality product. I can always go back and add features later if they're important. I don't know much about American football, but I know most of the game is making plays to move a few yards. You basically keep pushing until the opportunity comes to make a pass that gets you to the end zone, and you need to keep make good plays so you don't turn over the ball. That's what software development feels like to me, pushing quality improvements to keep making yards until eventually you're in a position where you're one project away from shipping something big.
I like this analogy. A lot of time leaders get in a tough 4th-down situation, where they must make a big play, and so they tell the players to make the big play. If the players fail, that's the players fault, the coach will yell at them and that's that; right? Well, no. If a coach acted like that they'd be fired, so why do we accept the same from our business leaders?
Someone I worked with noted there were two types of projects - projects that needed to be done by a date, and projects that needed to be done to a spec. Figuring out which one you're working on is the key - need to release by Christmas? Great, figure out what you can deliver by then and deliver it. Need to meet a compliance target? Great, figure out how long it's going to take.
It's true. But often that scope isn't properly defined. So you get a fixed timebox, a fixed "scope" (product has to be finnished) and a scope that's unclear. So first make sure the scope is properly defined. There's the current state and the desired state. There should exist a list of the business requirements that aren't covered by the current state.
Second make sure that list of business requirements is actually a list of business requirements. Often I see clients coming with lists of missing functionalities (e.g. a list with the desired functional design = waterfall). It's nice that clients come up with their suggestions on how things could be implemented. But these should not be set in stone and always come accompanied with the actual business requirements. If the business requirements are unknown the team will be unable to know if certain things might be covered in other ways. Or come up with alternative/reduced solutions to get them covered more quickly.
Second make sure that list of business requirements is actually a list of business requirements. Often I see clients coming with lists of missing functionalities (e.g. a list with the desired functional design = waterfall). It's nice that clients come up with their suggestions on how things could be implemented. But these should not be set in stone and always come accompanied with the actual business requirements. If the business requirements are unknown the team will be unable to know if certain things might be covered in other ways. Or come up with alternative/reduced solutions to get them covered more quickly.
What you described is a waterfall.
If you want to deliver quality stuff, you have to iterate fast a ask for feedback.
They screwed up be ause they spent too much time on the initial phase. During that time they should have already prepared few PoCs that could transform into MVP by now.
If you want to deliver quality stuff, you have to iterate fast a ask for feedback.
They screwed up be ause they spent too much time on the initial phase. During that time they should have already prepared few PoCs that could transform into MVP by now.
Also customer feedback usually trumps top-down opinions even when operating in a waterfall model. I've rescued a few "ScrumFall" projects by just ignoring sunk-costs and seeing how fast you can iterate to an MVP from what you have. If you real customers that find value in the smaller scope project - it trumps the political battle around what the scope really should be and buys you credibility to adjust timelines and iterate more in the future.
Yes! Thanks for calling this out I see this mistake so often.
This. Everything this.
There are great managers out there, who will take your job seriously, and who can amplify the value you create together, and there are “managers” who know only the whip. If you only know the latter, keep looking because you deserve better.
There are great managers out there, who will take your job seriously, and who can amplify the value you create together, and there are “managers” who know only the whip. If you only know the latter, keep looking because you deserve better.
> Reduce scope, or move the deadline
IMO, this is the only correct answer. Unless you're in a "lose the company" situation, burning out the developers will only make things worse.
IMO, this is the only correct answer. Unless you're in a "lose the company" situation, burning out the developers will only make things worse.
This ^ we usually rebaseline the schedule and deliver later.
I usually try to get the execs (sponsor, exec committee etc) to understand the difference between a hard and soft deadline. Hard being “it must be actioned” by a date such as a regulatory change, a construction project etc, and a soft deadline being “we want to do x by y” where the impact of delays is less.. perhaps worst case some revenue isn’t realised.
Perhaps trying to help solve the current project management approach issues would help you improve the workplace without having to leave (and would help all of your colleagues too it seems)
I usually try to get the execs (sponsor, exec committee etc) to understand the difference between a hard and soft deadline. Hard being “it must be actioned” by a date such as a regulatory change, a construction project etc, and a soft deadline being “we want to do x by y” where the impact of delays is less.. perhaps worst case some revenue isn’t realised.
Perhaps trying to help solve the current project management approach issues would help you improve the workplace without having to leave (and would help all of your colleagues too it seems)
This guy project manages
I think the answer is pretty dependent on what your personal role is. Are you a PM or tech lead or similar with the political clout to influence things?
If not, and your company asks you to work your ass off for their screwup, leave and never look back. You might be pleasantly surprised at what developer compensation is like these days.
If you are in a position to influence things, it depends how badly off track you and your team are. You need to be able to push back on unrealistic expectations. If you work yourself and your team to the bone and you still won’t achieve what’s being asked, definitely don’t bother. You’ll still have unrealistic and unreachable targets and all you will have achieved is moving the needle on how much you’re expected to work. If you think you might be able to pull off some heroics and save the project with hard work, you need to ask yourself: “Will I personally see any benefit from doing this? Will my team?”. If the answer is no, don’t do any heroics. Your bosses wouldn’t do it for nothing either. They may have KPIs that depend on this that you don’t have. That sucks for them.
You don’t want to set a precedent that you will pull weekends and evenings if you won’t see any benefit from it (think hard even if it has some upside).
What should happen is that the scope should be reduced to something that can be delivered in the original timeframe if possible, and then some milestones should be moved further out (far enough out that it’s deliverable). You don’t want to buy yourself time and then find it’s not enough.
If not, and your company asks you to work your ass off for their screwup, leave and never look back. You might be pleasantly surprised at what developer compensation is like these days.
If you are in a position to influence things, it depends how badly off track you and your team are. You need to be able to push back on unrealistic expectations. If you work yourself and your team to the bone and you still won’t achieve what’s being asked, definitely don’t bother. You’ll still have unrealistic and unreachable targets and all you will have achieved is moving the needle on how much you’re expected to work. If you think you might be able to pull off some heroics and save the project with hard work, you need to ask yourself: “Will I personally see any benefit from doing this? Will my team?”. If the answer is no, don’t do any heroics. Your bosses wouldn’t do it for nothing either. They may have KPIs that depend on this that you don’t have. That sucks for them.
You don’t want to set a precedent that you will pull weekends and evenings if you won’t see any benefit from it (think hard even if it has some upside).
What should happen is that the scope should be reduced to something that can be delivered in the original timeframe if possible, and then some milestones should be moved further out (far enough out that it’s deliverable). You don’t want to buy yourself time and then find it’s not enough.
Furthermore, this situation that you’re in is almost always optional. Managers vary in skill, and most deadlines can be moved if necessary. If your team only says yes and can’t ever say no, this will always happen. You should find a place with a management team that can make your life and work better.
Managements take the fire-aim-ready approach to projects. i.e. come up with a grandiose goal, set an unrealistic budget. Get some minor manager throw together a half-baked spec. Hire a sycophant project manager.
The viable plan: polish up your CV, get a better job. Your only responsibility is to yourself, your mental and physical health. If the managers want to burn down the company, that is their prerogative.
The viable plan: polish up your CV, get a better job. Your only responsibility is to yourself, your mental and physical health. If the managers want to burn down the company, that is their prerogative.
One startup, our MVP launch date (very hard date; miss it, and the company is over) was moved to earlier, by customer's manufacturing schedule change, just as half our small, high-powered engineering team got sick.
So I took the existing plan, from before the latest reality happened, and:
* Turned plan into refreshed sorted spreadsheet rows of prioritized tasks and estimated durations and assignments.
* Culled tasks very heavily and sometimes painfully.
* Kept in mind that the system had to work immediately at launch, and had to keep working, with production line uptime and correctness. (For example, there were some non-obvious system robustness/resilience tasks that I added, even as I was removing most other tasks.)
* Looked for opportunities to do things smarter, from the remaining essential tasks.
* Made sure the sick people weren't assigned to anything that absolutely had to happen.
* Kept updating the plan, sometimes multiple times a day, as tasks were completed, problems found, etc.
* Made sure that the estimates always said we'd hit deadline.
All this planning was rapid and intense, not "let's take a day to plan, and schedule some meetings, and have regular check-ins, etc.", and captured in a single view (the spreadsheet).
It was successful, ended up with 100% software uptime and correctness, for the entire contract period, of over a year. Some of that was because the technical cofounder who'd done all the initial work had experience with critical systems, and I followed through in the same spirit. Some of it was luck. Some of is was being vicious and smart about what work was done. Some of it was misery, knowing that the company, and a lot of people's livelihoods and career goals, relied on this coming together in time and working.
As for how to shield people from ulcers in a crunch: if anyone has to get ulcers, it should be leadership, quietly, from figuring out how to make this come together successfully, without the entire team exploding with ulcers.
And the team should see that leadership is all-in on making this be a success, and every individual implicitly buys in on staying committed to the team and project, and the team rises to the smart things that they are asked to do.
(Note: In this case, I used a spreadsheet, but in other cases, the single source of truth view for the entire project would more likely be a good Gantt diagram, or maybe a Kanban board. What's important are that it always reflects the best information and current decisions&activity, everyone is working from it and understands their parts in context rather than as checkoff tasks out of context, and it shows the project coming together.)
So I took the existing plan, from before the latest reality happened, and:
* Turned plan into refreshed sorted spreadsheet rows of prioritized tasks and estimated durations and assignments.
* Culled tasks very heavily and sometimes painfully.
* Kept in mind that the system had to work immediately at launch, and had to keep working, with production line uptime and correctness. (For example, there were some non-obvious system robustness/resilience tasks that I added, even as I was removing most other tasks.)
* Looked for opportunities to do things smarter, from the remaining essential tasks.
* Made sure the sick people weren't assigned to anything that absolutely had to happen.
* Kept updating the plan, sometimes multiple times a day, as tasks were completed, problems found, etc.
* Made sure that the estimates always said we'd hit deadline.
All this planning was rapid and intense, not "let's take a day to plan, and schedule some meetings, and have regular check-ins, etc.", and captured in a single view (the spreadsheet).
It was successful, ended up with 100% software uptime and correctness, for the entire contract period, of over a year. Some of that was because the technical cofounder who'd done all the initial work had experience with critical systems, and I followed through in the same spirit. Some of it was luck. Some of is was being vicious and smart about what work was done. Some of it was misery, knowing that the company, and a lot of people's livelihoods and career goals, relied on this coming together in time and working.
As for how to shield people from ulcers in a crunch: if anyone has to get ulcers, it should be leadership, quietly, from figuring out how to make this come together successfully, without the entire team exploding with ulcers.
And the team should see that leadership is all-in on making this be a success, and every individual implicitly buys in on staying committed to the team and project, and the team rises to the smart things that they are asked to do.
(Note: In this case, I used a spreadsheet, but in other cases, the single source of truth view for the entire project would more likely be a good Gantt diagram, or maybe a Kanban board. What's important are that it always reflects the best information and current decisions&activity, everyone is working from it and understands their parts in context rather than as checkoff tasks out of context, and it shows the project coming together.)
As a side note, why is it that whatever Very Smart organizational system using Trello or Asana that we have set up in our own lives, or in our company, (and now I have your company as a second example), when shit gets real it comes down to the "real" list which is a spreadsheet or in my personal case a text file? What does that say about our Very Smart organizational system?
In my experience, a team can run on just-in-time planning, the one simple task list, and the experience of their senior people for quite some time. It's even Agile: People, not processes. But what we lose is the ability to grow more senior people for when we run out of the ones we have just now.
The Very Smart organisational systems have inefficiencies, but they also have affordances. And more importantly, they have the structure to let multiple people poke at them at the same time, and allow people to learn and make mistakes without (normally) breaking everything that's currently in-progress.
Trying to run for too long on the one "real" list is a recipe for burnout and tech debt. And ensuring the team is using the right model at any given point in time is an art I'm not entirely sure I've mastered.
The Very Smart organisational systems have inefficiencies, but they also have affordances. And more importantly, they have the structure to let multiple people poke at them at the same time, and allow people to learn and make mistakes without (normally) breaking everything that's currently in-progress.
Trying to run for too long on the one "real" list is a recipe for burnout and tech debt. And ensuring the team is using the right model at any given point in time is an art I'm not entirely sure I've mastered.
Yes, don't become a slave of a list.
IMHO:
1. Some things done in everyday practice have big inefficiencies, or give the illusion of productivity and progress, and desperation can force a team to realize that.
2. A lot of tools are driven by enterprise sales, which means they target needs of large companies with very different needs than a startup-like team (in which it's easier to have everyone on the same page, aligned, and barriers removed).
3. A lot of tools are driven by enterprise sales, which can mean that the people who select and approve them aren't the people with experience using them. (And sometimes a team is forced to use poor tools, with adverse impact on effectiveness and morale, and then you get into a budget meeting, and see the SaaS fees the company is paying for those tears (TaaS).)
4. There are definitely projects I can't handle in a spreadsheet (most of them). But, when SHTF, and priorities change, the number of things you're focused on gets smaller and more in everyone's heads, the spreadsheet or text file might be most rapid to work with. (For SHTF deadline-hitting in another, much larger, startup, I would've forced everything into a canonical Gantt chart, just because the interdependencies were too complex, and declared the tons of Jira sprint Issues and manual team reports to be confusing and time-wasting noise, and everyone works&reports first from the Gantt.)
1. Some things done in everyday practice have big inefficiencies, or give the illusion of productivity and progress, and desperation can force a team to realize that.
2. A lot of tools are driven by enterprise sales, which means they target needs of large companies with very different needs than a startup-like team (in which it's easier to have everyone on the same page, aligned, and barriers removed).
3. A lot of tools are driven by enterprise sales, which can mean that the people who select and approve them aren't the people with experience using them. (And sometimes a team is forced to use poor tools, with adverse impact on effectiveness and morale, and then you get into a budget meeting, and see the SaaS fees the company is paying for those tears (TaaS).)
4. There are definitely projects I can't handle in a spreadsheet (most of them). But, when SHTF, and priorities change, the number of things you're focused on gets smaller and more in everyone's heads, the spreadsheet or text file might be most rapid to work with. (For SHTF deadline-hitting in another, much larger, startup, I would've forced everything into a canonical Gantt chart, just because the interdependencies were too complex, and declared the tons of Jira sprint Issues and manual team reports to be confusing and time-wasting noise, and everyone works&reports first from the Gantt.)
For #1 I'd wonder why we so quickly forget whatever it is that we're forced to realize. #4 makes a lot of sense though.
Maybe information density?
When I imagine a spreadsheet or text file for managing a project, in my mind I am picturing a lot of items on one screen of text. With very little "chrome" or extra whitespace, or needing to navigate across several screens to get the whole picture. Or learn specific tool features to get the view you want. And the simplicity of just adding a column to your spreadsheet, vs figuring out where to fit the new data point into the existing ticket structure.
When I imagine a spreadsheet or text file for managing a project, in my mind I am picturing a lot of items on one screen of text. With very little "chrome" or extra whitespace, or needing to navigate across several screens to get the whole picture. Or learn specific tool features to get the view you want. And the simplicity of just adding a column to your spreadsheet, vs figuring out where to fit the new data point into the existing ticket structure.
I think it says "don't get religious/superstitious about tools". Many can work, but they also don't replace project management people.
Priorities
When you switch to the personal text file, you're taking out a loan on when you'll do reporting and analysis on the work done
When you switch to the personal text file, you're taking out a loan on when you'll do reporting and analysis on the work done
> * Turned plan into refreshed sorted spreadsheet rows of prioritized tasks and estimated durations and assignments.
>
> * Culled tasks very heavily and sometimes painfully.
This is how any software project should run, continuously.
>
> * Culled tasks very heavily and sometimes painfully.
This is how any software project should run, continuously.
Important questions are: do you get paid overtime? Are there bonuses and/or promotions and/or time off later? Does management recognize the situation? Do you enjoy this company or the work or your co-workers when it’s not running late?
Is the deadline moveable in time or scope? Some deadlines are pretty firm and slipping will result in costing the company a lot of money.
If you stay, you should take notes on how management reacts, what steps they take to improve. Offering the right kind of constructive help to improve it is an opportunity to step into management if you want it. You know a lot more than I do about your situation, but I wouldn’t necessarily assume that meetings were the cause of overtime. Sometimes despite many meetings, lack of enough planning is still the problem. Or maybe the issue is that decisions were not being made in the meetings.
To answer the question, I’ve been in 5 companies that handled this 5 different ways:
- One company (film) that had paid overtime for 2-3 months at the end of every 18 month project. The overtime pay was 1.5x, but some accounting shenanigans made it so overtime pay didn’t kick in until 5 or 10 hours in, so it tended to work out more like 1.3x. Overtime was managed quite well IMO, but wasn’t seen as a problem. Post-project meetings would reflect on how to buffer production from changes in the story or examine accidents and discuss how to keep them from happening. The crunch times over several films slowly went down because management was improving. My base hours were 50/wk, crunch time hours were ~60-70. I did 80 once for a month when a project went off the rails. Management recognized it and this contributed to closing the division and moving everyone.
- Another company (games) had unpaid overtime for 4-6 months at the end of every 18 month project. Free dinner though! Discretionary bonuses tended to go toward people who put in more effort, though it was far from fair. Post-project meetings were slightly more about letting people vent than fixing the planning process, and would tend to reiterate the message that crunch time is inevitable. My base hours were 40-50/wk, crunch hours ramped from 50 to 80, peaking at 90 once or twice. BTW 80 for any real stretch is unlivable.
- When I ran my own startup, my overtime was unpaid and constant, never ending. ;) I probably worked 80-90 hours/wk, but it was way more flexible and much easier to do than when working for someone else’s company.
- When I worked for a web company that used continuous integration and delivery in 2 week sprints there was virtually no overtime, and we would punt features into the next sprint whenever they fell behind or grew in scope. There was a constant mild healthy pressure to deliver, but people clocked out at 5pm more consistently than anywhere else I’ve ever worked.
- At my current job, a hardware company, there is no official overtime or tracking of time at all, including “unlimited” vacation (which is kinda nice but I think tends to make me take less vacation than if I had a quota). Our software delivery is every 3-6 months, hardware projects every ~2 years. I tend to work more than 40 hours a week, and I put in extra hours above that when I want to do a little extra or do a good job on something, or I’m researching something I’m interested in. Compensation is good and my manager doesn’t think of jobs in terms of hours, he and I make sure I’m bringing value over the years.
Is the deadline moveable in time or scope? Some deadlines are pretty firm and slipping will result in costing the company a lot of money.
If you stay, you should take notes on how management reacts, what steps they take to improve. Offering the right kind of constructive help to improve it is an opportunity to step into management if you want it. You know a lot more than I do about your situation, but I wouldn’t necessarily assume that meetings were the cause of overtime. Sometimes despite many meetings, lack of enough planning is still the problem. Or maybe the issue is that decisions were not being made in the meetings.
To answer the question, I’ve been in 5 companies that handled this 5 different ways:
- One company (film) that had paid overtime for 2-3 months at the end of every 18 month project. The overtime pay was 1.5x, but some accounting shenanigans made it so overtime pay didn’t kick in until 5 or 10 hours in, so it tended to work out more like 1.3x. Overtime was managed quite well IMO, but wasn’t seen as a problem. Post-project meetings would reflect on how to buffer production from changes in the story or examine accidents and discuss how to keep them from happening. The crunch times over several films slowly went down because management was improving. My base hours were 50/wk, crunch time hours were ~60-70. I did 80 once for a month when a project went off the rails. Management recognized it and this contributed to closing the division and moving everyone.
- Another company (games) had unpaid overtime for 4-6 months at the end of every 18 month project. Free dinner though! Discretionary bonuses tended to go toward people who put in more effort, though it was far from fair. Post-project meetings were slightly more about letting people vent than fixing the planning process, and would tend to reiterate the message that crunch time is inevitable. My base hours were 40-50/wk, crunch hours ramped from 50 to 80, peaking at 90 once or twice. BTW 80 for any real stretch is unlivable.
- When I ran my own startup, my overtime was unpaid and constant, never ending. ;) I probably worked 80-90 hours/wk, but it was way more flexible and much easier to do than when working for someone else’s company.
- When I worked for a web company that used continuous integration and delivery in 2 week sprints there was virtually no overtime, and we would punt features into the next sprint whenever they fell behind or grew in scope. There was a constant mild healthy pressure to deliver, but people clocked out at 5pm more consistently than anywhere else I’ve ever worked.
- At my current job, a hardware company, there is no official overtime or tracking of time at all, including “unlimited” vacation (which is kinda nice but I think tends to make me take less vacation than if I had a quota). Our software delivery is every 3-6 months, hardware projects every ~2 years. I tend to work more than 40 hours a week, and I put in extra hours above that when I want to do a little extra or do a good job on something, or I’m researching something I’m interested in. Compensation is good and my manager doesn’t think of jobs in terms of hours, he and I make sure I’m bringing value over the years.
Quick story: ages ago, I was the tech lead on a console game. Being in stores for Christmas shopping season is a really, really big deal. I mis-estimated the project and under-led it early on, resulting in us being way behind schedule come summertime. For about a three week period, I moved a cot and sleeping bag into the office and pulled 70+ hour weeks to get the project back onto schedule. I never overtly asked, but the rest of the tech team stepped up to a somewhat lesser degree and we got the product into Sony QC in time for the holiday.
Did I get anything extra for it? I don't know. I can't point to a specific check that was tied to that cot. I do know that the company appreciated it and my overall trajectory there was good. I was also proud for myself that I could dig deep and really "bring it" for several weeks to reach a goal that meant something to me.
If I had to do it every year, it would grate on me. If I had to do it because other people screwed the pooch, it would annoy me. But I still look back fondly on the overall experience there.
Did I get anything extra for it? I don't know. I can't point to a specific check that was tied to that cot. I do know that the company appreciated it and my overall trajectory there was good. I was also proud for myself that I could dig deep and really "bring it" for several weeks to reach a goal that meant something to me.
If I had to do it every year, it would grate on me. If I had to do it because other people screwed the pooch, it would annoy me. But I still look back fondly on the overall experience there.
Doing so once as a “servant leader” is radically different than doing so often for “tyrant leaders”
You did it because it was a job well done and you took pride in it.
Despite the naysayers, aint nuttin wrong wit dat.
Despite the naysayers, aint nuttin wrong wit dat.
How did sleeping at work and pulling 70+ hour weeks affect your friends, family and mental health?
Girlfriend was in first-year med school at the time, so that worked out just fine. I played some softball games on my regular team, but otherwise just nerded/ground it out for about a month.
It was fine, really. Lots of people go through way worse and come out fine; it’s nothing like being deployed overseas in the armed forces, as just one common example.
It was fine, really. Lots of people go through way worse and come out fine; it’s nothing like being deployed overseas in the armed forces, as just one common example.
Yeah, some of my favourite experiences ever have been short term crunches. But it has to be opt in, and there has to be a satisfying outcome and stress relief afterwards or you just burn out.
We don't do deadlines.
We do scope.
We estimate scope using story points and estimate the number of cycles assuming "x" story points are hit in a cycle.
With clients, we share this process, giving transparency into our progress.
We never promise a specific release date, and if we see the timeline stretching further than the client would like, we adjust the scope of the project to shorten the length of the project.
I've never had a better relationship with clients with another model. They get to understand more of what a real development project is. We even invite them to our Cycle Demos for their project.
The best way to not get behind is to not set a deadline. Instead set a scope and budget. Communication is key. More often than not, adding developers does not speed up a project, only adjusting scope does.
Adjust Early. Adjust Accordingly. Adjust Often.
I've never had a better relationship with clients with another model. They get to understand more of what a real development project is. We even invite them to our Cycle Demos for their project.
The best way to not get behind is to not set a deadline. Instead set a scope and budget. Communication is key. More often than not, adding developers does not speed up a project, only adjusting scope does.
Adjust Early. Adjust Accordingly. Adjust Often.
I want to vouch for this 100%.
Personally, on my team we use Pivotal Tracker - it tracks our velocity for us and automatically "guesses" our release date based on our velocity. If we aren't happy with the projected date, we reduce scope aggressively. Clients see our backlog and can see when things change. Most of our project planning is completely automated by Tracker - we just create tasks and point them. It's the only thing that has been even remotely successful for us. If I had to give up Tracker for Jira I would quit my job.
Personally, on my team we use Pivotal Tracker - it tracks our velocity for us and automatically "guesses" our release date based on our velocity. If we aren't happy with the projected date, we reduce scope aggressively. Clients see our backlog and can see when things change. Most of our project planning is completely automated by Tracker - we just create tasks and point them. It's the only thing that has been even remotely successful for us. If I had to give up Tracker for Jira I would quit my job.
Take a look at Linear. We're all in.
As simple as Pivotal, none of the bloat of Atlassian tools.
You can set Linear up to almost emulate a Pivotal experience, but I personally love the keybinding first user experience of Linear. It makes it incredible fast to navigate, and its easy for all members to view the status of projects.
You can set Linear up to almost emulate a Pivotal experience, but I personally love the keybinding first user experience of Linear. It makes it incredible fast to navigate, and its easy for all members to view the status of projects.
Looks neat but we're all in on Tracker so not sure switching is on the cards. I'll keep it in mind for other projects/teams in the future though, thanks.
I am PM, PO, tech lead, and sometimes primary IC on several projects. I am also owner of a software consulting company so I also control budgets and customer relations. When (not if) projects go over my general strategy is to:
1) Take the pressure off the engineers by reassuring the client with one of several tools (i.e. monetary concessions, strategic scope limitation, detailed investigation, client education, etc). Stressed clients equal stressed engineers. The tension can be palpable. 2) Educate the client on the underlying reasons why we got here. 99% of the time it is because of mismanagement. It is up to management to manage client expectations vs reality and they have clearly failed to do that. It is like the situation where a physician with good rapport with the patient is less likely to sue in the event of a medical error. 3) If overtime is necessary, provide a bonus or extra PTO for overtime, even if it means the company needs to take a small financial hit. Why should engineers suffer the consequences of something that is almost always a management misstep?
I am in a unique situation because I wear so many hats at my company. Unfortunately this decision making process usually involves multiple people. The person controlling the budget is not the same one that is controlling the scope. You need to get the relevant stakeholders in a room together to figure out how to rebalance the expectation vs reality equation. Budget and/or scope are the two dials you can tweak. If this is difficult to do, it may be time to move on. Life is too short to be stressed about things you have no control over.
1) Take the pressure off the engineers by reassuring the client with one of several tools (i.e. monetary concessions, strategic scope limitation, detailed investigation, client education, etc). Stressed clients equal stressed engineers. The tension can be palpable. 2) Educate the client on the underlying reasons why we got here. 99% of the time it is because of mismanagement. It is up to management to manage client expectations vs reality and they have clearly failed to do that. It is like the situation where a physician with good rapport with the patient is less likely to sue in the event of a medical error. 3) If overtime is necessary, provide a bonus or extra PTO for overtime, even if it means the company needs to take a small financial hit. Why should engineers suffer the consequences of something that is almost always a management misstep?
I am in a unique situation because I wear so many hats at my company. Unfortunately this decision making process usually involves multiple people. The person controlling the budget is not the same one that is controlling the scope. You need to get the relevant stakeholders in a room together to figure out how to rebalance the expectation vs reality equation. Budget and/or scope are the two dials you can tweak. If this is difficult to do, it may be time to move on. Life is too short to be stressed about things you have no control over.
I have always done a "triage" of functionality, before starting. I call it "Front of the Box/Back of the Box/Side of the Box."
If it is important -to the end user; not the engineer-, then it gets prioritized over other functions. That is critical.
Think of a product package, sitting on a store shelf:
FRONT OF THE BOX:
This is three "Must Have" features. It correlates to the big, splashy text, on the front of a box. Without all of these, the product is a total failure.
BACK OF THE BOX:
This is four or five "Critically Important" features, that correlate to the smaller, yet still pronounced, features, listed on the back of the box.
SIDE OF THE BOX:
Everything else. Small text, on the side of the box.
When scheduling the project, it's critical to schedule Front Of The Box stuff, first, then Back of the Box, and, finally, Side of the Box.
Doesn't matter whether you are Waterfall or Agile. The important thing is to plan on implementing the "killer features," FIRST.
A lot of times, engineers want to get the difficult stuff done first (guilty as charged). This can often result in "bikeshedding" behavior, where a great deal of time is spent on stuff that isn't really relevant to the end-user.
When a project enters a "crunch phase," then it's important to start pruning. This is not popular. We need to remove feature development from the schedule ahead of us.
Since we have already implemented the important stuff, we will be pruning stuff that the end-users of our product don't really care about.
Also, I run what I call "Constant Beta." I get the project to an end-user-runable state, as soon as possible, even if feature incomplete. This gets me valuable feedback, and the important stuff (Front of the Box, first!) gets more testing than anything else in the product, since stakeholders are testing it, from the start.
This often results in pivots during development (as opposed to a janky MVP, destroying your brand).
But I have found many corporations won't do it that way. I had to wait until I was working for myself to do it.
Works a treat.
If it is important -to the end user; not the engineer-, then it gets prioritized over other functions. That is critical.
Think of a product package, sitting on a store shelf:
FRONT OF THE BOX:
This is three "Must Have" features. It correlates to the big, splashy text, on the front of a box. Without all of these, the product is a total failure.
BACK OF THE BOX:
This is four or five "Critically Important" features, that correlate to the smaller, yet still pronounced, features, listed on the back of the box.
SIDE OF THE BOX:
Everything else. Small text, on the side of the box.
When scheduling the project, it's critical to schedule Front Of The Box stuff, first, then Back of the Box, and, finally, Side of the Box.
Doesn't matter whether you are Waterfall or Agile. The important thing is to plan on implementing the "killer features," FIRST.
A lot of times, engineers want to get the difficult stuff done first (guilty as charged). This can often result in "bikeshedding" behavior, where a great deal of time is spent on stuff that isn't really relevant to the end-user.
When a project enters a "crunch phase," then it's important to start pruning. This is not popular. We need to remove feature development from the schedule ahead of us.
Since we have already implemented the important stuff, we will be pruning stuff that the end-users of our product don't really care about.
Also, I run what I call "Constant Beta." I get the project to an end-user-runable state, as soon as possible, even if feature incomplete. This gets me valuable feedback, and the important stuff (Front of the Box, first!) gets more testing than anything else in the product, since stakeholders are testing it, from the start.
This often results in pivots during development (as opposed to a janky MVP, destroying your brand).
But I have found many corporations won't do it that way. I had to wait until I was working for myself to do it.
Works a treat.
The reason you are supposed to do the "hard things first" is because of risk. If you do the easy but front-of-the-box things first, you might find out that the hard things are impossible. Software is complicated and so are requirements. Finding out your product is critically flawed too late burns time. I'm not into buzzwords or over-indoctrinated into methodologies, but I think Agile has that aspect right.
But if the "hard thing" is something not crucial to the end-user of the product, then it doesn't matter whether or not it's impossible.
Really bitter pill to swallow.
This philosophy is not easy for engineers (like me) to stomach.
Really bitter pill to swallow.
This philosophy is not easy for engineers (like me) to stomach.
The really important thing if you decide to go this route though is that each "thing" that goes on part of the box needs to be a complete feature. Typically projects aren't approached in that way - if someone builds out the front-end UI because that's highly user visible but someone doesn't hook up the backend (as an extreme example), the fact that the "front of the box" features are done is irrelevant, they're unusable without the less sexy stuff.
Not to say that it isn't possible to divide a project into independently "complete" features, it's just something you need to be really intentional about.
Not to say that it isn't possible to divide a project into independently "complete" features, it's just something you need to be really intentional about.
> they're unusable without the less sexy stuff.
Absolutely correct. I’m big on infrastructure. Infrastructure is not “shiny,” at all, most times, but it’s the glue that holds the whole shooting match together.
My designs often begin with infrastructure, but I’ve learned to architect flexible structure, as it usually needs to adapt to changing requirements from the frontend, as the project progresses.
In fact, I’m actually doing exactly that, with a backend connector layer, in my current project, right now.
The connector SDK (and backend server) is suffering performance issues, which degrades the user experience to an unacceptable level. Nasty time to encounter this, as the project is quite mature.
The current connector is really not something that can be easily adapted or fixed (I wrote it about six or seven years ago, as a generic SDK, for the backend server, which I also wrote). It needs a rewrite —usually a “death sentence,” this late in the project. I had to think long and hard, before making the decision to do this. If this weren’t a “Front of the Box” feature, it wouldn’t even be a consideration.
Because I always approach these types of projects in a loosely-coupled, “layered” fashion, it makes it easier to “swap out” parts.
Each layer tends to take the shape of a standalone “module,” with a clear, unambiguous, functional domain and API, along with its own testing, documentation, and project lifecycle. They usually take the form of discrete GitHub repos, and SPM packages. That is the case for the current connector, and will be the case for the new one (I already have it set up).
I expect the rewrite to take a few weeks. I’ll probably have the main coding of the SDK done, in a couple of weeks, but adapting the application to the new SDK, and fixing the inevitable swarm of bugs, will take a lot longer.
But it’s quite doable. It will work (I’ve done exactly this kind of thing, many times, before), and the final product will have a greatly-improved “killer feature,” as a result.
So I guess the TL;DR of that mess, is that the architecture, itself, needs to be planned in a way that affords reacting to unexpected stressors.
Absolutely correct. I’m big on infrastructure. Infrastructure is not “shiny,” at all, most times, but it’s the glue that holds the whole shooting match together.
My designs often begin with infrastructure, but I’ve learned to architect flexible structure, as it usually needs to adapt to changing requirements from the frontend, as the project progresses.
In fact, I’m actually doing exactly that, with a backend connector layer, in my current project, right now.
The connector SDK (and backend server) is suffering performance issues, which degrades the user experience to an unacceptable level. Nasty time to encounter this, as the project is quite mature.
The current connector is really not something that can be easily adapted or fixed (I wrote it about six or seven years ago, as a generic SDK, for the backend server, which I also wrote). It needs a rewrite —usually a “death sentence,” this late in the project. I had to think long and hard, before making the decision to do this. If this weren’t a “Front of the Box” feature, it wouldn’t even be a consideration.
Because I always approach these types of projects in a loosely-coupled, “layered” fashion, it makes it easier to “swap out” parts.
Each layer tends to take the shape of a standalone “module,” with a clear, unambiguous, functional domain and API, along with its own testing, documentation, and project lifecycle. They usually take the form of discrete GitHub repos, and SPM packages. That is the case for the current connector, and will be the case for the new one (I already have it set up).
I expect the rewrite to take a few weeks. I’ll probably have the main coding of the SDK done, in a couple of weeks, but adapting the application to the new SDK, and fixing the inevitable swarm of bugs, will take a lot longer.
But it’s quite doable. It will work (I’ve done exactly this kind of thing, many times, before), and the final product will have a greatly-improved “killer feature,” as a result.
So I guess the TL;DR of that mess, is that the architecture, itself, needs to be planned in a way that affords reacting to unexpected stressors.
It depends on what you are doing. Frequently you know you have A, B, C, D use cases in that order of complexity.
A lot of people's instincts will be "Let's try it out with an easy use case like B" and then make the go-forward bases on that.
Then you go to tackle C or D and find out it's a no go.
The better strat can be a spike on D to verify the solution can handle it. This is hack and slash; your validating. After you work on the mature solution.
I've seen so many times people sink time into the mature solution based on A. Then you find out it won't work for D or you finally measure and find out there is no benefit.
A lot of people's instincts will be "Let's try it out with an easy use case like B" and then make the go-forward bases on that.
Then you go to tackle C or D and find out it's a no go.
The better strat can be a spike on D to verify the solution can handle it. This is hack and slash; your validating. After you work on the mature solution.
I've seen so many times people sink time into the mature solution based on A. Then you find out it won't work for D or you finally measure and find out there is no benefit.
a) That hard thing should have been cut out and by definition is not part of the product. Didn't see a bridge with space rocket engines recently, as one could say.
b) Most times nobody knows what is actually crucial to the user -- including the user and management. Books and theses have been written on the topic. Companies experiment until something sticks. There is always the chance a feature is unnecessary.
b) Most times nobody knows what is actually crucial to the user -- including the user and management. Books and theses have been written on the topic. Companies experiment until something sticks. There is always the chance a feature is unnecessary.
I love this. I've always used the idea of creating an MVP first, but I really like your box theory.
It basically was inspired by Scott Jenson's The Simplicity Shift.
https://jenson.org/The-Simplicity-Shift.pdf (Downloads a PDF).
https://jenson.org/The-Simplicity-Shift.pdf (Downloads a PDF).
My company is trying to address this by changing our 15 minute daily status update meeting into an all-day 8 hour Teams call so the 4 project managers can interrupt me and the other engineer to ask what the difference between SQL and Excel is.
Paul? Is that you? This is Adam over in the assessments project. How are you? This sounds so familiar.
Other people's poor planning is not your emergency. That doesn't mean you don't go the extra mile to help, necessarily, but it's a favor, not an obligation. Maybe you do, maybe you don't, depends on how you feel about the people involved and whether they deserve the help.
If they don't get that, yeah, leave, will a smile on your face and a song in your heart. The only reward you'll get for staying, if they're not the sort who appreciate the above, is burn-out and more of the same crap in the future.
If they don't get that, yeah, leave, will a smile on your face and a song in your heart. The only reward you'll get for staying, if they're not the sort who appreciate the above, is burn-out and more of the same crap in the future.
[deleted]
There was a Saint that said: “I meditate one hour everyday, well everyday except when I have a lot of work, that day, I meditate two hours.”
That proverb is superb, when something is wrong and the team seems stressed I usually use it and we call a meeting to try to re-evaluate the situation.
Definitely you end up prioritizing and cutting in order to keep things on track.
Usually delays come from two sources: 1. Bells, whistles and nice to have functionality that are already working and keeps refining. 2. Engineers Ego: refactoring when they find that a nicer approach is possible. Just stop that and keep in mind that business comes first and you will eventually have time to rethink (if everything goes smooth).
Good luck!
That proverb is superb, when something is wrong and the team seems stressed I usually use it and we call a meeting to try to re-evaluate the situation.
Definitely you end up prioritizing and cutting in order to keep things on track.
Usually delays come from two sources: 1. Bells, whistles and nice to have functionality that are already working and keeps refining. 2. Engineers Ego: refactoring when they find that a nicer approach is possible. Just stop that and keep in mind that business comes first and you will eventually have time to rethink (if everything goes smooth).
Good luck!
About a decade ago our company was way behind on a large e-commerce project for a big client. Not due to anything the devs did. The sales team oversold without talking to tech first. So one day the head of our North American branch decided it would be cool to call an all hands meeting to demand everyone puts in 70 hour weeks to “get-er done”. This meeting happened to be April 1st. Many of us thought it was some kind of weird joke. Unfortunately no. Regardless, we got-er done and I personally pulled some +450 overtime hours (unpaid) along with similar amounts from my coworkers by the time it was shipped. We were given a single hundred dollars or so in gift cards for our efforts. Many good folks resigned that day.
Don’t do this. If you’re on the receiving end, just move on. If you’re on the giving end of this how do you sleep… ugh
Don’t do this. If you’re on the receiving end, just move on. If you’re on the giving end of this how do you sleep… ugh
Adding more managers.
I was in a meeting for a late-running project where there were two SMEs, me as the lone engineer, and seven managers. Project manager, scrum master, product owner, function vertical manager, project coordinator, and two front-line managers... in each daily stand-up.
When I said the number of managers was slowing us down because we had to constantly explain the project, they added a technical manager.
I'm looking elsewhere.
I was in a meeting for a late-running project where there were two SMEs, me as the lone engineer, and seven managers. Project manager, scrum master, product owner, function vertical manager, project coordinator, and two front-line managers... in each daily stand-up.
When I said the number of managers was slowing us down because we had to constantly explain the project, they added a technical manager.
I'm looking elsewhere.
This sounds like a previous job, though at least we had a couple of additional engineers. The "manager" to "engineer" ratio was still >1.
What you are experiencing is pretty normal, and if you're looking for a new job, chances are that you're not the only ones; therefore the project will become even more "compromised", for lack of better word.
Agile as a methodology solves the issue at a strategic level, but at the end of the day it is always human behavior that determines the way things work. Agile is a tool, and a tool is as good as the people who use it.
I suspect that your project encompassed a lot of people, I wonder if there is not since point of responsibility/accountability, so nobody make the hard choices, and the process was too "democratic".
Nothing can be done about this very project, and this is a symptom of the company as a whole.
This is how companies fail.
Agile as a methodology solves the issue at a strategic level, but at the end of the day it is always human behavior that determines the way things work. Agile is a tool, and a tool is as good as the people who use it.
I suspect that your project encompassed a lot of people, I wonder if there is not since point of responsibility/accountability, so nobody make the hard choices, and the process was too "democratic".
Nothing can be done about this very project, and this is a symptom of the company as a whole.
This is how companies fail.
Welcome to the world of software development. Only at my last job (~ 6 years before retiring) were there huge projects that were inevitably late. These were projects for the company's business, not external. Typically we were handed some requirements with a hard deadline, then everything changed daily (and was required for day 1) until we neared the deadline, then the deadline was moved; rinse, repeat. Then after months of this sometimes it was cancelled, sometimes it was postponed further, sometimes it finally shipped. It was a dance I got used to dealing with. Longer hours were asked, sometimes mandated, but everyone knew it was part of the show, and while as lead I worked longer hours I refused to demand my team did. In the end it didn't matter, as these projects involved huge numbers of people/teams so blame (fair and unfair) was spread around.
Once something shipped, if it worked, then no one remembered the pain until the next one.
If everyone is working long hours including execs and it's shared pain, something will eventually change for the better. My problem with it was when I worked long hours but the execs went on long vacations and weren't even available for approvals or questions. Then nothing will change and you should go elsewhere.
Once something shipped, if it worked, then no one remembered the pain until the next one.
If everyone is working long hours including execs and it's shared pain, something will eventually change for the better. My problem with it was when I worked long hours but the execs went on long vacations and weren't even available for approvals or questions. Then nothing will change and you should go elsewhere.
> no one remembered the pain
And you'll develop a Cassandra-like ability to see it coming when it is coming, and you'll also learn that the absolute worst thing you can possibly do is to try to get ahead of it in any way. Don't point out to them that they're on the road to ruin or they'll blaze down the road faster and then blame you for it.
And you'll develop a Cassandra-like ability to see it coming when it is coming, and you'll also learn that the absolute worst thing you can possibly do is to try to get ahead of it in any way. Don't point out to them that they're on the road to ruin or they'll blaze down the road faster and then blame you for it.
> our company is asking us to work weekends and extra hours
This is the only relevant point, and you can get your answer by asking if you will receive additional compensation for the additional time that you're being asked to put in. Paying you a salary doesn't give them the right to pretend that _all_ of your time belongs to them. If they want more of your time, they need to pay you more. If they say no, then you say okay and either stay and work exactly 40 hours per week until they fire you for "not being a team player" or whatever (for which I believe you would have cause to seek unemployment benefits, but I am not a lawyer); or leave.
Putting more pressure on developers is the _least_ effective thing that management could possibly do. Stress produces cortisol. Too much cortisol results in overall lower cognitive ability. Why would you stress out the people who need to be able to think clearly?
This is the only relevant point, and you can get your answer by asking if you will receive additional compensation for the additional time that you're being asked to put in. Paying you a salary doesn't give them the right to pretend that _all_ of your time belongs to them. If they want more of your time, they need to pay you more. If they say no, then you say okay and either stay and work exactly 40 hours per week until they fire you for "not being a team player" or whatever (for which I believe you would have cause to seek unemployment benefits, but I am not a lawyer); or leave.
Putting more pressure on developers is the _least_ effective thing that management could possibly do. Stress produces cortisol. Too much cortisol results in overall lower cognitive ability. Why would you stress out the people who need to be able to think clearly?
in small consultancies if you don't estimate correctly and don't deliver on time then you don't eat. It's refreshingly black/white. I think all developers and especially tech leads and "solution architects" should spend a few years in that world early on in their careers.
my current company ( a very large consulting firm ) will pull in people from top to bottom of the project org chart who specialize in getting things back on track. A team is dedicated to relationship management with the client to help them feel more comfortable about the situation, a team is dedicated to delivery management, and very good problem solvers are scattered throughout the delivery team to help with dev and get other devs back on track and unblocked.
preserving a good relationship with your client is all that matters in consulting so we'll gladly take a loss if it means maintaining a good relationship.
my current company ( a very large consulting firm ) will pull in people from top to bottom of the project org chart who specialize in getting things back on track. A team is dedicated to relationship management with the client to help them feel more comfortable about the situation, a team is dedicated to delivery management, and very good problem solvers are scattered throughout the delivery team to help with dev and get other devs back on track and unblocked.
preserving a good relationship with your client is all that matters in consulting so we'll gladly take a loss if it means maintaining a good relationship.
> Currently in a situation where our company is asking us to work weekends and extra hours because of a poorly managed project.
I'm not going to say you should never work extra hours but 9 times out of 10 this is a HUGE red flag. The company is responsible for managing timelines and setting priorities for what you should work on. I have occasionally put in a few extra hours (I'm talking <10 in a week) in a crunch period but never for more than 1 week in a row. Anything after 1 week starts to become the norm and that's not what I agreed to when I joined. Salarried does not mean they own you.
Weekends are 100% out of the question except for production emergencies (and if there is an emergency every weekend then no, there's not, don't be tricked into that BS). The business can decide to move the deadline or cut out some of the features but they can't decide to just get more hours from you for free (or rather they can but don't put up with that shit, find a better job).
I have a friend who was in this situation and he hadn't talked about it with anyone until he was nearly at his breaking point. He was telling us (we had met up for drinks) that he was working till 8-9pm if not later almost every day, every week and still feeling like he wasn't getting enough done. He was having regular breakdowns and crying at his desk. Sometimes you are in so deep you don't realize how absurd the requests from your company are and they were guilting him hard about it. This is someone I greatly respect and I would have never expected him to allow himself to be treated this way. We set him straight and told him to set boundaries, only work till 5pm, tell his boss to set the priority but he wouldn't be working overtime. He was in a contracting situation so his actual boss wasn't really involved in what the client was asking him to do but his boss was not a good boss and didn't help him out at all (meaningless platitudes were all he gave, he should have stepped in and set boundaries with the client). He set the boundaries, pulled himself back from the brink of despair, and started looking for a new job. He found one and he is much happier now.
Companies will take (and sometimes guilt you into) every hour they can get from you and rarely tell you to work less. Set boundaries and if they balk then start looking (though it sounds like you should start looking immediately no matter what).
I'm not going to say you should never work extra hours but 9 times out of 10 this is a HUGE red flag. The company is responsible for managing timelines and setting priorities for what you should work on. I have occasionally put in a few extra hours (I'm talking <10 in a week) in a crunch period but never for more than 1 week in a row. Anything after 1 week starts to become the norm and that's not what I agreed to when I joined. Salarried does not mean they own you.
Weekends are 100% out of the question except for production emergencies (and if there is an emergency every weekend then no, there's not, don't be tricked into that BS). The business can decide to move the deadline or cut out some of the features but they can't decide to just get more hours from you for free (or rather they can but don't put up with that shit, find a better job).
I have a friend who was in this situation and he hadn't talked about it with anyone until he was nearly at his breaking point. He was telling us (we had met up for drinks) that he was working till 8-9pm if not later almost every day, every week and still feeling like he wasn't getting enough done. He was having regular breakdowns and crying at his desk. Sometimes you are in so deep you don't realize how absurd the requests from your company are and they were guilting him hard about it. This is someone I greatly respect and I would have never expected him to allow himself to be treated this way. We set him straight and told him to set boundaries, only work till 5pm, tell his boss to set the priority but he wouldn't be working overtime. He was in a contracting situation so his actual boss wasn't really involved in what the client was asking him to do but his boss was not a good boss and didn't help him out at all (meaningless platitudes were all he gave, he should have stepped in and set boundaries with the client). He set the boundaries, pulled himself back from the brink of despair, and started looking for a new job. He found one and he is much happier now.
Companies will take (and sometimes guilt you into) every hour they can get from you and rarely tell you to work less. Set boundaries and if they balk then start looking (though it sounds like you should start looking immediately no matter what).
Is this typical, or atypical?
If it's typical (i.e., they're comfortable doing business this way) then yes it's time to move on.
If it's more or less a one-off and you believe your efforts will be rewarded eventually - and you're satisfied with the company and culture otherwise - then maybe it's worth staying.
In either case, guard your physical and mental health. In this regard, trust no one but yourself.
If it's typical (i.e., they're comfortable doing business this way) then yes it's time to move on.
If it's more or less a one-off and you believe your efforts will be rewarded eventually - and you're satisfied with the company and culture otherwise - then maybe it's worth staying.
In either case, guard your physical and mental health. In this regard, trust no one but yourself.
> In either case, guard your physical and mental health. In this regard, trust no one but yourself.
If people close to you tell you they get a stressed or exhausted read on you, absolutely trust them. Sometimes we are slow to realize these signs ourselves.
If people close to you tell you they get a stressed or exhausted read on you, absolutely trust them. Sometimes we are slow to realize these signs ourselves.
That's a good point. It's ultimately what I meant, but didn't properly say.
I should have said, "Trust no one at work but yourself."
Thanks for the save.
I should have said, "Trust no one at work but yourself."
Thanks for the save.
Dude, if I trusted myself I’d be so fucked.
> In either case, guard your physical and mental health. In this regard, trust no one but yourself.
This.
I have met people who did not protect/guard themselves. Some had gotten burned out after severe crunches and they needed very long breaks/vacations from writing software. Two that I knew of were still burned out 18 months after the crunch ended.
I don't mind putting out fires. It happens. I take offense when those fires are intentionally started by mismanagers.
The story of "EA Spouse" is not unique to the game industry. No place I have worked at has been quite that bad.
0 - https://web.archive.org/web/20061205035200/http://ea-spouse....
This.
I have met people who did not protect/guard themselves. Some had gotten burned out after severe crunches and they needed very long breaks/vacations from writing software. Two that I knew of were still burned out 18 months after the crunch ended.
I don't mind putting out fires. It happens. I take offense when those fires are intentionally started by mismanagers.
The story of "EA Spouse" is not unique to the game industry. No place I have worked at has been quite that bad.
0 - https://web.archive.org/web/20061205035200/http://ea-spouse....
Cut scope or move the deadline, whichever is most feasible.
Whipping the team is a great way to make them leave (like you want to, OP). My old workplace used to pay back overtime in paid leave, but it still didn't seem worth the stress.
It's up to management/leadership to have the hard convo with whoever you're delivering for to negotiate scope/deadlines.
Whipping the team is a great way to make them leave (like you want to, OP). My old workplace used to pay back overtime in paid leave, but it still didn't seem worth the stress.
It's up to management/leadership to have the hard convo with whoever you're delivering for to negotiate scope/deadlines.
The likelihood that this is their first project to overrun is quite low. Which mean they don’t learn from mistakes and it’s unlikely you can teach them. Pretend to work the extra hours but in reality look for a better job. I’ve done heroics before and lived to regret it every time. I’ve quit failing projects before and my only regret is not quitting them sooner.
If you actually succeed in saving the project they’ll reward themselves for their effective motivation.
I’ve had projects that managers refused to staff appropriately and tried to use my pride to work harder and prevent it from failing. I am prideful but there is a limit and they found it.
If you actually succeed in saving the project they’ll reward themselves for their effective motivation.
I’ve had projects that managers refused to staff appropriately and tried to use my pride to work harder and prevent it from failing. I am prideful but there is a limit and they found it.
Most western companies reduce the number of features to ship, or extend the deadline. They to some degree manage scope, risk and stakeholder expectations.
Only a seriously shit operation requires developers to “work weekends” or evenings in response to project incompetence. I would seriously recommend you look for employment elsewhere.
Only a seriously shit operation requires developers to “work weekends” or evenings in response to project incompetence. I would seriously recommend you look for employment elsewhere.
Dont be a hero. Dont encourage bad management. simply say it is stressfull. Also watch out for job postings that say exciting and aggressive schedule with fancy tpys.
Really one off situations are pretty common (once or twice a year). If the company is not making Money - they typically find themselves in this situation for a mad dash (usually results in poor engineering and poor outcomes).
Can you cut corners / steps to make code faster - sure - but if it fundamentally does not change the business / support structure of the company - it will always be the case.
Find another Job.
Really one off situations are pretty common (once or twice a year). If the company is not making Money - they typically find themselves in this situation for a mad dash (usually results in poor engineering and poor outcomes).
Can you cut corners / steps to make code faster - sure - but if it fundamentally does not change the business / support structure of the company - it will always be the case.
Find another Job.
As your https://en.wikipedia.org/wiki/Cone_of_Uncertainty gets increasingly confident, the key is to always think at least two steps ahead and take seriously what your estimates are, esp. long poles in the process.
I was an engineer for 20 years. Then an engineering manager for two years. And then I got hit with my first big project that was a month delayed due to dependencies we didn't anticipate.
The big learning there finally was always work backwards from your dates and ensure high confidence. If you're not high confidence in your date, you need to embed yourself with your dependencies and own the dependency outcomes until you can vouch for all of them (esp. your long poles, i.e., the dependencies that will take the longest or have the highest risk at particular stages in the project), ensure they are all high confidence.
There's no other way. Wisdom is knowing what to emphasize the next time in the planning or design phases.
When you're running late, the best thing you can do is begin that process and figure out what it really takes to get to a high confidence date (assuming no extra hours worked that risk burning out you, the team, etc.). Your stakeholders, if they accept a moved date, will want you to explain why you are high confidence for the new date given the trust you've lost for the previous date. You'll have to earn that trust back via repeated on-time delivery (or via raising the quality bar or providing other value to your stakeholders).
I was an engineer for 20 years. Then an engineering manager for two years. And then I got hit with my first big project that was a month delayed due to dependencies we didn't anticipate.
The big learning there finally was always work backwards from your dates and ensure high confidence. If you're not high confidence in your date, you need to embed yourself with your dependencies and own the dependency outcomes until you can vouch for all of them (esp. your long poles, i.e., the dependencies that will take the longest or have the highest risk at particular stages in the project), ensure they are all high confidence.
There's no other way. Wisdom is knowing what to emphasize the next time in the planning or design phases.
When you're running late, the best thing you can do is begin that process and figure out what it really takes to get to a high confidence date (assuming no extra hours worked that risk burning out you, the team, etc.). Your stakeholders, if they accept a moved date, will want you to explain why you are high confidence for the new date given the trust you've lost for the previous date. You'll have to earn that trust back via repeated on-time delivery (or via raising the quality bar or providing other value to your stakeholders).
If you don’t leave, your coworkers will leave before you. Then you will be put in charge of making newcomers do what your coworkers did, at half the pay and with half the experience.
Call in sick if needed. Move your resume around, leverage your network if you have it. Then leave.
Call in sick if needed. Move your resume around, leverage your network if you have it. Then leave.
What kind of company is it; startup? Is it a hard external deadline or self imposed?
At a startup for an externally imposed deadline (or otherwise some hard commitment) I would suck it up and retro and then decide based on the retro results.
For self-imposed deadlines where make or miss isn't directly under your or your small teams control I would not work too much personally.
Every single time I put in extra effort to hit internal deadlines that were ultimately outside my control I was burned. Every time.
At a startup for an externally imposed deadline (or otherwise some hard commitment) I would suck it up and retro and then decide based on the retro results.
For self-imposed deadlines where make or miss isn't directly under your or your small teams control I would not work too much personally.
Every single time I put in extra effort to hit internal deadlines that were ultimately outside my control I was burned. Every time.
We make random changes to tool use policies like "We're buying a lot of companies where the engineers don't know how to use TerraForm. We're changing our corporate standards to simplify our TF use so the following 15 statements aren't allowed in TF files anymore. This will also have the benefit of making deploys faster and therefore our total development time will go down because we can iterate faster."
I kid you not. This is something someone actually said.
I kid you not. This is something someone actually said.
A couple of questions to fill in the detail:
Are you in a management position? If not, there’s probably not much you can do at this point, nor is it your responsibility.
What kind of pressure is being put on you? Are expected to work inhumane hours to meet the deadline or what?
Are you in a management position? If not, there’s probably not much you can do at this point, nor is it your responsibility.
What kind of pressure is being put on you? Are expected to work inhumane hours to meet the deadline or what?
A healthy company will adjust one of the three axis. Lots of companies will act like their project is a make or break moment, but in reality it is management setting un-realistic deadlines. When the companies fall into the later category, if the developers decide to not play along management will threaten to, or actually will fire, not promote etc. the people dissenting against the craziness.
Unless the effort is well-circumscribed and short ("we will work an extra day the next three weekends"), congratulations, you are on a death march.
It is not going to change. We know that it's the worst possible way to run a project. We know long hours are actively damaging to cognitive capacity, introducing extra potential for errors and reducing overall output.
Well, OK, if you were in a position of power, it could change, because you could say "Nope. Not doing that". Short of that?
You can try convincing management that it's the worst possible idea, and they need to either cut scope or move the deadline. This will likely not work, because there's ego invested.
So... do look for that new job, just in case. And get out before you're completely burned out. (And if you can resist at all, make sure you limit your hours to something reasonable. You'll likely start excelling others by week 2)
It is not going to change. We know that it's the worst possible way to run a project. We know long hours are actively damaging to cognitive capacity, introducing extra potential for errors and reducing overall output.
Well, OK, if you were in a position of power, it could change, because you could say "Nope. Not doing that". Short of that?
You can try convincing management that it's the worst possible idea, and they need to either cut scope or move the deadline. This will likely not work, because there's ego invested.
So... do look for that new job, just in case. And get out before you're completely burned out. (And if you can resist at all, make sure you limit your hours to something reasonable. You'll likely start excelling others by week 2)
At my company, we don't have deadlines. We keep working on features, week after week. Once or twice a year, we cut a release.
Works pretty great.
PS Yeah, you should find a better job. They're out there!
Works pretty great.
PS Yeah, you should find a better job. They're out there!
Are you hiring?
What do you mean? Our company is a late running project. We just focus on moving ahead. When feeling demotivated, a quick look at others (cap/team size/burn rate/speed) always re-motivates. Funding is a non-issue, because we're legitimately doing a good job and it's legitimately hard and we're legitimately ahead.
I think 'projects' in big companies are often DOA because they lose the plot.
Don't get involved in partial problems, but always take flight to where there is a free view over the whole single great problem, even if this view is still not a clear one. - Wittgenstein
The major thing that we found was that you had to look at the whole problem. - Joseph Henry Condon, Bell Labs
... quotes via https://github.com/globalcitizen/taoup
I think 'projects' in big companies are often DOA because they lose the plot.
Don't get involved in partial problems, but always take flight to where there is a free view over the whole single great problem, even if this view is still not a clear one. - Wittgenstein
The major thing that we found was that you had to look at the whole problem. - Joseph Henry Condon, Bell Labs
... quotes via https://github.com/globalcitizen/taoup
First, we add more developers. When that doesn’t solve the problem, we re-assign people from other projects to the late one. When that doesn’t work, we negotiate with the client until they agree that what we can deliver is what they’d wanted all along.
I don’t see why we don’t skip straight to step 3, but meh.
I don’t see why we don’t skip straight to step 3, but meh.
> There were too many meetings and processes during the early months of the project
Those meetings and processes in the early months of the project? They should have informed both you (developers) and your management about the scope of the project, and how far along you are and how fast you are going.
Those meetings and processes in the early months of the project? They should have informed both you (developers) and your management about the scope of the project, and how far along you are and how fast you are going.
It really depends.
Was there some kind of thought-up end date? So what, it's running late.
Otherwise a common approach is to cut scope, deliver fewer features than initially planned.
If somebody asks you to work overtime, ask them how you'll be compensated. Factor 1.5 pay for overtime? An extra week of payed vacation? Get that in writing! If the expectation is to do it just to keep your job or "for the company", I'd say start looking for another job.
And no matter what, don't risk burnout. No amount of pay is worth that. If it's too much, either ignore the pressure, or if you cannot, quit immediately.
Was there some kind of thought-up end date? So what, it's running late.
Otherwise a common approach is to cut scope, deliver fewer features than initially planned.
If somebody asks you to work overtime, ask them how you'll be compensated. Factor 1.5 pay for overtime? An extra week of payed vacation? Get that in writing! If the expectation is to do it just to keep your job or "for the company", I'd say start looking for another job.
And no matter what, don't risk burnout. No amount of pay is worth that. If it's too much, either ignore the pressure, or if you cannot, quit immediately.
I do my best during working hours and if it fails it fails -- the actual source of the problem can take the blame
I'm in trading. There are no deadlines or late-running projects. Either the thing is going to be the present best thing to move us closer to more money or it is not. If it is not the best thing we could be doing right now we are going to drop it.
Historically, restarting a dropped project from scratch when necessary has led to better outcomes than sunk-cost-fallacy continuing.
We'll want to drop very few projects, but we can perform a rapid iteration cycle because of the feedback cycle. So almost anything can be derisked.
Historically, restarting a dropped project from scratch when necessary has led to better outcomes than sunk-cost-fallacy continuing.
We'll want to drop very few projects, but we can perform a rapid iteration cycle because of the feedback cycle. So almost anything can be derisked.
> How does your company handle late running projects?
The "founder" tells employees they suck, and that the company will go bankrupt if they don't move their ass to meet the deadline.
The "founder" tells employees they suck, and that the company will go bankrupt if they don't move their ass to meet the deadline.
Leave. Unless you really love the company. Then talk to you manager/anyone who has an impact on future projects about this, ask what the plan is to prevent this, and then leave.
Deadlines are typically not strict unless there is a contract in place. They can be moved. Asking people to put in some extra time once in a while is fine, even if not ideal, but not for extended periods of time. That leads to burnout and the company is valuing delivery over your health and your future ability to work for them.
Deadlines are typically not strict unless there is a contract in place. They can be moved. Asking people to put in some extra time once in a while is fine, even if not ideal, but not for extended periods of time. That leads to burnout and the company is valuing delivery over your health and your future ability to work for them.
This is the best piece of advice on this whole thread.
What executives say to employees:
<Nice English> "We are One team, we WILL get through this, teamwork makes the dream work etc."
<translation in plain English> "We will begin the death march to the bitter end".
What executives actually say behind closed doors:
"Well that shit didn't work. Do we let the idiot in charge have another swing at bat? Do we have an alternative lined up? No? I guess let him keep grinding the developers until they quit. Hey, how's your golf game?"
<Nice English> "We are One team, we WILL get through this, teamwork makes the dream work etc."
<translation in plain English> "We will begin the death march to the bitter end".
What executives actually say behind closed doors:
"Well that shit didn't work. Do we let the idiot in charge have another swing at bat? Do we have an alternative lined up? No? I guess let him keep grinding the developers until they quit. Hey, how's your golf game?"
Is this a one-off, or has it happened before?
If it’s happened before, who benefits from this structure? I’m guessing it’s not you (though you may find a way it could be).
If it hasn’t happened before, what’s different this time? Are more or different people or departments involved? What are their backgrounds and motivations?
All this is moot if you don’t have any influence to change either how things are done or how your contribution is perceived; in that case, use this as great fodder for interviews and get a pay bump in the process.
If it’s happened before, who benefits from this structure? I’m guessing it’s not you (though you may find a way it could be).
If it hasn’t happened before, what’s different this time? Are more or different people or departments involved? What are their backgrounds and motivations?
All this is moot if you don’t have any influence to change either how things are done or how your contribution is perceived; in that case, use this as great fodder for interviews and get a pay bump in the process.
My old company used to add more to scope and increase working hours/cancel holidays. in fact they always planned a release on thanksgiving because you know thats a good idea.
[deleted]
Failure to plan on your part does not make an emergency on my part. I have been part of too many projects where the people in control of the planning didn’t do their job or didn’t do it on time and they just expected those after them in the process to work hard to make up for their lack of work.
Joined a company that had been bought by a megacorp. for months would say we are launching on Monday. Code had dozens of SVN branches that hadn’t been merged in many months.
No original developers remained. Quit for many reasons.
Been a number of years. I wonder if they are still targeting Monday.
Been a number of years. I wonder if they are still targeting Monday.
In some other companies I've seen (not my own), step 1 is "Designate the scapegoat".
:-)
:-)
look for a new job or gather all the stakeholders, tell them that the way are pushing the team doesn't work at all, if you concede to work weekends nobody is going to reward you they maybe even be angry at you!
If you want to change the direction of the project and only if you want you because is a lot of work you should state your demands, negotiate a better compensation and only start after they put their money and compromise on the table, if not, you will get crushed and discarded and frankly is not worth it. My suggestion is that you shouldn't do a retrospective at the end of the project, you should stop it now, if they want to complete the project they should put skin on the game and not just pushing people to work harder.
If you want to change the direction of the project and only if you want you because is a lot of work you should state your demands, negotiate a better compensation and only start after they put their money and compromise on the table, if not, you will get crushed and discarded and frankly is not worth it. My suggestion is that you shouldn't do a retrospective at the end of the project, you should stop it now, if they want to complete the project they should put skin on the game and not just pushing people to work harder.
> My suggestion is that you shouldn't do a retrospective at the end of the project, you should stop it now
Very much this. In all likelihood, there won't be time for a retrospective because there will now be many prod bugs to squash, and probably another project or two that is already behind. Or if there is a retrospective, blame will be passed around and nothing will change.
Very much this. In all likelihood, there won't be time for a retrospective because there will now be many prod bugs to squash, and probably another project or two that is already behind. Or if there is a retrospective, blame will be passed around and nothing will change.
If the deadline was around a month or less and it wasn't insurmountable, work some weekends to get it past the finish line with meals provided and the understanding that every extra day worked was a free day off after the deadline. Now, if the deadline was further out and we were already in trouble then scope was reduced to something more manageable (I'm glad I didn't have to participate in those meetings). Where you should never be is at the end with an insurmountable amount of work left where everyone is working crazy hours with no end in sight. That's management fucking up, they should've seen it coming a lot earlier when you aren't meeting goals along the way.
I have been in this situation many times and just pressing developers is not going to work. In some rare cases adding more resources can help but usually only cutting scope and/or moving the deadline helps. Parkinson's law explains the meetings and pointless processes at the start; the first months it seems like there is a lot of time and there is no hurry to do anything. Then the actual underestimating (or overestimating as it may be) of it all will make the mess that you find yourselves in. If the management doesn't accept reality, you should find another job, because the team will break eventually as you can only do so many death marches.
Mostly delivering the inferior half baked product early and watching the customers burn.
If you can't change deadline as you learn, you have to control scope with an iron fist from the outset.
I've worked on projects where deadlines were revised each month based on new info, and effort/improvement was focused in gathering better info to inform an (ideally) increasingly accurate deadline confidence.
For fixed deadlines; scope, scope, scope. Cut the scope and take an honest look at why it is late ... start fixing those things with a smaller scope.
I'd never as a team to work overtime, and I work hard to ensure that situation never risks my teams jobs. If it comes to a crunch, the business failed their staff terribly.
I've worked on projects where deadlines were revised each month based on new info, and effort/improvement was focused in gathering better info to inform an (ideally) increasingly accurate deadline confidence.
For fixed deadlines; scope, scope, scope. Cut the scope and take an honest look at why it is late ... start fixing those things with a smaller scope.
I'd never as a team to work overtime, and I work hard to ensure that situation never risks my teams jobs. If it comes to a crunch, the business failed their staff terribly.
Just last week I had a meeting about a product that is late. Late by months, that is. But I just pointed out that there was another implementation that got in the way in lieu of Covid and so it's clear we need more time. Everybody zoned out, quickly shut their notepads and laptops and then someone said "OK then, see you next quarter"...
I do work for government tho' so I guess private sector would be less forgiven.
I also want to point out that that other implementation I mentioned was developed, pentested and shut down before production.
I do work for government tho' so I guess private sector would be less forgiven.
I also want to point out that that other implementation I mentioned was developed, pentested and shut down before production.
You mean... all projects?
Fire the people that did not meet the deadlines… :) just kidding. We basically re-organize on a frequent basis, re-define priorities and focus on the most essential items (and mvp) to be delivered first. Also, very importantly, we focus on iterations. Its better to have your teams work in a constant phase, and deliver increments, rather than a big bang. Small frequent increments allows you also to estimate the delivery date better.
I've been in a company when they asked us to work weekends. It didn't work out: the real reason for the delay was political (CTO dropped the entire backend because it wasn't in the language he liked) and they kept being late until the investors pulled the plug.
In other companies I've been at the cause was that the codebase was atrocious. Not much to do there if not to keep working as usual. Business kept pulling out resources though.
In other companies I've been at the cause was that the codebase was atrocious. Not much to do there if not to keep working as usual. Business kept pulling out resources though.
> CTO dropped the entire backend because it wasn't in the language he liked)
yeesh
yeesh
A wizard never ships late. We always ship at precisely the time we mean to. At least, that's how it is at the company where I work now.
I have worked at dysfunctional organizations like the one you describe. It's always a communication issue between different parties within the organization. Someone in sales works on a 6-month long quest to sign a new contract that will bring in the money to keep the lights on but it has delivery deadlines inked in that they lie to the team about and tell them the deadline is sooner in the hopes that even if they ship a little late it will still sail in under the contract deadlines. Nobody in the organization has explicitly worked out service objectives and written down the targets and goals so it's always implied that the system should be available 100% of the time resulting in the entire team being paged to handle every frustrated user request. There always several factors that contribute to dysfunction. It's never easy to fix.
If you don't have the political power, emotional energy, or see any possibility where your contributions could steer your organization away from repeating this scenario again, just move on. People are creatures of habit and changing habits takes time, energy, and discipline. But most of all it takes recognition: identifying and admitting that a particular set of behaviours is leading to this problem.
If you can do something about it and feel up to it, it's possible to turn that ship around if others are willing to join in. You have to be willing to step in front of the team, take responsibility, and be a leader. You may get less time for coding yourself and will be focusing on your communication skills and convincing others to join you. It's hard and it can turn an organization around.
At a prior company I worked at this is what I did, I became an engineering manager for a few years to do it, and it transformed the company and the engineers that worked for it. We went from a company that was constantly operating like the one you're describing: always fighting fires, hours of overtime, lost weekends, everyone frustrated. Within a year we hardly ever worked overtime. After another year we were responsibly sharing incidence response, had service objectives, and were shipping continuously. We even took on adapting the organization to take on compliance work in a regulated industry without adding undue stress. Some engineers that came to work with me had never worked on a healthy team before.
However I eventually came to the conclusion that management was too much stress for me and I went back to full-time engineering.
If that doesn't sound like something you want to work on: move on. Unless someone else steps in and does that work you will always be working overtime, being pinged at all hours of the day, wasting away weekends.
Update: clarifying the wizard statement: basically a healthy organization communicates openly and constantly. If we're close to a deadline we've set for ourselves and something isn't going right we talk about it. Often we will move the ship date because we prioritize quality higher than delivering at a particular time. Some times the ship date is important enough that we will scale back our scope and ship the missing parts after launch. But we always ship when we mean to.
I have worked at dysfunctional organizations like the one you describe. It's always a communication issue between different parties within the organization. Someone in sales works on a 6-month long quest to sign a new contract that will bring in the money to keep the lights on but it has delivery deadlines inked in that they lie to the team about and tell them the deadline is sooner in the hopes that even if they ship a little late it will still sail in under the contract deadlines. Nobody in the organization has explicitly worked out service objectives and written down the targets and goals so it's always implied that the system should be available 100% of the time resulting in the entire team being paged to handle every frustrated user request. There always several factors that contribute to dysfunction. It's never easy to fix.
If you don't have the political power, emotional energy, or see any possibility where your contributions could steer your organization away from repeating this scenario again, just move on. People are creatures of habit and changing habits takes time, energy, and discipline. But most of all it takes recognition: identifying and admitting that a particular set of behaviours is leading to this problem.
If you can do something about it and feel up to it, it's possible to turn that ship around if others are willing to join in. You have to be willing to step in front of the team, take responsibility, and be a leader. You may get less time for coding yourself and will be focusing on your communication skills and convincing others to join you. It's hard and it can turn an organization around.
At a prior company I worked at this is what I did, I became an engineering manager for a few years to do it, and it transformed the company and the engineers that worked for it. We went from a company that was constantly operating like the one you're describing: always fighting fires, hours of overtime, lost weekends, everyone frustrated. Within a year we hardly ever worked overtime. After another year we were responsibly sharing incidence response, had service objectives, and were shipping continuously. We even took on adapting the organization to take on compliance work in a regulated industry without adding undue stress. Some engineers that came to work with me had never worked on a healthy team before.
However I eventually came to the conclusion that management was too much stress for me and I went back to full-time engineering.
If that doesn't sound like something you want to work on: move on. Unless someone else steps in and does that work you will always be working overtime, being pinged at all hours of the day, wasting away weekends.
Update: clarifying the wizard statement: basically a healthy organization communicates openly and constantly. If we're close to a deadline we've set for ourselves and something isn't going right we talk about it. Often we will move the ship date because we prioritize quality higher than delivering at a particular time. Some times the ship date is important enough that we will scale back our scope and ship the missing parts after launch. But we always ship when we mean to.
[deleted]
> How does your company handle late running projects?
Extending deadlines to remain inside the timeframe.
In the long run renaming late delivery to 'common practice'.
Extending deadlines to remain inside the timeframe.
In the long run renaming late delivery to 'common practice'.
Here's what is likely to happen. You'll work nights and weekends to get this ugly baby over the line, if you are successful you'll have no meaningful change in compensation but the same is true if you don't deliver it on time.
The rewards have been nearly fully allocated into upper management caste over the past generation or so, but with no carrot they can't use the stick as much as they used to.
The rewards have been nearly fully allocated into upper management caste over the past generation or so, but with no carrot they can't use the stick as much as they used to.
> if you are successful you'll have no meaningful change in compensation
But the delivery time and efforts will become the new baseline standard.... to be exceeded in later project of course.
But the delivery time and efforts will become the new baseline standard.... to be exceeded in later project of course.
It will also be expected the next time a project falls behind and the calls of "but you managed to get it done last time" will then start. At that point it's time to move on.
Not just that, the next project will be just as tightly planned because last time it also ended up fine. And probably your project manager will get a nice bonus for getting things delivered so he can continue setting the example for others.
Exactly. It's a question of incentives. What pain does the management layer feel if developers keep pulling rabbits out of hats to get these badly resourced projects over the line? None whatsoever, only the rewards, so they'll do it again.
Sometimes, to save a piece of wood, the rot needs cutting out. Similarly, to improve an organisation, bad projects must be allowed to fail.
Sometimes, to save a piece of wood, the rot needs cutting out. Similarly, to improve an organisation, bad projects must be allowed to fail.
This sounds just like my husband! I say quit. Why waste your time. You think it won’t happen again and it will. But I also think he has only been asked to work one weekend one time. So it’s not too bad. I hope you are able to figure out what works for you.
Speak up about time management. You be the change.
Don't let your work identity interfere with your personal one; you are not your job/career—don't let it get to you. That said, put in whatever your terms of employment asks of you and negotiate overtime compensation if they're demanding more. You have just as much power as they do in these situations.
Let it fail. As a dev, they don’t have a lot of leverage over me, so deadlines are not my problem.
They could fire you, dock your pay or demote you
They could, but given that it'd just make the project later they probably won't.
People will always act like you HAVE TO show up and work overtime or weekends, but in reality it's a choice.
There may be some consequences, but most likely it'll just be that a manager pulls you into a room and has a talk.
I say stand your ground, have a backbone and live your life on your own terms.
People will always act like you HAVE TO show up and work overtime or weekends, but in reality it's a choice.
There may be some consequences, but most likely it'll just be that a manager pulls you into a room and has a talk.
I say stand your ground, have a backbone and live your life on your own terms.
And do what? Spend 3 months finding my replacement and 40 hours in interviews?
That will get the project done on time! /s
That will get the project done on time! /s
Have your team read this and know its a managment and not a team problem.
https://lucasfcosta.com/2022/09/15/deadlines.html
Yelling, threats, backstabbing, attrition, substance abuse.
We try to mostly follow the Shape Up methodology, ie shrinking scope and ship ”some version of the feature” that can fit the time budget.
Cut scope. You are on the exact definition of a death march. Your management must not be very experienced, this is a tale as old as time.
All the projects where I work are late so we've just learned to communicate with upper management about prioritization of work time.
Panic, blame, add lots of new people, sorry "developer resources". I believe Fred Brooks and something to say about this.
Get more funding. Adjust the expectations of stakeholders.
We do it the wrong way - add more teams/devs.
Fly into a blind panic, normally.
Before or after they fire me?
Is there any other kind?
badly
Don't destroy your mental/physical health for a shitty managed company, one time I had a project just like this, pushed it and it ended very badly - in a psychiatric hospital.
Find a new job and move on, take the good devs with you so you don't lose the synergy you built together. Tell them exactly why you're all leaving, perhaps next time they won't have so many damn meetings.
Most importantly - under no circumstances agree to work over 8 hours/day or weekends without them paying you double your usual rate. They must learn that shitty management has its price.
Find a new job and move on, take the good devs with you so you don't lose the synergy you built together. Tell them exactly why you're all leaving, perhaps next time they won't have so many damn meetings.
Most importantly - under no circumstances agree to work over 8 hours/day or weekends without them paying you double your usual rate. They must learn that shitty management has its price.
> Don't destroy your mental/physical health for a shitty managed company
Yes. Don't be me. I pushed myself too hard and got shingles* in my mid 30s, and activated my celiac disease (I've always had the celiac gene, but I find it quite the coincident that symptoms first showed up during this time) all within a 2 month timespan. A very stressful time, and it feels like those 2 months ruined my life, and it all happened so fast. Beware.
* Shingles was weird. Started with a weird feeling in deep deep tissue, then later a surface level rash with itchiness and numbness that comes and goes. There was one evening where the rash had flashes of extreme pain, just two or three times, and I came to realize why people with severe cases describe it as the most painful thing they've experienced. Fortunately, my case was mild and cleared on its own without much pain.
Yes. Don't be me. I pushed myself too hard and got shingles* in my mid 30s, and activated my celiac disease (I've always had the celiac gene, but I find it quite the coincident that symptoms first showed up during this time) all within a 2 month timespan. A very stressful time, and it feels like those 2 months ruined my life, and it all happened so fast. Beware.
* Shingles was weird. Started with a weird feeling in deep deep tissue, then later a surface level rash with itchiness and numbness that comes and goes. There was one evening where the rash had flashes of extreme pain, just two or three times, and I came to realize why people with severe cases describe it as the most painful thing they've experienced. Fortunately, my case was mild and cleared on its own without much pain.
I wonder how it compares with Hell's Itch / Suicide Itch. It can drive you mad. The cure for me was some Benadryl. Burning hot showers help for a few minutes too.
https://www.reddit.com/r/HellsItch/
https://www.reddit.com/r/HellsItch/
Glad you talked about it in detail and explained.Most folks dont share so you don't know until its too late.
Yes. Most painful thing ever. Inescapable pain.
> take the good devs with you
> Tell them exactly why you're all leaving
From many years in film and game development where crunch times were long and brutal, I totally understand (first hand, from experience) how bad this can get. I sympathize with the frustration.
However, be very very careful with these two bits of advice. The first one (taking people with you) is sometimes illegal, and even where it’s not, it will not be taken lightly, it could lead to legal and harsh retaliatory consequences that will not be pleasant.
The second one is also dangerous. Things you say when you leave can follow you out the door to your next job. You probably do not want your reference checks, or just people who know each other, to be spreading rumors that you’re combative and troubled regardless of the fact that poor management is at fault.
The better advice IMO is to find the better job and move on quietly. Trying to teach the company a lesson is very unlikely to work.
From many years in film and game development where crunch times were long and brutal, I totally understand (first hand, from experience) how bad this can get. I sympathize with the frustration.
However, be very very careful with these two bits of advice. The first one (taking people with you) is sometimes illegal, and even where it’s not, it will not be taken lightly, it could lead to legal and harsh retaliatory consequences that will not be pleasant.
The second one is also dangerous. Things you say when you leave can follow you out the door to your next job. You probably do not want your reference checks, or just people who know each other, to be spreading rumors that you’re combative and troubled regardless of the fact that poor management is at fault.
The better advice IMO is to find the better job and move on quietly. Trying to teach the company a lesson is very unlikely to work.
Trying to teach the company a lesson is very unlikely to work.
As an East Texas proverb states, “Don't try to teach a pig to sing, it will irritate the pig and frustrate you.”
As an East Texas proverb states, “Don't try to teach a pig to sing, it will irritate the pig and frustrate you.”
It's illegal to poach people (make them work for your company). It's not illegal to find a new job together with your friends.
But sure, being quiet about it is an option too - choose based on the situation. And indeed, err on the side of safety.
But sure, being quiet about it is an option too - choose based on the situation. And indeed, err on the side of safety.
> It's illegal to poach people (make them work for your company)
In most of the world (and where I live) it isn't, on the contrary having anti-poaching policies is illegal and resulted in a huge anti-competitive/wage-supression lawsuit:
https://knowledge.wharton.upenn.edu/article/silicon-valleys-...
https://www.classaction.org/blog/silicon-valley-antipoaching...
What's even more egregious is that a group of people leaving to start something better together is part of how silicon valley got started:
https://www.wikiwand.com/en/Traitorous_eight
In most of the world (and where I live) it isn't, on the contrary having anti-poaching policies is illegal and resulted in a huge anti-competitive/wage-supression lawsuit:
https://knowledge.wharton.upenn.edu/article/silicon-valleys-...
https://www.classaction.org/blog/silicon-valley-antipoaching...
What's even more egregious is that a group of people leaving to start something better together is part of how silicon valley got started:
https://www.wikiwand.com/en/Traitorous_eight
I was in the defendant class for one of these Silicon Valley film anti-poaching lawsuits. :) And I agree that companies, including the one I worked for, shouldn’t be able to agree to prevent hiring from each other. The main problem this caused was it made it harder for any individual to leave one company for another, with no poaching involved, and because of that (it was argued) it suppressed the general competitiveness and salaries of the employees.
Do keep in mind that this case (companies agreeing they won’t hire from each other) is a bit different from an angry employee leaving and soliciting some friends to go with him to a new company. Like I said, it might be perfectly legal, and yet still cause you serious trouble if you do it. Some people have ended up a lot more frustrated after leaving because of things they did on the way out. It can work out well if you’re really in a position to start your own company and fight like the Traitorous Eight, but for most devs who just want a job, making huge waves on exit is pretty dangerous. Don’t take my word for it though.
Do keep in mind that this case (companies agreeing they won’t hire from each other) is a bit different from an angry employee leaving and soliciting some friends to go with him to a new company. Like I said, it might be perfectly legal, and yet still cause you serious trouble if you do it. Some people have ended up a lot more frustrated after leaving because of things they did on the way out. It can work out well if you’re really in a position to start your own company and fight like the Traitorous Eight, but for most devs who just want a job, making huge waves on exit is pretty dangerous. Don’t take my word for it though.
I agree that it is normally wise to keep in mind the power disparity and interconnection between individuals and corporations. (And that not because something is legal you will have a good time)
> but for most devs who just want a job, making huge waves on exit is pretty dangerous
Yeah, it is easier (both in effort and in future prospects) to keep a low profile. Though I was focusing on legality/acceptability of poaching/leaving as a group.
> but for most devs who just want a job, making huge waves on exit is pretty dangerous
Yeah, it is easier (both in effort and in future prospects) to keep a low profile. Though I was focusing on legality/acceptability of poaching/leaving as a group.
Also is the word here really "illegal" or more like a breach of contract? I am not saying doing the opposite of what you signed is legal per-se, my point is that I am not sure if there are actual written laws saying you can't poach.
At least in my experience people agree to that, and it's usually when exiting a company, not when joining. As in "you agree not to initiate poaching up until 12 months after leaving the company".
At least in my experience people agree to that, and it's usually when exiting a company, not when joining. As in "you agree not to initiate poaching up until 12 months after leaving the company".
> As in "you agree not to initiate poaching up until 12 months after leaving the company".
Where I live that can be legal with the following caveat (same for non-compete):
- They have to pay you (a consideration) when signing such agreement
- It must be for a definite period of time. (Unsure about how much time is legal though)
- The only penalty for breach would be to return the consideration.
Where I live most non-competes/non-poaching agreements would be unenforceable since they don't meet the previous criteria. (Unenforceable clauses are normally refereed to as illegal though)
Where I live that can be legal with the following caveat (same for non-compete):
- They have to pay you (a consideration) when signing such agreement
- It must be for a definite period of time. (Unsure about how much time is legal though)
- The only penalty for breach would be to return the consideration.
Where I live most non-competes/non-poaching agreements would be unenforceable since they don't meet the previous criteria. (Unenforceable clauses are normally refereed to as illegal though)
Didn't know about that, thanks!
It doesn't really matter if it's illegal, they will retaliate. Have you done the thing you're advising this stranger to do ?
Yeah, many times. I'm always joining a new contract with at least some people from the previous ones. Never had anyone care in the slightest - it's not like the person would've stayed anyways. Why is it their business at all? The person doesn't belong to them.
I’m not certain but this sounds suspiciously different from what you suggested above. Joining a new job that just happens to have people from a previous one is completely different from soliciting co-workers to terminate their current contracts early, which is what you implicitly suggested above.
If the job is this bad, the other people are most likely going to be leaving too, all by themselves. I wouldn't be surprised if they activated their LinkedIn already. Asking them to go work together is nothing wrong.
It’s not safe to assume that is true from your employer’s perspective. You can assert your opinion, but acting on it can and does lead to real and severe consequences for some people. Be careful out there!
I could simply ask the people... At the project I talked about in my original comment we openly discussed looking for new contracts during the standup. Pretty hard to miss it for all sides.
But sure, be careful people.
But sure, be careful people.
> You probably do not want your reference checks
Does anyone even check references anymore in tech? My last two jobs haven't. The most current one didn't even ask for any. I figured that they realized that candidates won't list someone who will provide a bad reference, so it's a waste of time.
Does anyone even check references anymore in tech? My last two jobs haven't. The most current one didn't even ask for any. I figured that they realized that candidates won't list someone who will provide a bad reference, so it's a waste of time.
Employment and salary verification reference checks are common, I still receive them for ex employees of a small company started and sold years ago. It happened at my last few jobs in tech. BTW, they don’t have to ask you for any, all they have to do is call the company listed on your resume.
There are also informal “reference checks” though, where people who know each other talk about you, and even these are just one of many ways that your reputation can follow you. Leaving behind something very noteworthy like telling your bosses off and taking other employees with you is a good way to have people sharing stories about you.
There are also informal “reference checks” though, where people who know each other talk about you, and even these are just one of many ways that your reputation can follow you. Leaving behind something very noteworthy like telling your bosses off and taking other employees with you is a good way to have people sharing stories about you.
I hadn't had any references checked, much less even requested in probably a decade... that is, until my current job. So some do still do it, but apparently not many.
I'm curious to hear the story
Hi jjdeveloper, would you be interested in chatting for about 15 minutes? With a bit more context, I may be able to provide you with a bit useful advice that is relevant for your time. Send me a message if you are keen to chat.