Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Podcasts Gonçalo Silva on Working Completely Asynchronously

Gonçalo Silva on Working Completely Asynchronously

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Gonçalo-Silva of Doist about how they maintain a collaborative culture while working completely remotely and asynchronously.

Key Takeaways

  • There are approaches that can make a software product stable, robust and adaptive
  • It’s possible to have a completely distributed team that communicates almost entirely asynchronously while maintaining a collaborative culture
  • Newcomers bring fresh ideas and good questions – listen to them and appreciate the newcomer mentality
  • Frequently disassembling and reassembling teams create connections and spreads knowledge
  • If you want to have a super open culture, you also need to be open about who's responsible for making which decisions


00:05 Introductions

00:05 Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down with Goncalo Silva. Goncalo, welcome. Thank you very much for taking the time to talk to us. Now, you're based in, is it Spain or Portugal?

00:19 Gonçalo Silva: It's Portugal. I'm based in Porto, Portugal.

00:22 Shane Hastie: And I'm in New Zealand, so we're recording a remote session literally across the world. So, thanks for taking the time to talk to us.

00:29 Gonçalo Silva: Thanks for inviting me. It's pretty common though, in my activist, to work with people across the globe.

00:35 Shane Hastie: It truly is becoming more and more common today. The remote workforce is the norm. Before we get much further in, would you mind just giving us a little bit of your background?

00:44 Gonçalo Silva: My name is Goncalo. I'm a software engineer living in Portugal. I do travel a lot, but I've always lived and worked from here, and I've been with Doist for over eight years now. So, I was one of the earlier employees and I came in to start the mobile efforts, so it was at that time where everybody was realizing that mobile was going to be the next big thing, and most of the web-based products were moving into mobile. So, it's always been a fun ride because this is a bootstrapped company that has been remote from the very, very start. In fact, in the beginning, everybody was a freelancer, so there was the founder and he was just hiring different freelancers to do different things, until he realized that he needed an actual team to grow the product and the company more reliably.

01:32 Gonçalo Silva: But he didn't let go of that system where, even employees could work as freelancers, with the same kind of freedom, with the same kind of independence and autonomy that a freelancer has. So, it's been a very interesting ride because, truth be told, we were all very inexperienced and we grew the company from just a handful of people to 75 now, without any outside investments. Working all across the globe, we have people in five continents and it's been very interesting to build software at this scale, that lasts this much time across the globe.

02:07 Building products that are stable, robust and constantly evolving

02:07 Shane Hastie: A couple of things in the introduction I got for you that really stood out. One of them we were chatting a few minutes ago is, that code base has been stable and robust and yet evolving. How do you build software that is stable, robust and evolving?

02:25 Gonçalo Silva: This is a complicated topic because all of the software engineers I know are very passionate about this, in one way or another. So, the thing we try to do is we try to build software in a way that does not force us to rewrite it later down the road, and considering how long Doist has existed this is actually very important. Doist's first web release we made was 13 years ago, and this code base has never been rewritten from the ground up. I know that a lot of tech companies out there, every few years, they start rewriting things. We really try to avoid this and there's many ways in which we try to do this. For example, we have very strict code reviewing processes. We take code reviews very seriously. For example, it's not only about reviewing the codes, the reviewer is supposed to check out the code, test it locally, do a little bit of Q&A locally, which usually leads to very thorough, enriched reviews.

03:21 Gonçalo Silva: Other things we try to do is try to be critical of the hype, let's call it that. Every once in a while we have these hype cycles where things suddenly are the next best thing, and we try to be critical about them in the way where we try to look for the real merits. What are the novel ideas behind these approaches and how do they apply to us? So, instead of jumping on different bandwagons every three years, we are a bit critical and honestly, we take a little longer to adopt certain techniques, because as you know, most of them, they are on the top of the hype cycle for a couple of years, but then they fade out and something new comes along. Not all of them make it through the time, and we try to be strategical about which ones we adopt and why we adopt them.

04:06 Gonçalo Silva: And the last thing is pure honesty. We have our fair share of technical debt, just like everybody else. We do our best to try and manage that, and we try to be very conscious about the way we approach refactoring. So, in a way where we can do it very periodically on an ongoing basis to make sure that the technical debt that we accumulate, it's not necessarily a bad thing. It's a trade-off we make to move faster at one time, and then move slower later on. We just have to be careful not to let it grow to the point where we can't move, and that's exactly what we discuss often, how to tackle this and how to keep it in check.

