What they don’t tell you about creating style guides

slide reading "Step One: Make a Style Guide. Step Two: ? Step Three: Profit!"

What they don't tell you about creating style guides

This text was the basis of my recent talk at Write the Docs NA 2018, mostly about the glory and greatness of creating your own style guides from scratch. It highlights some of the major lessons I’ve learned about writing style guides, because I really like style guides — like, a lot. I make style guides for my own personal projects which only I will ever work on. I also help make style guides for wider use, including The Responsible Communication Style Guide. My current project is a style supplement for people writing about the Python programming language, so you will almost certainly hear me complaining about disambiguation if you run into me in person. 

STYLE GUIDE GIVENS style guides are amazing you should use style guides you should make style guides for your projects and organizations

I believe I’m among fellow style-guide enthusiasts if you’ve read this far, but let’s just go over a couple of givens for this article. First, style guides are amazing. They’re basically lists of style decisions your team needs to stick to while working on a project that you no longer have to keep in your head. When you’re writing with a team, sharing a style guide will help ensure you all write with a similar style. Readers won’t get confused by different spellings, editors don’t have to correct the same errors over and over again, and writers can eliminate internal debates about when to capitalize the word “internet”. Style guides aren’t limited to written content, either — there are design and coding style guides as well.

It’s easy to build up a whole bookshelf of style guides. There are references like The Chicago Manual of Style, industry-specific style guides like The Bluebook which covers legal documents, organization-specific style guides like The Microsoft Manual of Style for Technical Publications. Depending on the project you may need more than one style guide — you might use an internal style guide when you’re writing documentation, then need to grab something broader to look up what your internal guide doesn’t cover. Sometimes you may need to even pull a more general guide off your shelf, like the Chicago Manual of Style. It’s a somewhat graceful deprecation, keeping the guidelines we need close at hand, with a fallback plan for anything an internal guide doesn’t cover. Those internal style guides are mostly what we’re talking about here — though I still have more space on my style guide shelf if any of you are thinking about something bigger.

Making your own style guide is a relatively easy process. RCSG started as a list of notes I kept for my own writing and then shared with a couple of other people as a template to adapt for their projects. That list turned into a book because it just kept getting longer. You too have the power to create your own style guide deep inside of you. I have faith in each of you.

STYLE GUIDE STICKING POINTS questioning assumptions bringing in unheard voices providing education and tools

A lot of developing a style guide is exactly what you think it is. You make a list of what you want to cover in your style guide, maybe words that you need to make sure you capitalize correctly or a list of the colors you should avoid for buttons. You keep adding things when you hear a new suggestion or make a novel mistake. Personally, most of my style guides are just a list of errors I’ve already made and reminders to not make them again. Seriously, I’ve already got a list of errata to update for the next printing of the RCSG because I’ve made new and interesting errors since the book went to the printers.

You edit your list, realize you’ve missed some things, edit again. You ask some people to read it and give you feedback, then you incorporate that feedback. At some point, you’ve got something you’re ready to share with a broader audience. Consider that version a first edition, because style guides are not carved in stone. You’ll start a list of things you want to update in the next version the moment you print a single copy, too. It’s not too different from other process documentation.

There’s no secret sauce when it comes to creating a style guide. You make the tool you need. There’s no magic software that will automagically pluck words from your documentation and shove them into a style guide. You can get the job done in a text file if that’s the only software available to you (though I encourage you to learn from my mistakes and move your style guide out of your word processing software of choice before it’s longer than five pages). A style guide can live within your other documentation or be available separately, depending on what you need.

The mechanics of putting together a style guide probably already feel familiar and I don’t want to spend too much time on them. Let’s talk about the major issues that come up when creating a style guide instead. There are three key sticking points we’re going to cover here:

  1. Questioning assumptions
  2. Bringing in unheard voices
  3. Providing tooling and education

Question your assumptions

Sometimes I think that writing documentation is just a constant process of asking people to break down one step into smaller and clearer pieces. Everyone assumes that certain knowledge is universal. But unless we can develop species-wide telepathy, we can’t make that assumption. Every reader who looks at a piece of documentation brings their own experiences to interpreting it and may interpret it in an entirely different way.

That’s doubly true when working on a style guide. We can’t assume how other people use language. Consider the word “literally.” When I tell you that I am literally freezing, you know I’m cold. But am I actually literally experiencing a concerning drop in my core temperature? Not so much.

Despite my own feelings on the interchangeability of the words “literally” and “figuratively”, we haven’t just suddenly agreed to switch the meaning of a word out of nowhere. Different communities use different words in different ways. Language grows and changes to cover new concepts constantly, like how the word “computer” used to refer to a person making calculations, but now refers to a bunch of different types of devices. These changes are routine, through conversation, slang, academic use, memes, translation and literally every other time we communicate.

We can’t assume we know what someone means when they say “literally” anymore, at least without context. We need to ask.

I would go into a whole bit about user research here, but Jen Lambourne already said everything I was going to say, plus quite a bit more, so I’m just going to refer you to Jen’s talk at Write the Docs 2018 and keep talking specifically about style guides.

Ultimately, the more you can question your own assumptions around the meanings of the words you’re trying to define, the better equipped you’ll be to create style guides that speak to everyone. Jargon, acronyms, idiom, and slang may all have their place in writing — especially within technical writing — but only as long as they improve our ability to communicate.

