Equal Care Coop: Governance Through Design

Background

Equal Care Coop organized several co-design workshops using various approaches and with varying outcomes. The goal of the co-design was the creation of a platform that would support the autonomy of care receivers in building a personal care team, as well as for caregivers to be well-matched with care receivers and to find work for which they would receive a fair wage.

Rethinking Co-design

Equal Care’s experience of co-designing a platform demonstrated that design methods are decision-making processes – that the design of a system is an integral part of its governance. This is especially apparent in a worker-owned cooperative such as Equal Care, who through this process have demonstrated that ownership of the design through meaningful participation in its creation contributes to the overall governance of the organisation. In building their platform, Equal Care brought together the design of the platform and a sociocratic method of decision making. With this approach, roles, relationships and governance were able to remain experimental and flexible. Maintaining a level of informality allowed for this flexibility and allowed the group to create its own culture and ways of working with each other that best suits the needs of members. 

The design of the Equal Care platform enabled a structure and culture that acknowledges and validates labour that has been historically unrecognized and excluded. It allows family members providing care to realise that their labour is valuable and can be delegated to others through the platform, using the ‘hats’ mechanism of role distribution as well as through direct, unmediated communication with paid workers (commonly restricted by other care platforms). The platform in turn supports the agency of care receivers, who have the greatest stake in their care, to have a say in the design of the platform. When given the opportunity, many of these members stepped up to take part in the design process.

Equal Care’s Co-design Process

Summary

The following key elements of success emerged from this work:

• Building pathways of participation for members–through hats, teams and circles;
• Members learning and designing through direct engagement with the technology and the developer;
• Using a shared domain language–i.e. terms that have a meaning that anyone can understand, and functionality that starts off as “just a word”. For example, the concept of Teams started simply as WhatsApp groups entitled “Name of person’s’ team”, and the functions and practices of the teams grew from there, determined by the membership of each group. Then ‘teams’ appeared in the code as that functionality was built into the platform. This is the case for all objects on the platform, which also appear in Equal Care’s governance structures.

What Didn’t Work / Learnings

Phase I: Co-design Workshops

Due to a lack of funding, there was a long gap and therefore a disconnect between holding the workshop(s) and designing and building a prototype, resulting in the lack of a tight feedback and development loop. By the time something was built many of the original participants were no longer involved and couldn’t provide any feedback or further input. As a result, the co-design approach shifted to a ‘test and learn’, as particular elements of the model of care appeared in the platform

• Who was involved? 25 people over four sessions
• How many workshops? 4 initial sessions, many more after this with specific groups of people (stakeholders or roles) eg. team starters, advocate members
• What activities? Miro boards, printed prototypes, 121s, observing
• What outcomes? Service design flow, write-up of user research findings, flat prototype
• Any documentation? A platform-focussed Gitbook

Phase II: Community Circle

A sociocracy approach was used to create community circles including care workers, caregivers, and others with diverse backgrounds. Talking in rounds worked well – a co-design workshop with the circle inspired a lot of excitement and ideas. But ultimately the energy fizzled out and the approach could not be directly translated to tickets for feature development (although some did go onto the roadmap), because Equal Care did not have follow-on funding to do the implementation. However, ideas that emerged did get built in a no-code environment using SaaS (Jotform, Asana, even WhatsApp and vCita) – the collection of tools aptly named ‘Frankenstein. 

• Who was involved? Most people at EC were involved in this at the time, about 40 people
• How many workshops? 2 in the community circle
• What activities? Role exploration, permissions, drawing out the UI in small groups
• What outcomes? UI drawings, feedback, development of core roles, some of which found their longer term existence in the form of hats eg. matchmaker 
• Any documentation? Just workshop outputs at that stage

Phase III: Platform Council

A council was created made up of representative groups including members of the community, local partnership organisations, care receivers, caregivers, and someone who knew about technology. However it was too early in the coop’s development to succeed at creating a platform council – again, funding was an issue and additionally the members of the council, although representative of the coop’s membership groups, were not actually receiving or giving support with EC. 

• How many workshops/meetings? 8
• What structure or activities? Reporting + presentation + feedback
• What outcomes? Rich feedback from representative stakeholders
• Any documentation? Notes and presentations

What Worked

Through the co-design workshops Equal Care members learned that the design process worked best when it included building a prototype (no matter how rough) that workers could test out and provide immediate feedback on whilst being aware of the limitations. This required the participation of a developer who was committed to working as a member of the design team and to implementing feedback and ideas on an ongoing basis. This approach to co-design, which was more directly tied to governance through real-time design decision-making, was the most successful in providing tangible and impactful outcomes. 

The success of this approach was based on the confluence of 3 key things, with enough chaos in all 3 dimensions to allow folks to meet on level ground:

1. The existence of a platform. This included direct and easy access to and a relationship with the software engineer, and the ability of the engineer to quickly respond to feedback.
2. A clear governance structure.  Using the structure of a circle with a clear mandate and clearly defined roles within the circle (clear tasks and set of responsibilities for each member).
3. Operational impact. During the course of the platform development daily work was happening on the ground, enabling Equal Care workers to do what they needed to do and providing a real-time and real-life trial of the platform.

Governance by Design: Hats, Teams, Circles

