I once had a manager complain that I was being "too easy" on my team, because out of 8 teams, they were the only one that weren't charging overtime.
There were also complaints from the other 7 teams that we weren't being co-operative.
And so, I was called into a meeting with the manager, our director, and HR to discuss it.
Why, the manager asked, wasn't my team working overtime when everyone else was?
Because, I explained, my team made all our deadlines. Unlike the other 7 teams, I added.
The director checked, and yes, my team not only wasn't over budget due to overtime charges, we were the only one to make our dates.
Fine, HR said, but other groups are complaining you're not working with them.
Yes we are, I said. What we're not doing is dropping everything at the drop of a hat to work on unscheduled, unplanned work. When other teams ask for something, we ask them for a requirements definition, on paper, and then we're happy to work on it.
The manager's comment that we don't have time to write proper requirements, and if something is wrong, we just have to rework it didn't sit well with the director. Nor did the comment that every other team was ignoring process and basically winging it.
Admitting that other teams were working 18 hour days because they weren't following process was not the mic drop that the manager thought it was. I mean, it was, but not against me or my team.
And of course there’s the various tree + swing pictures of what everyone thought was wanted! The director was correct that not having requirements was a big no-no!
As a contractor, I wasn't amazed to see teams running around like chickens with their heads cut off. It's like firemen not being surprised to see buildings on fire. What did amaze me what their rationalizations for it.
Management excuses I've actually heard include:
- "Our product is too complex to have requirements"
- "We're too far ahead of the industry for CMMI process to apply to us"
- "Well, we didn't actually run the process, but there's no reason it wouldn't work"
- "Just because nothing's written down doesn't mean there's not a design"
When auditors failed one company, pointing out the HUGE disconnect between the shipping product and what passed for requirements (mismatched, incomplete, and contradictory as they were), the lead architect was told to draft a response. His formal response was:
"Auditors need to understand that the requirements aren't necessarily the best way to understand what the system does".
At one company when a customer "event" mandated that external auditors review them, senior management confidently told the auditors that they estimated their requirements compliance level was "somewhere between 85% and 90%, easy".
The actual number was 6%. That's not a typo. Six per cent.
A large portion of the staff not only didn't know the formal requirements process, they didn't recognize the name of the requirements system. When management tells the auditors that they expect to pass a CMMI audit with flying colours, because the Jira stories will show the compliance, and auditors find that 94% of the staff ask what CMMI and Jira even are, because they've never heard of them, it's not a good sign.
Management was stunned, and of course tried to blame it on engineering staff "hiding" their unfamiliarity with the formal standards they were expected to comply with.
Of course, the auditors found *years* of emails, project meeting minutes, SpeakUps, and other corporate reporting processes filled with the staff SCREAMING at management about the problems, but management simply ignored them.
So I found myself as lead engineer on a proposal being bid with two other companies. The proposal is correctly process heavy because of what it was for. My company and one of the others got their systems engineers together to do process mapping. The third? Oh we don’t have any such engineers, even though it was a requirement to have process according to the ISO standards. And this from a company that often features in the trade press for related reasons.
When senior management was challenged on it, they'd say that they didn't actually need a systems engineer position. They'd still claim to be doing all of the system engineering work, of course, just by people in other roles.
When I'd push them on it, they'd admit that I was "technically correct" that they weren't meeting the ISO requirement, but that the standard only "implied" a dedicated system engineering position. So long as the actual engineering work was being done, that would meet the standard. I had to "use your [sic] common sense" and realize that ISO standard was a guideline, and that the auditors would be fine with it.
Narrator: the auditors were not, in fact, fine with it.
And of course, the system engineering was wasn't being done at all.
The minute you start hearing words like "recontextualize", and "new mindset" coming out of architects or senior management explaining why they're right and the standard is wrong, it's a catastrophe in the making. It's not a question of whether it will crash and burn, only a matter of when.
I once had a manager complain that I was being "too easy" on my team, because out of 8 teams, they were the only one that weren't charging overtime.
There were also complaints from the other 7 teams that we weren't being co-operative.
And so, I was called into a meeting with the manager, our director, and HR to discuss it.
Why, the manager asked, wasn't my team working overtime when everyone else was?
Because, I explained, my team made all our deadlines. Unlike the other 7 teams, I added.
The director checked, and yes, my team not only wasn't over budget due to overtime charges, we were the only one to make our dates.
Fine, HR said, but other groups are complaining you're not working with them.
Yes we are, I said. What we're not doing is dropping everything at the drop of a hat to work on unscheduled, unplanned work. When other teams ask for something, we ask them for a requirements definition, on paper, and then we're happy to work on it.
The manager's comment that we don't have time to write proper requirements, and if something is wrong, we just have to rework it didn't sit well with the director. Nor did the comment that every other team was ignoring process and basically winging it.
Admitting that other teams were working 18 hour days because they weren't following process was not the mic drop that the manager thought it was. I mean, it was, but not against me or my team.
And of course there’s the various tree + swing pictures of what everyone thought was wanted! The director was correct that not having requirements was a big no-no!
As a contractor, I wasn't amazed to see teams running around like chickens with their heads cut off. It's like firemen not being surprised to see buildings on fire. What did amaze me what their rationalizations for it.
Management excuses I've actually heard include:
- "Our product is too complex to have requirements"
- "We're too far ahead of the industry for CMMI process to apply to us"
- "Well, we didn't actually run the process, but there's no reason it wouldn't work"
- "Just because nothing's written down doesn't mean there's not a design"
When auditors failed one company, pointing out the HUGE disconnect between the shipping product and what passed for requirements (mismatched, incomplete, and contradictory as they were), the lead architect was told to draft a response. His formal response was:
"Auditors need to understand that the requirements aren't necessarily the best way to understand what the system does".
At one company when a customer "event" mandated that external auditors review them, senior management confidently told the auditors that they estimated their requirements compliance level was "somewhere between 85% and 90%, easy".
The actual number was 6%. That's not a typo. Six per cent.
A large portion of the staff not only didn't know the formal requirements process, they didn't recognize the name of the requirements system. When management tells the auditors that they expect to pass a CMMI audit with flying colours, because the Jira stories will show the compliance, and auditors find that 94% of the staff ask what CMMI and Jira even are, because they've never heard of them, it's not a good sign.
Management was stunned, and of course tried to blame it on engineering staff "hiding" their unfamiliarity with the formal standards they were expected to comply with.
Of course, the auditors found *years* of emails, project meeting minutes, SpeakUps, and other corporate reporting processes filled with the staff SCREAMING at management about the problems, but management simply ignored them.
So I found myself as lead engineer on a proposal being bid with two other companies. The proposal is correctly process heavy because of what it was for. My company and one of the others got their systems engineers together to do process mapping. The third? Oh we don’t have any such engineers, even though it was a requirement to have process according to the ISO standards. And this from a company that often features in the trade press for related reasons.
I saw that happen repeatedly.
When senior management was challenged on it, they'd say that they didn't actually need a systems engineer position. They'd still claim to be doing all of the system engineering work, of course, just by people in other roles.
When I'd push them on it, they'd admit that I was "technically correct" that they weren't meeting the ISO requirement, but that the standard only "implied" a dedicated system engineering position. So long as the actual engineering work was being done, that would meet the standard. I had to "use your [sic] common sense" and realize that ISO standard was a guideline, and that the auditors would be fine with it.
Narrator: the auditors were not, in fact, fine with it.
And of course, the system engineering was wasn't being done at all.
The minute you start hearing words like "recontextualize", and "new mindset" coming out of architects or senior management explaining why they're right and the standard is wrong, it's a catastrophe in the making. It's not a question of whether it will crash and burn, only a matter of when.
Foolishness…. You at least work 23 hours and where appropriate 28 hours in a day
End the cycle of management violence! ✊