Creating norms in tech, and the climate crisis

I recently started working to help get a document together to help set some norms in the tech community (such that there is one) about our actions in relation to the climate crisis. So far, it’s been referred to as a climate code of conduct, and there was some push back about using the term code of conduct in this way, and it seemed worth sharing my thoughts here, so I can refer to them later.

Why you might call a normative document about how we work, a Code of Conduct

We have no generally accepted formal code of ethics like other professions in tech.

But one of the closest things we have seen work in a normative sense are Codes of Conduct.

They have changed behaviour at conferences and set norms that would not otherwise be followed, and as a result created a space that is accessible to people who previously did not feel safe.

One of the reasons I think Codes of Conduct can be effective is that they by designed to be universal, normative, inclusive, iterative, and explicit.

Codes of Conduct are explicit about what we consider acceptable, and there are consequences for not following them. There’s also an expectation that they evolve over time, as we learn more about who is being harmed, and try to include them in the conversation.

Crucially, they’re already in use – we currently rely on them to establish norms at conferences, but also for virtual spaces, like open source projects, online communities and so on.

I’m currently not aware of a mechanism that’s as widely used as codes of conduct for setting norms around behaviour, but I’d love to find out if there was.

Why you might not call such a normative document a Code of Conduct

Codes of conduct have previously been applied at or around events, and primarily refer to how attendees address each other inside the space itself.

It’s been a huge amount of work to get them accepted, and many brave people have had to put themselves in harm’s way for this to happen.

Including something as structural as an organisation’s policy around climate change, or a person’s individual decisions about travel, because they’re not directed at a given person, can feel like a stretch of the term Code of Conduct.

You might feel like this , even if someone’s individual decisions result in harm to the people you might want conferences, and by extension, the tech community as it grows -remember, the fastest growing tech communities are not in Europe or North America, bt mostly what you might call the global south now.

The result of this is you might feel really uncomfortable about using the term Code of Conduct in this way – it’s different to how Codes of Conduct have been used previously – and you might worry that it would weaken what a Code of Conduct already stands for.

A different frame – protecting against different kinds of violence

When I first heard the “this weakens a Code of Conduct” argument in tech, I felt pretty miffed, as it felt like taking the one tool in tech communities, that’s been historically useful against oppression of minority groups, as it basically felt like saying:

“screw you, I got mine, and those other people over there don’t matter enough for me to be okay with you using that term”

It seemed to go against everything I read about intersectional theory, and the number of people objectively being harmed by actions we’ve been taking in the global North for the past few decades left a really, really bad taste in my mouth.

I need to stress – I don’t think that’s the case, and I’ve only shared it here as I think it’s more useful to acknowledge emotions when you feel them, and then work to share how you moved on from feeling that way, for the benefit others in a similar situation.

Violence – more forms than just the physical

One term, or way to look at thing that helped me get past this, was understanding how people talk about violence.

It might be useful to understand a specific use of the term violence, and specifically, structural violence as described in Wikipedia as it helped me make a distinction in the two positions above, about using Codes of Conduct. I first came across it when reading Violent Borders.

One way people talk about violence is in terms of behavioural violence (sometimes referred to as direct violence), cultural violence, or structural violence.

  • Behavioural (or direct) violence – might typically refer to one person targeting one person specifically, and generally mistreating them, or causing them harm. This is the probably what we think of the most when we hear the term violence.
  • Cultural violence, as the name suggests is about creating or supporting a culture that legitimises or justifies this kind of direct violence.
  • Structural violence, tends to refer to decisions that result in harm happening to someone, even if we don’t mean to do it. The harm is typically caused in a more widespread, diffuse way, and while the damage done is real, it’s harder to pin it down to a single person, or identify a single person as a target. There might be deliberate policy decisions inflicting structural violence, but generally speaking, it’s much harder to see things like this as a direct form of violence.

Codes of conduct as we have used them so far seem to refer to direct violence (i.e. one person directly treating someone terribly), and cultural violence (stuff that might that lead to, justify or legitimize this kind of direct violence), and as such, they take steps to protect people against them.

I haven’t found any Codes of Conduct or similar in tech, that explicitly refer to structural violence or have explicit safeguards against it.

And yet – many of the problems around the climate, are you might call structural violence.