04:42 99% of communication at Doist is asynchronous

04:42 Shane Hastie: So, a constant balancing act. One of the things that intrigues me, and I'd love to hear how you respond to it. You're a completely distributed virtual organization, you said 70 something people over five continents. What has that meant to the underlying architecture of the product? When we think of something like Conway's law, the architecture matches the communication structures in the organization.

05:07 Gonçalo Silva: Communication is actually a good point because the way we communicate is very specific and I think more and more companies are moving into it, which is, we communicate basically asynchronously all the time. And this is not only about day-to-day communication, even the pull requests reviews. We do them asynchronously. We don't pair program. It's very, very rare for us to pair program because we avoid methodologies which require people to be online at the same time. Truth be told, we can have three people across three times zones, eight hours away from each other, and they won't be online simultaneously all the time. So, generally speaking, the architecture of our code was grown very organically. In that sense, again, in the same sense of honesty, I think we made some really good decisions early on which didn't bite us later on, because in the early days we didn't really think things very through.

05:59 Gonçalo Silva: The value of fresh eyes that new people bring when they join. We just wanted to build products and put them to market. That thinking came a little later. And luckily we haven't had to make drastic changes to any of those earlier architectural decisions. Now, we have a very open culture where people can come in, they can challenge anything at any time regardless of who's working on what, and this has been super effective. Honestly, especially as when we hire new people who come in, look at things with fresh eyes and make a bunch of high impact suggestions, which we then try to adopt as quickly as possible. We discuss, and when we agree, we don't delay adopting these for very long. So, we try to leverage this fresh eye mentality from newcomers as much as we can. But I guess what I'm trying to say is, it's still a very organic process, but given our completely fully distributed structure, the way we communicate, the way we work, is completely asynchronous. Personally, I think this is the real revolution. It's not remote work, it's asynchronous communication.

07:00 Asynchronous communication in long form discussions

07:00 Shane Hastie: How does that work? Do you have synchronous time? You're talking about, we discuss things, but do we discuss asynchronous, or do you have blocks of time maybe where people call or even get together?

07:11 Gonçalo Silva: The only synchronous thing we do are meetings, and we keep meetings to a minimum. Everything else is asynchronous. The way we discuss things is very much forum-like, so somebody posts about something, a few hours later somebody else comes and posts a reply, and we have this discussion for a few days going on. It's always long form, always thought out, and this is 99% of the conversations we have about everything. So, I understand why we could be sceptical about this. For example, decision-making is delayed, because most things will take at least 24 hours to move ahead.

07:48 Gonçalo Silva: But the truth is, from my personal experience and I think I can speak for everybody at Doist, this leads to so much better discussions and so much thoughtful ways of approaching a problem, which in the end leads to better decisions. So, we can take the hit on the decision speed because we gain in decision quality. But, yeah. I mean, definitely, all of our discussions are exactly long form posts, separated by a few hours by different people, ongoing through many different days. Everybody does it like this, management, engineering, design, et cetera. It's how we work, most of the time.

08:24 Shane Hastie: That must take a bit of getting used to when you first come on board.

08:26 Onboarding in the asynchronous environment

08:26 Gonçalo Silva: Yeah. For sure. I mean, onboarding was something we realized very early on that we needed to work on because this is very different from how people usually collaborate. And it's not only about the asynchronous communication, it's also about how much independence and how much autonomy people have. We also noticed that a lot of people struggle with this initially because they are expecting it to be clearer on what they need to do or what they need to focus on, what they need to deliver. And while we try to make this clear, there is a lot of autonomy going around. Figure out whatever you should be doing and then do that.

09:00 Shane Hastie: How do people decide who works on what?

09:03 Describing the Do System way of working

09:03 Gonçalo Silva: Okay. So, we have this system, we have the Do System. This is documented in a huge blog post we have on our blog, but we have these things we call the Do Cycles, so they're month-long cycles. And we have adopted something that Spotify does, which we thought was a very novel idea, where they assemble squads of people, of different areas of the company, designer, engineers, people from marketing, et cetera. Then they have this month-long project to execute. Let's call it, implement the feature. But the point is, that squad has full ownership over what they're doing throughout that month, so they have these very broad guidelines in the beginning. We want to implement a calendar view for instance, and then they can go off and figure out what exactly is this calendar view? How will it work? How does it solve the problems that it's set out to solve?