Examine the status quo

That’s a side benefit of creating a style guide to share with other people, by the way. To create a good style guide requires asking questions about the status quo. If your documentation is all in advanced technical jargon, developing a style guide is a chance to ask why. If there isn’t a reason, style guide development will also offer an opportunity to make some changes to the way your organization communicates.

Many people won’t argue with a style guide once it’s established. I would never encourage any of you to use this fact for evil. For good, though? It’s an opportunity to advocate for changes to the status quo. When you’re making or updating a style guide, you get to choose whether to capitalize the word “Internet.” You also get to choose how members of your organization refer to people, what metaphors are considered inappropriate in your materials, and whether images must have alt text tags. Each of these decisions is an opportunity to create a more inclusive organization as much as a way to coordinate the voice of your organization.

Of course, you should go through all the appropriate approval channels before implementing a style guide, and of course, you should work with your team to make sure decisions are acceptable to as much of your organization as possible. You can adapt and update your style guide as appropriate for your organization.

But that one dudebro in your office who refuses to give you input during the process and then wants to know what they can do to change the whole style guide after the fact? Yeah, for that dudebro, your style guide has already been sent out to be chiseled in stone. Sorry, dude.

I should also warn you about the danger of swinging too far in the opposite direction. While requiring writers to match an organization’s voice and style makes sense, style guides are not meant as ways to police other people’s tone or voice. There is no one true way to write in English and we should only attempt to describe how to use language in our own context. We need to empower writers to do better. It’s never our job to tell people they’re writing incorrectly At best, I’d consider any attempt to enforce particular ways of writing or speaking to be classism. At worst, doing so is a well-established and particularly destructive method of colonization. It also results in bad writing.

So, yeah, writing a style guide is more responsibility than it might look on the surface. Pulling together lists of words and styles isn’t nearly as hard as understanding the impact of a style choice. We have an obligation to take extra care when developing style guides, especially those intended to be used by a diverse audience. We need to balance the voice of the organization with the voice of the writer. We can clarify how we communicate, without policing other people’s writing in a problematic way.

Bring in unheard voices

Empathy is the best tool we have for building effective style guides. We need a lot of compassion in this process, too. We need compassion for our users — the people who will use this style guide to write documentation — but we also need empathy for our users’ users — the people who will read the documentation our users write. Finding enough empathy may be the hardest part of writing a style guide.

Hopefully, you can find compassion for fellow writers, whether they write documentation full-time or write on top of other responsibilities. To empathize with your readers, you need to make sure that you have an understanding of the many backgrounds your readers may come from. I’m not just talking about understanding if someone has the technical know-how to get through your documentation. I’m talking about understanding cultural context around the words we use and repurpose for technology. I like the example of the Chevy Nova. According to urban sales legends, the Chevy Nova sold poorly in Latin American markets because “Nova” means “doesn’t go” in Spanish. Snopes has disproved this story, but I still use it because all of the actual examples I could use require content warnings.

We’re all aware that listening is a key skill for documentation. We know that we need to listen to as many people as we can who create, consume, or otherwise interact with the materials. But there are still voices we can learn from who we fail to hear. We need to listen to programmers with dramatically different backgrounds. I know how to write for the 20-something dudebro with a computer science degree, but I don’t know if the same materials will work for a single parent trying to learn to code in between taking care of kids. The only way to learn is to listen to people who are not in this room. If we want to build a truly inclusive industry, we need to meet the needs of people who haven’t been able to join us yet. We need to go out and find them.

You won’t be able to ensure your style guide is all things to all people. Starting with the intent to listen, and iterate on feedback on as it comes in is the right place to start, though. Include the people you already have access to — as many editors, sensitivity readers, beta testers, and users as you can practically manage — and build on that base to include new voices as you find them.

Pro tip: Inclusion during the development process also gives other members of your organization a sense of ownership and improves the likelihood they’ll use your style guide when it’s complete. It’s nice when doing the right thing makes your life easier.

Empower community members

And, of course, what’s the point of a style guide that no one uses? I feel like there should be a good punchline here, but there’s not really a joke. There’s no value in a style guide no one will use.

The best style guides empower their users. In my ideal world, I could hand anybody a style guide and some workflow documentation and they’d immediately be able to contribute to a writing project. That might be a little utopian, but it’s not as far off as you think. Consider Wikipedia. The site’s Manual of Style is somewhat buried, but the editing FAQ is a mini-style guide, covering things like link formatting and how to write article summaries. It’s more than enough to get someone started on their first Wikipedia edit. The Wikipedia Editing FAQ is a gateway style guide. It empowers people to make immediate changes.

Honestly, you’ll know your style guide is top-notch when someone outside of the docs team can hate-edit inaccurate documentation without needing to talk to an editor. I can tell you from experience that most style guides and contributor onboarding systems are not at this level.

Provide education and tools

Ultimately, a style guide should democratize the writing process in your organization. Style guide users should be able to write more clearly without relying entirely on editors or experts.

That’s a big “should.” There are a lot of assumptions there — and since we’re questioning our assumptions, we need to unpack that “should.” All other things being equal, a style guide should democratize the writing process in your organization. Those other things are the tricky part, though. We can’t just hand people a tool and assume everything will be fine. We need to educate our communities on how to use those tools.

