Author Archives: Andrea Middleton

Currently at Reddit, I spent 10 years as a community organizer on the WordPress open source project. I'm also an avid reader, wine enthusiast, and parent of two.

The people you’re leading have changed

michael barbaro: You’re saying the British people saw this as a moment to look in their prime minister’s soul, and they don’t like what they’re seeing?

mark landler: That’s right. I think that some of what was acceptable two years ago in a new environment, in this serious post-Covid, post-Brexit world somehow doesn’t look as acceptable anymore. The hypocrisy that could have been laughed off earlier can no longer be laughed off.

And so I think that’s really, when you get right down it, what’s happened to Boris Johnson. He hasn’t changed, but the people he’s leading have changed. And crucially, they’ve changed how they view him.

From How Partying Could Be Boris Johnson’s Undoing, on The Daily

We’re coming up on the second anniversary of when COVID started changing the world, friends. As experienced leaders know, the body remembers — and very often has a better alarm system than our over-stimulated, distracted brains. This means that you, along with everyone in your team, community, family, and organization, are sailing into a storm of possibly subtle, but irresistible emotional turmoil. 

I know, count on me for a sunny outlook, right?

Now, we’ve been through this before. If you look back at your notes, or think back to what it was like to collaborate with humans this time last year, you’ll see a lot of what you’re likely to see in the coming months: “wow so many people struggling,” “that project got unexpectedly complicated,” “things going really slow/fast/sideways right now,” “something’s off but I can’t figure out what.”

Yep, more of that is on the horizon. But wait, there’s more!

Listen: everyone you know has now been through 2 years of trauma. THE WHOLE WORLD has suffered two years of trauma, and that trauma was laid on top of all the trauma and suffering — from systemic oppression, from climate collapse, from economic inequality, from everything else that’s already painful about life — that was already happening!

During any given stage of this pandemic, everyone you know has thought about how they might die, sometime soon. Loved ones have died, or become incapacitated by long COVID. We’ve been robbed of rituals, celebrations, and traditions, at a time when we needed them most! Decisions about going to a party have become, unpredictably, life-and-death decisions. WTAF.

Person Wearing Grey and Orange Hoodie Sitting on Brown Wooden Park Bench during Daytime
Photo by Serkan Gu00f6ktay on Pexels.com

We lucky people who have survived this pandemic so far… we have adapted. I love how adaptable humans are; we survive things that we don’t even think we can survive. At work (unless your work is healthcare and if so, I can’t even start to express how grateful I am for your work and how sorry I am that it’s so awful these days) or in your family or community, it might even have felt like you were getting “back to normal,” or “back to business.” And we’re so eager for that, right? For the trauma to end, for all this nonsense to just be over. 

But leaders, remember: adaptation is change. To survive this terrible time, everyone in the world has had to change.

We didn’t want to! In many cases, we hate that we’ve changed. In many other cases, the change has been unexpectedly meaningful and freeing. AND, if you try to act like things are normal (even “new normal”) right now, you are going to screw it up; maybe you’re already screwing it up, and you just now realized how. 

So here’s my thought: what if we approach these next few months as if we’re starting anew? Find all your assumptions — assumptions about your work, your community, your family, your organization, yourself… go as far as you dare. And then question them ALL. 

Woman Looking at Sunset
Photo by Pixabay on Pexels.com

Get to know your people again, as if for the first time. Ask them if they need different things from you, the team, or the community. See if they want to work on something else, or explore a different approach to their work, or a new part of your organization. Review your leadership tools, and see if you’re still using the right ones. Get flexible in new ways. Rethink your old plans, to see if they fit with this new world we live in. 

And while we’re on the subject, these next few months are probably the wrong time for your sunny-rah-rah disposition to be a primary leadership tool. Suffering is everywhere these days: stinky, despair-tinged, anxious, exhausted, “I don’t know how I get through this” suffering. Promising that everything’s going to work out… is not helpful right now; it’s tone-deaf. We haven’t been fine for a very long while, thank you very much. 

Bree Newsome is an amazing writer, producer, activist, artist, and consultant.

We survive best by staying connected. You can’t fake connection, so turn up the volume on the respect and authenticity you bring to your work and conversations. Connect with your people in their struggle, hold space for their pain, bear witness to their suffering. If you can do so without making everything about you, share what you’re wrestling with as well. Don’t try to fix them; cherish your people *in* their pain, and stick with them as they navigate it.

The only way out is through; let’s all work toward coming through, together. 

Letters to an open source contributor: Trust

Open source software projects depend on a large group of passionate “do-ers,” who collaborate online to build or improve something that they all care about. Connections between contributors is frequently tenuous; you’re reviewing code or designs or discussing UI with people you may have never met or seen, and maybe never will. But you want to work together, toward a common goal, and working together requires trust.

Image from The New Yorker cartoon by Peter Steiner, 1993

It’s not easy to build trust among strangers via the internet, but it’s not impossible, and it’s worth your time. Strangers-on-the-internet-trust is fragile, though, so this is primarily habit-building work. Here’s my advice on how to build and keep trust in an open source project:

Be reliable

If you only take one piece of advice from this article, let it be this one. Trust is built, sometimes imperceptibly, by engaging in predictable, repetitive positive behavior over time. Even if you do not *intend* to show people you are trustworthy, if you repeatedly keep your promises, people will start to trust you. Predictable behavior makes people feel safe, so people will tend to have a more positive impression of reliable contributors, as well.

Warning: this goes the other way, too! If you repeatedly *fail* to keep your promises, or unpredictably attend meetings/give feedback/respond to comments, then people will — usually unconsciously — decide you are not trustworthy. Open source communities tend to be skeptical already, so it’s particularly difficult to prove you can be trusted, if you are not reliable.

Now obviously, the best laid plans “gang aft agley.” And a contributor community is made of humans, so they know that sometimes emergencies or unexpected things happen. If something comes up that will affect your ability to keep your promise, or delay your ability to do so, then you just need to tell people in advance. And if you can’t do something that affects other people’s ability to do work, then you need to find someone to cover for you, in advance.