09:54 Disassembling and reassembling teams frequently

09:54 Gonçalo Silva: And how can we deliver this to users and market it, et cetera? And then every month we can assemble this squad, they can work on this thing, they can ship it, and then we can disassemble and assemble, again, randomly to work on something else. This has been a great way, first of all, to create proximity in an otherwise fully distributed company. We don't have a water cooler. We don't have an office. People don't meet face to face. So, the fact that we assemble these squads somewhat randomly every month gets people working with random other people across the company. And also it's a great way to share knowledge and promote ownership over the things we are building. So, Doist is not a product of its founder, it's not a product of leadership, it's a product of everybody working together to achieve these goals.

10:41 Shane Hastie: Couple of things I'd love to delve deeper into on this one. This random reteaming, forming a new team once a month, who decides who's going to be in what team working on what piece? Is it pull, is it push?

10:54 Gonçalo Silva: So, yeah. That's a good question. It's also very interest based. So, every cycle we have these few initiatives we want to work on, and then people are inside each team, inside the Android team, inside the web team, inside the iOS team. They talk within each other and they say, "Yeah, I'm super interested in this one. And I like that one." And they sort themselves out. Nobody's telling anybody what to work on. Of course, I mean, we need to distribute ourselves across the initiatives. We can't have everybody working on one and nobody working on another, but it's pretty organic. So, inside the teams, in the first day of the cycle, people just talk it through, figure it out and then split themselves across the different initiatives.

11:35 Shane Hastie: So, somewhat pull more than push?

11:38 Gonçalo Silva: Yeah, for sure.

11:39 Shane Hastie: How do you overcome in that new team, the form, storm, norm, perform, the Tuckman, takes people time to get used to working together?

11:47 Overcoming the challenges of team formation

11:47 Gonçalo Silva: That's definitely a trade-off we make, so arguably if we had stable teams we would be more efficient inside these teams. There's no argument there. Something we've found that helps a lot in the system that we use, is having strong guidelines for how the squad should work, especially within the first couple of weeks where the work is still a bit undefined and it needs to get more definition and be kick started. So, we have this one page document basically, that the squad can read about how to set the squad up. For example, there's a kickoff meeting. There is something we call the spec, where people... Single document outlined they work collaboratively to outline the problems they are trying to solve. What approaches could be good candidates, from a high level perspective, of course.

12:32 Gonçalo Silva: And what are the actionables for each of the squad members to the first few steps? This creates some structure where people can get a headstart without having that built in system that a permanent team has. And after a couple of weeks, the work to be done becomes a lot clearer. So, there's less friction from the lack of experience of working together, because most of the work is very clear, what do you need to do and who needs to do what. So, we try to circumvent that, especially the first couple of weeks are very well structured for these squads to hit the ground running and start producing results as quickly as possible.

13:07 Shane Hastie: Who defines those processes and do they get changed?

13:11 Gonçalo Silva: Oh, yeah. So, our product team is the team that works the most on this, but it's just like everything else at Doist, it's a very collaborative effort. So, this is not like... We don't need to get anyone's approval to challenge any of this. And honestly, every time we discuss the way we work, there's dozens of people joining in on the discussion and voicing their opinions, and I think because of this in the end, we have a much, much better result. But I'm pretty sure that, from my personal experience, if you're a company using a more traditional system, even if you're using Waterfall, or if you're using a more modern take like Agile, or if you use a custom, something that you built internally, like we do, with the Do System, I am pretty sure this topic of how people work is a hot topic everywhere with strong opinions, strong frustrations, strong wins.

13:59 Gonçalo Silva: So, we try to leverage this as much as we can by letting people join in on the discussion and being part of the decision circle, without though being affected by consensus decision-making, because of course, if you have 50 people discussing something, you're going to struggle to reach a consensual decision. And that's why I said in the beginning that the product team owns this process, but we are very upfront about it. It needs to be as open as possible to discussion before we decide.