People choose to run servers that are powered by burning coal, or choose to fly all over the place – someone absolutely booked a flight to do this, to chose one provider over another. There’s a link between these things and a changing climate, and as we’ve seen with heatwaves in India of late, There is a definite human cost.

But it’s not direct violence aimed at a specific person.

Why this matters.

I’m working on a document that currently uses the term of Code of Conduct in the context of Climate, and I’m struggling with this at the mo.

There is no real kind of commonly accepted, effective normative mechanism in tech in use that people explicitly agree to follow, like a code of ethics, or practice, or charter, like other professions.

The Code of Conduct is the closest thing we have that I can think of right now, that is universal, normative, inclusive, iterative, explicit, and most importantly widely used.

The thing is, using the term Code of Conduct to talk about structural decisions and policy in this way, is a departure from how they’ve been used before.

When it comes to the climate crisis, there are clear things we need to do, and that we are are objectively failing to do, and harm is being done to countless people as a result.

I’d find it really useful to learn about other mechanisms that are powerful like Codes of Conduct, in widespread use, and don’t result in this kind of scope creep to how we currently think of Codes of Conduct – if you know any, I’d love you hear form you.

You can leave a comment on this blog post, or contact me the usual ways listed on this site.

Writing up IotMark, part 2 of 2

I said on twitter that I’d do a write up of the Friday IoTMark workshop last week:

I’ve had enough people fave it to give me a reason to write it, but over the weekend, I realised that giving context and backstory to the event took up more than 1500 words already. I’ve split that out into a separate post, so here’s how the day went down and the key things I learned.

Much less than 60 people this time around

Previous events have been relatively large affairs, taking over entire venues, with breakout rooms, and culminating in a somewhat chaotic mob-editing of a google doc, to come up with either a bill of rights style document, or some kind of spec or set of principles to inform the creation of a certification mark for connected products.

This time round, there was a handful of people, in person, in a room for the whole day in central Mitte instead – albeit one with a nice view from the tenth floor, and a few people skyped in, in anm iPhone in a glass, to make them easier to hear.

DSC_0345.jpg

What we were going for

The goal of the day, as I understood it, was to get the ideas in the most recent document in better shape for being used as a basis for a certification mark.

This included:

  1. tidying up the language and trying to make it as accessible as possible without losing the substance of the initial document
  2. reconciling it with the issues raised on github, and feedback when presenting it at Mozfest in November 2017.

There was also a move to make the IoTMark something people and organisations of all sizes could realistically commit to adhering to – when setting up a certification mark can easily cost more than 40k USD, it makes sense make it something that actually could be adopted.

A bit like Energy Star, for IoT

DSC_0387.jpg

One strategy to follow if you want a diverse set of people to commit to a set of ideas, is to introduce levels of commitment, so you aren’t asking for people to make a binary all in/ all out choice.

There was already some implicit sense of grading here in the normative language (a MUST  is non-negotiable, but a SHOULD for example, is not absolutely mandatory), so started with that, to come up with a rough set of three groupings.

I say groupings here, because it’s really, really hard to have a single axis when discussing these products, that goes from, say, bad to good. It’s much more complicated than that, and different people value different qualities – some people might value openness of software and hardware over the supply chain transparency, and some might treat being explicit about how personal data is used as more important than marketing to a specific group of people.

That said, one grouping was considered a bare minimum – something considered reasonable to expect anyone wanting a connected product that follows the principles to follow. It felt important to have something everyone could have as some shared values, before focusing on diverging areas.

Relating GDPR to IoT

The other thing that came out of the day was just how far reaching the GDPR is when it comes to thinking about about connected products, and why it made sense to think about it in the context of IoT.

It’s a common refrain that the tech industry needs to improve when it comes to it’s cavalier attitude to people’s data – often deeply personal data secured in dangerously careless ways, and used in ways that definitely aren’t in the interests of the consumer.

I also think it’s safe to say that there is appetite for change, and well… from my perspective at least, GDPR feels like change for the tech industry in the same way that a giant asteroid might have represented change to wildlife around the end of the Cretaceous period on Earth.

To be clear, this change isn’t necessarily bad – asteroids can sometimes get rid of dinosaurs and make life easier for us humans, after all.

Why you might care about GDPR for IoT

I often point people to these posters from the co-up to help understand the ideas behind the GDPR, and why it’s a big deal – for many consumers, the ideas in the GDPR don’t sound like unreasonable things to ask for, especially when there often seems to be no real penalty for bad behaviour, from lawmakers.