If you don’t find someone to cover for you on some urgent or important work, it’s possible that someone else will jump in and handle it (this is an example of leading at any level). You’ll be tempted to think that, because people kept working despite your unreliable behavior, that the unreliable behavior had no impact. Wrong! People remember when you don’t keep your word. They will probably forgive you and they may keep liking you, but the trust they had in you is damaged. The more unreliable you are, the harder it is to convince people that *this time* you can be trusted.

Be realistic

Important! This is the most pernicious pattern I see, among well-meaning contributors.

Don’t give your word if you can’t keep it.

I know you want to do it all, I know it’s all important, I know people need help. But you do absolutely no good when you make promises that you can’t keep. In fact, you do damage to the effort, because you’re taking a contributor spot that might have been filled by someone who did have the time, but was just too timid to speak up, or was waiting to see if they were really needed. It’s harder to hand off work that you can’t do after all, than it is to get someone to do work that no one was doing in the first place.

Underestimate how much time you’ll have, and then work from that expectation. Doing more is always welcome, but doing less will cause problems for others. Even if you mean well, you will still lose trust by over-estimating your available time or skills.

Be consistently genuine

People don’t trust liars, for good reason. If you lie or try to deceive people in an organization, two things will happen:

  1. Word will spread. No one likes being deceived or manipulated, and they will complain to SOMEONE. This is prime gossip material. Open source communities are like small towns: we have no secrets.
  2. People will stop believing your word, even if you didn’t lie directly to them, AND even when you are telling the truth.

You can build trust back up after you’ve been reliable for a while, but overcoming your reputation as a liar is incredibly difficult. The best approach is to tell the truth or, if there’s a good reason you can’t, then say nothing at all. Smart people will hear both what you say and what you do not say.

Be generous

Weird, right? But people want to trust people they like, and people like people who help and care about them. So in order to build trust in an organization, be as generous as you can be: with your time, your feedback, your support, and your praise.

Photo by Zen Chung on Pexels.com

While we’re here, remember that one way to act “stingy” in open source is to take more than your share of credit for work. By lifting other people up higher than yourself, you demonstrate a generosity of spirit — humility, really — that shows up as a gift in open source.

Be generous with your attention, as well. People are more inclined to like and trust someone who is genuinely interested in their goals and well-being. Ask people how they’re doing, and remember details about their lives. Tell people when you notice they’re doing great work — and notice that great work in public, too.

What did I miss?

I’ve definitely fallen into a few of these patterns myself, so I know how easy it is to do. What are some other ways you see people making it more difficult to trust them? How do you judge whether you can trust someone? Share your thoughts in the comments!

Click here for more letters to an open source contributor

Letters to an open source contributor: Leadership

Much of my work in WordPress over the past decade has involved coaching and training leaders working in open source, and as I wind down this part of my career, I find I have a lot to say on the topic! I’m going to try to follow my own advice and be brief here, but I do not promise.

If you’re just getting started hearing me talk about leadership, I recommend a previous post of mine: What happens when you won’t admit (or don’t realize) you’re a leader. That piece resonated with a large number of people I’ve worked with in WP, so I’m recommending it as supplemental reading for this article.

Oh! And the other important thing to know, going into the leadership advice I will share below, is that I firmly believe in leadership at any level of an organization. Open source embraces this idea, in that our organizations are usually less hierarchical and, because the work is accomplished by the people who show up at the time, more fluid when it comes to who we look to, when we’re navigating a problem.

So! With those ideas in mind, let’s dig into more advice for leaders in open source.

Don’t make yourself indispensable

One of the most powerful things I’ve learned from Josepha is that

If you can’t be replaced, then you can’t be promoted.

– Josepha Haden Chomphosy, Executive Director of WordPress

I know, I just told you that open source isn’t very hierarchical, and I wasn’t lying. This concept applies to flat/open source organizations more like this:

If you can’t be replaced, then you can’t ever work on cool new stuff. Because if you do, all the cool old stuff you built… will end, or break.

Teaching people how to do the work that you do? It’s time-consuming, and can be a real challenge. But the people who do this — who document their code, who design in public, who create a succession plan and train their replacements — those people get the best that open source has to offer. They get to create amazing new features, programs, events, etc… and then they get to see those things keep growing, even when they move on to the next thing.

Recruiting, training, and cultivating your successor will make you much freer and more nimble, in an organization. It’s also the best way to ensure your work has a lasting effect.

Love your beginners

Photo by Ron Lach on Pexels.com

If you want your project/initiative/coalition to grow, you need to welcome new people into it. One of the things about new people = they don’t know everything yet. Don’t fall into the trap of thinking that ignorance is the same as stupidity — answer questions (even the ones you answer a lot!) with warmth and grace.

Also, be aware that beginners are a rare and valuable resource. They see things with fewer preconceived notions than the people who’ve been around for a long time. They question things that tenured contributors don’t even notice anymore, or have given up complaining about but still dislike.

Beginners are also an endangered resource! If you can get them to stick around a while, and train them for a while, then guess what? They’re not beginners anymore! So be sure to engage with your new people while they’re still new, and can help you fill in some blind spots or clarify where your outreach or messaging is still confusing.

Open source your decisions and thought process

Working in public is one of the hardest things we do, in open source, but profoundly worthwhile. Transparent processes and work patterns result in well-documented decisions, which lead to higher-quality contributions in the future.

I had this realization a few years back, when I was complaining (not for change, btw) about how many suggestions my team got, that didn’t demonstrate an understanding of what our work was about, or why things were set up a certain way.

“Why don’t they understand that [thing that was obvious to me at the time]?!?,” I fumed. And then it hit me: BECAUSE I HAD NEVER TOLD THEM.

Me, about me.

When you keep your concerns, doubts, convictions, and theories private, then the people who show up to collaborate with you… are slower to connect with both you and the problems you’re trying to solve together. Maybe so slow that you never connect in the first place.

But thought leadership can scale pretty elegantly, if you are willing to work in the open and diligently share your goals, observations, reasoning, and philosophies. It’s not easy, but it works.

