Pledge Works Inventory
A list of things and how to use them.
I look at the parts of Pledge Works in more depth with examples of how we use them.
Decision matrix or pledge checklist?
A decision matrix is suitable when you are choosing between two or more candidates, such as between analytics or discussion services, hardware or software products, or programming languages and frameworks.
- Should we use Google Analytics or Plausible?
You can also use a decision matrix to choose between strategies. Do you want to target a small number of large clients, or everyone? These are questions you'd want to answer yes to.
- Do we have the resources for this strategy?
- Can we recruit and train the necessary staff?
- Will we be able to retain our existing clients?
- Does this benefit us and our customers?
A pledge checklist helps you live up to your pledges when you create things. If you are building a website, you want its content to be accessible to everyone, and to avoid upsetting people.
We write pledges that force us to make decisions. If a pledge is too vague, we write one that is more specific.
We pledge to have a net positive effect on people and the planet.
Is a good starting point for an organisation but too general when developing new features, so
We pledge not to use practices identified as dark patterns.
The second pledge honours the first and makes clear what we won't be doing.
Pledges are more effective when they are written with a specific context in mind. They can be organisational, applying to everything and everyone, or apply to a single piece of work however small.
When I start a new piece of work, and as requirements become clearer, I write pledges that are increasingly specific. I stop when the consequences of a decision can be verified or measured.
The wording is less important than matching the statement to the situation or scope.
Writing our own pledges gives us less wriggle room. We find it hard to ignore what we have committed to. But we look around for inspiration.
There are many sources, from professional codes of conduct through oaths, pledges, and promises, to manifestos. RTW has its own list of pledges.
We maintain a list of public declarations.
Looking at ethical questions from a professional standpoint is productive. People working in PR, HR, development, design, management, and analytics have different responsibilities and concerns. Pledges written with a specific role in mind are relevant to everyone. When it comes to making decisions they have equal weight.
Role-based pledges can be reused from place to place, and if you are at an organisation that is not open to addressing ethical questions, outside support from peers may help.
Democracy at work
We favour a democratic approach to ethical oversight. The more perspectives we include the less likely we are to make mistakes and incur risk.
Pledges that challenge unethical behaviour are best written by the people that must honour them. We write pledges as individuals, teams, professionals, and organisations, then hold ourselves accountable. If we fail, we do so openly and honestly.
Decisions can be reached quickly with or without a decision matrix or pledge checklist. When pledges are broken, or when there is no clear course of action, voting determines what happens next.
Implicit in a pledge is why it should not be broken. It should be clear to people why dark patterns in website design are unethical. But where there is doubt or uncertainty, add links or an explicit reason.
We pledge not to use practices identified as dark patterns because they are dishonest, disrespect users, and may be harmful.
In agile software development teams allocate time to review recent work. Some use retrospectives to look at how things have been done, and what could be improved. Both reviews and retrospectives use voting to canvas opinion.
In Behaviour Driven Development - a form of agile development - everyone involved directly on a project discusses new products and features, and votes on them before ideas are implemented.
Voting is often used by teams to estimate how long a piece of work will take.
Where software teams have autonomy, voting is common.
A team using Pledge Works votes when a planned piece of work or decision breaks one of its pledges.
This can happen at the outset of a project or after team members have reviewed a piece of work in detail using a pledge checklist or decision matrix. If the team has the authority, it can block a piece of work until the reason it breaks a pledge has been resolved. If it isn't clear what to do, the idea is put in quarantine.
When the team is not the ultimate arbiter - and can be overruled - their objection is placed on record. The objection may lead to nothing, or to change. At the very least the team, and the individuals in it, have voiced their opinion.
Voting on whether to accept work or plans that break pledges is an expression of the team's conscience.
Software teams often consider edge cases. But there are classes of potential problems that are missed because it is impossible to imagine every context in which someone uses a product.
We don't know the mistakes we are going to make, but we promise to address them. If you want to challenge any of our decisions please do so on our GitHub Discussions board.
The Pledge Works team has pledged to be transparent by default. We will make public our decisions and how we reached them. If we don't, we will say why.
Transparency is generally a good thing but individuals especially can be vulnerable to unfair criticism. Transparency should be approached with caution and offered, not expected.