Planning for education needs to be a part of your style guide development before you ever look up your first acronym. For experienced documentation writers, that education may mean a short workshop on the specifics of *this* style guide, while other users may need more of a “Style Guides: How do they Even” class. Ideally, someone should be able to pick up a style guide and use it without a class but given that very few people seem to read style guides all the way through, personal walkthroughs is a really good idea.

I like to start my educational plan with materials on how to contribute to new iterations of the style guide, by the way. The more people who can add to and improve a style guide, the more the workload is spread out, which isn’t exactly altruistic but is a necessary practicality.

If you can create a culture of contribution for your style guide from the start, you’ll enable improvements you can’t imagine ahead of time. Go beyond writers, too — if you’ve got a developer who needs to write at least some of their own documentation, giving them access to your style guide files can let them build tools that work for them (and that might work for you, too).

Don’t fall into the trap of thinking of a style guide as a book or a handout. Digital style guides put information in a wider variety of hands and create a world of potential right now, from providing a basis for new kinds of linters to upgrading spellcheck to something far more useful. Imagine how great the future will be if we make all of our style guides available via API!

Move the Overton window

Style guides represent the future, whether we know it or not. They streamline production processes and give people power to work on their own projects.

They also give us the opportunity to talk about how we write and why. Those discussions have the power to change the world. Style guides offer a clear indicator of how an organization wants to discuss different questions. A style guide that cautions users against terminology that some readers will find offensive is an explicit Overton window. An Overton window is a guide to what we consider appropriate to share in public discourse. For example, women wearing pants in public was considered highly inappropriate — until the Overton window moved as more and more people decided pants are perfectly reasonable apparel.

Our communities, both technical and not, are facing big questions about what we want to look like in a year, in five years, in ten. Within technology, many of these big questions are about inclusivity. Some communities have hard-coded styles of communication that exclude everyone who hasn’t personally written a programming language. Some communities want to make sure that the benefits of technology are available to everybody. The ways we style materials dictates, in part, what side of the divide our organizations land on. The more tools we have to create inclusive documentation and other materials, the faster we can move the Overton window towards expectations of respect and inclusion, at least within our own organizations.

STYLE GUIDE-BASED REVOLUTIONS style guides empower contributors style guides inspire questions about the status quo style guides are the future

I’m not expecting anyone to go back to work just to lead a style guide based-revolution (though if you want to, I’d love to hear about it). I am hoping, though, that you’ll start thinking about how you style your own work and whether a style guide will help your organization communicate more effectively.

I’m hoping you’ll think about the cultural assumptions that go into a style guide and how to give a voice to more people in your organization.

I’m hoping you’ll think about the communication status quo on the projects you work on and whether that status quo is effective.

I’m hoping you’ll drive big conversations about the future of our communities and how to welcome more people to those communities.

STYLE GUIDE TAKEAWAYS style guides are awesome when you make style guides, consider assumptions empowerment the future style guides are powerful

To sum up: style guides are awesome.

You should make at least one style guide in your life, if only so I have more people to commiserate with, I mean talk shop with.

When you’re making style guides, consider the assumptions you make, how you can empower the people who will use your guide, and what you hope the future brings, at least in terms of communication.

Lastly, making a style guide is an awesome responsibility. It gives you the opportunity to guide conversations, defeat miscommunications, and maybe even inspire newcomers to your communities. Subtle, yes, but style guides are powerful — and with great power comes great responsibility.

 

You can watch me give the original version of this talk at Write the Docs here, with bonus digression into why peanut butter isn’t the All-American treat we think it is.

You can buy a copy of The Responsible Communication Style Guide here.

Download My In-House Style Guide Template to Use However You Want

I’m excited to share the template I use for creating in-house style guides, as a reward for The Responsible Communication Style Guide Kickstarter reaching $10,000 in backing. Want to really improve your company’s communications? Back the Kickstarter today!

TL;DR: Here’s the link to download my in-house style guide template: the style guide as a .docx!

Keep reading for some context!

Whenever I sit down with a prospective client to work on their content, I ask about style guides: Does the organization or project rely on a particular style guide? How do they enforce style guidelines? How do they update the style guide?

I get a lot of blank stares. That’s okay, because very few of the organizations I work with are founded by trained content creators. While I know that anyone who already has a style guide in place will be easier to work with, I don’t consider a lack of a style guide a problem — at least before we start working together. I do insist, however, on making a style guide before we start on any other content projects. I need a style guide before I can create new content, audit old content, or even decide on what belongs in an editorial calendar.

Creating an in-house style guide isn’t that difficult of a process, provided you’ve made a couple dozen style guides over the length of your career. Part of that is experience. Part of that is building a template that can be customized to different organizations quickly. While I can’t give you a self-serve package of my expertise, I can give you the template that I’ve built up over the past decade or so.

I’m sharing this document as a .docx so you can easily adapt it to your own ends. You’ll want to start by reading through the style guide and adding in the information your organization needs to reference regularly (like exactly how to spell, space, and capitalize your company name). After that, you can share it with your team.

Remember, your style guide is a living document. Whenever new questions come up, add the answers to the guide. Whenever your organization hires a new person or releases a new product, add them to the guide. Whenever a content creator screws something up, add the information they need to avoid future problems to the guide. Schedule a regular review to update and clarify your in-house style guide. This template, by the way, is also a living document. I keep adding information to it, tweaking it, and looking for ways to improve it.