After attempting different approaches to co-design, Equal Care landed on an approach to design governance (both governance through design and design through governance) with the idea of hats and teams and circles. 

• What is a hat? A hat is a role. A hat can be a non-professional role or situation in life (e.g. daughter, mother, brother, etc), a formal role (e.g. paid caregiver) or a governance-related role (e.g. team starter – see more about these roles below). Wearing a hat provides a step into ownership. 
• The ability to stack the hats that people wear was the key to unlocking cooperative governance, education, and confidence in being able to contribute to, produce ideas for, and actively engage with the design of technology.
  1. Stacking the hats means that any member of a team can take on multiple roles, may be part of more than one team, and may have different roles on different teams. 
  2. This allowed for sharing of knowledge across teams, particularly where one person who had worn a hat in another team could advise and assist someone newly wearing the hat in the team they were in. For example, a profile-holder role meeting up with another member to go through the process of updating the team owner’s profile in the platforn. Or a rota hat holder talking through their process over the phone with another member. Recently, “C” posting a suggestion into a shared chat to use the  :red_circle:  emoji to indicate shifts in the calendar that needed covering, helping them to stand out.
• In order to begin this process of stacking the hats, EC did the same thing as when starting teams in the first place: normalising the language, embedding it into policy, and posting about it in the chats as if it were already in existence. EC developed some larger hats / roles for the circles – Recruiter and Team Starter being the two essential ones that needed the most time and attention to develop. Once these roles were recruited for and filled, conversations about hats in teams started to open up more. The development of the hat cupboard then emerged from this process, and hats started being built into the platform e.g a profile holder has editing permissions for the team owner’s support profile. 
• The first circle was formed with 2 team starters, Emma, Kate, and a software engineer. Circle members had direct access to and over time built a relationship with the software engineer, who could see what was going on as they learned their role. As they did their care work the engineer built the functionality that they needed.
• Learn more about hats, teams and circles. 

Why it Worked

• Members were exposed to repeated platform development cycles and met regularly to talk to the developer to share feedback and input, including a lot of direct messaging over the platform
  1. This allowed for a very full and active free flow of ideas and resulted in an incredible transformation in care workers’ knowledge and confidence. 
  2. Workers started off with a very low level of digital competence and through this process began announcing new features and talking to other care workers about the process of platform development. 
  3. Team starters moved from saying “I don’t know anything about tech” to announcing features, suggesting designs, and reporting bugs. 
  4. This had a trickle-down effect to the rest of the membership and is the beginning of a real recipe for ownership of digital development in and amongst lay people within the coop members.
  5. A virtual office space tool called Gather played a key role in communication among members who were not co-located. References to meeting on the pirate ship became commonplace.
• Having one developer, though not ideal, provided an intimacy and connection that would not have been possible with a large development team. This did also limit the development pipeline and make it substantially more challenging than it may have been with, say, a team of two engineers.

Key Processes

Trust assessments and hat nominations are key processes making up Equal Care’s unique operating structure and approach. 

Trust Assessments

“Re-focusing on the importance of building trust and not losing sight of the bigger picture in our attitudes to risk.”

Learn more

Hat Nominations

“The purpose of hat nominations is to clarify, share out and make genuinely explicit the work associated with caring for a team.”

Learn more

To learn more about how Equal Care is organised and makes decisions, please see https://work.equalcare.coop.

For more information on Equal Care’s policies, please go to https://policies.equalcare.coop/.

Platform Technology

• The platform is a web app / website along with Rocketchat 
• Members sign in to their calendar and profiles
• API in the platform talks to Rocketchat via Discobot.
  • There is much potential to improve, when funds are available!
• The tech platform helped Equal Care to iterate and map the system of hats
• Development of  matching functionality, and member profiles is in mid-stage progress (as of December 2024)

Challenges

• As the coop grows it’s a challenge to develop features responsively
• The coop may be getting too big to be able to do the kind of “conversational development” that worked so well initially
• No longer building the foundation, but trying to build the house while fixing the foundation!
• The more features we have, the more chance there is of having bugs. Some features were built in a MVP kind of way and now it’s necessary to build those out. 
• It’s a bit of a setback to be teaching folks to use the platform, then have it break, as it becomes necessary to re-teach them. It is also hard to do all at once when people join. Having someone in a well-being role will help with this.

Current status

• People reach out to the developer (through chat or email) with a bug or with questions, or communicate  directly to Emma. Emma is working closely with with the developer and providing a buffer for him, and getting a sense of the mood and general tone of feedback.
• The calendar is released and working. Still with a to-do list but it’s functioning. The previous developer had been building it bits at a time, and was sitting down with two to three self-described “technophobes” as well as those comfortable with technology, and making changes based on those discussions. 
• Each member now has their own calendar and timeline showing support hours and hat work.
• Administrators add the hats and approve the hats (there is now a hat built for this – the hat-holder hat); this permission has been democratized.
• Now have a team of four doing design and development, and are unable to add more resources until more funding is available. 
• Have completed another round of co-design –starting again– using a Miro board and post-its to capture challenges with the matching process. Once co-design is complete will move into a freer exchange that was the pattern that the previous developer established. Have gone full cicle in many ways. The design process takes a long time, and a lot of resources are needed!