Play the long game

Things tend to move slowly in large organizations, even if you have all the power in the world. Groups with broad impact are powerful but tend not to be nimble. So you will run into a roadblock or traffic jam in something you’re trying to accomplish.

When this happens, try not to force it. Do your best to take the long view, and bide your time. I have accomplished a lot of things in WordPress that I wasn’t sure were possible, sometimes simply because I stuck around longer than the people who were blocking my progress.

Be patient, pace yourself, and keep a few ideas on the back burner, for when conditions might be right for them. The story only ends when you stop writing it.

Looking for more advice?

If you’re joining this open source advice series in progress, you might enjoy the other articles, too!

  1. Intro: Letters to an open source contributor
  2. Communication
  3. Collaboration
  4. Criticizing for change

I think I have a few more of these articles in me, so stay tuned!

Letters to an open source contributor: Criticizing for change

This post is subtitled “criticizing for change” because not every criticism is fueled by a desire for change. Some arise because someone is having a rotten day, looking to connect over a shared experience, or even declaring what they value. Treating all criticism equally is as big a mistake as ignoring all criticism.

But this post is for critics, not those being criticized. More specifically, this article is for those of you who see things that you think are wrong in open source, and want tips for sharing your critical feedback in ways that that are more likely to result in a change.

The bigger the change, the longer the game

Photo by Krivec Ales on Pexels.com

Organizational change takes time. Big-impact changes take time. Big-impact changes in large organizations take a LOT of time. Change advocacy can be tiring, so I recommend taking the long view and setting yourself smaller, more attainable goals that will pave the way toward your ultimate goal. If you can, if you are privileged enough to have the time and stamina, pace yourself.

Avoid personal attacks

Some open source projects like WordPress have fostered a deeply connected, engaged community of contributors. Open source is also deeply vulnerable to the Five Geek Social Fallacies, which can lead the group to close ranks around a community member if that person is criticized or attacked, even if that person has done bad things.

This doesn’t mean that you can’t say, “this person’s behavior was terrible.” You can. But if you lead with “this PERSON is terrible” and point to their behavior, you will lose a lot of people before you even get to your examples.

For better or worse, repetitive critiques of a particular person or people result in diminishing returns. The reason I encourage people to love their critics is because most people start ignoring messages from “a complainer” or “someone with a grudge,” after a time. If you’re playing the long game and working toward change, then remember to criticize the behavior, not the person.

Build coalitions

In open source — and probably everywhere — it’s easier to get people to listen if you are speaking as part of a group, instead of a lone voice of dissent. This doesn’t mean lone voices of dissent are any less correct, or that a group is guaranteed to be right. I’ve seen large groups of people who were wrong, in open source, and been part of groups that were wrong, myself. That’s just part of being human. (Unfortunately. I sure do love being right.)

That said, building a coalition is the most effective tactic I know, to successfully accomplish change in an organization. Convincing other people of your idea’s merit on a small scale demonstrates a plausible promise. That plausible promise helps more people take your idea seriously. As you continue to test the idea with more people, presumably the idea gets refined and improved, helping it fit better into the fabric of the project. Eventually, the idea builds enough momentum that it takes on a life of its own. By the time that happens, you can usually just sit back and let the organization grow into the change.

Optimism FTW

Open source contributors are optimistic — you don’t put the time into contributing to a project that’s bigger than you, unless you have hope that your work will have an impact. Our work is fueled by hope, and our hope fuels our work. In contrast, advocating for change can be discouraging, which can lead to cynical or despairing attitudes.

I hope this goes without saying, but I’ll say it anyway: you’re going to have a really rough time getting inherently optimistic people to want to work on a change that comes with the message that “we’re all doomed.” And if you believe, down deep, that nothing’s going to help, then you’re probably not criticizing for change in the first place.

Either way, “this idea could make us great!” is a much more motivating message than “this idea could make us less terrible!” Tap into that open source optimism, and let it give your idea wings.

Pragmatism is powerful

It may be that the change you’re suggesting is morally right. I hope it is! But remember that what’s considered morally right… varies between different cultures. And most open source projects include contributors from many different cultures — WordPress certainly does. So I recommend against relying on the argument that “it’s the right thing to do.”

Instead, focus how the change you seek will help the organization move closer toward its goals. Warning: this does require you to understand what the goals of the organization are! But if you don’t know that already, then pause until you learn them. You never know… what you identify as a bug, might actually be considered a feature!

What did I miss?

Any other tips for our change-makers? Does something I’m saying sound wrong to you? Share your advice or ask questions in a comment on this post!

Letters to an open source contributor: Collaboration

You don’t have to want to collaborate to use WordPress to do great things. You DO need to collaborate if you want to do great things in the WordPress open source project, though.

Collaboration isn’t always the fastest way to accomplish something, but I think it is the best way to accomplish things that have a huge impact. Most people are called to open source contribution because they are impact-driven and know that by working with lots of other people, they can grow their own skills and make better decisions/products/programs. Also, it’s fun!

So here’s some advice I find myself sharing semi-frequently, on collaboration in open source

Love your critics

Now don’t get me wrong — I don’t like being criticized; I hate being wrong, and I hate thinking that someone things I’m wrong even more. AND….

Don’t make the mistake of throwing away valuable feedback just because someone is angry or shares opinions you don’t agree with. You probably don’t know everything (and if you do, I wish you’d write it all down so I could, too!), so even mean feedback is data.

Photo by Anete Lusina on Pexels.com

If you accept the notion that good ideas can come from anywhere — a foundational idea in open source, fwiw — then it’s criminally stupid to decide to stop listening to someone, just because you don’t like what they’re saying.

Beyond avoiding dumb moves, sometimes critical feedback is immensely useful. You can use it to check in with fellow contributors to see who shares the same ideas but just hasn’t been brave enough to say anything. You can use it to learn how you might be mis-communicating or misleading people in your communication. You can use it to fill in your own blind spots.