You’ll notice that there’s some information about writing inclusively in this guide. If this is a topic you’re just starting with, I recommend reading the white paper I released with Recompiler Media on quick changes your marketing team can make to dramatically increase your audience (PDF!) with an inclusive approach. If you aren’t thinking about inclusivity, you’re probably reaching only a fifth of your potential audience. If you are thinking about inclusivity, you can take your content to the next level by backing The Responsible Communication Style Guide Kickstarter.

The Responsible Communication Style Guide: A Kickstarter and an Explanation

TL;DR

I’m working on The Responsible Communication Style Guide with Recompiler Media. This project is something I’ve been thinking about for years and I wanted to write up how I got to this place.

Our Kickstarter is here — backing at the $15 level is the fastest way to get a copy of The Responsible Communication Style Guide to use in your own work.

CONTENT NOTES

This post is over 2,500 words. There’s some heavy emotional stuff in here (lived experience + the Holocaust, how language affects our lives, and diversity in technology). I do hope you’ll read the whole thing.

How to Screw Up as a Journalist in One Easy Step

I screwed up early in my career as a freelance writer: I conducted an email interview with an individual named “Chris” for an article I was working on. In the article, I referred to Chris with a male pronoun. My source emailed me immediately after reading the article to say that “Chris” was short for “Christine” and that she would appreciate me fixing the error.

Chris was super nice about the whole thing, making me think that I wasn’t the first person to make this particular mistake. Now I do some obsessive Google-ing if I’m not sure how to describe a person just from an interview — though even Google can’t always tell me enough information.

Ever since, I’ve also been looking for a guide or workshop or some sort of education on how to ask questions about identity without being offensive. Sure, asking someone their pronouns is one of my standard interview questions (along with how to spell their name and what their professional title is), but that’s not enough.

  • How do you even begin to ask a trans person about referring to them by their dead name if you’re writing about them during a time when they still used that name?
  • How do you make sure that unconscious bias doesn’t influence your writing?
  • How do you write about someone engaged in activism without bringing an internet shitstorm down on their heads?
  • Heck, how do you even determine if you’re only telling stories about people like you or if you’re finding diverse sources or stories?

I don’t have the one true answer to all these questions. Figuring out how to handle these sorts of topics requires both empathy and context. Context, in turn, requires lived experience.

What is ‘lived experience?’ Lived experience, or the experiences, emotions, and impressions of a person living as a member of a minority, is easily dismissed as a buzzword from a women’s studies class. Hanging out in tech circles, I mostly hear people talking about their lived experiences and how they differ from what other people may see (such as a woman talking about an act of discrimination, only to be told by a man that he’s never seen any problems in the industry). While I don’t think that this sort of gaslighting should be dismissed, there are even bigger dangers to ignoring others’ lived experience: My paternal grandfather was a Holocaust survivor. He spent six years in concentration camps. When he was liberated in 1945, he was 18. He weighed 85 pounds. In the years that followed, my grandfather encountered Holocaust deniers. These people told my grandfather that the hell he went through never happened.

I don’t want to turn this blog post into an example of Godwin’s Law, but every time I hear someone discounting lived experience, I see them become a little more willing to accept anti-Semitism and other bigotry. Suffice it to say that I strongly believe in the importance of involving someone with lived experience when creating training materials about their identity, history, community, and other related topics.

Back to the Question at Hand: Improving Our Ability to Communicate

At the same time, expecting anyone (no matter their lived experience, expertise, or knowledge) to educate either individuals or organizations purely out of the goodness of their heart is both rude and unreasonable. My landlord doesn’t let me live in my apartment out of the goodness of its warm, fuzzy, corporate heart, so I need to spend my time in a way that gets my rent paid — and I expect the same to be true of every human I encounter. (Kronda Adair has written several brilliant posts on this topic — start with this post.) In the event we all wind up living in a communist utopia, remind me to revisit this point.

That means paying multiple editors to look over my work who can bring the right context to it, right? Since I don’t have a lot of money, I generally can’t afford to work with more than one editor on a project. As it happens, since I write for the web, I often can’t afford to work with even one editor.

When I’m flying without a grammatical net, there are some options for improving my writing without spending a ton of money:

  • I use a ton of technology. There are tools to analyze common grammatical mistakes, such as the spell check tool built into most word processors. But there are also tools that do more specific editing tasks, such as the Hemingway app, which helps writers to follow Hemingway’s writing advice (limited adjectives and adverbs, short sentence structures and so on).
  • I got an education in writing and communications, and then kept learning. I have a couple of degrees in communication, which included loads of classes on writing. I also still read a ridiculous amount about writing. I kept learning after getting a degree, using self-education materials available from experts, ranging from writing hacks to full-fledged textbooks. A degree isn’t necessary in this field and an in-person class isn’t even required.
  • Lastly, I adore my style guide. I don’t (usually) sleep with the AP Stylebook, but I still keep both the digital and print copies handy. I also own a bunch of other style guides. I ask the publications I write for if they have their own style guides. I also have made my own style guides, both for individual publications I work on and more generally (i.e., I’ll go to bat with an editor to make sure ‘internet’ is not capitalized).

