The relational tech approach centers the relationships of the people building, using, and funding a technology. If you're wondering why on earth we'd center relationships, check out Why We Need Relational Technology.

This page is a guide to the framework itself. I'll go over my process for creating and improving relationships, as well as my tools for unearthing hidden needs for individuals and for projects as a whole.

Let's get into it!

I believe that a good relationship is one where people feel comfortable sharing their needs, and where both people in the relationship can take a collaborative attitude towards getting those needs met, even when the needs are in conflict.

When working with clients, I operationalize this needs-based approach into "The 5 Cs":

The 5 Cs define an order for relationship-building, which can be adapted to any given scenario (a project seeking funding; a burned out maintainer; a community that wants to diversify; etc). That order is:

1. Clarify your needs

Before you can share your needs with others, you need to figure out for yourself what they are. I go into this in much more detail below.

If we can't clearly articulate our needs to ourselves, we surely can't articulate them to others. And any attempts to connect with people who can meet our needs (the next step in the process) will be inefficient or ineffective, because we won't even know what we're looking for.

2. Connect with people who can meet your needs.

In the next step, we identify people who can potentially meet our needs. We try to form new relationships with them, or, if we already have relationships, adapt them as needed.

When it comes to forming new relationships, our approach will depend on the context. This step might look like:

• a project that wants to get in touch with their users putting a request to connect in their release notes, or searching for mentions/uses of their project on github and gitlab or social media
• a project that needs design help connecting with a community like open source design
• a maintainer who wants more core contributors talking to potential contributors at a sprint or meetup
• a project that needs funding reaching out to the larger organizations or companies that use the project

Changing existing relationships can sometimes be harder than forming new ones, especially if you feel vulnerable about the needs you're trying to get met. But you might be surprised just how open your existing connections are to changing the way you interact. Maybe they've been hiding their needs, too.

Which brings us to...

3. Communicate your needs to each other.

In a relationship, both peoples' needs are important. So in addition to communicating your needs, we'll need to ask our conncetions to share their needs, too.

This can be very straightforward, but it isn't always. People need to feel psychological safety before they can express their needs. This can take a lot of time, or a little—feelings of safety are very context dependent. In addition to depending on the personality of the people involved, and the environment, it also depends on the need. Some needs tend to be easy to share, like asking for the answer to a question. Others tend to be much harder, like asking for money or for help with burnout. But even "easy to share" needs can be hard. Plenty of people are too shy to post a question to a chat full of strangers.

4. Navigate conflict between your needs and their needs.

When people start sharing their needs, inevitably you will discover that some of those needs are in conflict. In a healthy relationship, conflict is neither avoided nor escalated.

It's pretty easy to look at two people screaming at each other and say "Yikes! Conflict! That's not good!" But conflict avoidance can be just as unhealthy. It leads people to suppress their needs, for fear that sharing those needs would provoke a conflict that could hurt them, or you, or the relationship.

A healthy relationship is not the absence of conflict; it's the continual working through of conflict with warmth and connection.

In other words: conflict acceptance, not conflict avoidance.

Identifying conflicts proactively, before they've caused anyone a ton of stress or pain, keeps them from escalating. And for already escalated conflict, a focus on the underlying needs can help calm things down. This is especially true when all sides can acknowledge that everyone's needs are valid, regardless of whether the proposed solutions for meeting said needs are harmful or simply impractical.

The ability to work through conflicting needs is one of the most important skills a person can have. Practicing this skill in the context of your open source project will benefit you in many ways beyond open source.

5. Commit to meeting each other's needs.

Commitments often feel risky. What if something changes, and your commitment is now in conflict with something really important to you? Well, if you've learned to handle conflict healthily, you'll be able to navigate a changing commitment. We can't eliminate the inherent uncertainty of life, but we can help each other be confident that when life throws us curve balls in the form of new conflicts, we will navigate them with care and grace.

---

By following these steps, we can create relationships where we feel comfortable sharing our needs, where we embrace and address conflict rather than avoiding it, and where we can commit to and show up for each other.

We can create good one-to-one relationships, and a good 'group relationship'—that is, a good community culture.

All of the steps in the 5 Cs are important, but the first—clarifying your needs—is the most foundational. If you can't do that, you can't do any of it!

In order to correctly identify our needs and create relationships with people who can meet them, we need to embrace a lot of things that have been dismissed and devalued.

In open source, we way over-value coding skills. Sure, coding's important, but the biggest problems open source projects face are not due to a lack of coders but to a lack of other skills, such as fundraising, marketing, design, user experience research, project management or community management.

Why are we devaluing the things we need the most? Why are we making our already overwhelmed maintainers, who usually have no training in any of these things, serve as user support staff, lead designer, event planner, marketing expert and everything else? We could instead be welcoming people who already have those skills—or want to grow those skills—into the open source community (for instance, via a whole community sprint).

