Building a remote-friendly company: an interview with Webflow CEO Vlad Magdalin

Written by shannon | Published 2018/11/21
Tech Story Tags: remote-working | company-culture | webflow

TLDRvia the TL;DR App

Vlad Magdalin shares his insights on building a remote culture at a startup. Find out why worrying that remote workers won’t work is an immature fear, how writing can replace whiteboarding to improve decision-making, and why connecting with coworkers is just as important as connecting with the mission — if not more so.

Webflow gives creatives the power to build completely custom, responsive websites — visually. They’re based in San Francisco where brothers Vlad and Sergie Magdalin launched the company in 2013, but they have team members scattered across the globe. Vlad sat down with me to talk about early fears, aha moments, highs, and lows of managing a decentralized team.

I’m one of Webflow’s far-flung people — well, sort of. I’m only flung about 1500 km (900ish miles) north of San Francisco where I live in Vancouver, Canada. And I’m not exactly an employee, but I have an ongoing, part-time contract as an editor for the Webflow blog. This means that for the last year and a half, I’ve gotten a backstage peek at some of their company culture and the importance Webflow places on social bonds that extend beyond work.

There’s something special happening at Webflow. The team is truly excited to be part of making Webflow better for the people using it. I was curious to talk to Vlad about what they’ve done to make it so, and I’m thrilled to share our conversation with you now.

I count 75 on the Webflow team. Did you know you’d be remote-first from the beginning?

Yes, and only about 25 of us are in San Francisco, so we’re 70% remote.

We didn’t know we’d be remote-first. We actually thought it would never work. We tried to find our first hire locally. We knew we needed an engineer, but the only one we could find willing to work for a severely underfunded startup lived in Sacramento. That’s Dan Rogers — who’s still with us. Thanks, Dan!

We optimistically believed he’d eventually move to the Bay Area once we could afford to pay him more.

Because we really thought, how do you work on a design tool without a whiteboard right in front of you, sitting next to the person you’re collaborating with?

We learned pretty quickly that neither were necessary. So it was by coincidence and luck that we were “forced” into hiring our first remote team member. This gave us confidence to hire our next remote person, who was in Finland, and then another in Moscow.

So no. It wasn’t planned at all. Part luck and part circumstance.

Is bringing a remote hire to San Francisco still on your radar?

Only if it’s on a team member’s radar. If someone wants to move, we’ll do everything we can to help, like file for various visas and pay for relocation expenses.

We’re flexible around what works for each person. A closer time zone means more time overlap, but it’s not a requirement. In fact, I think we’ve had more people move from San Francisco than we’ve had relocate here.

If you’re a founder, you can’t ignore that 99.9% of the most talented people in the world don’t live in (or can’t move to) San Francisco.

My advice would be to consider building a remote-friendly team and culture from day one.

Are you taking inspiration from companies that are already successfully managing a remote culture?

Half and half. Initially there weren’t many remote-friendly companies. Automattic — the company that runs WordPress — had a remote model. Over the last five years there’s been a pretty big shift and companies like Zapier and InVision have shown it’s possible to have a fully distributed workforce.

Some of us came to a remote model independently because of who we could hire, how open we were to hiring remote folks, and seeing evidence from other companies. Many companies have grown more comfortable with this concept because of others’ success.

Other than not being able to gather around a whiteboard, what were your fears around a distributed team?

Some obvious but immature ones like: How do you know someone is working? How do you know they’re being productive?

You learn over time that it’s a micromanage-y fear that doesn’t matter if you hire the right people and set the right expectations. If they have the skills and support to get the work done, and you show that you trust a person to do their job, you get better work.

Not having this ability to brainstorm live on a whiteboard created some benefits where someone — let’s say a product designer — instead of whiteboarding something with an engineer or another designer, would put together a Dropbox Paper document.

Putting that document together requires more thought and articulation, which is a great pre-requisite to discussing that idea with others. And once that document is articulated, it can be shared not just with one person — that you happen to be in a room with — it’s an artifact that can be shared across the entire team.

So you get to a shared understanding of the problem you’re working on much faster — by not having access to this whiteboarding, we arrived at a better way to collaborate.

Can you talk about what it’s been like to build team culture with everyone spread out?

In that first year, for the few people in San Francisco, there was a very limited social structure, because everything was remote. Since most of the collaboration happens on Slack — or I guess it was HipChat at the time — there weren’t many locals for team events or outings.

That got easier as more people joined the team in San Francisco and we got an office — there was more of a critical mass for people to do social things with. Which also created another critical mass when remote folks traveled into the city and there were more people to grab lunch with, take to happy hour, watch a movie with, or explore the city.