The resources for writing responsibly and ethically are few and far between. During my education, the closest I got to a class on how to write with some level of sensitivity was a graduate-level course on how to write about controversial topics — where ‘controversial’ was read as ‘political’ or ‘religious’ more than anything else. (Side note: That class was taught by Arthur Magida, author of How to Be a Perfect Stranger, which I have referred to as The Book that Keeps Me From Screwing Up Other People’s Weddings. I highly recommended it.)

That particular class was incredibly valuable, but I had to wait until I was working on a master’s degree to have an instructor start talking about how to start thinking about dealing with difficult topics, despite taking my first journalism class in middle school. How is there not a basic class in every journalism, public relations, and marketing program on how to write for diverse audiences? We teach basic interviewing techniques, like how to ask a question to high school journalism classes, but fail to teach those same students which questions to ask or who to ask questions of. I don’t know what your student paper looked like, but mine didn’t exactly reflect the demographics of our student body. It reflected the perspectives of the teachers leading the class and of the kids in accelerated English classes — despite having a big ESL program at our school, I can’t remember a single ESL student writing for the student paper. I’m not advocating for fully restructuring journalism (yet!) but we do need to make a point of teaching empathy in journalism.

We’re at the beginning of conversations about representation in the media. There are a few organizations now that try to track statistics on authors and writers, like the VIDA Count. Getting more diverse writers (and other media makers) into big publications is just a first step. Telling stories of underrepresented demographics is the next step — and I’m not talking about tokenism. Pro tip: it’s perfectly fine to have an article about a technical project led by a woman without ever asking her about whether she thinks tech is a tough industry for women. As a matter of fact, skipping the focus on how different the story’s subject is means that you get to spend more time on how cool the actual project is.

Some individuals and organizations have started working on this problem, but many resources are fragmented. I have more than a dozen style guides and media guides just for covering religion. (I’ll get more into what’s out there in another post I’m already working on.)

We still have a long way to go to get to a truly diverse media scene, though. I keep thinking of our current media landscape as the beginning of a very long journey — we’re still outfitting ourselves for the trek and don’t really know what’s on the trail ahead. We won’t even know some of the work we need to do to get to that far off Wonderland until we get on the road. We know that we need to remodel or replace many of the systems in place to produce journalism and other media, but until that work is done, we won’t know many of the steps that come after.

Let’s Talk Ideals and Infrastructure for Writers

In my ideal world, I could just use pronouns that aren’t based on gender for writing and everything else. I recognize that I have to stick to the current system if I want readers to be able to understand everything I publish, but I certainly don’t like the existing system.

Until there’s a good opportunity for a linguistic revolution, I’m focused on making the existing system better. That means starting with the writers who make the articles, blog posts, and other things we read (along with the scripts for plenty of the audio and video content we see, too). Style guides are a good starting point for talking about how we cover things because we’re already used to looking up details we might get wrong.

In fact, some organizations have put out specialized style guides for how writers can cover their specific communities. These resources are all over the place, however, and sometimes contradictory. Creating a standard resource is the first step to making improvements in who writes what stories. Having discussions about diversity and inclusion before publishing anything will, at least, limit some of the more thoughtless headlines and references that we see constantly. As a personal goal, I’d like to see publishers avoid referring to an Olympic athlete as someone else’s wife.

I have thought of other formats this style guide could take. I kept coming back to the idea of doing the research and running an in-person workshop, geared towards newsrooms. But while we clearly need more educational materials about writing responsibly, style guides have more power than classes. I’ve taken more writing classes than I can count. I don’t remember where all the handouts and notes are from those classes, though I can point to the occasional writing hack and say that I picked it up from a particular instructor. You could have swapped out most of my writing teachers for other writing teachers and I would never have noticed.

But taking my AP Stylebook from me would turn me into a mess. And while I could manage if you took my Chicago Manual of Style or one of the other style guides I rely on, I would be pretty unhappy. These reference books have impacted my writing far more than anything or anyone else.

Making a Real Difference with The Responsible Communication Style Guide

I’ve spent the past couple of years casually talking about making a style guide that answers some of the questions I have. Audrey Eschright, the publisher of the Recompiler, heard me talking about the idea for The Responsible Communication Style Guide this spring. She said that she wanted something similar and would be willing to work on the project.

Working with Audrey is amazing — we’re on the same page about everything except whether there’s a hyphen in ‘ebook’ (I’m anti-hyphen, while Audrey is pro-hyphen, if you’re wondering). Perhaps the most important thing we agree on is how to construct The Responsible Communication Style Guide. Our particular manifesto for this project can be broken down into the following bullet points:

  • We’re hiring the right people to write each of these sections and we’re paying them. None of that crap about asking people to educate us for free here.
  • We’re creating a printed resource, as well as a website. Different people use different formats (and we’ve got some cool ideas for even more approaches once we’ve got the initial iteration ready).
  • We’re developing training around The Responsible Communication Style Guide, because people only use resources they have some familiarity with.
  • We agree that this sort of style guide isn’t just about writing clearly. It’s also about being able to communicate in a manner that doesn’t harm anyone: writers, editors, and publishers influence culture and attitudes so directly that we have an obligation to use that power responsibly.

Yes, we’re both absolutely scratching our own itch with The Responsible Communication Style Guide. But we’re also creating something that we know there’s a need for — and something with the potential to guide major conversations in technology. Yes, journalists working in this space need the guide. But there’s more room than that in the long run. Ultimately, everyone in technology is a writer: a programmer writes documentation, technical blog posts, and internal talks, even if they never publish a single word outside of an employer’s media. Designers, marketers, and even business analysts create reams of written material every day.