One tool for helping us identify needs that have been devalued is the Visibility Spectrum exercise.

Some work within a software project is celebrated. Designing and building a new project from scratch, or adding big features to an existing project, is enjoyable and often prestigious work. Other work is visible, but not often celebrated, like adding tests or documentation to a project.

Some work that happens in a project is invisible - only a few people know it's even happening. For example, a community manager might have a a one-on-one conversation with a community member who has been causing trouble, to find out what's going wrong.

Some work is not just invisible but missing entirely. Maybe a project is difficult to use. They need help from someone who can do user research and user design. But no such person exists in the community, and no such work is being done.

Finally, there is work that isn't done and doesn't need to be done. For example, an open source project probably doesn't need a gardener's help getting it planted (unless it's some kind of open source gardening project). We can call this work unnecesary.

I use the metaphor of a spectrum because sometimes these categories bleed together at the edges. If ten people in a thousand person project know that a kind of work is happening, is it visible or invisible? If a kind of work could maybe be useful but surely isn't vital, is it missing or unnecessary?

The point of the spectrum is to help projects think about the work being done - and the work not being done - in their project. Does it actually meet all their needs? Is their work that should be more visible? More celebrated? Are there things the project needs that don't currently get done at all?

Below is a table showing many different kinds of work. I've bucketed them into the five parts of the spectrum based on typical patterns in open source projects, but every project is different. A good exercise for projects is to take the full list and put them into categories together. Where does each task fall in your project—and are you happy with that?

(Do you have tasks that you think should be added to this list? Let me know!)

You might notice, when looking at my buckets, that a whole lot of the 'invisble' work is highly relational. Relational work is vital to project success. And yet it's often done quietly, behind the scenes, with no reward or support for the people doing the work.

You might also notice that a lot of the "missing" work is work that would connect contributors to users and funders. Few projets have anyone doing user research or applying principles of user-centered design. User interactions are often limited to answering questions in help channels, mailing lists, and issue trackers. Similarly, connections to funders are often limited to creating a patreon or open collective account and hoping people decide to donate.

This is not a failure of individual maintainers or communities. It is a failure of our ecosystem as a whole, for not actively welcoming in people with a diversity of backgrounds, interests, and skills.

For open source to succeed, we need to embrace our whole selves: all of our needs, and all of the many kinds of people who can help us meet them.

.

It's hard enough to identify overlooked parts of our projects and communities. It's even harder to identify overlooked parts of ourselves.

Many people are taught to suppress and dismiss their emotions. This is especially true for men, who make up a disproportionate percentage of the open source community, but it's true of many women and non-binary folks as well.

It was true of me. It took me ages to realize I was dismissing my emotions. Fun fact: I used to work as a neuroscience researcher, using fMRI technology to study emotions. "How can I be dismissing them?" I would have protested. "I know they're important! I'm spending all my time studying them!" Friends, this is called 'cognitive bypassing'. It turns out thinking about emotions is very different from feeling them.

We need to feel our emotions in order to understand our needs. Emotions are the best information we have about what our needs are and whether they're being met.

If you feel exhausted every time you look at your issue tracker, you have needs that are not being met.

If you get jealous of people who are paid to work on their projects, you have needs that are not being met.

If using a piece of software makes you want to throw your computer across the room, you have needs that are not being met.

If watching people flock to Facebook and Twitter instead of platforms that value their privacy and autonomy makes you die inside, you have needs that are not being met.

If you want to grow your community, but are overwhelmed by all the new responsibilities that would be involved, you have needs that are not being met.

Every single emotion we feel is a pointer to an unmet need. We can't always follow the pointers. In fact, for those of us who've been taught to dismiss our emotions, we often can't follow the pointers. It's like a faulty garbage collector was installed in us early on, one that takes away the pointers—that is, the emotions—before we're ready. Before we can follow them to what we need.

But, with practice, we can get better at following the pointers. And, if you work with me, I am going to ask you to practice. I will ask you how you're feeling, and how that might relate to your needs. Maybe just casually, in conversation—or, if you're up for it, we can go through my needs assessment exercise. That exercise is a more structured way of helping you understand your needs by listening to your emotions.

You might be wondering how all of this high level conceptual stuff ties in with the specific services I offer.

Each of the pages on the individual services I offer (e.g. leadership pathways, whole community sprints, etc) goes into detail about how I customize the 5 Cs approach to address specific problems, and all of them involve some kind of needs assessment.

Rest assured that I am not dogmatic about this framework. Like any abstraction, it has limitations and flaws. I'm always ready to adapt to client needs—and I strongly encourage clients, or people who've applied this framework on their own, to give me feedback about what didn't work.

The most important thing about this framework, and the only thing I won't compromise on, is this: my unwavering belief that everyone deserves to have their needs met.

And yes, that means you.