14:27 Shane Hastie: And who decides what features we're going to work on? What is the list of things for the next month?

14:33 Do Ideas to get ideas into the backlog for consideration

14:33 Gonçalo Silva:  In terms of decision-making, this is also the product team, but how these ideas get to the product team is very unique. We have this internal system that we call the Do Ideas. Yeah. So, we have the Do System, and then we have the Do Ideas, where everybody can propose ideas. And these proposals are small posts, again in the same forum parallel, where people advocate for a specific feature. So, they make a pitch, let's call it that, which problem they are trying to solve, how they think it should be solved, and why this change would have an impact. And in many ways, they become advocates for this initiative, and many, many times, actually all the time, the product team takes this into consideration and schedules feature work based off of these internal suggestions. So, luckily, I guess we've built a very product minded organization because we get a lot of ideas.

15:23 Shane Hastie: How do you maintain that culture, particularly with that asynchronous aspect? How do you nurture and look after, and what are the key elements of that culture? So, you've spoken a lot about that autonomy, independence, the self-organization, how do you prevent the anti-patterns?

15:42 Maintaining culture in an asynchronous organisation

15:42 Gonçalo Silva: I think something that we must keep an eye out, although what I'm about to say did not stand the test of time. We're 70 something, we're not a thousand people or anything like that, so we'll see how that scales for us. But it's really walking the walk. So, when we say that we take ideas into consideration and then we want people to be upfront and challenge things, the worst thing we can do is then not do anything about that, or take too long to action. So, if we get 10 idea proposals but we only take one into consideration, this sends the wrong message. If we tell people to challenge our systems with whatever arguments they have, but then that does not result in any change, then that easily spoils the openness and autonomous culture that we have. So, the thing that's very important to do, and this, I think, applies mostly to leadership is really doing things in the same exact way as we advocate for them.

16:35 Gonçalo Silva: So, if people actually go out of their way to challenge something about the company, that's a very uncomfortable thing to do. It's not easy to do that. So, once that happens, that needs to be dealt with, with the respect that it deserves. So, it needs to be discussed properly and wherever the discussion leads needs to be resulting actions, in specific actions that can be somehow measurable and you can track back to that discussion that they were made. So, just keeping this respect for when people go out of their way to share things, to share their frustrations, to share their suggestions, to share their ideas for features, whatever, giving it enough respect is the number one thing we can do to keep this culture alive, because then we're creating the incentives to do this. Then we have an incentive system that works. So, it's not only talking about this, it's the actual way we do things, not only what we talk about. And the same exact thing with autonomy.

17:30 Gonçalo Silva: So, being proud of the things that we do autonomously as well as whenever something does not go exactly according to plan, not putting too much emphasis on that, because with autonomy it's easy to drop the ball, let's call it that. So, keeping the focus on the wins and keeping the focus on learning from whatever does not go according to plan is another way, I think, to maintain strong autonomy. So, in the end, I guess the best way to keep our culture as it is, it's really to practice what we preach every day, not every once in a while, but every day. And if at some point we realize we can't practice what we preach, then we need to change what we preach and not just pretend that we have a culture and then we have another one.

18:14 Shane Hastie: If somebody is listening to this and thinking, wow. I would love to bring some of these ideas into my team. What are some of the gotchas? What are some of the things, hey, advice for young players, so to speak, don't do this?

18:28 Avoiding some of the gotcha’s

18:28 Gonçalo Silva: I think there are a few cons. Something that immediately jumps to mind, and it's something we discussed a bit earlier on is consensus. So, when you have all of these discussions, big and small, in an open forum with a lot of people, consensus will be problematic. And truth be told, when we were less people, when we were 20 people, we could often go for consensus. We could often lead a discussion in a way where one argument will win over most people. As we grew this stopped working, and this was a growing pain for awhile. We would literally have discussions for too long, where we were looking for this consensus but it just didn't exist. So, at some point we need to separate. What is the idea of forming phase from what is the decision-making phase? Because the idea forming phase, the more arguments you have, the better. The more angles you have, the better. The more gotchas you have, the better. But when it comes to making the final decision, decision making needs to be clear.