All that to say, don’t write people off as trolls unless they’re abusive, making personal attacks, or inciting violence. In open source, as in many other places, resilience in the face of criticism will make you much more effective, longer.

Assume smart predecessors

This is a twist on “assume good intent,” which I probably should have included in my Communication article.

I often talk to open source contributors who have found an organizational dysfunction and are passionate about fixing it. They come at the problem from multiple angles, talk to all sorts of people about their ideas for making things better, and keep running into roadblocks. It might be that others see the problem and have learned to work around it, or that fixing the problem isn’t a high priority right now. It might be that people disagree there is a real problem. Regardless, it’s frustrating for all involved.

My advice: when you notice an inefficient or “broken” thing in an organization — whether you’re just getting started or moving deeper into the group — get curious and ask yourself a few things before acting:

  1. Am I the only person who notices this, and if so, why?
  2. Who else experiences this problem?
  3. Has anyone tried to address it in the past; if so, what did they try and why did it fail?
  4. Do I have the agency/authority/expertise to fix this? Who does?
  5. What does this “broken” thing fix, in the organization?

That last question is the most important one. Here is a truth: no organization tolerates broken processes unless those “broken” things are actually functional for some person or group. That doesn’t mean that anyone intentionally set it up that way — almost always not! — but if it’s persisted for a while, then this broken thing is fixing something, somewhere. And until you know who benefits from the inefficient process, you have at best a 10% chance of success, in changing it.

In your zeal to contribute, don’t assume you are the first smart or perceptive person to join an open source project. This doesn’t mean you don’t have the “right” answer! but do yourself the favor of learning from tenured contributors, and spending your energy wisely.

Start small and iterate

Mighty oaks from little acorns grow!

Photo by Eriks Abzinovs on Pexels.com

Open source is very friendly to new ideas and experiments. But when you work on a large scale, or in a large project, it can be hard to discern how and when to experiment. If you are still working on building trust with other contributors, the best way to try out a new idea is on a small scale at first, but in a way that can scale if your experiment is successful.

The best open source experiments start out by answering these questions:

  1. What problem are we trying to solve?
  2. What theory will we test in this experiment?
  3. How long will we test this theory?
  4. Who will participate in the experiment?
  5. Who needs to know about this experiment? Who needs to agree to it?
  6. How will we measure the outcome of our experiment, in a way that tells us whether we’ve solved the problem?
  7. If this causes an unforeseen problem, how will we gracefully end the experiment?
  8. Where will we communicate about this experiment?

You can limit the impact of an experiment’s failure (to the organization and other contributors) by offsetting risk and scope. If the impact of an experiment’s failure is likely to be low, then the scope of the experiment can be more broad. If the impact might be high, then the scope of the experiment should be more narrow. 

What did I miss?

Does this all make sense? Is there another tip for effective collaboration that you wish more people knew? Add your advice or questions in a comment on this post!

Letters to an open source contributor: Communication

Josepha likes to say, “all problems are, at their heart, communication problems,” and I couldn’t agree more. The most powerful tool in your open source toolbox is not an understanding of code or usability, but rather the ability to express yourself and understand what other people are trying to say.

Here are some qualities I have observed among highly successful contributors in open source:

Brevity

Avoid “walls of text,” long paragraphs, and complex sentences.

Inexperienced or insecure contributors sometimes try to establish credibility or persuade their audience by writing a LOT of words. This is a mistake. Verbose communication requires people to work extra-hard to understand what you think or want. By the time they think they understand you, they are likely irritated that they’ve had to work so hard, or they have untested assumptions about why you’re burying them in words.

This is not easy advice for me to follow, because I love words and complex sentences! So when I’m writing to communicate in open source, I make a first draft and then cut words and sentences as far as I can. I sometimes joke that most of my writing time is actually spent deleting!

In open source, time is short and information overload is constant. You appear aggressive and disrespectful when you only communicate in long, complex messages. Be kind; be brief.

Humility

Don’t try to establish credibility by trying to appear smarter than other people; it just makes you look like a jerk. No one wants to work with someone who brags about their skills or calls attention to other people’s ignorance.

Photo by Magda Ehlers on Pexels.com

No one was born knowing any computer language, or any fact, about open source or WordPress. Even if people were snotty to you as you were learning — remember how bad that felt, and don’t perpetuate the pattern. Rise above, and be kind to those who know less than you.

Showing off rarely makes you popular in open source, but humility and helpfulness nearly always do.

Consideration

Open source projects are, if they’re lucky, global organizations full of very different people. Working in the open, with lots of people who are very different from you, is a great way to build something extraordinary.

Photo by Dio Hasbi Saniskoro on Pexels.com

To communicate effectively in those conditions, you must consider how your messages will be received by people from many different backgrounds and cultures. This isn’t just about refraining from slurs, swearing, broad generalizations, and gendered language — though, please avoid all that too! Really, I mean it!

But considerate communication is also:

  • thinking about how to include more people into the conversation, regardless of time zone,
  • allowing enough time for people with different availability to join a discussion or project,
  • assuming positive intent,
  • using group Slack pings sparingly, and
  • thinking about how people will feel, when they read your message(s).

We also communicate considerately by focusing our criticism on the problem, rather than the people. Personal attacks won’t get you anywhere that you really want to be.

Over and above

For even more open source/WordPress communication tips, check out these lessons from the WordPress contributor training course!

What did I miss?

Hey, other experienced open source contributors, what else do you think people need to know, about communicating successfully in open source? Add your advice in a comment on this post!

Letters to an open source contributor

As mentioned, in September I’m leaving Automattic and my full-time role supporting contributors and programs in the WordPress open source project.

(I’ve been overwhelmed by the number of people who’ve taken the time to tell me that I’ve had a positive impact on them or on their experience in WordPress. Thank you so much, friends! It means so much to know that I made a difference.)

Also as mentioned:

One of kinds of “invisible” work I do as a leader in an open source project is to coach or mentor contributors who are new to WordPress, or who are looking to grow in this community/ecosystem. If you’re thinking “I’ve worked with Andrea before, and she never told me what to do!” then it might be that I had feedback that I was waiting for the right moment to share. It’s also possible I was shadowing YOU and hoping to learn how you do cool stuff around WP. Anyway, I have a lot of stored up counsel, that I want to share with a bunch of people before I go on my possibly-forever hiatus.

