A practical tool that invites you to write pledges for better outcomes as part of your existing product development processes. This modular and adaptable tool supports responsible design and development in different contexts.

Note: This tool is still under development; we are seeking broader validation in different contexts. Join the discussion to share your experience, ask questions, and make suggestions for improvement.

About this tool

Pledge Works is a tool we developed to bridge the gap between good intentions and everyday product decisions. Its core idea is to write pledges for better outcomes at every step of your existing processes, in cascading levels of granularity.

The goals of Pledge Works are to:

• help individuals and teams figure out how their values and principles might be reflected at each level of granularity;
• increase the transparency of ethical assumptions and beliefs that usually remain hidden;
• invite and facilitate cross-functional ethical discussion;
• encourage team members to consider more responsible choices rather than always going with industry defaults.

Pledge Works is modular and adaptable. On this page, we present several examples of possible applications but we also invite you to adapt the tool to your needs and use only the parts that make sense in your context.

Pledges Works Building Blocks

Pledges and Better Outcomes

What are pledges? Pledges are promises – commitments to yourself, your team, your customers, various stakeholders, and the planet – to seek better outcomes in context. While you can write pledges using different formulas, they should be concrete and useful for guiding product decisions.

Examples of pledges at different levels of granularity:

• “We will ensure people’s anonymity on votes both in the UI and on the API.”
• “As a responsible team, we pledge to use simple and inclusive language in the UI because we want to make our tool accessible to non-native English speakers and easy to adopt in diverse teams.”
• “As a responsible UX professional, I pledge to the planet: I will minimize digital waste and use tools that aim to reduce our environmental impact because I want to do my part in keeping the climate livable for future generations.”

What are better outcomes? It depends on your industry, type of product, purpose, and values. For instance, some obvious better outcomes are sustainability, accessibility, security, etc. While we do believe our own pledges lead to better outcomes, we don’t want to be prescriptive about what this means for you. We also acknowledge that desired outcomes change and evolve over time, and should be checked against the impact your product has on different types of people (regardless of whether they give you money or use your product) and the planet.

Example: if you’re a large social media platform, you might initially say the outcome you strive for is increased engagement. But as you check that outcome with people using your product, you see that the outcome has negative consequences for a lot of people. You decide to shift your focus on people’s well-being and experiment with new business models that can complement this focus.

Pledge Types

Within Pledge Works, we see two basic types of pledges:

• Context-based pledges that are written to fit a specific context or scope of work (e.g., project, epic, sprint).
• Role-based pledges that are written from the perspective of a person’s role and bring in considerations from diverse professional codes of ethics (e.g., ACM Code of Ethics and Professional Conduct), communities of practice (e.g., Ethical Design, Principles of Green Software Engineering).

Both types of pledges inform each other and can be combined when writing new pledges.

Pledge Formulas with Examples

Your pledges can include different elements, depending on what you want to emphasize.

Simple pledges: at its core, a pledge is a promise of how you intend to act responsibly. They should be written at the appropriate level of detail, using language you’re familiar with.​

Examples of simple pledges:

• Simple company-level pledge based on ResponsibleTech.Work pledges: “We pledge to respect people we build products for and treat them as friends, not users.”
• Simple project-specific pledge that is derived from the company-level pledge of respecting people: “We will ensure people’s anonymity on votes both in the UI and on the API.”

Responsible stories: are written in a format similar to user stories, and include a declaration of WHO is making the pledge, the PLEDGE itself, and (optionally) a REASON for making the pledge. They can be written from the perspective of a group of people (e.g., “team”, “company”), a role (e.g., “developers” “product manager”), or even individuals.

We recommend adding the adjective “responsible” in front of the pledge actor to help you frame your thinking but you can add your own (e.g., “privacy-focused”).

We find that writing reasons can be quite challenging but useful for examining your motives, especially if you dig in a bit deeper with tools like the 5 Whys.

Examples of responsible stories:

• Company-level responsible story: “As a responsible digital agency, we pledge to write energy-efficient software because we want to reduce our overall carbon footprint.”
• Project-level responsible story written from the perspective of the team, which includes different roles (developers, designers, copywriters, etc.): “As a responsible team, we pledge to use simple and inclusive language in the UI because we want to make our tool accessible to non-native English speakers and easy to adopt in diverse teams.”
• Project-level responsible story written from the perspective of a specific role (developers) that refers to outside accessibility guidelines: “As responsible developers, we pledge to use the axe Accessibility Linter Visual Code extension, or equivalent, to parse our HTML in order to follow WCAG accessibility guidelines that will help all our end users use the website.”
• Role-specific individual responsible story that refers to a higher level company pledge: “As a responsible product manager at ACME company, I pledge to advocate for what people using our product need to make their life easier because our company pledged to develop products that improve people’s lives.”​

To WHOM Pledges: an extension to the responsible story type, which also includes the intended audience. Might be especially useful for freelancers or teams and roles that find themselves juggling conflicting responsibilities.

Examples of to WHOM pledges:

​“As a responsible UX professional, I pledge…“

• “… to people using the products I design: I will design delightful experiences that don’t waste your time and respect your other needs because I believe that digital products should improve rather than aim to take over our rights.”
• “… to people not using the products I design: I will be mindful of how my design choices might affect you negatively because I don’t want to inadvertently hurt people.”
• “… to the planet: I will minimize digital waste and use tools that aim to reduce our environmental impact because I want to do my part in keeping the climate livable for future generations.”
• “… to clients: I will design solutions within your budget and time constraints as long as they don’t harm the well-being of people or the planet because I respect you as people and your goals of running a profitable and reputable business.”

Regardless of which pledge type you choose, you should use words and language that feel natural to your team. For instance, if saying “we pledge” feels awkward to you, feel free to write simply “we will” or “we promise to”. Just make sure it feels like you’re committing yourself or your team to some concrete action.

Pledge Checklist

We also recommend writing a pledge checklist that makes it clear what upholding each pledge means. You can add the checklist to the pledge card in Trello, Jira or whatever tool you’re using, to make it easy to follow your progress. The pledge checklist will likely be updated as you work through the implementation and uncover more specific questions.

Example: if we pledge to ensure voting anonymity in the Trello Power-Up we’re developing, a simple pledge checklist could look like this:

• “As a team member or board owner, I cannot see who voted in the Challenge Toolbox when looking at cards or board statistics.”
• “As a team member or board owner, I cannot see who voted in the Challenge Toolbox when I export the board or query the Trello API.”

You can also think of the pledge checklist as acceptance criteria for the pledge. However, with pledges, it will not always be possible to satisfy all checks due to conflicts with other pledges or compromises we have to make with other teams/roles, so the pledge checklist is not set in stone and can be adapted as we get a better idea of what’s both feasible and acceptable.

Sources of Pledges

You don’t have to write pledges from scratch; in fact, we recommend you start with an existing list of higher-level pledges or principles for inspiration. You can use:

• a general list of pledges such as our ResponsibleTech.Work pledges,
• pledges focused on a specific area of responsibility such as the Sustainable Web Manifesto,
• existing values and principles a company might have in place,
• profession-based principles (e.g., design principles) or professional codes of ethics (e.g, ACM Code of Ethics and Professional Conduct),
• outcomes from Consequence Scanning sessions or other ethical tools.

When writing pledges for a new project, start with existing higher-level pledges in your company or organization (if they exist) and combine them with role-based pledges and pledges from other sources that are relevant to your project.

Example: your company is starting a new project that will use machine learning algorithms and you have no previous in-house expertise in the field. You should look at existing sources such as Responsible Machine Learning Principles or Data Science Ethics Checklist to help inform your pledges for the new project. If possible, hiring outside expert help is also advisable in such scenarios.

Pledge Works In Practice

Responsible Project Kickoff

Regardless of which product development methodology you use, you probably have some sort of a project kickoff before you start developing a new product, a larger chunk of functionality, or take on a new client project. During project kickoffs, teams usually define project scope and discuss business, user, and technical requirements to figure out what needs to be built, why, for whom, by when, and roughly how.