Chaos Monkeys for your data pipeline, otherwise known as Europeans

In addition, if you are building a connected product the the changes to privacy law are extraterritorial, as in – if any citizens of EU member states end up in your data pipeline, or data is proceeded in the EU these laws still apply. I think Heather Burns, covers this really well in a recent piece aimed at web developers, and much of it applies for IoT too:

In May of 2018, a major upgrade to Europe’s overarching data protection framework becomes enforceable. This will be followed by a companion piece of legislation pertaining to data in transit. The extraterritorial nature of these two frameworks — they protect the privacy rights of people in Europe regardless of where their data is collected — means that they will become the de facto standard for privacy around the world.

Enforcement may be another issue, but given that for 300 million people at least, the biggest changes to privacy law in 25 years are coming into effect this year, and will force changes anyway, ignoring it seemed short-sighted, as well as being against many of the ideas in original document.

Overlap between IoT principles and GDPR

I’ll end this section with one thing that struck me – it’s totally possible to build connected products that comply with the ideas of the GDPR, and there are very large companies doing exactly this. In fact, there’s some great stuff by Matt Webb, on how privacy can be a competitive advantage for IoT services that’s worth reading if you’re interested in this field.

He cites Hoxton Analytics as a good example – by building privacy into their product from the beginning, they could be deployed in places more invasive systems couldn’t, helping them against competitors – there’s a lot of FUD about GDPR, but it’s also an opportunity to rethink the playing field, something lots of companies already invested in one way of working seem to miss.

RFCs versus principles

Another thing that came up thing during the day, was the difference between a spec using specific normative language as described by the IETF, which you typically validate programmatically based on the MUSTs and SHOULDs, and a set of principles which tend to have more fuzzy edges, and are more open to interpretation.

It’s relatively old now, there’s some really great thinking in Lawrence Lessig’s book Code, about different ways of enforcing behaviour, which I think is relevant.

I don’t have the book handy, but Danah Boyd’s blog summarises one of the key ideas nicely :

In his seminal book “Code”, Larry Lessig argued that social systems are regulated by four forces: 1) the market; 2) the law; 3) social norms; and 4) architecture or code.

I think it’s easy to conflate these. When you’re trying to bring about a specific kind of behaviour you want people to follow, it’s worth thinking in these terms, so you don’t try to make one force act as it’s another.

Embodied thinking in physical space

DSC_0382

Finally, in the afternoon, after re-reading through the the principles as described in the original Open IoT documents, referring to the Github issues, and Mozilla versions, and deduping them, we spent a bunch of time finding ways to group these principles, to make it easier to follow a meaningful amount of them if you can’t follow all of them.

If you have a load of people in a room, and you need to help build a shared understanding, one strategy to help people to this is use some physical token represent an idea, and let people use the physical space to communicate how ideas relate to each other.

Given we had spent a bunch of time already checking our understanding of the ideas in isolation, I found it useful to help communicate positions for people in the room to discuss more effectively.

The downside here when you are skyping people in, is that they’re not able to move things around themselves – and by doing this, you’re making a specific decision to favour collaboration in the room, over those who are remote. In most cases, I think this is the right call, as the alternative is often to collaborate at speed of the person with the lowest bandwidth connection, which reduces what you can get done in a limited amount of time.

I’d love to hear suggestions for finding a way around this – while you can use tools like realtimeboard to create a whiteboard-like experience, you’re still reducing the richness of your interactions in the room to what the software lets you do with a piece of backlit glass.

How to get involved in this in future

If you’re interested in any of this, I’d suggest heading to the iotmark website – from there you can see the current version of the principles, join the slack workspace, or subscribe for updates over email, or follow the IotMark on twitter.

As ever, comments on this post are welcome, and if you prefer you can contact me directly.

 

 

 

My first experience with Liberating Structures Labs

More and more these days, I’m seem to earn my crust helping people talk about technology, and their strategy around using it in an organisation, rather than writing code myself. Just like you have tech meetups to find out about out shiny new frameworks and software, you get meetups for where you can find out about shiny new frameworks for running workshops and meetings better. Liberating Structure Labs is an example, and I went last night. Here’s my write-up.

Liberating Structures?

As far as I can tell, Liberating structures is a free-to-use set of principles and activities to help structure meetings and events, as a response to the rigid, stifling structures of convention ways of getting people to work together in a shared space. Here’s the blurb from their website, explaining the problem:

