Book review: People Powered

Jono Bacon knows something about communities. He wrote the book on it, in fact. And now he has written another book. People Powered is a guide for how companies can create and curate communities.

I often see companies try to start what they call “communities”. In reality, they are ways for the company to get free labor that provide no real benefit to the the participants. But it doesn’t have to be that way. A community that doesn’t benefit the sponsoring company is not likely to continue receiving sponsorship. But if there’s no benefit to the community members, the community will not thrive. Only when everyone involved gets value from the community will the community be vibrant.

A community mission is different than your business vision, but tightly wound around it.

All too often, books like this prescribe the One True Way™. Bacon does not do that. He fills the book with many things the reader should do, but he also makes it clear that there are many right ways to run a community, just as there are many wrong ways.

People Powered is a starting point, not an answer. As I was reading it, I thought “this is a good set of recipes”. Further on, Bacon used the same metaphor. Curse you, Jono! But it’s an apt metaphor. The book presents advice and knowledge based on Bacon’s 20 years of community management. But each community has specific needs, so the reader is encouraged to selectively apply the most relevant parts. And in the tradition of open source, plans should be iterative and evolve to meet the changing needs of communities. Like any good cook, the recipe provides a starting point; the cook makes adjustments to taste.

If I could sum up People Powered in two words, I would pick “be intentional.” Given two more words, I’d add “be selective.” People are often tempted to do all the things, to be all things to all people. And while that may be in the future of a community, getting started requires a more specific focus on what will (and more importantly, what won’t) be done.

People Powered is full of practical advice (including a lot of calls-to-action to find resources on jonobacon.com). But it also contains more philosophical views. Bacon is not a psychologist, but he has made a study of psychology and sociology over the years. This informs the theoretical explanations behind his practical steps. It also guides the conceptual models for communities that he lays out over the course of the book. And to prove that it’s a Jono Bacon book, it includes a few references to behavioral economics and several to Iron Maiden.

I really enjoyed this book. Some of it was obvious to me, given my community leadership experience (admittedly, I’m not the target audience), but I still got a lot of value from it. Chapter 9 (Cyberspace and Meatspace: Better Together) particularly spoke to me in light of some conversations I’ve had at work recently. People Powered is an excellent book for anyone who is currently leading or planning to lead a community as part of a corporate effort.

People Powered (affiliate link) is published by HarperCollins Leadership and was released yesterday.

Disclosures: 1. I received a pre-release digital review copy of People Powered. I received no other consideration for this post (unless you purchased it from the affiliate link above). 2. Jono Bacon is a personal friend, but I would tell him if his book was awful.

Using the wrong tool for the job

My first professional job was as a systems administrator in a small academic department on a large university campus. One of the worst parts of this job was dealing with the poster printer the department made available to students and faculty. It was self-service the whole way — users were expected to design and print their own poster. They could come to us for help when the printer malfunctioned (as it often did), but that was about it.

One of the results of this was that people, particularly the graduate students, did their poster design in PowerPoint. It was ubiquitous, it was familiar, and it produced something that looked poster-like. It also didn’t play nicely with the printer. PowerPoint was designed to make slide presentations, not 42″ wide posters. It’s not that PowerPoint posters didn’t work, it’s that they didn’t work quite right. The margins were a little off. Sometimes elements wouldn’t be quite where you expected them. It annoyed the hell out of me.

The wrong tool is easier

But as I’ve gained some experience, I’ve come to understand why people use the wrong tool for the job. It’s because the tool isn’t as wrong as it seems. Why should a graduate student spend time learning a design tool that they’ll use once per year when they can get a good enough result from what they already know?

Spreadsheets are the most widely-used database in the world (I’m guessing) because they’re ubiquitous and easy to start with. By the time you’ve outgrown what’s reasonable in a spreadsheet, you’re already committed. It’s why my post on date-based conditional formatting in Google Sheets is one of this blog’s most-read posts, even though it’s a poor fit for a spreadsheet.

People’s jobs are bigger than a particular task that they try to accomplish with a piece of software. Tools that require an up-front investment — even if that pays of over a short amount of time — are going to be a non-starter. This short-term thinking is natural. It’s not a user problem, it’s a management problem.

The wrong tool isn’t wrong

There’s also the case where what seems like the wrong tool is a failure to properly identify the problem. Take this tweet:

Using an excavator to row a raft down a river seems wrong. But what’s the goal? And what are the constraints?

Does it make sense to have an additional piece of equipment? How much more does that cost in time and labor? Is it even possible to get a powered barge to the location?

It’s an off-label usage of the tool, but doctors write off-label prescriptions all the time. Just because a tool isn’t right in a standalone context, when you look at the bigger picture it can be.

Adding more isn’t always better

