Embracing and Refining Remote Work

A Digits founder explains why they went fully remote after leaving Twitter, running a 20-person team across seven states on Central Time. They use weekly sprints with Monday kickoffs, Wednesday check-ins, Friday demos, and rotate team pairs every two to three weeks to stay coordinated.
Chapters
The thing I'm most interested in talking to you about today is something that you were so ahead of the game on, independent of the product. It's about how you organize the company. And you— I remember you talking about it 2 years ago— you launched this company completely virtual. Everybody is, is working remotely. Everyone's working from home. And I'd love for you to tell us a little bit about this because I think we're going to get quite an education. The timing couldn't be better. So why did you decide to start remotely? And how, how does that actually work?
Yeah. And this was a really hard decision that I'd say was really non-obvious in 2018. And so the context was I was leaving Twitter. I'd been head of consumer product at Twitter. And I had seen there the challenges in building large product engineering orgs. In San Francisco, you're dealing with tremendous competition for great talent. And because of that, you naturally wanna hire great people where they are. And so you're motivated to set up these remote offices. And so for Twitter, we had offices in Boston and New York and Seattle and Boulder and London and so on and so on, right? And when you have that dynamic, it starts adding a lot of friction. You feel the necessity to travel between offices to visit them. You're really consciously aligning work for different teams in different offices to try to make sure they feel involved in the core product. But that the work also suits the skill sets of that office. It basically, it created a lot of overhead. And so when Wayne and I were starting Digits, we realized that this was a long-term mission. This was not going to be a quick flip of a company. Building a whole finance stack is very challenging. And so we wanted to set the company up for long-term success. And we knew we couldn't hire the size and caliber of team we wanted all in San Francisco. So we would have people who worked for Digits elsewhere. And so then it became, do we go down this remote office path, which we'd seen quite well, or do we try something new? And I had a feeling that there was a— there was huge advantages to being fully remote in terms of putting everyone on the same level playing field. You didn't have this sort of second-class citizen character that came out with having these distant offices. And so it was an experiment. I'd say honestly, even a number of our own investors in Digits were of originally quite skeptical, and it's just been magical in how it's played out, honestly. Like now, I wouldn't consider any other approach, and the majority of our team has told me they would not go back to an office in the rest of their career. Like they view this as a far superior way of working.
Amazing. So let's get a little logistics. How many people are they and where are they located?
Yeah, so right now we're 20 people. It is primarily a product engineering team, and we're spread out all across the country. So we're in 7 states right now, about 50/50 on both coasts. We have made a number of decisions. And so there's different degrees to going fully remote. One of the big things we decided to do is be remote but synchronous. So we're not just, oh, people around the world working whenever. We have agreed as a company to basically work Central time. And so there's a bit of a skew East Coast, West Coast based on people's hours and when they eat dinner. But the vast majority of the team is all online at the same time during the core of the day. And that makes so many things easier because you can have direct conversations. You can work with each other face-to-face, even though you're on screens. It makes it a lot easier.
So, so let's talk about the details. I know you've really thought about the logistics here of how people collaborate. How much time are people doing heads-down work? How much time are they collaborating? You know, do you have to set an appointment to talk to someone? Is someone interruptible? You know, what does this look like?
Great question. So we had this advantage that we were designing the company from scratch to be remote, right? And so we could really optimize every process in order to make that effective. And so we've done a few things that I think are quite different from other companies. So we run a really tight cadence. We do weekly sprints. And so we kick off the whole team every Monday. Everyone sets goals for the week together. We do Wednesday check-ins, basically checking in on the status of projects. And then we do Friday show and tell, which is my favorite time of the whole week. And literally every group shows off what they built. And it could be a product thing. It could be some very deep technical logging solution or data manipulation. On the product side, it'll be wireframes. On the marketing side, it'll be blog content. It's sort of all across the company. And so that keeps everyone in close contact because you're basically seeing everyone every 48 hours. Then we decided, okay, every project, how do we go tackle it? And the danger with sort of working from home or from a coworking space is it's very easy to just be isolated and to sort of rabbit hole down in something like I'm stuck on a bug or I'm trying to figure out a problem. And all of a sudden hours go by, no one knows what you're working on, communication breaks down, et cetera. And so we decided from the early days to set up sort of a buddy system is what we call it. And so every project is basically tackled by at least 2 people, usually 2 to 3 people. And what that means is you always have someone you're working with during the day on this project. On the engineering side, it's pair programming. On the product side, it's collaborative whiteboarding and wireframing. On the marketing side, it's co-editing blog posts. And so we found that this scales actually quite naturally across the team. And the easy critique is like, oh wait, you're having 2 people do each job. Isn't that inefficient? And we found the opposite. So projects get done way faster with way higher quality because you have the thoughts and ideas of two people all at once. On the engineering side, your code review is built in because you're pair programming with someone. And so you're not waiting for someone to review your pull request hours or days later. And so it creates a great rapid-fire progress there. And it makes it more fun because now you are talking with someone, whether it be on video or audio or just screen sharing during the day. And it feels like you're sitting right next to them. And so that's honestly been super successful for us, and I think makes the whole work-from-home thing more collaborative to a degree than if you were all in offices and sort of running between meetings.
Super interesting. Now, how often do these teams switch up?
Yeah, quite frequently. This is another thing that we've done that's different. And I think traditionally product organizations, eng organizations are structured as teams with managers, and the teams are pretty static, and then the projects sort of change over time. And we've taken the opposite approach. So at Digits, and we did this prior at Crashlytics and up to a team of about 85, so it scales quite well. We change the teams every 2 to 3 weeks as projects emerge. And so what this does is it prevents ossification. You don't have someone emerge as sort of the de facto leader of this team and everyone just sort of naturally else falls into a subservient role. You don't have someone decide, oh, they're the control person over this part of the product and they get to make all the decisions. Like things ebb and flow across the team. You get to work with a much wider range of people over the course of the quarter. And it's more fun 'cause it builds more trust and you build more relationships. And so what we do is we scope things in what we call horizons. So a horizon is roughly a month long and that's the duration that teams will be roughly stable for. And then we do these series of weekly sprints. And then as those projects wind down, we'll break apart that team, form a couple of new teams, and take on new projects and go from there. And so it's a really— it keeps it interesting and fun every week.
More from GHION.AI

O processo de reconhecer limites, mesmo quando a vida parece exigir sempre mais.

Depois de tantas histórias, aprendizados e pausas necessárias, o @interior_iza está de volta








