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 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 and form new relationships with them, or strengthen existing relationships.

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 them

This list of potential approaches is endless. I'm still very much learning myself, but I am always adding new ideas to the list.

Changing existing relationships can sometimes be even harder, especially if you feel vulnerable about the needs you want to get met. Asking an existing contributor if, for instance, they'd like to co-work regularly so that you can meet your social needs might feel very intimidating.

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 for a long time, too.

Which brings us to...

3. Communicate your needs to each other.

In a relationship, both peoples' needs are importants. 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 in order to 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/situation, 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 room 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 "Oh, 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. Especially if there can be acknowledgement from all sides that everyone's needs are valid (although the proposed solutions for meeting said needs may be 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 likely 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 less 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 not to quibble over exactly how to place each type of work. It is, instead, to help projects think about what work is being, or could be, performed in their project. It is to help them think: should this be more celebrated? More visible? Is there something we need to do, that we don't currently do 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 better exercise for projects is to take the full list (plus any other kinds of work they'd like to add!) 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. Relatively few projets have anyone actively doing user research or applying principles of user-centered design. User interactions are often limited to answering questions in #getting-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 stumble across it and 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.

My point is: I get it if focusing on your emotions, especially in a professional context, feels sappy and wrong. Typing these words right now feels sappy and wrong. But the words are still true.

We have to listen to our emotions because our 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 irritated by questions about how your project works, 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 a little 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. The needs assessment exercise I do with many of my clients asks about emotions directly and indirectly. If that sounds awful to you, we're probably not a good fit. If it sounds good but scary, just let me know, and we can ease into it.

(That said, I am not a coach and I am definitely not a therapist. If you're really struggling to get in touch with your emotions, I highly recommend working with a trained professional. It's been invaluable for me.)

Sometimes, as a freelance programmer, I would have clients ask, "Can you write some code that does X?"

My answer was never "yes" or "no". It was "Why do you want code that does X?" In other words, what need does that serve? Often, the client was unclear about their own needs, and figuring out what they truly wanted sent us off in a completely different direction. If I hadn't asked about their underlying needs, we would have wasted a lot of time, money, and code.

That's why I always start by clarifying needs. You may come to me for help finding funding and realize you actually want to wind your project down. Or you may want help building a big community but what you actually need is just a few dedicated collaborators and a more social work environment.

Or maybe what you think you need is what you actually need. That's great too! Some people are blessed with great self-knowledge and if that's you, we can move quickly on to the next step in the process.

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/visibility exercise.

Rest assured that I am not dogmatic about this framework. Like any abstraction, it has limitations and flaws. I'm always ready to adapt or diverge as needed to meet 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. Even if we can't meet a need of yours, it's still worth acknowledging and validating that need.

One final note about this approach: it's not a quick fix.

Back in 2019 I gave a talk at PyCon about Python's governance transition from a Benevolent Dictator For Life model to an elected steering council. In preparation, I looked at the history of Python and interviewed several people who'd been involved in the process. It became clear that while the transition from BDFL to steering council happened relatively quickly (6 months, from July 2018 to January 2019) the structure and culture that enabled the transition to happen had been put in place over decades.

Now, I'm not saying change will take decades. But it can take months or years. You'll have to be patient, and committed.

You'll also have to be brave. Saying "you should share your needs!" is easy. Actually doing it can be very, very hard. But you don't have to do it alone.

The world needs open source communities that are living their values not just in the license they pick but in the relationships they have and the culture they cultivate. And you deserve to work on projects that bring you joy and meaning.

That is the end goal of the Relational Tech approach: joyful communities of people living their values and doing meaningful work—together.