Earlier this year, I attended a pitch night at my local coworking space. One of the teams that presented is working on a product to help prevent driving while drowsy. It’s a noble goal — drowsy driving can be as dangerous as drunk driving. Like drunk driving, people aren’t very good at self-evaluating their fitness to drive when they’re sleepy.

But as they talked, I sat there going “no. What are you doing?” They talked about learning who the driver is and establishing a baseline of their attentiveness to measure their drowsiness. All kinds of cool whiz-bang stuff. And maybe someday they’ll add some haptic feedback to the steering wheel.

I suggested that they target diabetics as a first market. Hypoglycemia is dangerous, too, and it’s an easily-defined audience, which helps in initial go-to-market efforts. When I talked to them after their presentation, they started talking about maybe adding blood sugar sensors.

No. Just no. I asked them if they’d considered what storing data might mean. It creates a liability for the driver in case of an accident. It could be used by insurance companies to change rates. It could be compromised and used for something else.

Using the latest tech is neat, but only when it makes sense. And sometimes, the more you add, the worse things get.

If you want a diverse community, you have to stand up for marginalized members

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.

Naming your language interpreters and ecosystem

Last week, Fedora contributors proposed to change the meaning of “python” from “python2” to “python3” starting with Fedora 31. This makes sense in the context of Python 2’s upcoming demise. But some feedback on the mailing list, including mine, wonders why we’re perpetuating it.

Should there also be no “pip”, no “pytest”, no “pylint”, … command? I would say “yes”. Admittedly, it’s avoiding future pain in exchange for some current pain. But we’re already dealing with a disruption, so why enable the same issues when it’s time for Python 4?

This is bigger than Python, though. If you’re following semantic versioning, I argue that you should name your interpreters and any ecosystem executables with the major version name. Unless you’re promising to always maintain backward compatibility (or to just stop working on the project), you’re eventually setting your users up for pain.

What about non-programming languages? This is probably good advice for anything with a client-server model (e.g. databases). Or anything else where the command is separated from other components of the ecosystem. You could extend this to any executable or script that may be called by another. That’s not wrong, but there’s probably a reasonable line to draw somewhere.

Wherever you draw the line, doing it from the beginning makes life easier when the new, incompatible version comes out.

On reading documents in meetings

Amazon famously has meeting attendees read documents at the beginning of the meeting. It seems to work well for them (I’m not sure that’s the secret sauce, but that’s for another day). Tech exec Jason Crawford recently had a Twitter thread promoting this concept.

He got some disagreement on this, including from my friend Julia who considered it “inaccessible and exclusionary”.

Her arguments are right on and sufficient on their own. But there’s a broader point too: this is solving the wrong problem.

[ed note: The previous paragraph does not sufficiently express my intent. The exclusionary effect that Julia points out are reason enough to not engage in this practice. Full stop. My point about “solving the wrong problem” are more along the lines of “even if it weren’t exclusionary, here’s why you shouldn’t do it.” Thanks to Ruth for the comment that calls this out.]

Is your document too long for people to understand and digest? Fix that! Identify people who can act as editors that can help others within your organization write better documents. Or better yet, pay for writing training for your employees. It costs money, but it produces real (but hard-to-quantify) savings. Not only will you save time by having more understandable documents, but you may even have better ideas.

Are people not reading it because they’re too busy or don’t care? Fix that! Maybe it’s irrelevant to the person; that’s an indication that they don’t need to be invited to the meeting anyway. Or maybe they’re overworked, or mis-worked. That’s a management problem that will manifest elsewhere. Or maybe they’re just not doing it. Again, that’s a management problem — if that doesn’t show up in their performance evaluation, then you’re showing that it’s not actually important to you.

Jason suggests scheduling a 90 minute meeting if the document takes 30 minutes to read. That’s a waste of 30 minutes. Yes people should absolutely read the document. But they should also have the flexibility to do it when it makes sense to them. Maybe they have a train ride home that they’d rather do reading on. Maybe they like to block out time around their other meetings. It’s not valuing their time to decide when they get to read the document.

He also says it avoids “negotiation” about how soon in advance a document should be sent. This is a cultural norm that you can set. All of this comes down to a shortcut to avoid the hard work of setting a culture that gives people flexibility while still holding them accountable.

Don’t give gatekeepers a foothold

Gatekeepers are a problem in communities. They decide — often arbitrarily — who can and cannot be members of a community. Are you a true Scotsman? A gatekeeper will tell you. And if there’s something they don’t like about you, or they’re feeling particularly ornery, they’ll keep you away from the community.

Gatekeeping is a problem in open source communities. More experienced (or just louder) contributors set a bar that new contributors cannot meet. This is bad for folks who want to contribute to the project, and it’s bad for the project’s sustainability.