This guide gives people who don’t necessarily think of themselves as writers a starting point for thinking, talking, and, yes, writing, about users in an empathetic way. There’s a real potential for The Responsible Communication Style Guide to equip us for important conversations by providing an introduction to concepts of identity and a framework for writing about those concepts.

So here we are. There’s a big chunk of my heart and soul up on Kickstarter right now. I’m a bit terrified, especially of getting things wrong with the people who I want to contribute to The Responsible Communication Style Guide. I’m ridiculously hopeful about what bringing this project to life means for the books and blogs I’ll read in the future. I’m wound up waiting to see who will back this project. We’ve got just under a month to make this happen. Let’s go.

We Need Your Help

If you are as excited as I am, we are looking for help!

  • Please consider backing our project, even at a low level. If everyone just bought an ebook copy at the $15 level, we would need just over 1,300 backers — and there are far more than 1,300 people writing about these topics.
  • Please share our Kickstarter with everyone who you think might be interested. From our perspective, that means journalists, marketers, speakers, and other folks who write publicly. But once the Responsible Communication Style Guide is a reality, we expect people to use it in ways we never considered.
  • Please let us know if you think of any ways to make this material more accessible to your community. We have some ideas (I want a linter for writing!), some of which will be incorporated into this first iteration of the guide and some of which we’ll work on after the Kickstarter (including my hopes for a linter).

Thank you for reading this whole long post and thank you for your help.

PyCon, by the Zines

I spent last week at PyCon NA (in Portland this year — how convenient!). I made a zine to hand out explaining the Python community in Portland, along with suggesting some events for out-of-towners.

Here’s a PDF you can download if you want to check it out.

Even better, I wasn’t the only zine maker at PyCon!

Jessica Garson organized a zine open space where I met a few other media makers. Jessica also gave a lightning talk about teaching with zines (her slides are here).

Roxanne Johnson presented during the poster session (Data People: Learn Python) and brought a zine she made called “Build Your Skills in Data Analysis.”

Audrey Eschright was working on The Recompiler while at PyCon and announced the next call for contributors, covering hardware.

The PyDX Post-Mortem

We spent over a year planning PyDX. From my perspective, the result was worth every bit of stress. I’ve been thinking about what I want to say about the conference now that it’s over. I’ve stopped and started this post a dozen times so far. Several versions have been downright sappy.

Instead, here’s the top five things that stuck out for me during PyDX.

1. Bake Diversity in from the Start; It’s Not Something to Add Later

I have no shame when it comes to talking about diversity numbers in order to drum up sponsors, but I actually feel good about how we PyDX organizers handled questions of how to make our conference more diverse. We focused on what real people needed to feel comfortable showing up to a conference — providing a safe environment, offering child care, even small group opportunities.

  • We came within four tickets of selling out.
  • We provided full scholarships to more than 90 percent of applicants, and were able to offer free tickets to the rest through our volunteer program.
  • We didn’t keep official numbers on diversity, but I made some informal counts. About half our attendees and speakers were diverse on some axis.

We didn’t have to focus on creating diversity when we already had a space that welcomed diversity in — and we responded directly to what people told us they needed to be able to attend. Remember, you can’t assume you know what anyone else needs.

Given that I attended a conference earlier this year that was exceedingly proud that 15 percent of attendees were women, I feel great about PyDX on this front.

2. Technical Talks Don’t Get All That Much Love, Surprisingly

I was obnoxiously proud of our speaker line-up, but I was surprised by what attendees responded to most enthusiastically. Looking at social media during the conference and talking to attendees afterwards, everyone was excited by talks that focused less on code — talks about topics like how to learn and how to build culture did really well.

The exceptions — the technical talks that got rave reviews — all had one of two key characteristics. Either they were workshops, where attendees participated and left with code of their own, or they were doing something far outside of typical Python projects, like making music,

Just about all of the talks went well, by the way. I’m not critiquing any of our speakers here. I’m speaking solely about what attendees were most excited by.

3. Not Screwing Up Codes of Conduct Requires Planning

I strongly believe that having a code of conduct is a minimum requirement for a conference (as well as smaller events and even occasional meetups). Having one sets expectations and creates a safer environment for every single attendee.

Organizing PyDX has only solidified my belief. The experience also highlighted some areas where we can make setting up and enforcing codes of conduct much easier — PyDX was a learning experience, because I’ve usually only been in a position to think about codes of conduct for smaller events.

These are my key takeaways:

  • Create an incident response plan in advance. You never want to be trying to figure out how to deal with a specific issue in the moment, especially when you’re already stressed out of your mind about whether the keynote speaker’s laptop is going to work properly with the A/V equipment.
  • Talk to an expert when creating your incident response plan. We actually didn’t write our own plan — instead, Audrey Eschright sat down with us and went over potential issues and how we wanted to handle them. She put that information together into a document we could refer to during the conference and that had enough detail that we could hand it to a volunteer if need be. Budget the money for that sort of expertise; it’s far cheaper than a lawyer after the fact.
  • Every single organizer and volunteer is on duty for code of conduct issues. You should absolutely have a point person, but any attendee facing a problem will talk first with the staff member they most trust who they can catch alone. And those conversations are going to come up unexpectedly — no matter the events I’ve attended, restrooms are de facto meeting rooms because most people feel they can safely talk about anything there.