Conventional structures are either too inhibiting (presentations, status reports and managed discussions) or too loose and disorganized (open discussions and brainstorms) to creatively engage people in shaping their own future. They frequently generate feelings of frustration and/or exclusion and fail to provide space for good ideas to emerge and germinate.

What’s proposed instead are a set of 33 or so different activities, with clear sets of rules, that you would apply, depending on the outcome you’re after when you have people in a room with you. you might recognise some of these from other disciplines if you ever facilitate UX workshops, run retrospectives in agile teams and so on:

Screen Shot 2018-02-22 at 09.50.12.png
A list of the 33 (oops! 35) Liberating Structures to use

Testing these somewhere safe

One thing about these sets of activities, is that to test them at work is usually quite a high stakes gamble – you don’t know how well thought through they are at this point, or whether they’re a good fit for where you work.

Generally speaking, wasting a load of other people’s time with experimental techniques for workshops or meetings, could be seen as a career limiting move, so it’s useful to have somewhere to try them out first to see where the pitfalls are, so you know how to recover if things go south when you do talk your boss into letting you try them.

As I understand it, this is the purpose of the Liberating Structures Labs, and last night, we ran through a few exercises to get familiar. Each meetup has a theme, and last night the theme was Building a Culture of Collaboration.

Impromptu networking

IMG_20180221_193102.jpg

The first was an ice breaking opening game – with some nice easy to follow instructions on how to run through it. The page for it is here, but in a nutshell, the idea is to provide some prompts for conversation, and have some time boxes, to make it easy to chat with each other.

It worked pretty well, and I think I’d use it myself in future, as a quick ice breaking game, when I want some clear, rules. As an example of how careful application of structure can be liberating for people in a workshop, I found it a really effective demonstration of the key ideas I understand Liberating Structures to be about.

Panarchy

IMG_20180221_193207.jpg

The next part  was introducing a much larger activity, Panarchy, which as you’d imagine from the Pan part of the name is pretty ambitious in scope – you essentially look at how to answer a pre-defined question at a number of different levels of abstraction from the micro/individual level, through to groups, and industries, right up to policy and even myth-making.

Interestingly, it was initially introduced as a tool in healthcare to help structure a system-level response to the spread of MRSA in hospitals – so rather than being a comparatively vague question like “How can we build a culture of collaboration?“, it was a much more concrete problem to solve, with a much more measurable upside: “How can we stop accidentally killing people in our care with antibiotic-resistant super bugs?”.

For me at least, while I enjoyed the conversation with other attendees, I found it that we left the exercise without many useful insights we could take away – it didn’t feel like such a strong demonstration of the technique for me.

I think this is a function of the initial question being so vague to accommodate the free workshop format, where you can’t control who is coming, but also highlights how important it is to be able to provide context before you put forward a question for an exercise like this.

1, 2, 4

One thing that caught my attention, that I haven’t seen in other playbooks of activities like the GameStorming approach, was how composable the activities were – you would make new structures from combining other structures/activities. In Panarchy, a key mechanism for getting insights out of people was something called 1,2,4 – if you’ve ever run a design studio with Lean UX, or a charette exercise, the idea of going from individual work, then sharing in pairs, then progressively larger groups, will be familiar.

1, 2, 4 is a nice reduction of these ideas down to their essence – and looks to be applicable in lots of places where you might have groups where one or two people are more forthright with opinions than others, and you risk losing some useful information if you let them dominate discussion. For me, it felt like a good introduction to the structure (what do I call these? A Liberating Structure? An Activity? There has to be a less clumsy phrase than liberating structure to use in sentences).

The main niggle I had here was the issue of timing – when you don’t have a visible way of keeping time in a timeboxed activity, or a designated timekeeper, it’s still easy to end up giving the floor to the most talkative person (I try to keep track of this, I’m often a guilty party here).

An interesting grab of tools

I hadn’t heard of Liberating Structures before, but broadly speaking the activities seem very accessible, and there’s enough variety in the 35 structures for it to feel like a pretty comprehensive toolbox, that works in a wide range of contexts, in the same way that Game Storming provides a useful set of games to use in workshops depending on what you’re after.

I think I’d like go to the next meeting to explore it more, and if you’re curious about having a useful set of teachable techniques to help get more out of meetings with others, I’d happily recommend it.