Ask HN: How does your company handle late running projects?

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.

You mean... all projects?

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.

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.

Mostly delivering the inferior half baked product early and watching the customers burn.

> 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.

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?

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.

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.

> 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'.

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.

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.

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.

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.

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.

We do it the wrong way - add more teams/devs.

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.

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!

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.

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.

Panic, blame, add lots of new people, sorry "developer resources". I believe Fred Brooks and something to say about this.

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.

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.

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.