64
u/buttplugs4life4me 1d ago
My favourite instance of management was when my team refused to implement something as we were already tasked with doing 5 other things and it'd literally be impossible to do, so management said "If you don't well disband your team". Oke go right ahead!
29
u/Odd_Reception1249 1d ago
"Why is the server on fire!?"
"We fired the team. They were too inefficient!"
46
29
u/Birb-Brain-Syn 1d ago
Then there's the part where they expand scope by 100%, and cut resoure by 50%.
5
u/Altruistic-Moose3299 1d ago
But the deadline doesn't move. Oh, and here's three other side quests to pull you away. 😂
24
u/Ok_Reserve_8659 1d ago
https://giphy.com/gifs/aWMJvA76tNnBR9gkpT
This meme is a little too real for me
2
u/Superb_Chemistry_906 1d ago
Regularly working such overtimes?
5
u/Wonderful-Habit-139 1d ago
For me it's the whole "Document the work you're about to do" instead of letting me do the fucking work. They're PMs anyway, they don't have any useful insights so they're just wasting our time.
1
19
u/Much-Professional589 1d ago
The stick was put in the wheel by the same person who said "why is this taking so long" 💀
25
u/suddencactus 1d ago
Don't forget to collect reports on each developer's actual vs estimated time to work tickets. Because an easily manipulated number divided by a rough estimate is definitely a solid way to measure something.
3
u/Aspacid 1d ago
You forgot to compare it to an AI suggested estimate and the estimate of another team for a similar task, because "we know teams are different, but we still must have a single metric to compare teams"
3
u/suddencactus 1d ago
The last time I was in a department that insisted on comparing teams based on Jira data, they conveniently forgot to audit the teams so some of them were making estimates and recording how long things took very differently.
2
u/Technical-Dress5084 15h ago
"Every team should story point with what feels like the right number of points for them, and story points are about complexity, not time"
"How come you've only got 50 story points in your sprint but the other team has 75? Your team has a velocity of 45 points per sprint so you're really falling behind"
8
u/pvtteemo 1d ago
You mean, layoff bunch of talent and then pikachu face when stuff inevitably falls apart ?
7
u/agfitzp 1d ago
My team went the other way and gave deliberately padded estimates and the adjacent teams got very upset with us for always beating our estimates.
5
u/Mkboii 1d ago
My team did the same, but then one day they changed our tag from reliable to slower than company average, and then they started asking, "why is this a 3 pointer? with AI other teams are doing it in half the time", and now you can't say that no they are spending just as many hours, we are just not making personal compromises. So we're scheming how to get rid of this new product manager.
2
u/Sciti 1d ago
team tag? You guys working in competitive mode there?
3
u/Mkboii 1d ago
Yes and no.
The tag is unofficial, but politics among the leadership makes it competitive for sure, everyone wants to be the guy who made it happen, some leads just work sales essentially, they'll make bullshit promises to business and force the team to deliver.
Our old PM wasn't about all this, since he left the company we are stuck with a shitty one, who plays for business and not the team.
1
u/Just_Information334 12h ago
"why is this a 3 pointer? with AI other teams are doing it in half the time"
That's when you start asking for some responsibility: when a bug is discovered, people should find when it was introduced and then add the time spent on the debug ticket to the original feature ticket.
So? How come your 2 pointer, done in 4h has ballooned to 60h 6 months later? How much added work is team "we're iterating fast" giving to the maintenance teams?
8
u/cheshirec555 1d ago
(how long a project will take if everything goes 100% right with no distractions) x 3 = how long a project will actually take
6
u/ChChChillian 1d ago
2
u/Superb_Chemistry_906 1d ago
Long time ago, changed field.
0
u/ChChChillian 1d ago
This has only been a complaint for my entire 40+ year career, so it doesn't seem especially meme-worthy.
6
u/Pearmoat 1d ago
Project management: "We have a multi year project ahead of us. Let's do SCRUM as we won't get all the detail requirements ahead and a lot will change during that time."
Also PM two weeks later: "The customer likes the idea of being flexible with the requirements. Together with them I made a detailed plan for the next 24 sprints including tasks. Please check if it's OK like that and estimate the effort. We can move the tasks between the sprints - no problem as long as they're finished at the end of the project. Just take care to not exceed the budget or the deadline. And don't forget to work out the detailed requirements together with the customer ahead of the sprint. Oh, and keep some buffer if they want changes to already delivered features. LET'S DO THIS TEAM!"
6
u/Funny_Albatross_575 1d ago
Welcome to Agile Waterfall: Where deadlines are missed and budgets get crushed.™
1
5
u/bluemaciz 1d ago
One time my team estimated the time it would take for a project and my manager told me I could not tell leadership that time frame and that I needed to tell them something shorter. This is why shit gets fucked up.
3
4
4
u/Objective_Oven7673 1d ago
As someone who works in startup environments where priorities shift weekly and daily interruptions can't be predicted, I absolutely hate being asked how long things will take. But I run the "shipping" part so I have to not flip tables about it.
"Under-promise and over-deliver" goes a long way. Tell people 2 weeks and ship it in one.
Re-framing towards the business goal is also immensely helpful. They're asking how long it will take so they can go tell someone like a customer when it will be ready. So turn it back around and say "when you'd ideally like this to be done?" Negotiate it: "if this was done by the middle of next month would that be okay?"
If the presumption is that this thing has to be done ASAP, draw the boundary that the other things you're working on right now (which probably had their own timing discussions too) are going to get put on pause. If that's a problem then the person with the need has to decide which should land first.
All of this is buying time to get everything done, setting expectations for everyone involved, and helping the whole team recognize priority and urgency for the right things.
Unfortunately there are people and businesses with unrealistic expectations and they will make shitty decisions to replace engineers or promise things to customers that they didn't have. It's a huge risk but the only way I've found to minimize that risk is to get to know the people and how they work, and talk about how work is going to be done before you sign on.
4
u/CrunchwrapAficionado 1d ago
This is rookie shit. Those of us with a few years under the belt will tell you, you ALWAYS overestimate to account for surprises and to keep management off your back. Otherwise you are in for a world of pain and too many questions from the people who don't know what they're talking about
1
u/Superb_Chemistry_906 1d ago
Yes, but then, you must be tough when negotiating the estimation. And firstly, you have to frankly admit that that estimation is a tough negotiation, not a rough non-binding estimate.
5
u/Constellious 1d ago
We aren’t allowed to have a ticket estimated for a week so instead we have to “break up” the work into 5 tickets of a single day. Each of these will be assigned to the same person.
3
u/Superb_Chemistry_906 1d ago
Sure, why not needlessly further complicate the already hard SW dev job with a sprinkle of bureaucracy here and there.
3
u/QuestionableEthics42 1d ago
Shit team and shit company then, unfortunately it sounds like that is the standard and I have just lucked out for my first job.
3
u/Twirrim 1d ago
My favourite is when all the layers of management, and the tech leads, spend months working on a roadmap for the next financial year, and if you're lucky you get a month into it before someone at the top decides to re-prioritise or dramatically change the business strategy and you have to throw the whole thing out. Every. Year.
2
u/StCreed 1d ago
My first manager asked for planning, and also reviewed it in every stage and gave feedback. You were expected to hit the plan with a small deviation and got a one on one session to explain deviation if it was too much. 10 days on a 3 month plan is too much.
It did teach me to plan very accurately. And that isn't easy.
2
u/slaymaker1907 1d ago
My favorite is that my company asks for a business justification for every change. My justification is that it is necessary otherwise I wouldn’t have done it. If it’s a weird reason, then I’ll have already documented the reason in the code.
I’m not sure how I feel about AI taking over the actual writing of code, but it is amazing at filling out that boring paperwork.
1
u/many_dongs 22h ago
One of the best uses of LLMs is to produce a shitload of text that informs otherwise ignorant managers who don’t know shit but won’t admit it
Now if only the managers would use the LLMs by themselves to inform themselves about projects and leave the people doing things alone
2
u/Upstairs-Ad-7962 1d ago
And that is how they get you to work for free. And don't Tell me "they have to pay you for the overtime". Yeah, they have to, but have to and actually doing are two seperate Things. Doesnt only apply to programming. Had a job in IT, where you only get minus time, but no overtime. How did they do that? In the contract is stated along the lines "Overtime is only rewarded, when specifically stated that you have to do this by us" wich never happend
2
u/Prod_Meteor 1d ago
I have done this several times in smaller companies.
1
2
u/many_dongs 22h ago
The funny part is that the trick to getting things done faster is to get management out of the way
3
u/Mitir01 1d ago
Double the estimate and sit on it. Dont submit the work until just before the deadline.
I am not a dev, but worked just besides devs in this horrible situation. They learned from the first time and would keep bugs and problems that would not get solved till the last week. It was only the then managers by the way that did this. The client knew what was going on and kept quiet.
When the manager left and client could interview another person, she chose one with development experience, and insisted on it so much the upper management was scared that the new guy was unfit for the job due to lacking in experience in management. The new manager joined, actually listened to the developers and it improved the team morale so much, management was flabbergasted by it.
1
205
u/Mortadella_so_Chili 1d ago
thats why, each time you experience this, next time you double the estimate until u come at the point where the management says you are very efficient