How does team culture play out in time zones with little overlap?

We’ve always been uncomfortable with hiring people from time zones where there’s zero overlap. We don’t have any experience hiring east of Moscow, for example. We also haven’t had that many folks apply from those areas — so there’s a bit of a fear there based on a lack of experience. But it’s not completely out of the question.

There’s a question of critical mass for people in those time zones. Our first team member in Europe had a pretty tough time because six hours out of their working day, there was nobody online. Now we have 10-plus people in Europe, so there’s a online community with the same hours. I think it’d be pretty tough for the first few people in — let’s say India or China — to get up to speed and feel connected to the team. That’s a bridge we’ll cross once we get there.

Do team members in time zones with little overlap adjust their work days?

Yes and no. It depends on the team member. We have two or three hours of overlap with Europe — their early evening, our early morning — but we don’t force people to completely shift their schedule. So although they’re not overlapping the majority of the day, there’s always a bit of overlap where people can talk live, which is really helpful. And we don’t ask people to work at night, although it’s been known to happen.

We make sure our processes are as asynchronous as possible for team meetings. We have pretty small teams and they coordinate their own schedules.

How do you overcome the communication challenges that come with a distributed team?

Over-communication is key. We’ve had times where a fraction of the team discusses something — on Slack or in person — that impacts another person or another team, and it’s not communicated. Or it’s communicated in a way that it assumes it was communicated. Or, someone just forgets to communicate it. It’s a constant challenge and something we’re still learning to work around.

As we get larger, communicating the strategy and direction of Webflow is a priority. It used to be much easier when it was 10 or 20 of us. We’d cover it in product and engineering meetings and people would naturally absorb that information. Now that we’re closer to 80, we’re starting to cover it in all-hands meetings, reinforce it, and repeat it.

And even that’s not enough. If someone misses an all-hands meeting when something important is covered — even though there’s a recording — we have to assume people won’t watch it.

We’re doing things now like informal coffee chats where we hang out and talk as a team about anything.

But just like in any company, remote or not, communication’s always an issue. It’s always something we can get better at. Being remote forces things to be written most times. Decisions aren’t made in a hallway conversation — we use GitHub, Slack, Dropbox Paper, or a Google Doc that has a referenceable history and the context of a decision.

What tools are you using to facilitate a remote-friendly culture?

Slack is the biggest one, but it comes with its own challenges — it can be a fire-hose of notifications and it sets the expectation that you’re always on call.

But I find it hard to imagine working like this without Slack. When Slack has goes down, it feels like communication is cut off. You almost feel mute, like you don’t have this immediate connection to your team.

GitHub is the huge one for our engineering team. Zoom is another tool we use. As long as you have screen-sharing, can talk face-to-face, and there’s an asynchronous way to communicate, that covers the basics.

Do you encourage or require people to work on-site?

Travel is something we encourage that’s been super helpful — every time somebody shows up to the office, it’s hugs all around. But travel is not required by any means, it’s just an option we make available.

We’re experimenting with getting specific teams to arrange their own offsites. Maybe they meet up in San Francisco or Colorado and work together for three or four days in the same city.

We’re trying to encourage more of that to get those social and team bonds formed better. Having a sense of cohesion beyond the day-to-day professional work is important with a remote culture. People stick around when they feel connected — not only to the mission, but to the people they’re on that mission with.

How long have you been doing the annual retreat and what does it look like?

We’ve been doing an annual retreat since year one.

The retreats are typically four to five days offsite, usually in some far-off destination. We’ve gone to Tahoe, Mexico, Lisbon, among other places. Part planning and part fun. It’s a time of brainstorming, innovation, idea sharing, and setting a focus for the year. We do a lot of team activities in small groups or as an entire group.

We build in time to hang out, relax, and explore whatever city we happen to be in. It’s a great time to reconnect, or in many cases, connect for the first time. Last year I met some team members in person who I’d been working with for two-plus years. It’s the best reset and a chance for us to recenter and create this North Star we’re shooting for — the whole team gets excited about rowing in the same direction.

The retreat also provides motivation to get stuff done. It always feels great when we ship something major before the retreat and we have something to celebrate — rest after a big accomplishment.

You have something you call all-hands meetings?

Yeah. They’re a weekly meeting where we introduce new team members, give updates on product developments, make announcements, answer questions, and celebrate milestones. We also do an activity we call “Props” where team members have a chance to celebrate others on the team.

How have all-hands meetings impacted company culture?

We started all-hands meetings two years ago. When the team was smaller, we had informal hangouts and as we grew, began to see a need for structure. We introduced slides and started recording the meetings.