A recent Opensource.com article asked “What is a Linux user?“. In the initial version, it left open the possibility that if you’ve only used a Linux desktop that doesn’t require a ton of tinkering, then you’re not a real Linux user. Fortunately, the comments called this out quickly. And the author, to his credit, did not hold this view. He quickly updated the article.

The revised article does a much better job of closing the door on gatekeeping, but I would rather it have never run at all. By engaging in debate on the question, you give it validity. It’s best to deal with gatekeeping by not even acknowledging that the question is valid.

Just write the damn thing

When working in a group, you may sometimes struggle to get the group won over to your way of thinking. It’s a challenge. Sometimes you can’t state your case in a compelling manner. Sometimes your idea is terrible. Sometimes the group just won’t listen. But there’s a shortcut you can use to give your opinion a head start: write it down.

Blank pages are scary. They contain infinite possibility. It turns out that infinity is a really big, daunting concept. People don’t like them. This makes the blank page your opportunity.

Undoubtedly, the team will edit your draft heavily. It may get to the point where nothing remains of your original work. That’s okay. By having your opinion be the starting point, you give it some extra weight. You’re framing the discussion. If you’re particularly sneaky, you can even go a little beyond your actual position so that when it gets edited more toward the “middle”, it lands where you wanted.

This isn’t a fool-proof method by any stretch of the imagination. But you’re giving your idea a little bit of a boost. Even if your position isn’t the one the group settles on, being willing to write that first draft sets you apart. It doesn’t particularly matter if it’s good or not, because it’s going to be revised and revised and revised. So do you yourself a favor and just write the damn thing.

Your company is not a sports team

I don’t remember how it crossed my field of view, but I recently read a blog post from the CEO of Carta. In it, he talks about their company culture and how new employees get introduced to it. Since I have had a few conversations on this general topic with my colleagues who are in charge of such things at my employer, I read it with great interest.

Until I got to the sports team analogy.

Most companies find role models in other companies (e.g. Facebook, Google, GE). They aspire to be like “Company X”. I propose an alternative model for Carta. We don’t model ourselves after companies. We model ourselves after professional sports teams. My question for you is, “What is the difference between a company and professional sports team?”

What?

There are many similarities between Carta and a professional sports team. For starters, our entire company meets everyday at 8:30am to begin the day together. Everyone — engineering, sales, services, office management. Nobody is exempt. In sports, even the goalie, who may have a completely different practice schedule from the rest of the team, still meets at the same time to warm up.

[…]

Most people think it’s crazy that we make everyone be in the office at 8:30am every morning. We think it is crazy not to. The New England Patriots would never tell players, “Show up for practice when it is convenient.” If you want to be the best in the world at what you do, start every day together.

This is bad. It is so bad. What I read when I see this is “if you’re a parent, we don’t want you.” Or any other number of reasons why being in the office regularly at 8:30 might not work.

Now don’t misunderstand me: it’s important to be a reliable coworker. But the idea that the entire company needs to start the day together is ridiculously exclusionary. Sports teams practice together because they need to work closely together in split-second situations. They need to develop an almost telepathic understanding of what their teammates will do. They also get paid millions of dollars a year.

Your office manager does not get paid millions of dollars a year. The success of your company does not depend on the perfect, split-second timing of your lead developer and East Coast sales representative. You should develop team rapport and trust but in a way that makes sense for the work they do. Not exclusionary Valley Bro crap.

There are some really good ideas in the post: the full-day culture orientation, the idea of not taking too much capital in an attempt to grow as fast as possible, the idea that everyone contributes to customer success. But the shadow of the crappy sports analogy is deep enough to overwhelm the good parts.

Over-engineering customer service

I recently saw a tweet that infuriated me:

“We welcome our customers,” Best Buy training supposedly says, “not greet them.” First off, if you’re doing this, fuck you. This is silly word-lawyering for any job, but particularly for retail. They’re already relatively low-paid and high-bullshit, why are you making it worse?

But even apart from treating your employees like they’re people, there’s a business argument for this. Over-engineering customer service interactions makes them less serving of the customer. Empowering the employees to serve the customer leads to better service. And it turns out better service can help you keep your customers.

By coincidence, I had to deal with a couple of financial firms earlier this week. The first interaction boiled down to “welp, I can’t really do much for you. Go away.” The second, with Fidelity, made me feel like my problem was their problem, too, and it would get solved. Every time I’ve needed something from Fidelity, I’ve felt that way.

The same is true for T-Mobile. Even when it’s possibly not their problem, they do as much as they can to help me solve it. As a result, I’m still a T-Mobile customer, even though the coverage map isn’t as coverage-ful as I’d like. This is in no small part due to the quality of service I’ve received.

In both of these cases, the customer service representatives don’t feel like they’re mindlessly reading from a script. I get the sense that I’m talking to an actual person who wants to solve my problem, not close my case. They don’t seem to be judged on the difference between “greet” and “welcome”.