And what do we do in WordPress when we have something to say? Well, we blog about it of course. 🙂

“Letters to a Young Poet, by Rainer Maria Rilke” by elycefeliz is licensed under CC BY-NC-ND 2.0

So please stay tuned for a series of articles, which will include possibly-sassy versions of the advice I generally tailor to individual needs and moments. I hope that sharing my observations about what works and doesn’t work, when trying to accomplish things in WordPress, will result in some assets that help open source contributors, even when I’m not around. As you can see from this title, I’m going to try to humbly channel Rilke.

Is that even possible?

Stay tuned to find out!

Thanks for a great 10 years, WordPress!

My friends! After 10 years of working full-time on the WordPress open source project, I have some news: I have accepted a community-focused role at Reddit, and will be leaving Automattic in September.

I will take a break from contributing to WordPress until the end of the calendar year, if not permanently. I think the transition from a full-time, paid contributor to a part-time, volunteer contributor is made smoother with ample “reset” time.

Taken at WordCamp Toronto 2018

I was hired by Automattic in 2011 to implement a new WordCamp program, which had been designed and launched by Jen Mylo (Jane Wells at that time) and Matt Mullenweg. Helping WordPressers understand why it was necessary for them to follow rules/guidelines/expectations was… a challenge, I’m not going to lie! Looking back, I can clearly remember all of my mistakes, and only dimly remember my successes… but we’re all still here, so I guess we didn’t do too badly in the end.

Speakers, sponsors, volunteers, and attendees gather for the inaugural WordCamp US 2015 #wcus, https://www.flickr.com/photos/wordcampunitedstates/23801673750

Since starting that journey I’ve organized events large and small, advised/cajoled/cautioned/mentored/encouraged countless contributors, resolved and de-escalated conflicts, spoken at conferences, recruited innumerable contributors, and trained many, many leaders. I’ve helped onboard people and businesses all over the world to open source culture and philosophies, and helped bring people together to work on (and sometimes solve!) complex problems. I couldn’t be more proud of what we’ve all accomplished together!

The “silly” group photo from the WordPress Community Summit 2017, in Paris

I am so grateful to have spent the last 10 years working with WordPress contributors. I don’t think there’s a better place to learn about and grow open source, and it’s been my honor to collaborate with so many ambitious & independent optimists over the years, even if we didn’t all always agree! I absolutely *LOVE* to learn new things, and the WordPress ecosystem has never failed to bring me valuable lessons on the regular.

I know that I’m leaving the people of WordPress in excellent hands with Josepha and all the other clever, compassionate leaders that have joined us over the years. I hope that, if you’re a WordPresser and you have the energy to help, that you’ll take every opportunity to lead at any level, making WordPress a little more friendly and welcoming for others. If I’ve helped you in any way, the best way to thank me is by helping someone else. Maybe even more-than-one someone else. 🙂

I plan to continue using this site to share my musings and learnings about community, open source, and leadership, as I discover what Reddit has to teach me. If you want to keep in touch, be sure to subscribe to this blog (in the footer), or come find me on Twitter or LinkedIn.

Thanks for all the fish, WordPress! It’s been a wonderful decade, and I can’t wait to see what you do next.

Blackfoot wisdom, Maslow’s hierarchy, and open source

In a fascinating recent article called Could the Blackfoot Wisdom that Inspired Maslow Guide Us Now?, Teju Ravilochan (along with contributing editors Vidya Ravilochan and Colette Kessler) shared that 

Maslow’s Hierarchy of Needs may have been inspired by the Siksika (Blackfoot) way of life… His time there upended some of his early hypotheses and possibly shaped his theories…. Whereas mainstream American narratives focus on the individual, the Blackfoot way of life offers an alternative resulting in a community that leaves no one behind.

– Teju Ravilochan, Could the Blackfoot Wisdom that Inspired Maslow Guide Us Now?
Image of the Siksicka Nation crest, with a stylized buffalo in the center of a circle, two feathers on the left and right side of the circle, and a pipe and hatchet at the bottom of the circle, crossed.
Photo by @AlbertaRhPAP, licensed under CC BY 2.0

According to Gitxsan, First Nation member, and University of Alberta Professor Cindy Blackstock, Maslow had been “stuck on his developmental theory” before visiting the Blackfoot Reserve, and found shape for his ideas in their teachings. In an article called Maslow’s hierarchy connected to Blackfoot beliefs, Karen Lincoln Michel recounts a presentation by Dr. Blackstock in which the familiar pyramid diagram of Maslow’s hierarchy* is compared to a First Nations perspective:

from Maslow’s hierarchy connected to Blackfoot beliefs by Karen Lincoln Michel

“First of all, the triangle is not a triangle. It’s a tipi,” Blackstock said. “And the tipis in the Blackfoot (tradition) always went up and reached up to the skies,” she said.

Another difference noted by Blackstock is that self-actualization is at the base of the tipi, not at the top where Maslow placed it. In the Blackfoot belief, self-actualization is the foundation on which community actualization is built. The highest form that a Blackfoot can attain is called “cultural perpetuity.”

from Maslow’s hierarchy connected to Blackfoot beliefs by Karen Lincoln Michel

* It’s worth mentioning that this pyramid diagram was not created by Maslow, and that Maslow himself “made it quite clear that we are always going back and forth in the hierarchy, and we can target multiple needs at the same time.”

OMG OSS

This diagram is exciting because when I think about successful open source communities, they look a lot like this First Nations model. In open source, we frequently discuss ways to avoid the tragedy of the commons, but — at least in my reading — spend less time talking about what we could aspire to. If we want open source to endure beyond the closed/proprietary platforms that it’s competing with, I think we should aspire to a model founded in Blackfoot beliefs.

