4 ms·

This is also true for security teams and privacy teams and accessibility teams. Yet they are extremely important.

bentcorner 4y ago
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.
- cpeterso 4y ago
  Does Microsoft no longer have STEs and SDETs?
  - ThrowawayB7 4y ago
    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.
- tpmx 4y ago
  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.
  - opportune 4y ago
    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).
    - tpmx 4y ago
      In case you're confused about the downvote(s): https://news.ycombinator.com/item?id=32730380 https://news.ycombinator.com/item?id=32730380
- munificent 4y ago
  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.
PragmaticPulp 4y ago
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.
- UncleMeat 4y ago
  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.
  - strix_varius 4y ago
    > 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.
lefstathiou 4y ago
IMO, security and accessibility are more objective ends than "responsible innovation" which can be plagued by bias and personal agendas.
Ensorceled 4y ago
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 ...
- UncleMeat 4y ago
  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".
  - Ensorceled 4y ago
    I think most privacy teams are responsible for compliance to legislation and, hence, have clearly defined, concrete goals. Are you disagreeing?
    - detaro 4y ago
      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.
    - UncleMeat 4y ago
      No. I am saying that privacy teams often go beyond that and that this "beyond" is in the vague and ill defined territory.
hn_throwaway_99 4y ago
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.
- unicornhose 4y ago
  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.

cpeterso 4y ago
Does Microsoft no longer have STEs and SDETs?
- ThrowawayB7 4y ago
  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.
tpmx 4y ago
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.
- opportune 4y ago
  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).
  - tpmx 4y ago
    In case you're confused about the downvote(s): https://news.ycombinator.com/item?id=32730380 https://news.ycombinator.com/item?id=32730380
munificent 4y ago
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.

PragmaticPulp 4y ago

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.

UncleMeat 4y ago
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.
- strix_varius 4y ago
  > 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.

lefstathiou 4y ago

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

Ensorceled 4y ago

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

UncleMeat 4y ago
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".
- Ensorceled 4y ago
  I think most privacy teams are responsible for compliance to legislation and, hence, have clearly defined, concrete goals. Are you disagreeing?
  - detaro 4y ago
    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.
  - UncleMeat 4y ago
    No. I am saying that privacy teams often go beyond that and that this "beyond" is in the vague and ill defined territory.

hn_throwaway_99 4y ago

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.

unicornhose 4y ago
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.