4 ms·

> Teams like this attract a certain type of person, and it's not a builder. Ditto for financial audit teams and so-called "IT security": all they do is block,

> Teams like this attract a certain type of person, and it's not a builder. Ditto for financial audit teams and so-called "IT security": all they do is block, I've never had anyone in either function build something or help me work faster, just additional processes and bureaucracy that slows down real work. edit: I thought my sarcasm would be apparent, but Poe's law strikes again.

strix_varius 4y ago
I haven't worked much with financial teams, but the security teams I've worked with have absolutely helped build our products. They put practices & systems in place that made a golden path to getting software green-lit for production.
eropple 4y ago
"Fast" is not the only descriptor that should be applied to work where a financial audit might be involved. "Correct" probably has a few things to say. "Legal," too.
aaronbrethorst 4y ago
Same with QA. Fire those guys!
- strix_varius 4y ago
  This, but non-ironically.
commandlinefan 4y ago
> financial audit teams and so-called "IT security" They do fill a role that actually needs to be filled, though.
browningstreet 4y ago
I'm in a highly regulated industry segment and work in an information security related function. You've made my day.
- sangnoir 4y ago
  You're welcome!
sofixa 4y ago
It's not their job to build, it's their job to ensure that what you build isn't crap on any number of fronts (security, compliance with regulations). You know, important things that impact your users (if you have the best software ever, but it leaks user PII in the HTML because you're a dickhead who wanted to build fast without any regard for security, that's not great).
- MattGaiser 4y ago
  Sure, if they helped you figure out a way to build, that would be fine. Far more often, I am just told to kill feature/bugfix/concept. At a past job, the security people were against the idea of self password reset at all.
  - Zircom 4y ago
    The security team at my current company also refuse to allow self password resets. The only way is to call our service desk and give them your DoB and last 4 of your SSN... and they completely ignored me when I pointed out that for at least half the population the US that information is more or less public due to several data leaks.