19:27 Gonçalo Silva: Like who's responsible to make this decision? It could be a person, it could be a team, it doesn't matter, but it needs to be explicit, because if it isn't, you're going to spend a lot of time discussing things and not taking any actionables from them. So, that is the first gotcha, is that if you want to have a super open culture, you also need to be open about who's responsible for making which decisions. Another gotcha is also that there's a lot of really nice things about working asynchronously. I keep going back to this because I think it's such a big win, thoughtful, long-term discussions are just so different from the real time chit-chat that most companies do and I've got myself engaged in this. The signal to noise ratio is just so much higher, but at the same time, there are many things that we have perfected over the years with synchronous communication.

20:15 Gonçalo Silva: For example, for engineers, pair programming, which just break down in the system and we need to look for alternatives that possibly won't serve the exact same goals, but they will have to, in the end, be of service in terms of, I guess in the end this is all about knowledge sharing. And learning and teaching and growing together. And a specific example, we don't do pair programming, honestly, we can't do it across the company, but we invest a lot of time in reviewing and documentation. So, we really want people to be really world-class at documenting their work and having other people review that documentation, understand it, ask questions, challenge it, et cetera. But it's a trade off. Like if you're using to a set of principles and then you have to adapt to another set of principles to make it work, it can be a little tough.

21:05 Gonçalo Silva: And again, onboarding for us was critical to set the expectations and share best practices from early on, which I also think other people trying to solve would have to think about, how to onboard people into this new way of working and thinking. But in the end, I think it's also about trust. I think that's another core point of the way we work. We trust each other to the point where we don't micromanage, we can't even micromanage even if we wanted to. We don't centralize decision-making or better, we do centralize decision-making, we don't centralize the discussions that lead to decision-making. So, we keep things as transparent as possible. And if you look over all of these things, transparency, trust, independence, autonomy, if you see value in these things, then I think it's very much worth exploring what the cons would be and how you could make up for them. If on the other hand these are things that you don't value, then I don't think this is something you should explore actually, because a lot of the core principles of working remotely and working asynchronously are exactly this, trust, autonomy, independence, et cetera.

22:13 Shane Hastie: How often do you get people that join and just don't cope?

22:18 What happens when people can’t cope with the asynchronous way of working

22:18 Gonçalo Silva: That's actually very rare, which is interesting. I thought it would be more prevalent, but we've had cases like this. I remember distinctly a few years ago, we had this person join the company, we struggled for awhile in the beginning to get a good rhythm of productivity and delivering solid work. This person was amazing on a personal side and they had an amazing resume. So, I was their team lead and I was actually taking it very hard on myself. Like what was missing? Why were we unable to make this work? And after a few months we talked and we said, okay, this is not working. So, I'm sorry, but we're not going to continue with this, but we kept in touch. And the funny thing was this person found a local job shortly after, and they were super happy, very quickly.

23:04 Gonçalo Silva: So, it was one of the clear examples where we did all we knew, as best as we knew at the time to make it work. We set the expectations clearer. I remember that this person was struggling with autonomy, so I started to work with them to create a more specific plan for them. So, taking away some of their autonomy so that I could work with them on the tasks that they needed to do. This was still not working. Communication was not great. And suddenly moving back into a local company, with a regular office, in real life colleagues together at the same time, and suddenly everything was perfect and working fine.

23:39 Gonçalo Silva: So, I think for some people, this will be tougher than for others, but luckily, over the past decade or so we have just a couple of cases like this. It's not very widespread and we're over 70 people. Of course, we have hired some people, we have also fired some people, some people left, so as usual. So, I would say the sample size is starting to become significant, and most people do enjoy this kind of autonomy and control over their work, and also their lives, because people are expected to work 40 hours per week. That's it. We don't care when people work these hours. If they want to make super long lunch break to be with their kids, please go ahead and do that. Nobody's expecting anything else.

24:23 Shane Hastie: Goncalo, if people want to continue the conversation, where do they find you?

24:31 Gonçalo Silva: I'm on Twitter. My handle is a little complex. It's Goncalo S. Silva. But, yeah. Twitter is the platform that I use to communicate, and my direct messages are open so anybody can ask me questions. I get back to every direct message that I get, so that would be a really good way to reach out to me, in public or in private.

24:47 Shane Hastie: Thanks so much for taking the time to talk to us today.

24:51 Gonçalo Silva: Thank you for having me. I had a great time. Thank you.


More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article