The contrasting diagrams above illustrate a difference in worldview that often appears when welcoming newcomers into open source. Many people who come to free, open source software communities are dazzled by the freedom, because they see that freedom as a way to accelerate their own self-actualization. 

In the case of the WordPress community, they see opportunities to found businesses based on WordPress extensions (themes, plugins), WordPress site building, WordPress hosting, or WordPress training. They see opportunities to build their skills through code review and design feedback from world-class developers and designers. They see opportunities to build a following through speaking at WordPress events and leading WordPress communities. These people are not wrong, necessarily, but they might not be aware of the whole picture. 

Participating in the WordPress community only to further self-actualization could be crudely described as a “what’s in it for me,” or an opportunistic, approach. Opportunism is an anti-pattern in an open source organization for many reasons, not the least of which is how it limits someone’s growth in the community. When someone is primarily interested in what an open source project can do for them, regardless of how that affects the ongoing success of the project, then their circle of caring is limited, as is their influence in the group. 

The First Nations diagram helps illustrate this: open source works much more along the lines of the First Nations model, in which self-actualization exists in the base, supporting community actualization and cultural perpetuity.

While Maslow saw self-actualization as something to earn, the Blackfoot see it as innate. Relating to people as inherently wise involves trusting them and granting them space to express who they are (as perhaps manifested by the permissiveness with which the Siksika raise their children) rather than making them the best they can be. For many First Nations, therefore, self-actualization is not achieved; it is drawn out of an inherently sacred being who is imbued with a spark of divinity.

– Teju Ravilochan, Could the Blackfoot Wisdom that Inspired Maslow Guide Us Now?

“In the Blackfoot belief,” according to Blackstock, “self-actualization is the foundation on which community actualization is built. The highest form that a Blackfoot can attain is called “cultural perpetuity.” Community actualization is the communal responsibility of “meeting basic needs, ensuring safety, and creating the conditions for the expression of purpose” for individuals. 

In the WordPress community, community actualization occurs in SO many ways: when experienced WordPress enthusiasts help new WordPress-ers find the right plugin or configure their theme the way they want it. Community actualization happens through the work of our support forum volunteers, and in the work of community organizers who make space for new voices in WordPress to share their unique perspectives. We’re also supporting community actualization when we “call in” those whose behavior causes harm, showing that someone may need extra support in their own self-actualization. The work of core developers and designers to continually fix and improve WordPress through regular software releases, bringing new and refined features to 42% (and counting!) of the internet, is community actualization too. And of course, the community actualizes when we gather to share knowledge (and food!) at a WordCamp or meetup.

A group of conference attendees, sitting in a circle, with plates of food in their laps, in a grassy space.
Photo taken by Aaron Hockley at WCSF 2013

WordPress community actualization provides space for the self-actualization of millions: all WordPress users, of course, and all those who work or play in the WordPress open source project. And when we do it right, when we bring our generosity and patience to how we collaborate, remembering to holding space for others to feel welcome and join in, and acknowledging all the people who got us here, then we also further our cultural perpetuity.

As Karen Lincoln Michel describes it, cultural perpetuity is “an understanding that you will be forgotten, but you have a part in ensuring that your people’s important teachings live on.”

WordPress works toward cultural perpetuity when we work in public, where our work is archived (so future contributors can learn from us). We support cultural perpetuity when when we welcome and mentor new contributors, and when we hand off leadership roles to others. I also see us shoring up cultural perpetuity when WordPressers blog about how to succeed, and when we share what WordPress has done for us.

Open source = a better internet

A clockwork-style spiral, metallic, with roman numerals and with rays on the outside of the spiral
Perpetuity, by Ghetu Daniel, is licensed under CC BY 2.0

I love seeing WordPress grow, because I believe that open source makes the internet a better place. I also believe that welcoming people into thriving open source communities can help them find the kind of interdependent, mutually-beneficial society that is elusive in many parts of the globe. 

According to Blood and Heavy Head’s lectures (2007), 30-year-old Maslow arrived at Siksika along with Lucien Hanks and Jane Richardson Hanks. He intended to test the universality of his theory that social hierarchies are maintained by dominance of some people over others. However, he did not see the quest for dominance in Blackfoot society. Instead, he discovered astounding levels of cooperation, minimal inequality, restorative justice, full bellies, and high levels of life satisfaction. He estimated that “80–90% of the Blackfoot tribe had a quality of self-esteem that was only found in 5–10% of his own population” (video 7 out of 15, minutes 13:45–14:15). As Ryan Heavy Head shared with me on the phone, “Maslow saw a place where what he would later call self-actualization was the norm.” 

– Teju Ravilochan, Could the Blackfoot Wisdom that Inspired Maslow Guide Us Now?

This is the kind of idyllic state that I hope for, in the WordPress we are all building together. By continuing to support community actualization and cultural perpetuity, our dedicated contributors make this possible.

Thank you to all current contributors who make up this interdependent web of support. If you’re not already contributing to WordPress, check out our teams, and join us! There’s a seat for you at this table. 

Further reading

Even more tenderness, even more compassion

In the US, we hear the pandemic is ending. A billion people have been vaccinated worldwide, and government restrictions are relaxing in many places. I’ve been fully vaccinated, and my pod will be fully vaccinated by next weekend. I have plans to see family members I haven’t seen in almost a year, and I’m so grateful for the hard work and science that went into the rapid creation of the COVID vaccines. 

And I’m sad. I’m so very sad, and so very angry, and so very, very, VERY tired.

I thought I knew exactly how tired I could get, because 2020. This time last year, I was tired in my bones — the stress of uncertainty, invisible risk everywhere, supply chain failure, the late stages of the Trump re-election campaign and presidency… it was exhausting.

So much of that rotten stuff is gone now, and I don’t feel better.

UGH! I just don’t feel better, and it makes me both mad and afraid. Anyone with chronic mental illness or a history of trauma will be familiar with the thoughts that surge: “What if I never feel better again? What if my capacity for joy and peace is just gone? What if this broke me permanently, like nothing else has been able to do… quite… so far?”