fruit2020 4y ago
I used to feel the same when I worked for a bank. And then I worked at a place where security was so unregulated that TBs of data and millions of user’s accounts could be stolen just with a shared password and no one would notice
jollyllama 4y ago
Yes. Does the GP think the same thing about security engineering teams? What about QA engineers?
Karrot_Kream 4y ago
It's because security, audit, and ethics teams aren't judged by how much they enable others, they're judged by how many threats they block. I work at a well-known tech company but joined when they were still very small. Our original security "team", a team of 2 engineers, were highly plugged into the product and the concerns of the then-small engineering team. This team was always willing to help and enable builders to stay security conscious. As we grew into a large company and our security team became an entire organization at the company, the org lost all connection with the product and became a more classic blocker-based team. The org lost empathy with the product and was judged on no product metrics, so naturally the culture in the org began to just be saying "no" to engineers all the time. A few of the earlier hires still try to help, but for the most part they just block.
specialist 4y ago
Ages ago, one of the managers on my team was complaining about how unhelpful the rest of the company was being (with our team's upcoming product release). I explained the job of everyone else in the building was to say "No" and their job was to get those people to say "Yes". "But, but, but aren't we all on same side?!" "Oh you sweet innocent child..." Once this manager understood the rules, they did quite well playing the game.
IG_Semmelweiss 4y ago
Security is a discrete objective with a distinct success / failure metric. "Responsible innovation" is not discrete. In simplest terms, one can judge if security is succeeding with a security audit. Either access is avaiable to the right parties, or not. One cannot say with certainty if one is being a responsible innovator. If your products are great bc they are are built quickly on top of a swiss cheese security policy, the security team is à blocker (or at worst, a delayer) of the company bankruptcy from fraud/fines/asset loss. If responsible innovation is blocking product, its not certain what (if any consequences) there will be if the product is unblocked. Therein lies the problem
miked85 4y ago
Not really Poe's law. The statement may be exaggerated, but is also true to a degree.
- sangnoir 4y ago
  > ...without a clear indicator of the author's intent, every parody of extreme views can be mistaken by some readers for a sincere expression of the views being parodied. This checks all the boxes on Poe's law: [x] Parody [x] Reductio ad absurdum intent [x] Extreme view [x] Mistaken as sincere

strix_varius 4y ago

I haven't worked much with financial teams, but the security teams I've worked with have absolutely helped build our products. They put practices & systems in place that made a golden path to getting software green-lit for production.

eropple 4y ago

"Fast" is not the only descriptor that should be applied to work where a financial audit might be involved. "Correct" probably has a few things to say. "Legal," too.

aaronbrethorst 4y ago

Same with QA. Fire those guys!

strix_varius 4y ago
This, but non-ironically.

commandlinefan 4y ago

> financial audit teams and so-called "IT security" They do fill a role that actually needs to be filled, though.

browningstreet 4y ago

I'm in a highly regulated industry segment and work in an information security related function. You've made my day.

sangnoir 4y ago
You're welcome!

sofixa 4y ago

It's not their job to build, it's their job to ensure that what you build isn't crap on any number of fronts (security, compliance with regulations). You know, important things that impact your users (if you have the best software ever, but it leaks user PII in the HTML because you're a dickhead who wanted to build fast without any regard for security, that's not great).

MattGaiser 4y ago
Sure, if they helped you figure out a way to build, that would be fine. Far more often, I am just told to kill feature/bugfix/concept. At a past job, the security people were against the idea of self password reset at all.
- Zircom 4y ago
  The security team at my current company also refuse to allow self password resets. The only way is to call our service desk and give them your DoB and last 4 of your SSN... and they completely ignored me when I pointed out that for at least half the population the US that information is more or less public due to several data leaks.

fruit2020 4y ago

I used to feel the same when I worked for a bank. And then I worked at a place where security was so unregulated that TBs of data and millions of user’s accounts could be stolen just with a shared password and no one would notice

jollyllama 4y ago

Yes. Does the GP think the same thing about security engineering teams? What about QA engineers?

Karrot_Kream 4y ago

It's because security, audit, and ethics teams aren't judged by how much they enable others, they're judged by how many threats they block. I work at a well-known tech company but joined when they were still very small. Our original security "team", a team of 2 engineers, were highly plugged into the product and the concerns of the then-small engineering team. This team was always willing to help and enable builders to stay security conscious. As we grew into a large company and our security team became an entire organization at the company, the org lost all connection with the product and became a more classic blocker-based team. The org lost empathy with the product and was judged on no product metrics, so naturally the culture in the org began to just be saying "no" to engineers all the time. A few of the earlier hires still try to help, but for the most part they just block.

specialist 4y ago

Ages ago, one of the managers on my team was complaining about how unhelpful the rest of the company was being (with our team's upcoming product release). I explained the job of everyone else in the building was to say "No" and their job was to get those people to say "Yes". "But, but, but aren't we all on same side?!" "Oh you sweet innocent child..." Once this manager understood the rules, they did quite well playing the game.

IG_Semmelweiss 4y ago

Security is a discrete objective with a distinct success / failure metric. "Responsible innovation" is not discrete. In simplest terms, one can judge if security is succeeding with a security audit. Either access is avaiable to the right parties, or not. One cannot say with certainty if one is being a responsible innovator. If your products are great bc they are are built quickly on top of a swiss cheese security policy, the security team is à blocker (or at worst, a delayer) of the company bankruptcy from fraud/fines/asset loss. If responsible innovation is blocking product, its not certain what (if any consequences) there will be if the product is unblocked. Therein lies the problem

miked85 4y ago

Not really Poe's law. The statement may be exaggerated, but is also true to a degree.

sangnoir 4y ago
> ...without a clear indicator of the author's intent, every parody of extreme views can be mistaken by some readers for a sincere expression of the views being parodied. This checks all the boxes on Poe's law: [x] Parody [x] Reductio ad absurdum intent [x] Extreme view [x] Mistaken as sincere