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.

Definitely helps you make your point.

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.

Very much disagree. Good security teams, good privacy teams and good accessibility teams should understand that their highest priority should always still be to ship product. Their job should just be to make sure that the product that ships is secure, ensures privacy and is accessible.

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.

It seems that you could also see the responsible innovation team in the same light -- 'the product that ships should be innovating in a responsible way'.

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.

Same with QA. Msft rolled QA and dev into a single role and (IMO) it was a detriment to the dev cycle. It's difficult to switch builder and blocker hats.

QA is an interesting one because many companies don't separate QA from development and it works pretty well. I think the main reason you can pull this off is because you can "do QA" by writing automated tests, so it still fits into the "builder" style of work that engineers prefer.

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.

We used to have a large QA silo at a previous job. They did exactly that. We broke that down that by moving the QA engineers into the respective product teams - and kept them, there.

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.

Agreed. QA is really helpful for anything UX/UIrelated (where the alternative is often experimentation, which really is only good for changing already existing things, and not necessarily ideal for new things). Or if something is so big, complex, and crusty like Windows, where it’d be a Sisyphean task to go back and add automated testing everywhere it could theoretically be useful, it’s a lot better as a stopgap than idealistically declaring you don’t need QA since in theory you could automate things (if you were willing to spend 2000 person-years on it).

In case you're confused about the downvote(s):

https://news.ycombinator.com/item?id=32730380

Does Microsoft no longer have STEs and SDETs?

IIRC, the STE role was eliminated in 2006 or so.

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.

IMO, security and accessibility are more objective ends than "responsible innovation" which can be plagued by bias and personal agendas.

I think these are all examples of teams that can have concrete goals: accessibility teams can be enforcing a standard or regulation (like WCAG), privacy teams can be auditing for compliance to GDPR or COPPA, security teams can be monitoring for security updates, pen-testing, and auditing for compliance to standards like PCI DSS.

"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 ...

Consider privacy. I'd wager that most people on HN would prefer it if major social media and advertising companies were doing more than waiting for legislation and implementing the bare minimum. "Privacy" in the aggregate is vague rather than concrete. Similarly, you could imagine a team who is responsible for addressing actual policy concerns around things like amplifying sectarian violence and also having a broader and more vague mission around "harm".

I think most privacy teams are responsible for compliance to legislation and, hence, have clearly defined, concrete goals. Are you disagreeing?

One would hope the goal of a privacy team would be to work to improve and maintain privacy, even if they are not strictly legally compelled to do so in the specific case.

No. I am saying that privacy teams often go beyond that and that this "beyond" is in the vague and ill defined territory.

Legal is the barest.minimum,.and at times actually can force bad practice to boot. (e.g. UK Network Security Guidance)

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.