I keep talking to people who feel the same way. “Things are getting better,” we tell each other. “Why don’t I feel better? I feel so sad, so unhappy; why?” We look at each other in shared, helpless, irritated anguish. 

Here’s the thing about traumatic events: when a crisis hits, many people (like me) shift into survival mode, and focus on getting through the crisis with minimum damage and risk. I’m excellent at this, and so is my partner. We both survived traumatic events in our past, so survival mode is even familiar, in an almost-comforting way. You put as many feelings aside as you can, and you get the job done. One foot in front of the other; take a breath, and keep moving. 

But of course feelings don’t just go away because I’ve gotten too busy for them. And when it’s time to get out of survival mode, the feelings are there, and they suck. 

This is a kind of delayed grief, even a delayed reaction to trauma, and as far as I know, the only way out is through.

Image of a small dejected child, head lowered, with hair covering face. Child is wearing a fluorescent yellow shirt. Image is very dark.

I know I’m not alone in this — all around me, I see co-workers, friends, and family struggling with exhaustion and deeply painful emotions. This is a time to be tender with ourselves. “But I’ve been reaching for gentleness, for patience and kindness all year, and last year too!” my stubborn brain might say, “Surely it’s time for something else!” 

“It’s time for even more,” says my heart. “It’s time for even more tenderness, even more compassion.” However you get there: whether you start by being compassionate with someone else, and then find that same compassion for yourself… or if you need to start with yourself first, and then bring it to others. 

Because you can’t get blood from a stone. Productivity may have to wait a while longer; goals may be delayed. Quality might have to slip in some places. We’re not back to normal yet; not even close.

If we must be wretched a while longer, let us do so with grace, and grant grace to others.

The other side of the coin: what people get out of contributing to WordPress

The first iteration of this article, The 4 “Gets” in WordPress Community Organizing, was written in 2019. In this update, I apply these ideas to all parts of the WordPress open source project.                     

People all over the world contribute to WordPress, in many, many ways. 

WordPress contributor handbooks have lots of public information about what each team does, and how or what they ask people to give when they contribute. However, there isn’t always a clear explanation of what contributors might expect to get, from or through their contribution. While many people know that WordPress is made possible through volunteer time, it’s sometimes less clear what kind of reciprocity exists in the project. But for everything that a contributor gives, there is almost always something that they receive.

Photo by Raphael Brasileiro on Pexels.com

Here’s an incomplete-but-good-starter list of some benefits that WordPress contributors might get, through contributing to WordPress:

Impact

As of early 2021, WordPress powers 40% of the web. That’s an enormous footprint for an open source project. The decisions made by Core designers and developers affect millions upon millions of users. Translators extend the power of WordPress to 75% of the world’s population that doesn’t speak English. WordPress community organizers bring together nearly half a million enthusiasts per year to talk about the software. Our documentation and support forum threads are viewed by millions of people every month. 

It’s hard to find another volunteer-based, open source organization that compares to WordPress, for reach and impact. 

Growth 

In WordPress, most volunteer opportunities are based on your interests, not your experience. WordPress community organizers aren’t required to have organized an event, or have managed a team, before taking on a leadership role in their local communities. No one reviews a developer’s resume, or a designer’s portfolio when considering whether to merge a patch to the WordPress core software. You don’t need to be a professional speaker or educator to create a workshop for learn.wordpress.org.

And yet, working in WordPress gives contributors a chance to develop a broad array of skills: leadership, communications, design, logistics, marketing, fundraising, management… the list goes on.  Every one of these skills can create opportunities in someone’s professional career or personal life — and generally can offer a safe place to experiment, where you’re not risking your career if your idea doesn’t work out. 

Training/Support

Most of what contributors need to know to get started, and become proficient, is publicly available. You don’t need anyone’s permission to submit a patch, share a solution in the support forums, or test a theme for accessibility.  Onboarding to many roles is unusually short, compared to many other global volunteer programs — even for roles with specialized skills/knowledge, like writing lesson plans or translating WordPress. 

Our training, documentation, best practices, and tools are produced by experienced contributors — many of whom do that kind of work professionally. And when contributors run into problems they don’t know how to handle, nearly every team has a group of experienced helpers available to give feedback. Through sharing feedback, contributors grow together as they work to meet the high standards that come with high-impact work.

Safety

Though this limited autonomy sometimes shows up as a “bug” for contributors (sometimes it sounds like “why are people getting in the way of my excellent & important idea?!”), I firmly believe this is a desirable feature. 

Nearly every contributor opportunity has checks and balances in place, which reduce risk when volunteers try out their bright ideas (either in theory or in practice), without endangering the success of any major WordPress components or initiatives. Code contributions are reviewed by world-class developers before being added to the core software. New event formats are discussed and refined before we try them out, are documented, and then iterated upon. Translations are reviewed and edited before they go “live.”

So! 

Those are some pretty great things you can expect when contributing to WordPress! AND… there are things that no one gets, or that only come with time or experience — and it’s important to call those out too.

What WordPress contributors don’t get (right away, and sometimes ever)

Photo by Tim Gouw on Pexels.com
  1. Complete autonomy. As mentioned above, contributors can make a lot of powerful choices when helping to build, maintain, extend, and promote WordPress — but that doesn’t mean they can make just any choice. If you accept a position of responsibility as a WordPress contributor despite disagreeing with some parts of the role, you’re still expected to do the things that everyone in that role is asked to do — they’re part of the job.
  2. Commit-level access. WordPress contributors are full of bright ideas, which is a lot of what makes this project so great. Not every bright idea meshes well with WordPress project values or works on a broad scale, though. The WordPress open source project is open source, but it’s not open commit*. Even if you are certain that your idea is a good one, it still might not work as part of WordPress core software, or in the WordPress community. Commit-level access (and similar levels of responsibility on other WordPress contributor teams) can be earned over time, of course. 
  3. And other things.  There are other things, too, which are detailed in contributor handbooks or other kinds of contributor training or resources. (For the Community team, they’re outlined in the 5 Good Faith Rules for meetups, plus Should You Be An Organizer? and Representing WordPress docs in the WordCamp organizer handbook.) To summarize, it’s best not to try to establish a leadership position in WordPress for self-serving purposes. Likewise, if your leadership approach includes hateful or very controlling behavior, WordPress probably won’t be a good fit for you.

