Corporate Surveillance

“So every purchase initiated or prompted by a recommendation you make raises your Conversion Rate. If your purchase or recommendation spurs fifty others to take the same action, then your CR is x50. There are Circlers with a conversion rate of x1,200. That means an average of 1,200 people buy whatever they buy. They’ve accumulated enough credibility that their followers trust their recommendations implicitly, and are deeply thankful for the surety in their shopping. Annie, of course, has one of the highest CRs in the Circle.

The Circle, p. 252

In May 2017 I invited Adrian Hon, entrepreneur, author and futurist, to our speaker series at Mozilla. I’d read his book, A History of The Future in 100 Objects, after hearing him read from it at The Long Now, and I fell in love with the approach of giving retrospectives from an imagined (and well-informed) future vantage point. As we discussed what scenarios could be most relevant and meaningful for us at Mozilla, we decided to arrive on surveillance as a focus.

Specifically, Adrian presented from the perspective of someone in 2027 looking at us then (in 2017), in awe of how readily everyone accepted ongoing, intimate surveillance in the home through devices from Amazon and Google, after buckling so strongly in response to CCTVs in the 1990s.

It’s two years later and nothing freaky has happened with Siris or Alexas (yet). But we have gotten less trusting of surveillance in the home as we continue to learn more about the implications of our data; surveillance capitalism is emerging from academia to the mainstream.

That is, we’re more aware and (legitimately) wary of how our personal data can easily be misused in consumer free and commercial services. But what about surveillance in the workplace?

This screenshot is not from the Circle. It’s an enterprise tool licensed by major companies to encourage their staff to post content about their company on a business-social network.

It is opt in, and the marketing doesn’t suggest companies tie job performance to these dashboards (though…their client endorsers advocate using them to exert social pressure among teammates). And, in fairness, corporations have been able to monitor at least some of their staff’s activity for a long time (though…maybe not quite to the extent that technology offers today. At all).

As the past few years certainly remind us, just because you can, doesn’t mean you should. Guess we’ll see.

p.s. just came across this Quartz piece – from two years ago – lamenting the advent of corporate surveillance (and echoing my fears of Slack). la la la.

UX vs. DX

I was introduced to Estelle Weyl through my colleague Ali, who suggested Estelle as a speaker for Mozilla’s speaker series. I was intrigued with Estelle’s teaching on the differences between how we as humans perceive the speed and performance of our web browsers (vs. the precise, technical “reality”).

She was of course great, and her final slide also called out another important distinction:

So how fun was it when, a bit over a year later, she invited me to moderate a panel on, yep:

We had Tomomi Imura of Slack on board, and were super fortunate to recruit Sarah Federman (newly) of Atlassian and Jina Anne.

This group was so amazing, they agreed to meet on a holiday before the event to huddle. It was there that the subtitle emerged:

We realize we hadn’t intended it, and while we didn’t want to make the Lakoff mistake, we did think it was cool.

So, whiskey it was.

Oh also, the conversation was as great as these women. Estelle and Timomi had previously posted different ways to tackle this. Estelle defines DX as “the methodologies, processes, and tools (frameworks, libraries, node modules, pre- and post-processors, build tools, other third-party scripts, and APIs) by which developers develop web applications for their user base.”

And, because developers are often users too (think developer tools, and of course, frameworks), Timomi approaches their DX in a way that exhorts developer tool makers to keep the developer experience – as users – in mind.

So as a group, we broke this down further, looking at why some developers may be tempted to not think about the UX (whether those users are developers or not, per above), and instead adopt a “resume-driven development” approach (h/t Estelle again) that favors them showing off knowledge of sexy new frameworks vs. delivering a solid UX.

There are also work culture pressures to deprioritize UX. Ship fast or first or cheap, user-be-whatevered, can be a hard force to combat when it comes from management.

But, as others pointed out, developers can still make the choice to not be overly-reliant on tools or frameworks so they can choose the best route for the end-users. Individual engineers can ask forgiveness vs. permission in adopting a user-centric, front-loaded design approach from the start. Finally, to steal (again) from Estelle:

Taking the time to do it right the first time is “fast to code”. Refactoring is not. If you keep the six areas of concern — user experience, performance, accessibility, internationalization, privacy, and security — at top of mind while developing, your finished product will be usable, fast, accessible, internationalizable, private, and secure, without much effort.

Estelle Weyl