Good security and privacy teams do a lot of work to establish good practices and build frameworks and platforms for others to build upon.
The bad security teams just show up and expect to say criticize everything and stop other teams without providing workable alternatives.
The problem with having a team with a vague charter (“responsible innovation”) with unclear scope (e.g. not just security or just privacy) is that it’s really hard for them to feel like they’re building foundations for others to build upon. It’s too easy for them to fall back to roles where they see themselves as the gatekeepers and therefore backseat drivers of other teams. It becomes a back door for people to insert themselves into power structures because nobody is entirely sure where their charter begins and where it ends.
Of course. But good security teams also say "no you can't do that even though it would be the fastest path to market." And looking at a team that says "no" and saying "ugh these people aren't builder they are just getting in the way" is a great way to end up with a company that is irresponsible towards their users.
We can talk about whether this particular team is effective. We can talk about unclear scope (though, IMO, the scope here is no less clear than "privacy"). But the complaint that teams that put barriers in front of other teams are always bad is insufficient at best and downright dangerous at worst.
> But the complaint that teams that put barriers in front of other teams are always bad is insufficient at best and downright dangerous at worst.
Nobody made that complaint.
Please don't misrepresent my statement, which was specifically, "to justify your own existence, you have to put blockers in front of people who are actually trying to build things."
Good security teams build & they help others build as well. They build secure-by-default platforms, secure common libraries, and guidelines for others to follow with confidence. Working with a good security team means you're confident your product will get to market faster because, at launch time, you know you'll be green-lit since you followed the org's security best practices.
That kind of team doesn't have to invent blockers in order to justify its own existence.
You should edit your statement to include the word "invent" - that goes a long way towards describing the blockers you talk about as invalid, made up, not relevant to real business constraints, etc.
So then the followup question is, based on what do you make the claim that the team under discussion didn't build anything?
You admit that teams in this space can and do often build tools to make things secure by default or private by default, so why couldn't this team be involved inbuilding "responsible" by default?
Your argument here is basically that you believe security and privacy "blockers" are inherently of value, so a team enforcing them isn't 'inventing' blocks, but other teams are.
The bad security teams just show up and expect to say criticize everything and stop other teams without providing workable alternatives.
The problem with having a team with a vague charter (“responsible innovation”) with unclear scope (e.g. not just security or just privacy) is that it’s really hard for them to feel like they’re building foundations for others to build upon. It’s too easy for them to fall back to roles where they see themselves as the gatekeepers and therefore backseat drivers of other teams. It becomes a back door for people to insert themselves into power structures because nobody is entirely sure where their charter begins and where it ends.