Onboarding at a Radical Enterprise

Recently, I joined an organisation with some radical ideas about company culture. Let's look back over my time at TalkJS so far, and discuss the things that stood out to me — both good and bad.

Hi, I'm Steven! I love cats, tech, and talking about cats & tech.

A couple of months ago, I joined TalkJS as a full-stack developer. At least, I think that's my job title. I don't really know. It never came up.

TalkJS is weird like that.

A High-Value Culture

An organisation's culture is made up of values and norms. In other words, it's the combination of how we act (behaviours / norms) and why (mindset / values). TalkJS focuses on getting the values right, and lets the norms emerge naturally.

We value independence, autonomy, and freedom. We respect each other as humans, with lives outside of work, who know how they work best. We value making the best product we can - something so amazing that it forces everyone else to pay attention.

It's one thing to talk about those values, and pretty much every company does. But what happens if you take those values, and use them as a cultural anchor? What behaviours do we encourage, by holding those values at the heart of the company?

Well, you normalise things like the mid-day nap:

You normalise taking real time off:

And in a much broader sense, you normalise trusting people to choose for themselves. Work anywhere, any time, on whatever helps make TalkJS better. You can work on Christmas Day if you want, and you can skip the Company Meetup without needing an excuse. I struggle to think of anything that's mandatory.

In short, TalkJS is a company where a bunch of humans come together to make something cool. And now I'm one of them.

Joining TalkJS

The culture at TalkJS didn't come as a complete surprise to me. During my interviews, everyone had reinforced that this weird culture was legit. Speaking of interviews, my technical was on Slack, via text. That's how we communicate day-to-day, so that's what the interview should assess.

On top of that, I'd just finished reading A Radical Enterprise. It's a case study of businesses like TalkJS that replaced their power-based management. Instead, they embrace a bottom-up culture, that's much more employee-led.

I recognised a lot of those traits in TalkJS. Autonomous employees making decisions for themselves. Empowering people to create cultural change and resolve tensions. Caring about each other's human side and creating psychological safety. Making their ideas vulnerable to discussion and criticism.

Company culture was one of the main reasons I agreed to come work here. So clearly, I was better prepared than most would've been. There was still a lot of things that surprised me, and bits I wasn't prepared for:

I had no idea what anyone did

Job titles aren't a big thing in TalkJS. I don't know mine and I don't know anyone else's job title. The only job title you do see is CEO. But we have two, and they do completely different things day-to-day.

There's no org chart, nobody puts their job title on Slack, and everyone is active in all the Slack channels. I joined #admin-finance out of pure curiosity, because it was a public channel. I'm definitely not an accountant.

Nobody is siloed based on their job title, which is great. But it did mean that I joined our first retro and had no idea what anyone's main focus was. Easily solved, but not something I'd anticipated!

Documentation is essential

In an async-first environment, you can never get an instant answer to a basic question. As a newcomer, if you have a question that isn't answered in the docs, or on Notion, then you risk getting blocked waiting for someone to answer.

I can't lie, we're not great at this. On day 2, I found a page in the company handbook documenting a process we briefly tried a couple of years ago. You can't assume that the documentation is up-to-date.

So, I got comfortable with git blame, reading through commit messages and pull request descriptions. I started using Slack's search - there's millions of messages going back years, and I'm probably not the first person to ask.

More importantly, I started documenting things myself. I put more effort into my pull requests, and tried to fix the mistakes in out-of-date Notion pages. I learned to ask for help in open Slack channels, rather than DMing people. It's not a replacement for proper documentation, but it's better than nothing.

Just fix it

When I noticed a problem in the code, or a minor bug, I tried to find a backlog of issues that I could add it to. I couldn't find one. We have a '2022 Roadmap', but it's only 150 words long. A bit too high-level for my little bug.

I asked around. Where do you document small bugs?

You don't.

If something's worth fixing, and it's a 10-minute job, then just fix it. Add it to whatever PR you're making. Point it out in the PR description, and move on.

I've worked at companies of all sizes, but that came as a shock. No long process, adding it to a backlog, waiting for it to be prioritised, including it in a sprint, and so on. Instead, you just fix it.

We care about being agile, and not about doing scrum.

Dutch directness is real

I was prepared for company-culture shock. But I wasn't prepared for real culture shock. I'm working with people from all over Europe and Africa, but TalkJS is still a Dutch company at heart. With a Dutch communication style.

I'm British, and I didn't realise how true the stereotypes were until joining TalkJS. Compared to other Brits, I'm very straightforward and logical in the way I communicate. But as a nation, we read between the lines and do things indirectly.

So when the company's Dutch Directness collided with my timidness, I assumed people hated my ideas. I would suggest something and people just openly said they didn't like it! How could they be so rude? They must truly despise it, and me!

It took a long time, a lot of private chats with people, and a whole lot of miscommunications before I figured out the reality. They didn't like the idea. That's why they said "I don't like that idea." How radical.

Now that I'm used to it, the directness is quite nice. I know nobody here hates me. If they did, they'd probably just tell me.

The meetup was weird, but also wasn't

The company meetup was a couple of weeks ago. I got to meet almost everyone I work with, in the flesh. I'd worked with these people for months, but barely knew what they looked or sounded like. I thought it would be really weird.

Instead, it felt like I already knew everyone. My mental image went from 2d to 3d, and I know them better now. But it wasn't a massive surprise meeting them for the first time. Which, in itself, was a surprise.

There was one weird thing. Towards the end of the meetup, we all worked together in an office. We are terrible at working in person. It reminded me of onsite companies going remote at the start of COVID, without changing anything. You had people spending 6 hours a day in Zoom meetings.

Instead, we were a fully-remote team, suddenly working in person without changing anything. We sat in a room together, typing away in complete silence. It was quieter than some libraries. At one point, I started getting into a heated debate with someone on Slack, while looking directly at him. We talked instead.

The new normal

While joining TalkJS was a shock, I think leaving would be even worse. Very quickly, I've got used to this way of working. It feels natural, and it just makes sense. I'm rapidly forgetting all the problems with normal companies.

This feels right, like it's a work environment that's meant for human consumption. And I'm endlessly shocked that it's not the default.

Advice for the next person

What advice would I give to myself a couple of months ago, or to the next person that joins TalkJS?

(If this has sounded interesting to you, please do come work with us. I want co-workers that get excited about company culture with me)

The most important recommendation I have is that you need a mentor - someone you can ask for help, and get a quick answer. Don't be afraid to say when you're blocked by something, because it will happen a lot. If better documentation would've helped you avoid a problem, write it for the next person.

You need to over-communicate. Write twice as much, three times as often. Working onsite, or at a more synchronous remote-first company, you instinctively know what people are getting up to. At TalkJS, we only know what you tell us. Consider reading this amazing blog post about high-resolution communication.

Try to be vulnerable. Share your thoughts, and be open with your emotions. Nobody will shame you for being stressed, or upset, but they are more likely to offer help and support. Share when things aren't going so well, and ask for help.

I'd also suggest that you keep a list of all the things that went wrong. I'm writing this blog way too late, and I've forgotten a lot of the problems I had along the way. If we know what the problems with onboarding are, we can just fix it.

And if you're joining TalkJS, call me when you arrive. Maybe I can help!