This is also true for security teams and privacy teams and accessibility teams. Yet they are extremely important.
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.
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.
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.
Definitely helps you make your point.
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 difference between these things and something like a "Responsible Innovation Team" is that the goals of the latter are often poorly defined and amorphous. What does "Responsible Innovation" really even mean? But contrast that with, for example, security goals, which are primarily "don't get breached". Security folks, privacy folks and accessibility folks should all have a very well-defined job to do. For the other "PR-focused" teams, they usually have to make work up to justify their jobs.
Note that, obviously, it's also possible to have bad security people, for example, who only see their job as to throw up roadblocks and demand that your security checklist is ever-growing. I'd even say these are the majority of "security" people. But the good security people who are able to integrate themselves successfully into your product development processes are worth their weight in gold.
Also IME none of these things are binaries -- a product could be more or less secure, privacy-respecting, and accessible, just as it could be seeking to innovate more or less responsibly. Different aspects of security, privacy, accessibility, and responsible innovation will be important at different times, depending on what's happening in the world.
The jobs are never as well-defined as you'd imagine.
In 2014, for most divisions, the SDET role was rolled into the function of SDEs, reportedly resulting in drastic attrition of the converted SDETs. The exception was the operating systems division, which was reported to have laid off all of its SDETs at that time.
Turns out many kinds of businesses/product teams (including Microsoft's Windows team, I'd say, from personal user experience) need dedicated QA people because many worthwhile tests can't really be automated well enough with a reasonable effort, or if they can, it's something that often breaks and needs regular maintenance.
I suspect that in the Windows case they simply stopped testing those troublesome cases.
If you asked engineers to do a large amount of manual testing, they would either (a) tell you they were and then secretly automate it, (b) simply not do it, or (c) quit.
"Responsible Innovation" is kind of nebulous and I would expect it to be problematic unless given clear rules of engagement and supplied with a strong leader.
That said, somebody needs to be responsible for dealing with the endless stream of products that are deeply flawed out of the box: builtin racism, builtin stalking/harassment tools, "0-day" doxing of existing users ...
Thing is, any way Twitter can innovate in a way that would bring income is likely unethical. Either it will try to increase engagement by polarizing people - increasing heat; selling user data; showing advertising or additional worse things.