Share your thoughts

What do you think about this list of “get”s and “don’t get”s — does it accurately describe the kinds of personal return that contributors can reasonably expect for the time they invest in contributing to WordPress? Follow-up question: what did you expect you’d get out of contributing to WordPress, and what did you actually get?

*An ”open commit” project allows anyone, no matter their level of familiarity or expertise, to commit their code to the core code base. 

Some reflections on Dotorg dilution, and how to combat it

When I started working in WordPress, about 10 years ago, Jen Mylo warned me about about something pretty early.

At some point, you start seeing all the things that aren’t working, and you will want to fix them all, all at once. Don’t let yourself get distracted. You’re here to work on certain things, and you can’t do that if you’re working on all the things.

— something like what Jen told me, probably back in early 2011

Let’s call it Dotorg dilution.* This experience — being overwhelmed by the many places and people needing help, and taking on so many things that you suddenly find yourself spread too thin to accomplish much of anything at all — hits nearly everyone who gets involved in the WordPress open source project beyond a surface level. WordPress tends to attract helpful people (luckily for us!). The organization is vast. There’s a lot to do, and not a lot of people to do it.

I’ve seen this affect contributors differently, depending on whether they are paid or volunteers, so I’ll address both cases separately.

Volunteer Contributors

Dotorg dilution generally hits a volunteer/unpaid contributor in the Engaging or Producing stage, and it can block or slow someone’s progression on the contributor ladder. I usually notice because suddenly that person is everywhere, taking part in every new project, initiative, or experiment that comes along. Burnout is a danger at that point, and a number of enthusiastic people cycle out of volunteering every year because the dilution makes them feel (rightly) that they aren’t making a difference. Here’s my advice for avoiding that:

Stop and drop

If you’re struggling with this problem, I recommend you pause and spend some time thinking about what excites you most about contributing to WordPress. Then, identify how much time in a typical week or month you might have available for volunteer time, both in the short- and long-term. It might be someone can help in the support forums or translations while their local WordCamp isn’t in active planning, but during the 3 months of pre-WordCamp intensity, they have to step back from contributing in another area. Once you figure out what you realistically have time for, start cutting back on your commitments.

It’s OK to step away

Once you’ve decided how much time you plan to put into your WordPress contributions, communicate proactively if you need to change your role, reduce your commitments, or take a break. Very, very few contributor roles require long-term, fixed time commitments (which is great for flexibility). In the case of work that includes fixed time commitments or specialized skills/knowledge, such as WordCamp lead organizing or a role on a WordPress core release, it’s important to communicate as early as possible if you think you’ll need to step back, for a time or permanently. Nearly every contributor has had to make a tough decision about priorities in their WordPress work, so messages like “I really wanted to do this, but I’ve found that I just don’t have the time” are nearly always met with understanding and grace.

Fight FOMO with long-term thinking

For better or worse, many things move slowly in WordPress. Just because there’s a lot of energy around an idea or initiative right now, doesn’t mean you need to drop everything else to focus on a new project. Many, many (most?) projects go slower than expected, or will need a new influx of contributors in a few months or next year — in fact, that’s when they’ll need help even more! Large-scale organizations like WordPress frequently need help with sustainability even more than they do with new initiatives.

Come back anytime

Finally, I hope all volunteers remember that WordPress is a safe and welcoming place to step away from and back to. If we haven’t seen you around in a while, we probably miss you! Come on back, as soon as you’re ready or have time for a new challenge.

Paid Contributors

Dotorg dilution can affect paid contributors differently, due to a few factors:

  1. We’re here to do a job. Companies don’t just send employees into WordPress to do “y’know, whatever looks important.” We’re all on teams that have set goals — ambitious ones, at that! — and if we don’t work on the things we’re asked to work on, there will be employment-level consequences. That said, we all have some autonomy in our work, and we’re all very performant. It’s easy to think, “I’ll just take this on in my free time. All of those people are working on this in *their* free time, why not me too?”
  2. We have more time than most. Compared to most volunteers, paid contributors have an embarrassment of hours to work on things. Not offering to spend time on something can sometimes feel awkward if you’re the only person in the meeting or group who’s being paid to contribute, or contributing full-time.
  3. We can lend legitimacy. If an initiative or project has paid contributors working on it, that will sometimes give people the impression that it’s “sanctioned” or prioritized by project leadership (which is not always true). Volunteer contributors who consciously or unconsciously recognize this, might put extra effort into recruiting paid contributors for their passion projects/ideas.

Avoiding Dotorg dilution as a paid contributor isn’t complicated, but it’s also not easy. Here are some tactics that have worked for me and others I know:

Make all WordPress work = work

This is one of my preferred tactics: I don’t contribute to WordPress in my non-work time. I might volunteer for other organizations in my free time, and I might even help them with a WordPress site as part of that volunteer work (woe be unto them, I’m not very helpful). But if I do WordPress work after-hours, then I’m working after-hours — no exceptions.

Check in with your lead or colleagues

If an initiative seems really compelling to you and seems to need people badly, but also seems like it’ll interfere with your assigned/identified high-priority work, check in with your colleagues to see if the work fits into someone else’s work scope. If you think your list needs to be re-prioritized, definitely talk to your lead about that before you go too deep on a “new, shiny.”

Remember that challenging problems can lead to growth

WordPress is an organization that fosters growth for volunteers with many backgrounds and skill sets. We’re an incredibly supportive bunch, too. If you’re not able to help this time, or this year, that doesn’t mean an initiative is guaranteed to fail — and if it does fail, that failure may be more beneficial than you expect. Failed experiments can teach just as much as successful ones.

Share your challenges or pro-tips!

If this resonates with you, or if you have questions or wisdom to share, please comment below!

*This was originally described to me as “dotorg disease,” but I’m renaming it because…. well, pandemics.