At one company, we were required to send documentation packages in the invitation to review meetings. There was a formula dictating how soon the meeting could be held after the invite, in order to give the attendees time to read the documentation. The minimum was two days, and grew based on the size of the documentation.
This was to prevent people from sending out invites with a 300 page design document at 9am for a 1pm review. As had happened in the past. Many times. Management had freaked out about it, and rightly so. And so, rules were added to give people adequate time to prepare.
Not that it mattered.
The design reviews typically went like this:
Manager: "I didn't have time to read your design, just tell me what it's supposed to do"
Developer: "As described in the document, it rehydrates all datablades in the bijective manifold before modifying the extent so that the reflectconverter will instantiate the private association reference into the SS2 export stack in order to sent the XRNT data to subsystem SS2, by-"
Manager: "WHAT! All XRNT is confidential data, and SS2 is visible to the customer! You know this. These is completely unacceptable. Why are you doing this?"
Developer: "To meet requirement SS2-INTF-3212: 'The SS1 subsystem shall send XRNT data to the SS2 system every 12 seconds via a TCP/IP interface.'"
Manager: "This is a horrible requirement! You should not have implemented this requirement without checking with management first"
Developer: "I told you about it five months ago. Here's the email"
Manager: "I do not have time to read emails. You should held a design meeting for this issue"
Developer: "I did. Here's the meeting invitation. The PM and I attended it. You declined at the last minute. The PM approved the requirement. Here are the meeting minutes"
Manager: "This still violates SS1 security. You should not have proceeded without approval"
Developer: "The PM doesn't care about SS1 security, and he approved the design"
Manager: "That is the PM position, not the SS1 group position. You should have raised it to SS1 management"
Developer: "I did. Here's another meeting I called with you to discuss it. You declined that meeting as well. You added a note saying that a developer's job is to implement approved designs, not question them, and I should implement it. So, I did."
I'd say that at least 75% of my design reviews in that company ended up with the management either (a) rejecting the approved requirements, or (b) rejecting that base product functionality that projects were based on. In other words, things that were outside the control of the developer, and had nothing to do with the design being reviewed.
It was honestly amazing. I've never been in a company where the *reviewers* got action items and the developer didn't.
Of course, the company metrics didn't have a state condition for "requirements rejected" as a legitimate reason for rejecting a design, so their metrics were all over the place.
Naturally, this was not seen as a failure of management, but of engineering. Senior management did start an investigation, but they were unable to determine why so many problems were being found so late in the development process.
No developers were interviewed in the investigation, of course.
From what my moles in the company say, things haven't changed, and management still can't understand why they keep losing money...
Moral of the story: GPT prepare a 20 slide presentation with boring first 2 slides and impactful 2 trailing slides. Do whatever the hell you want with the remainder of the presentation.
Wow, you had as much as 20 mins😂😂😂Some of us get less than 5 mins to present something we've been working on for months.
great one!
Oof. 🔥
And that's why I … [CENSORED] him, your honor. 😈
At one company, we were required to send documentation packages in the invitation to review meetings. There was a formula dictating how soon the meeting could be held after the invite, in order to give the attendees time to read the documentation. The minimum was two days, and grew based on the size of the documentation.
This was to prevent people from sending out invites with a 300 page design document at 9am for a 1pm review. As had happened in the past. Many times. Management had freaked out about it, and rightly so. And so, rules were added to give people adequate time to prepare.
Not that it mattered.
The design reviews typically went like this:
Manager: "I didn't have time to read your design, just tell me what it's supposed to do"
Developer: "As described in the document, it rehydrates all datablades in the bijective manifold before modifying the extent so that the reflectconverter will instantiate the private association reference into the SS2 export stack in order to sent the XRNT data to subsystem SS2, by-"
Manager: "WHAT! All XRNT is confidential data, and SS2 is visible to the customer! You know this. These is completely unacceptable. Why are you doing this?"
Developer: "To meet requirement SS2-INTF-3212: 'The SS1 subsystem shall send XRNT data to the SS2 system every 12 seconds via a TCP/IP interface.'"
Manager: "This is a horrible requirement! You should not have implemented this requirement without checking with management first"
Developer: "I told you about it five months ago. Here's the email"
Manager: "I do not have time to read emails. You should held a design meeting for this issue"
Developer: "I did. Here's the meeting invitation. The PM and I attended it. You declined at the last minute. The PM approved the requirement. Here are the meeting minutes"
Manager: "This still violates SS1 security. You should not have proceeded without approval"
Developer: "The PM doesn't care about SS1 security, and he approved the design"
Manager: "That is the PM position, not the SS1 group position. You should have raised it to SS1 management"
Developer: "I did. Here's another meeting I called with you to discuss it. You declined that meeting as well. You added a note saying that a developer's job is to implement approved designs, not question them, and I should implement it. So, I did."
I'd say that at least 75% of my design reviews in that company ended up with the management either (a) rejecting the approved requirements, or (b) rejecting that base product functionality that projects were based on. In other words, things that were outside the control of the developer, and had nothing to do with the design being reviewed.
It was honestly amazing. I've never been in a company where the *reviewers* got action items and the developer didn't.
Of course, the company metrics didn't have a state condition for "requirements rejected" as a legitimate reason for rejecting a design, so their metrics were all over the place.
Naturally, this was not seen as a failure of management, but of engineering. Senior management did start an investigation, but they were unable to determine why so many problems were being found so late in the development process.
No developers were interviewed in the investigation, of course.
From what my moles in the company say, things haven't changed, and management still can't understand why they keep losing money...
Moral of the story: GPT prepare a 20 slide presentation with boring first 2 slides and impactful 2 trailing slides. Do whatever the hell you want with the remainder of the presentation.