The best part is when you fail to make the one day deadline (as do all of the other subsystems), and it gets pushed back a day, the PM then adds another week's worth of tasks to the list.
I worked on a project where management rejected engineering's plan to do 8 releases over 3 years, because "releases have a high associated cost" and "you shouldn't need more than 4 releases".
Time it took to do all the release paperwork and associated process: roughly 3 days, depending on which group you were int.
Number of actual releases in the first year because PM declared an urgent fix was needed in the field: 37.
Standard number of work days per year: 252
Number of days doing paperwork for releases that year: 111
My director thought I was kidding when I said that the project team spent 45% of the entire year doing nothing but release paperwork, until he looked at the release history.
Read the autobiography of Thomas J Watson, the founder of IBM. He made a point of walking through his shop floor every day as he left work and chatting with one of the employees. They wouldn't know who he was, so they'd speak openly about the real problems. He learned which of his executives were reporting things honestly, and which were hiding things.
I've challenged executives to walk through the shop floor and they've been absolutely flabbergasted at what they saw, because it completely contradicted everything they'd been told by the staff that reported to them. Others who made a point of going though the shop floor every couple of weeks had a much better idea of what was really happening.
And, of course, if what you see with your own eyes doesn't match what's being reported, people need to explain why what they've reported doesn't match reality.
When an executive asked why X took so long, we'd list the problem as Y holding things up, and management would interject that no, Y wasn't a problem, Y only took "5 or 10 minutes", it was the engineers that were at fault.
I'd then challenge the executive to sit down and see for himself, surely he could spare "5 or 10 minutes", couldn't he?
And so he or she would sit down. Often the manager would be right next to us. What followed was invariably a sequence of:
- That doesn't look right...
- Why is this so *slow*?
- What, what? I've never seen this screen
- Why is it asking that? I've never been asked that.
Etc., etc.
Eventually, the exec or manager would finally react with an "OH, COME ON" to the system's behaviour, proving our point. Sometimes it was an hour into the "5 or 10 minute" processor, sometimes longer. Once, an exec left at the two hour mark, but had his assistant sit with me and take notes of all the issues. It took us two days, and he had something like 14 pages of notes listing over 80 obstacles. This was a process that management had assured the executives that it was "flawless" and "only 5 to 10 minutes". And when they then claimed ignorance of the 80 issues the assistant found, we produced hundreds of emails, meeting minutes, status reports, SpeakUps, etc. reporting the problems over and over and over again.
Good managers (and there are some) take actions to correct the issue. Bad managers (there are more of those) will either create yet another group to study the problem and do nothing, or simply kick the problem back to the people who'd been ignoring (or hiding) the problems, and nothing gets fixed.
I once worked in a group where the developers were using 8 year old "value" PCs. Engineer's children had more powerful computers in their second grade classrooms than their parents had at work. When the executive asked me how long this had been going on, I asked him how long he thought we'd been using 8 year old computers. Did he think we'd had 2 year old computers and then replaced them with older tech?
Obviously, the problem had been going on for a decade. And obviously, that meant that management had either allowed it, or been unaware of it, all that time. For that to happen, upper management has to be completely blind to how their company is being run.
I had a PM who wanted to discuss the status of projects daily. I also had to account for my time. He once asked why I was putting so much time in "status meetings." I had to point out to him that it was all him; he could go with fewer meetings or meet for less time. He didn't get it.
At one company, people booked 12pm-1pm for lunch, because if they didn't, it would be filled with meetings.
Managers *still* booked meetings for 12pm-1pm, because "that's the only time people are available". Wait, didn't the system tell you that people were already booked in that time slot? "Yes, but I know it's just for lunch, they don't really have a meeting then". So the time slot was booked, and you booked the meeting then anyway...
Feed her an alarm clock so you can hear her coming. ⏰ Tick. Tock.
tinker bell of the office socialization and politics
The best part is when you fail to make the one day deadline (as do all of the other subsystems), and it gets pushed back a day, the PM then adds another week's worth of tasks to the list.
I worked on a project where management rejected engineering's plan to do 8 releases over 3 years, because "releases have a high associated cost" and "you shouldn't need more than 4 releases".
Time it took to do all the release paperwork and associated process: roughly 3 days, depending on which group you were int.
Number of actual releases in the first year because PM declared an urgent fix was needed in the field: 37.
Standard number of work days per year: 252
Number of days doing paperwork for releases that year: 111
My director thought I was kidding when I said that the project team spent 45% of the entire year doing nothing but release paperwork, until he looked at the release history.
If i ever run a company i just need to read the comments to figure out how to avoid being a dumb manager or c suite
Read the autobiography of Thomas J Watson, the founder of IBM. He made a point of walking through his shop floor every day as he left work and chatting with one of the employees. They wouldn't know who he was, so they'd speak openly about the real problems. He learned which of his executives were reporting things honestly, and which were hiding things.
I've challenged executives to walk through the shop floor and they've been absolutely flabbergasted at what they saw, because it completely contradicted everything they'd been told by the staff that reported to them. Others who made a point of going though the shop floor every couple of weeks had a much better idea of what was really happening.
And, of course, if what you see with your own eyes doesn't match what's being reported, people need to explain why what they've reported doesn't match reality.
Absolutely agree! It is amazing how often this happens
I used to call this the "Oh Come On" value.
When an executive asked why X took so long, we'd list the problem as Y holding things up, and management would interject that no, Y wasn't a problem, Y only took "5 or 10 minutes", it was the engineers that were at fault.
I'd then challenge the executive to sit down and see for himself, surely he could spare "5 or 10 minutes", couldn't he?
And so he or she would sit down. Often the manager would be right next to us. What followed was invariably a sequence of:
- That doesn't look right...
- Why is this so *slow*?
- What, what? I've never seen this screen
- Why is it asking that? I've never been asked that.
Etc., etc.
Eventually, the exec or manager would finally react with an "OH, COME ON" to the system's behaviour, proving our point. Sometimes it was an hour into the "5 or 10 minute" processor, sometimes longer. Once, an exec left at the two hour mark, but had his assistant sit with me and take notes of all the issues. It took us two days, and he had something like 14 pages of notes listing over 80 obstacles. This was a process that management had assured the executives that it was "flawless" and "only 5 to 10 minutes". And when they then claimed ignorance of the 80 issues the assistant found, we produced hundreds of emails, meeting minutes, status reports, SpeakUps, etc. reporting the problems over and over and over again.
Good managers (and there are some) take actions to correct the issue. Bad managers (there are more of those) will either create yet another group to study the problem and do nothing, or simply kick the problem back to the people who'd been ignoring (or hiding) the problems, and nothing gets fixed.
I once worked in a group where the developers were using 8 year old "value" PCs. Engineer's children had more powerful computers in their second grade classrooms than their parents had at work. When the executive asked me how long this had been going on, I asked him how long he thought we'd been using 8 year old computers. Did he think we'd had 2 year old computers and then replaced them with older tech?
Obviously, the problem had been going on for a decade. And obviously, that meant that management had either allowed it, or been unaware of it, all that time. For that to happen, upper management has to be completely blind to how their company is being run.
I had a PM who wanted to discuss the status of projects daily. I also had to account for my time. He once asked why I was putting so much time in "status meetings." I had to point out to him that it was all him; he could go with fewer meetings or meet for less time. He didn't get it.
There goes you, confusing the manager with complex if then statements.
I used to book a fake meeting in one of the conference rooms to get some peace and quiet.
At one company, people booked 12pm-1pm for lunch, because if they didn't, it would be filled with meetings.
Managers *still* booked meetings for 12pm-1pm, because "that's the only time people are available". Wait, didn't the system tell you that people were already booked in that time slot? "Yes, but I know it's just for lunch, they don't really have a meeting then". So the time slot was booked, and you booked the meeting then anyway...
Relatable.