by jjdeveloper on 9/20/22, 1:03 PM with 172 comments
by retrac98 on 9/20/22, 1:31 PM
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.
by noodlesUK on 9/20/22, 2:52 PM
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.
by neilv on 9/20/22, 4:58 PM
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.)
by dahart on 9/20/22, 2:41 PM
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.
by sokoloff on 9/20/22, 2:21 PM
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.
by chrisoconnell on 9/20/22, 4:02 PM
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.
by yshrestha on 9/21/22, 2:04 AM
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.
by ChrisMarshallNY on 9/20/22, 9:20 PM
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.
by PascLeRasc on 9/20/22, 4:27 PM
by yamtaddle on 9/20/22, 2:49 PM
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.
by professorTuring on 9/21/22, 1:06 AM
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!
by arriu on 9/21/22, 2:49 AM
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
by octokatt on 9/20/22, 6:58 PM
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.
by SMAAART on 9/20/22, 2:59 PM
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.
by coldcode on 9/20/22, 2:20 PM
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.
by cweagans on 9/20/22, 5:15 PM
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?
by chasd00 on 9/20/22, 2:27 PM
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.
by joshstrange on 9/20/22, 4:19 PM
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).
by chiefalchemist on 9/20/22, 1:49 PM
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.
by rukuu001 on 9/21/22, 3:04 AM
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.
by cjbgkagh on 9/20/22, 3:07 PM
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.
by aryehof on 9/21/22, 4:30 AM
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.
by Terrible on 9/20/22, 4:05 PM
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.
by tmsh on 9/20/22, 11:00 PM
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).
by otikik on 9/20/22, 9:17 PM
Call in sick if needed. Move your resume around, leverage your network if you have it. Then leave.
by Rapzid on 9/21/22, 12:06 AM
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.
by dingosity on 9/20/22, 4:38 PM
I kid you not. This is something someone actually said.
by vlunkr on 9/20/22, 1:42 PM
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?
by lgleason on 9/20/22, 11:09 PM
by groby_b on 9/20/22, 2:58 PM
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)
by BurningFrog on 9/20/22, 2:36 PM
Works pretty great.
PS Yeah, you should find a better job. They're out there!
by contingencies on 9/20/22, 3:14 PM
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
by Aeolun on 9/20/22, 3:53 PM
I don’t see why we don’t skip straight to step 3, but meh.
by azangru on 9/20/22, 1:41 PM
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.
by perlgeek on 9/20/22, 1:33 PM
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.
by zepppotemkin on 9/20/22, 11:31 PM
by renewiltord on 9/21/22, 1:55 AM
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.
by yodsanklai on 9/20/22, 10:05 PM
The "founder" tells employees they suck, and that the company will go bankrupt if they don't move their ass to meet the deadline.
by Taylor_OD on 9/20/22, 4:59 PM
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.
by rawgabbit on 9/21/22, 4:39 AM
<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?"
by Arubis on 9/20/22, 3:02 PM
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.
by lovetocode on 9/20/22, 2:19 PM
by lasereyes136 on 9/21/22, 4:57 PM
by treeman79 on 9/21/22, 1:11 AM
Been a number of years. I wonder if they are still targeting Monday.
by dwheeler on 9/20/22, 10:49 PM
:-)
by chudi on 9/20/22, 4:39 PM
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.
by MonkeyMalarky on 9/20/22, 4:07 PM
by tluyben2 on 9/20/22, 2:05 PM
by gw99 on 9/20/22, 1:40 PM
by sirsinsalot on 9/20/22, 2:40 PM
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.
by pelagicAustral on 9/20/22, 2:37 PM
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.
by chadlavi on 9/20/22, 1:29 PM
by s-xyz on 9/20/22, 10:44 PM
by jokethrowaway on 9/20/22, 7:07 PM
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.
by agentultra on 9/20/22, 2:34 PM
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.
by mihaaly on 9/20/22, 2:01 PM
Extending deadlines to remain inside the timeframe.
In the long run renaming late delivery to 'common practice'.
by willcipriano on 9/20/22, 1:54 PM
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.
by jazzyfizzle on 9/21/22, 4:51 AM
by asow92 on 9/20/22, 5:14 PM
by throwawaysleep on 9/20/22, 4:43 PM
by adave on 9/20/22, 3:07 PM
by itisit on 9/21/22, 4:16 AM
by aloukissas on 9/20/22, 6:45 PM
by remote_phone on 9/20/22, 4:50 PM
by adamdusty on 9/20/22, 2:57 PM
by shaftoe444 on 9/20/22, 2:41 PM
by unixhero on 9/20/22, 3:41 PM
by giantg2 on 9/20/22, 2:31 PM
by tommykins on 9/20/22, 11:23 PM
by sys_64738 on 9/20/22, 3:59 PM
by commandlinefan on 9/20/22, 2:53 PM
by KaiserPro on 9/20/22, 3:52 PM
by WHATDOESIT on 9/20/22, 1:14 PM
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.
by hmcamp on 9/20/22, 4:03 PM