4. Venues Control So Many Things and They Could Use Their Power for Good

Our venue was our single largest expense. Our venue was also the most constraining factor in planning PyDX. Until we’d found a venue, we couldn’t figure out food, childcare, or even the actual dates of the conference.

First off, the UO White Stag Block was a great venue to work with. They were able to meet most of our requirements right away and there was really only one request we made that couldn’t be met, due to the classes that were in session in the building during our conference.

That said, any venue winds up controlling a lot of how a given conference runs. We had to work within our venue’s constraints:

  • We could only use specific tape for hanging anything on the walls.
  • We could only use catering that had already been approved by the building.
  • We had to have insurance for the event.

That last constraint has kept me thinking: Insurance is required in order to fix any problem that occurs during the conference, including legal dilemmas. Why don’t venues have similar expectations for tools that mitigate risk, like codes of conduct? Isn’t requiring events to do more work to avoid any problems or negative attention more cost effective for venues?

5. The Amount of Help People Offer is Amazing

PyDX is truly a community conference. We had two larger sponsors: MailChimp and Anaconda, both of whom made a major difference in our ability to put on the conference. But around 80 percent of our funding came either directly from ticket sales or from local companies supporting the conference (including a lot of consultants and other small businesses!).

I feel like everyone I spoke to in the weeks leading up to PyDX offered to help in some way. The whole experience has been an important lesson in gratitude for me — a reminder that people will help if you just remember to ask. A few will even go out of their way to help without the request.

Thank you to everyone who made PyDX a reality.

And for those inquiring minds who want to know, we were four tickets short of selling out, so I’m not getting the tattoo. At least, I’m not getting it this year.

A Preview of the Conference I’ve Been Planning for the Last Year

pydx-color-logo-blue

I’ve been working on PyDX for over a year. So have my phenomenal co-organizers, Rachel Kelly, Georgia Reh, Melissa Chavez, and Christopher Swenson. This weekend — October 10th and 11th — all of that hard work is going to pay off.

PyDX, by the way, is a community conference for Python programmers in the Pacific Northwest.

Our Schedule Rocks

I’ve already said that I sort of wish I wasn’t organizing PyDX, because I want to attend it. We’re filming all of the talks, in part because I would cry if I didn’t get to hear at least a few. Here are the talks that I’m particularly thrilled about:

  • Melissa Lewis’ keynote (Saturday AM) — I’ve had the pleasure of hearing Meli speak at PyLadies events and she is going to blow away the PyDX crowd.
  • Terian Koscik’s Build a Bot workshop (Saturday AM) — Terian has an impressive array of Twitter bots that do some cool tricks. She inspired me to start working on my own Twitter bot, but I need some help (I’ll probably watch the video of this talk repeatedly).
  • Evan Palmer’s Making MIDI Music with Python talk — I admit that I actually got to hear Evan practice this talk, but I’m still excited for the final version. He’s making music programmatically!

You can see the whole schedule here as a PDF. I’m biased, of course, but I think we’ve got a great line up across the board.

I’m incredibly grateful to our speakers for putting in proposals and agreeing to speak at PyDX. Many are traveling to Portland on their own dime to do so and I’m a little in awe of the group of people we’re bringing together.

A Conference for Everyone

One of our commitments from the start of organizing this thing was to create a welcoming conference where everyone feels comfortable. Every PyDX organizer has been to tech conferences where we’ve felt like we don’t belong and we’re willing to go to extreme lengths to avoid anyone feeling that way this weekend. A lot of these decisions, by the way, didn’t take all that much time or money to implement.

A Dry Conference: Tech conferences tend to be boozefests, even though many people either don’t drink at all or would prefer not to drink around people they know professionally. So we’re not providing alcohol as part of the conference (though attendees are welcome to meet up after hours for drinks if that’s their thing).

A Code of Conduct: I’ve reached the point where I just won’t deal with events and organizations that don’t have a code of conduct (as well as a way to enforce their CoC). It’s a matter of safety.

Scholarships: Our tickets are priced at $100, which isn’t cheap. The value is more than there (especially when you consider we’re providing food, childcare, great speakers, and more) but we are aware that it’s out of reach for many of the people who might benefit from attending PyDX. So we’re offering scholarships. And if you want to sponsor someone else’s scholarship, you can sponsor for any amount through this payment form. A full scholarship costs us $200 to provide, because we offer stipends for travel and other expenses, depending on the recipient’s need.

We had a good business case for diversity, by the way, which helped us explain the importance of these steps when fundraising and marketing. PyCon North America is taking place in Portland in 2016. We’re making sure that anyone who is considering learning Python before that point has an easy way to get started and to join the local community (which desperately needs more programmers).

Plenty of Pythonic Personality

Community conferences are great because they have more personality. When a conference hosts several thousand attendees, everything has to run like a well-oiled machine. But since PyDX is a smaller community conference, we can have a little fun.

Our entire vibe is a weird mix of hipster jokes and Monty Python references. I’m still not sure I’ve found all the jokes on our website, but I did have a great time writing our sponsorship prospectus (I did have to spend some time researching synonyms for ‘artisanal’).