It’s the one guaranteed time during the week that we spend together as an entire team. It’s incredibly valuable to see everyone’s faces, hear their voices, talk about company and personal stuff, share updates, and celebrate.

We spend a lot of time on our product roadmapping which opens up a lot of transparency around what’s coming down the pike. The response has been overwhelmingly positive.

It also encourages cross-team collaboration and feedback. Someone might say, “Hey, I see we’re planning this feature — have we thought about taking it in this different direction?” Or maybe what we actually have is a band-aid solution and someone says, “Here’s an actual thing I think will solve this problem.”

You mentioned the importance of trusting the people you hire. Tell me more about how that evolved.

Almost every company I worked at in the past had an implicit assumption that working from home is not real work. In fact, it wasn’t even an option at one agency I worked for — you had to take a sick day to work from home.

The fear we all have is: how do we know someone actually is working?

And very quickly, you just know by the output. If somebody is not producing the work they were hired to do, we need find out what’s happening. Are they struggling with something? Are the expectations clearly set?

But if the first question is, “Are they watching Netflix?” you probably didn’t have enough confidence to hire them in the first place. Once we saw that our remote folks were doing equal or greater work output, those questions went away.

That level of trust is gained during our rigorous interview process — most of our team members go through up to a week of a paid contract on a real project. It gives us insight into how they work, ask questions, communicate in general. We get a pretty good picture of whether a person can do what they say they can do, and whether they can stay accountable.

The baseline assumption is that the people we hire can be trusted and our hiring process tests for that.

We’re also very selective — we look for people with remote experience. The vast majority of people who joined our team have run their own agency, worked independently, or worked remotely for other US companies. They’re used to the remote model and know how to get their work done without being on-site.

What’s the Webflow philosophy around logging hours?

Nobody really gets value out of logging hours aside from having a retroactive record of what was done.

We have a super-lightweight on-track/off-track mechanism that’s mostly a communication medium to help our product teams with timelines. And when you’re off track, there’s a mechanism for getting back on track.

It’s not a shameful thing to be off track. We use the RDA model — rework, defer, abandon — where you can either:

  • Rework a track by cutting scope
  • Defer when you run into some big hairy unknown and need time to detangle it
  • Abandon when you get new information that makes a track uncertain and need to figure out if you should still devote time to it

We trust that people are doing their best work, which makes hourly reporting unnecessary. We assume people are trustworthy and have the best intentions.

Trust is something you lose rather than something you gain.

It’s assumed that each person trusts that everybody else on the team is doing their best work. And then when things go off track, it’s almost never a loss of trust. We work together to find out what the unknowns are.

That much trust on such a large team is incredible.

The amazing thing about Webflow is that there’s this baseline of people really loving our mission — they care about what we’re working towards. A big part of our team joined directly from our community. Their lives were changed by Webflow and they want others to experience that too.

There’s an inherent desire to be a really great company and an outward model of what a tool and a platform can be. And that bakes in this care for wanting to do the right thing, not just for yourself and for your career, but also collectively — for the company and for the mission that we’re on.

I think we have something special. So if a customer is really upset, every single person on the team understands that we’re building a community that’s bigger than us. It’s made up of hundreds of thousands of other designers who rely on us to do the right thing.

From the perspective of team members and leaders like yourself, what are the biggest struggles of managing a remote team?

Number one, I would say communication. It’s just part of the human condition. Communication is hard and we’re doing a lot of things to help encourage more open and transparent communication around decisions and being inclusive when decisions are made.

Maintaining a close culture also becomes harder as the team gets bigger. I know everyone, but it’s definitely less deep than it was when we were 20 people.

Which leads to the challenge of … I wouldn’t call them cliques, but … people who know each other much better because they work intimately on projects and initiatives together. Sometimes you might not meet or cross paths with someone for many, many months.

Recently we had a situation where one of our engineers asked, “Who is this person that’s reviewing my code?” We hired somebody while they were on vacation so they missed the introductory thread and the all-hands meeting. A bigger group means connections aren’t inherently there from the get-go — they happen over time.

There’s just a lot of overhead too. Especially in other countries, we bring people on as contractors, which has a lot of different limitations. We have to make sure we’re working within a country’s guidelines, and as we get more and more people in a specific country, we’ll need to set up a full legal subsidiary there.

But it’s encouraging to hear that other companies, like InVision, who are in the hundreds of people, have been able to scale without creating too much friction.

Most of the challenges, like communication and coordination, are not exclusive to remote companies. Our struggles would be similar if everyone worked in our San Francisco office.

What advice would you give someone who wants to hire remotely?