While project kickoffs often include ethical discussions, they are rarely made as explicit as, let’s say, user requirements. Some ethical requirements get buried under the not very attractive label of non-functional requirements. With Pledge Works, ethical requirements are discussed on equal footing with other requirements and made explicit by writing project pledges.

Writing project pledges through ethical alignment

To write initial project pledges (which can later be broken down by epic, sprint, etc.), you should discuss and review desired better outcomes, company purpose, values and principles, and contextual- and role-based pledges at a higher level. With all these elements, you can perform the ethical alignment process to figure out what responsibility will look like in the context of the project when combined with other requirements on the table.

If the project involves external clients, the client should ideally be involved in the ethical alignment part of the project kickoff to ensure your definitions of responsible development match.

Responsible project kickoff with Pledge Works

The outcome of a responsible project kickoff is a project backlog or list of requirements in your usual format (e.g., if you’re using SCRUM, you might start with a backlog with user stories) with the addition of context-based pledges that you’re going to use to guide your project decisions.

You might use tools from the Pledge Toolbox to help you with ethical alignment during this stage. More important than the tools you’ll use, are the discussions you will have, ideally involving cross-functional teams and experts in different fields. If you feel you lack suitable ethical expertise, it is also a good idea to involve external experts and perspectives.

Responsible Implementation

Pledge Works implementation cycle

Pledge Works is an ongoing process that doesn’t stop with writing pledges on the project level. Just like existing agile practices, pledges adapt to your scope of work and change as a result of new learnings.

The Pledge Works implementation cycle has three main elements:

1. Write pledges in context: writing initial pledges should be a cross-functional team activity during which the team combines diverse perspectives with other project requirements (see the Responsible project kickoff section above for details) and defines the scope of work. Writing pledges helps the team reach a consensus of what responsibility looks like within the context of a specific project, epic, or sprint.

For example, if we agreed that protecting user privacy is important to our company, what do we pledge to do to ensure privacy protection on the new website we’re developing?

1. Seek better outcomes: once you have clarity on shared values and make pledges visible in your existing tools (e.g., product roadmap, sprint backlog), you can start using context- and role-based pledges to consistently challenge default outcomes. Your pledges become ethical requirements in decision-making and can be used to challenge user stories or tasks that break pledges or to celebrate user stories or tasks that uphold pledges. Taking individual responsibility for speaking up, regardless of job title, is key in this part and helps your team members train their responsibility muscles.

For example, when a request comes in to add Google Analytics to our new website, any team member can challenge it by referring to the privacy pledge and start a discussion on possible alternatives, making privacy a key requirement in the decision-making process.

1. Review outcomes together: despite your best intentions, you will be occasionally forced to make compromises and make decisions that break your pledges, or be surprised by unintended consequences and perspectives you missed. This is why reviewing outcomes and pledges as a team is an equally important part of the process. The review can help you update pledges and ensure you’re still moving in the right direction.

For example, we end up adding Google Analytics to the website because it’s not feasible for the marketing team to switch to a new analytics product by the time we have to deploy the website. However, we involve marketing in planning a company-wide transition to a privacy-first analytics provider and ensure we are transparent with our customers about current limitations and future plans. Both the development and marketing teams write new pledges to reflect this decision as a reminder of the promise we made to each other.

Let’s take a closer look at each of these parts and how they can be combined with existing processes.

1) Write pledges in context

At the beginning of a process (new project, initiative, epic, sprint), the team should take the time to write concrete and specific pledges related to the process you’re starting. You can make this part of your sprint planning sessions, project kickoff meetings, or other existing events you have in place. Just ensure you have a bit of time to think about what being responsible means within the specific context.

Questions you should try to answer while writing pledges:

• What are our business, user, and technical requirements?
• What are our constraints?
• What is our purpose? What values, principles, and pledges have we previously agreed upon?
• What does acting responsibly look like in our context?
• How will we know if we’re upholding each pledge?
• What trade-offs are we making? How will we mitigate them?

2) Seek better outcomes

The next step is to consistently apply your pledges to seek better outcomes. Here are some of the ways you can to this:

• Use your pledges as ethical requirements in decision-making.
• Challenge user stories or tasks that break pledges.
• Celebrate user stories or tasks that uphold pledges.

Having concrete pledges should help you start more ethical discussions and seek alternative solutions that lead to better outcomes. Rather than always going with what everyone else is doing (e.g., “add Google Analytics to the website”), use the pledges to challenge the default outcome and explore alternatives (e.g., “Do we even need analytics? Is there an alternative that is better aligned with our values and pledges?”). As you gain more clarity during implementation, you might even update your pledges or pledge checklist to be more specific and applicable.

It’s important to** keep relevant pledges visible** in whatever tool you use to keep track of your day-to-day tasks or to make product decisions.

Example: If you use a backlog in Trello or Jira, add a column that lists your pledges or add a “Pledge” label to pledge cards and add them to your sprint backlog among other cards. Apply the same principle to your high-level product roadmaps.

When you see a card in the backlog that breaks a pledge (either on the same level of granularity or higher up), you can bring it up in the comments, on Slack, or during standups and other meetings.

If you’re using a spreadsheet to make a decision, add the relevant pledges in the same spreadsheet for guidance.

Challenging product decisions with pledges might seem difficult at first but you can think of it as training your responsibility muscles. Additionally, the pledges help your team develop a shared language, which makes it easier to bring up questions when something feels off and to celebrate the hard work that goes into acting more responsibly.

Questions to answer during this stage:

• Is my work aligned with our pledges?
• Is there anything in the project that feels off? How does it relate to our pledges?
• Are we doing things the way they’re usually done without considering alternatives? Which alternatives might lead us to better outcomes we seek in our pledges?
• Are the decisions we’re making moving us in a generally good direction?
• Are we making any compromises? How will we mitigate trade-offs?

Seeking better outcomes on your own

Ideally, your company, product team, or clients would be on board with Pledge Works and embrace it at every step of the process. Realistically, we know that the adoption of Pledge Works likely won’t be fast and all-encompassing. This is why it’s important that seeking better outcomes can also be done bottom-up, starting from an individual who wants to take responsibility for their work.

As a tech professional, you can write your own set of role-based pledges. If you’re a member of an organization such as ACM, you can base them on their Code of Ethics. If not, you can write your own based on what’s important to you. (Hopefully more professional organizations and communities will eventually come together to create their professional codes.)

Once you have your pledges, you can publish them on your website, LinkedIn profile, etc., and refer to them when you see something problematic at work or when working with a client as a freelancer. It might not be as powerful as referring to pledges your company, team, or client decided to uphold beforehand, but it’s the start of a conversation. Referring to community best practices can also lend more weight to your argument if you can demonstrate something is frowned upon – or even forbidden – by your professional code.

3) Review outcomes together

And finally, you should also take the time to regularly review outcomes as a team. Most products end up being used in ways we didn’t anticipate or have unintended consequences. If you’re serious about taking responsibility for your products, for the choices you make, you also have to review outcomes and use them as inputs to improve your future decisions. A review is also an opportunity to be honest about the trade-offs you made and make plans for how you can do better in the future.

You should again include a cross-functional team in your review to capture diverse perspectives. You might even involve people using your product or being affected by your product to get a better view of the outcomes. If you see you’re missing a certain expertise, involve outside experts to help you with the review.

You can add the review of your outcomes to your regular review and retrospective sessions because determining the consequences of your product is just as important as the discussion on whether you delivered the promised business value.

Questions to answer during this stage:

• Did we meet the expected outcomes?
• Why not? (Use the 5 WHYs to questions)
• What was good?
• Should we update our pledges or outcomes?
• What do people outside our team say about our product? How can we involve these perspectives in our review and incorporate them into our pledges?
• Should we include additional experts in the review?
• What compromises did we make? How will we mitigate trade-offs?

Additional Resources

• Pledge Toolbox: a set of tools to help you write and examine your pledges from a wider ethical perspective.

Case Studies

• The Public Good: a web developer explains how Pledge Works helps them incorporate ethical thinking in their work, and uses the example of a company selling carbon offsets to show how writing pledges shapes decision making.