And I’ve dared the community to help us sell out. If we sell out of tickets (and yes, scholarships count), I’m going to get the PyDX logo (the snake at the top of this post!) as a tattoo. I was originally threatening to get that tattoo on my butt. However, since I want to be able to show it off without violating the code of conduct, I’m thinking my leg is a better bet. Last time I checked, we still needed to sell about 40 tickets for me to get that tattoo. Want to make it happen? Buy a ticket (use FRIENDOFPYDX for 10% off) or sponsor a scholarship (same payment form as before). You know you want to see me all inked up.

 

You Never Know What Will Happen to the Work You Send Out Into the World

Quite a while ago, I wrote an article about web typography, “10 Web Typography Rules Every Designer Should Know, for WebDesignerDepot.com. To be frank, I’d forgotten about the article for the most part — while it’s a topic near and dear to my heart, it’s not one that I’ve written about recently.

But a few months ago, I got a pleasant surprise. A student studying web design in Australia emailed me, explaining that she had used the article in a design project. Not only that, her whole class had received the same assignment, using my article for the basis of a layout.

It’s a funny feeling, knowing that something I wrote is used in educational materials. A mostly good kind of funny — partially curiosity about how my article was chosen, but also partially that feeling you get when you hold a new baby and wonder if you’re going to absolutely screw up the poor kid’s future.

Image courtesy Celeste Watson, a graphic design student who I am sure we’ll hear great things about soon.

What I Learned From 4 Free Ebooks

Offering the four free ebooks I’ve published here over the past *ouch* two months has been a learning experience. I’ve published ebooks before, usually for a set price, but this was a very different experience.

In short, it took a lot longer than I expected. The individual facets of the project — writing, design and so on — weren’t particularly difficult, but life got in the way, as it tends to, and there were certain things that simply didn’t go as I had planned.

That’s not necessarily a problem, in my mind. It just means that a little more planning is necessary up front.

What, Exactly, is a Great Response?

I didn’t necessarily promote these ebooks the way that I’ve promoted those projects that I expect to earn me money directly. I want people to read and download these ebooks, but there isn’t any sense of urgency that I need them to do it now. When selling an ebook, I’ve found that since I know that most sales come in the first few days or weeks a product is available, I’m constantly in a rush — I want to get the word out to as many people as possible. But with these ebooks, I was more concerned with creating a lasting resource.

Nonetheless, I feel like I’ve gotten an incredible response. I’ve received incredibly positive emails and tweets, telling me that the ebooks that I released were exactly what people needed. Each ebook answered a very specific question — one that any writer could probably have come up with an answer for if she was willing to go through a couple of months of trial and error. But these ebooks seem to have sped up the process for quite a few writers, making me very pleased with the response.

What You Should Take Away from My Ebooks

I hope that you’ve learned some ways to make your freelance writing path a little easier to follow, but there’s another message that I hope you take away from these ebooks.

I wrote and edited and designed and promoted these ebooks all by myself. I had a little help: I forced my husband to read through each ebook even though he isn’t a freelancer. He’s good at catching typos, though, and he can’t easily escape. I also asked a few friends to read through them (a special shout out to Ali Luke for her incredible attention to detail).

But creating an ebook isn’t out of reach for any writer who can at least read up on the mechanics of offering an ebook. It’s a long process but it isn’t particularly difficult. If I can do it, I don’t see any reason that another writer can’t manage the same. After all, I learned about all of this stuff by being downright nosy and reading everything I can get my hands on — it’s not hard.

I’m finding my own business headed more and more in this direction, as well. While I love working with (most) of my clients, I’m a lot more passionate about my own projects. I like putting together ebooks and websites and all of that, and I’m making an effort to make that a much bigger part of my business. It’s not for everyone, but I have to encourage you to think about the options that are out there and see if you’re interested in more than just client work.

Image by Flickr user Thomas Favre-Bulle

Free Ebook: Time Management for Writers

The second of the four free ebooks I’m creating is now available! This ebook covers time management strategies that will help you make sure that there is room in your calendar for your writing.

I’ve written a lot about productivity (several of my clients have been productivity blogs) and, as a result, I’ve tried a lot of different strategies to make my work more efficient. Some have worked and some haven’t. This ebook represents what I’ve seen work over the years, including exactly the system I use. It offers a lot of information that will help you find the methods that work for you and your writing style.

I’d love to hear what you think of the ebook!

You can download all four ebooks at this link.

I’m Thankful For…

This week is Thanksgiving, at least in the U.S. In addition to thinking about all the amazing food I plan on eating on Thursday, I’ve given a little thought to why I’m so thankful to be able to make a living off of my writing.

  1. There are no limits on what I do, except those that I create. If I was working for an employer, I would be able to get a raise of a few percentage points every year, if I was lucky. As a writer, though, there have been years where I more than doubled my income from the year before.
  2. I really can work from anywhere. If I want to spend a month or two in another country, all I need to do is make sure that I can get internet access. Packing is probably a good idea, as well.
  3. I hate working in a traditional office environment. Wearing office appropriate attire was the bane of my existence during the different times I’ve held down such jobs — and the fact that going barefoot in offices is a provlem for most employes was a major issue for me.

Not to be particularly maudlin, but I appreciate that not everyone is willing or able to work like I do and this seems like a good time to think about the matter. Is there anything about writing for a living that you’re particularly thankful for?

Image by Flickr user Sugar Daze