What I learnt from Jason Fried about running a remote/async software company

I’m running Arkency for 10 years now. Arkency is a remote company and an async company. We have created our own unique culture of working and collaborating. When we started, there weren’t really many sources to look up to in regards to remote work.

Basecamp (former name: 37 Signals) is such a company. They have existed before Arkency. They were kind enough to be very opinionated about the way they work, they blogged about their efforts. Not only Rails was an inspiration from Basecamp to Arkency, also the remote work was.

It was a true pleasure to me, to watch the Jason’s Fried talk on their way of working, now after 17 years of running Basecamp.

The whole video along with the transcript is available here, but in this blogpost let me list my lessons I’m taking from Jason + my comments on them.

Writing is wonderfully emotional

This part was said by Jason as a response to (a very common) question how to get emotions in remote companies. I fully agree with this statement. We read books which tell us stories about past, present and future, we follow heroes and significant characters, all in the form of writing. Writing can be emotional, if one has the writing skill.

Pre-requisite to collaboration is the writing skill

At Basecamp, they hire only people who are good writers. This is also a rule at the Arkency recruitment. We want to see how people communicate, before we hire them. It’s not a hard requirement, but a blog, a book or even a Twitter can help us decide how good at written communication you are.

Many developers are introverts. What I learnt over the years working with the Arkency people is that introvert/extravert split doesn’t matter in remote/async companies. People who would never say a word during a live meeting, are communicating super-precisely when they are allowed to take their time to form their thoughts. Writing doesn’t promote extraverts nor introverts, this is an orthogonal skill.

A writing skill is not about grammar nor about a rich selection of words, although they do help. The writing skill in our context is to send the right message to other people. Some people prefer bullet points, some are able to build nice stories. It’s all good, there’s no one way of expressing yourself.

As with every skill, we can always improve. Was my writing clear to others? Am I getting some signs, that my writing was too cryptic and not understood? Are other people involved in my writing? Do they reply? Am I too abstract? Am I starting the right conversations?

Sometimes, not writing is the skill. Choosing where to direct people’s energy is also important. Are we discussing minor points for too long? Is this getting us closer to our goals?

Discuss ideas, not people - a way of dealing with conflicts

In every situation, where passionate people collaborate, some form of conflict or disagreement will appear sooner or later. This is not bad on its own. In fact, this is an opportunity to remind ourselves, how much we care. We care so much that even though we respect each other, we are ok to disagree, for the better good. What’s important here is again - the writing skill. We usually disagree in writing. Writing is wonderfully emotional, but also wonderfully asynchronous. I can take my time to think, why we disagree. Most importantly, we discuss ideas. We shouldn’t let our egos to dominate the conversation. It’s all about ideas, reasoning, finding what’s best. It’s clear, as Jason put it, that companies should be more interested in working with people who prefer to conflict ideas, not conflicting other people.

A meeting splits your day into 2 parts

Jason and Basecamp are against meetings. That’s a similar approach at Arkency. As developers, we usually work on deep problems. This requires our focus. Meetings are an interruption. In the spirit of Jason’s talk - if companies are products, then meetings are bugs.

Dependency is a bug

If you need access to some information and it’s not there for you, this is a bug in the company. If you need to wait for someone with answers to your questions, this is a bug. Remote/async companies (but also office-based companies!) usually have great documentations. Whenever you spot a missing information, it’s a good moment to fill the gap. Developers have the concept of the Scout rule, always leave the code in a better shape. People in companies can follow the same rule in regards to documentation. Always leave it in a better shape.

Pitches require a long-form

At Arkency, we constantly come up with some ideas. Sometimes one sentence is enough to express an intent. Jason’s point on long pitches got me thinking. New ideas are meant to change the current situation. Is my description clear enough? I have a lot to improve here.

Access to everything - feeling obliged to follow

Jason said that at Basecamp almost everybody has access to almost everything. This is similar at Arkency. However, Jason made an interesting point - when people get access to everything, they feel obliged to follow everything. This is not always the best way to spend people time - to follow all teams/projects/channels/ideas.

Regular write-ups are key

In some companies, people write summaries on what they did or will do every day. In other companies it maybe every week. The point here is to let other people know what is going on. As Jason clarified it - they’ve had it different when there were 20 people than now when there’s 50 people. I see the same at Arkency, we keep the company intentionally small (15-20 people) not to get caught in the communication problems.

Treat your company as a product

This is probably the main take-away of the talk. As a software company we’re familiar with the concept of product. A product has features, it has bugs, it may have a backlog of things to do. This can all help shaping the company. A company, similarly to a product needs a constant process of iterating on.

This was just a short list of the Jason’s tips, go watch the whole talk.

It’s worth a mention that Basecamp released a book, called Rework where they share many such thoughts. At Arkency, we have released a book which reflects our process based on Async and Remote, called Async Remote.