Openness isn’t just for code: Radical transparency at OpenCraft
This article was written by Jeff Miller, a member of the OpenCraft marketing team.
It’s probably not a surprise that a company that develops open source software values transparency. After all, transparency is one of open source’s biggest benefits. Concerned about the security of the software? Worried about whether it is compatible with other critical systems? Need to understand exactly which services the application relies on? With open source, there’s no need to simply take the word of the vendor or consultant for answers to any of these questions. You can go directly to the source.
Open source principles also diminish the chance of vendor lock-in. Our clients can see their code and can move to another vendor at any time.
Here at OpenCraft, we don’t just believe in the transparency of our code. We believe in transparency within our working environment, as well. And, once again, you don’t have to take our word for it. We make nearly all of our internal guide for operations and policies, the OpenCraft Handbook, available for anyone to read. We’re not alone in having a public handbook. Gitlab, Trello and Basecamp also make theirs accessible to everyone.
If you read it — and we encourage you to do so! — you’ll see that openness is listed first among OpenCraft’s four core values (the other three are quality, commitment and empathy). That’s not an arbitrary ordering. Openness comes first, because it forms the foundation of our company culture.
But while our handbook is publicly available, there are a few things we keep private. Our internal discussions, for the most part, remain internal. Certainly, reviews of pull requests and discussion on public edX Jira tickets are available to people outside the company. But we recognize that our clients have different needs and a different philosophy than we do, so we typically don’t perform client work in public, though internal discussions about projects are available to team members. That said, if a client is open to radical, public transparency of our work with them, we’re happy to oblige!
It’s also important to note that, even internally, we don’t make everything public. Financials, for example, and initial pull requests for new team members remain private. Occasionally, there’s justification for a private one-on-one. But our strong bias is toward transparency.
That said, our default is to practice radical transparency at OpenCraft. Private discussions are rare. In fact, we actively discourage them. Instead, nearly all discussions occur in the open, where anyone in the company can read them.
That may seem extreme. Some might wonder whether everyone really needs to know you’ll be 5 minutes late to a meeting. But just as writing code in the open results in better quality software because others are able to see flaws and improvements that you might overlook, we’ve found that our company runs better when it’s impossible to hide or spin information. When all communications are public, it forces people to think about the entire group in all their conversations, and that fosters a culture of inclusivity that reduces politics and the formation of cliques. Plus, you never know who might need to know something that seems trivial to you. What’s more, if that conversation about something “minor” leads to a broader discussion about something more important, it’s not always easy or natural to move it back into a public forum.
Our radical transparency with internal communications also creates a resource that comes in handy when we add new people to the team or need to pick up work from a colleague who’s out sick or on vacation. Our tools are searchable, so essentially the entire history of the company is readily accessible.
Of course, this level of openness might mean it takes longer to do something. A quick note that you might fire off to a single colleague requires a bit more consideration when you know it will be public to the entire company. But we find that extra consideration to be a feature, not a bug. It makes everyone act more thoughtfully and, in the long run, leads to smoother operations and more collegiality. Sharing information in the open results in clearer, higher quality communications. It’s worth the extra effort.
Managing the flow of information
Another potential problem with radical transparency is that people can become overwhelmed by the constant stream of communications, much of it not relevant to your specific work. Even if you don’t work in a radically open environment like we do, many of you have probably experienced similar problems with Slack and other communications platforms.
So how do people at OpenCraft keep up with so much information and so many direct pings in real time?
The answer is simple: they don’t. We do not expect people to be “always-on”, as we mentioned in our previous post on how we enable remote work.
Writing good code is a creative activity, and people can’t do good creative work without big blocks of uninterrupted time. So long as people look through the main feed a couple of times a day and respond to direct pings within 24 hours (not including weekends — we don’t expect anyone to work weekends), we each make our own schedules. When you’ve worked under these kinds of expectations, you quickly find that the vast majority of communications don’t have to be immediate. For the most part, we work asynchronously.
Additionally, open discussions generate a lot of information and noise, so we don’t expect team members to read everything. We provide ways to mitigate the noise effect and for team members to know and choose what is relevant to them. Team members can use email filters to screen out irrelevant conversations. Plus, we recently deprecated our @all email address, and instead use an internal forum with different categories, each with their own level of urgency and response time. Announcements, for example, need to be read within 24 hours. Discussions, on the other hand, can wait a full week and only require a response from those directly pinged. For many other categories, reading their content is entirely optional.
Openness creates better code. And we’ve found it also creates better companies.