Two words: It’s inevitable.

Companies like Facebook and Google have enough cachet that they might be able to get away with having a very strict no-remote policy. They can set up an office and make a full presence in more cities rather than allow folks to work remotely.

But the trend is already turning with companies like LinkedIn and Amazon. Both have a growing remote population. Amazon is having trouble hiring some folks because they’re not able to move. Sometimes an offer — financially and practically — has to be so outsized to cover the life changes required for somebody to move.

A spouse has to change their job and get a new one. Kids have to drop friends and change schools. Maybe you have to sell a house and buy a new one. You might have to go to a different country and learn a language. Those are massive barriers, and as a startup, you don’t have the advantages of Facebook and Google.

You can’t just say, “All right, well, I’m only going to hire you in London or San Francisco.” There’s growing competition with companies like Webflow, Zapier, and InVision. The list is doubling — if not tripling — every year. Remote team members have so many more options that are compelling, well-paid, fairly compensated, and interesting.

By not considering a remote model, employers are cutting off — not even exaggerating here — the vast majority of the talent pool in the world. And they’re essentially choosing to compete with the most profitable and most well-capitalized companies in terms of salaries and stock options.

So for new startups, it seems like a huge disadvantage to not consider remote as a first-class option. The benefits, in most cases, far outweigh the perceived costs. And the main benefit is having a much, much wider pool of talent to work on your product or service — it seems like a no-brainer.

If you tack it on as a principle later, it will be a pretty tricky experience for your first remote candidate. Not only will you have to get that person used to your culture, you’ll need to retrain your existing, onsite folks to think in a remote-first way.

Especially with the technology we have today with Zoom, Slack, and other online real-time collaboration tools — they’re erasing the line between what you’re able to do on- and offsite.

What has been the most surprising, delightful thing about this remote-first culture?

It’s created this melting pot of ideas. Some ideas I disagree with, but over time, the dynamic of learning from many different perspectives has made my experience at Webflow better, and ultimately, improved our product.

There’s a lot of diversity built into the company by virtue of not hiring from a local pool.

Is there anything I didn’t cover that you want people to know?

Working remotely can be hard. Especially if you’re the only person on your team in a specific city.

We have a Remote Life channel in our Slack where people share struggles and strategies. We encourage people to find coworking space — Webflow will reimburse up to a certain amount of coworking costs. We recognize that some people need a dedicated space to work, separate from other life activities. Some people might have a home office. Some might not. Maybe their home office is not compatible with how their family operates.

Making sure everyone feels part of the team is an ongoing challenge and solving it is almost a luxury — it requires money for things like travel.

So we’re still working on some challenges, but it’s encouraging to see all the progress made in the last few years. And new technology is always making things easier.

It sounds like if you had a magic wand that would centralize Webflow, you wouldn’t do it.

I wouldn’t do it because I now know — years later — how important non-work areas of life are to our team members. And those things are impossible to replicate if everybody was in the same place.

Anna Kelian, one of our team members in Lebanon, has been a sports reporter for one of the major soccer clubs in the Lebanese Premier League for a long time and she’s well-known by the players. No matter how smooth we make the move to San Francisco, it’s a major part of her life that would have to be cut off — a part she can’t do remotely.

We just hired our latest QA Analyst — his name is Mark, and he lives near London, UK. He’s also a professional magician on the side, and the community he’s built in his local area is deeply meaningful to him. He would never have joined our team had we not been remote-first, and now we get to benefit not only from his QA expertise, but also his amazing magic shows which leave us mesmerized. I dunno about you, but that makes this whole remote thing pretty … um … magical.

There are so many stories like this on the Webflow team. Maybe someone who’s reading will be our next story — because we’re hiring!

As long as you have an internet connection, the work we do at Webflow can be done digitally and is very compatible with a remote framework. But the sports your kids play, their friends, your friends, family — all that stuff is so much more deeply tied to location.

When you’re fresh out of college and you’re looking to try out a different city is when centralizing might make sense because it’s good for both parties. But that’s a tiny window of time. And if you’re only hiring people in that window of time, you end up with a monoculture of fresh college grads all at the same stage of life. And that’s how startups grinding 16 hours a day emerged — that’s not healthy.

If I could wave a magic wand, I’d make it possible for people to travel more often — us to them and them to us. Even outside of work people should travel — experience more locations, cultures, geographies, cuisines, and people.

I wish we all had a magic wand.

Yeah — I hear they sell them on Amazon.


Written by shannon | Content Strategist. Writer. Knitter. Spaghetti squash enthusiast. I want to stand in the sun.
Published by HackerNoon on 2018/11/21