#17 - Remote Work & Asynchronous Communication at Doist - Gonçalo Silva

Episode Introduction [00:00:45]

Henry Suryawirawan: [00:00:45] Hello, my friend. It’s really great to be back here with another new episode of the Tech Lead Journal with me your host, Henry Suryawirawan. Thank you for tuning in and spending your time with me today listening to this episode. If you haven’t joined any of the Tech Lead Journal social media channels, I would encourage you to spend a few seconds right now to click on the links in the show notes, where you can find this show either on LinkedIn, Twitter, or Instagram, and join a fast growing number of people who have been following the show so far. Make sure to also subscribe and follow this show on your favorite podcast app.

In the spirit of the Thanksgiving Day that has just passed a few days ago, I would like to express my deepest gratitude for all of you my listeners out there, who have been listening and supporting the show since I started it in August this year. I can’t tell you how much it really means to me to hear some of your lovely comments and feedback, and how you have been finding the show useful by listening to my conversations with great technical leaders that I’ve invited to the show so far. And if any of you would like to send your Thanksgiving wishes and messages to this show or me, you can drop them as comments or emails on those social media channels or directly to me. And please know that I’ll be reading them one by one personally.

The year 2020 has been a challenging year for all of us due to the COVID pandemic, in which all of us have had to adapt and make major adjustments towards our daily lives and our work approaches. And this year, many of us have to start adopting some forms of remote work, like working from home, especially when most countries started to implement lockdown to limit the spread of the pandemic. While some of us could switch to remote working seamlessly, for some others, it might not be as smooth and productive as how we expected it to be. And for this reason that I invited Goncalo Silva, the CTO of Doist, the company behind the popular productivity app, Todoist, and the communication app, Twist. Doist has been a remote first company practically since the founders started working on Todoist in 2007, and became officially fully remote when it hired its first remote employee in 2011. Doist has a mission of building the future of work by creating tools that promote more fulfilling ways to work and live. Doist has also been promoting the way they work, which they call the future of work, by publishing and sharing lots of great articles on their famous blog, Ambition & Balance.

In this episode, I learned a lot from Goncalo about Doist and its remote working history and culture, including some advantages and disadvantages of remote work. We also discussed at length about having asynchronous communication as the first preferred communication style instead of the synchronous communication, and why it is such an important communication style to adopt in a remote team. Goncalo then shares about Doist’s core values, the cornerstone of every single thing that Doist does as a company, from creating processes to decision making and also recruiting. Towards the end, Goncalo also shared some engineering and technical practices that Doist does, especially the ones important for a successful remote team, including the importance of pre-allocation and prioritization to avoid being blocked when you work remotely.

This was such a great conversation and learning opportunity for me, especially since I’ve always been intrigued by how a fully remote company works, and that it could still succeed and thrive compared to the traditional working model. And since I’ve been a longterm avid user of Todoist, having this conversation with Goncalo has also been a great pleasure for me.

I hope that you will enjoy this great episode. Please consider helping the show in the smallest possible way, by leaving me a rating and review on Apple Podcasts and other podcast apps that allow you to do so. Those ratings and reviews are one of the best ways to get this podcast to reach more listeners, and hopefully the show gets featured on the podcast platform. Let’s get the episode started right after our sponsor message.

Introduction [00:05:32]

Henry Suryawirawan: [00:05:32] Hi, Gonçalo, good to see you! It’s great really to hear some things about Todoist. I’ve been using your product a lot. And I know you are one of the well-known companies doing the remote work, especially during this pandemic time. It will be very precious to hear your experience, sharing the best practices. And I’m really excited to see you and talk to you about remote work today.

Gonçalo Silva: [00:05:54] Hi Henry. Thank you for inviting me. I’m very excited to be on the podcast today as well. Thank you.

About Doist [00:05:59]

Henry Suryawirawan: [00:05:59] So Gonçalo, maybe first of all, can you brief us what is your company doing? Doist, right?

Gonçalo Silva: [00:06:04] Yes. So our name is Doist. We’re building two products that people know about. So Todoist is the most popular one. You probably have heard it. It’s a task manager and personal productivity app. We’re also building Twist, which is a team communication app that focuses on asynchronous communication, long-form thoughtful communication. But ultimately what we’re doing at Doist is, we have this motto that we say we are building the future we want to work in. And of course, we’re building the tools for that future. But also we’re building the culture for that future. And that’s why, for example, we work remotely. That’s why we think about ways of working sustainably. That’s why we’re investing in things like asynchronous communication. So we’re really trying to make a dent in the workplace, also by living our ideals. This comes through our tools, and also the way we work specifically.

Career Journey [00:06:52]

Henry Suryawirawan: [00:06:52] Before we start, obviously, as usual I will ask my guests to share their career journey. So maybe Gonçalo can you share with us your career journey? What are some of the major highlights or turning points? What made you started working in the remote company?

Gonçalo Silva: [00:07:05] My career is a bit interesting because I transitioned from freelancing to working remotely. And I guess you could say a lot of freelancers already work remotely. They’re just not employees of someone. My backstory comes from open source software. So I was lucky. My first employer let me do a lot of work around open source, particularly Rails. So I worked in a lot of popular libraries back in the day. Things like ActsAsParanoid, permalink_fu, like a lot of the early Rails apps use these libraries. And I was one of the either creator or maintainers. On the technical side of things, I feel like that already gave me a lot of remote experience, because I was working with people all around the world. After that stage, I was a freelancer for a while. And then again, I guess I realized I was working remotely, with clients in this case. And actually that’s how Doist comes into my background. Doist was one of my clients. Actually my last client. They hired me in Android app. At this time, Doist had four people in total. Together with a friend who was working with me on this project, we built Todoist Android app. And along the process, we were just having so much fun. It was really a nice way to work that we thought, you know, let’s strengthen this collaboration and let’s join the company as employees, regular employees. That’s a highlight, going from open source software development to freelancing and then Todoist, still as a remote company. Honestly, I feel like my in-office experience is probably lacking at this point, comparatively, at least.

And then of course, I went through the turning points that I think most technical leaders have gone through — when you first go into management and you notice your life is turned upside down. It’s very different coming in, writing code, having technical discussions day in day out, to coming in leading a technical team, thinking about technical direction, and balancing all the trade-offs one must do all the while managing the people on the team and helping them, supporting them, growing them. It’s a big shock. I think I struggled a lot with the reward mechanisms, for example. I think rewards in programming are usually very immediate. You do something. It looks great. You’re proud. You feel great. When you’re building a team, you’re kind of like setting other people up for success. And it can take a long time to see the benefits. It’s just a very different way to work and contribute. And I think the last shock for me was when I changed from managing people to managing managers in the CTO role. And honestly, sometimes people say that the biggest shakeup a person can have in their career is if they dabble into management, because they will realize they’re changing careers. I think the change from managing people to managing managers is maybe even more drastic, because suddenly it’s very different. You’re managing people who have their own sets of ideals and incentives. They have their own plans for their teams, and you’re trying to communicate well and align everybody, and still also support them and coach them in managing people. It’s a very different way of working from managing people and from being an individual contributor. So generally speaking, these things that I’m describing to you happened over the last 13 to14 years and I think remote work has been, always been very core to my way of working, where even when I don’t realize, when it’s not very explicit, like it is today at Doist .

Henry Suryawirawan: [00:10:00] So if I understand correctly, you have never worked in a typical corporate enterprise?

Gonçalo Silva: [00:10:05] I have, but when I did spend a significant portion of my time working on open source software. So I was in the company. I collaborated in internal projects just like everybody else. But most of my attention was in the open source contributions, because the company used these projects. So I was tasked with improving them as well. Even though I was in this more corporate environments, I was spending a lot of time working with the community, which was around the world.

Doist Remote Work History [00:10:30]

Henry Suryawirawan: [00:10:30] Thanks for sharing your story. Definitely, it’s very interesting somebody who came from open source, do freelancing quite a fair bit, before fully immersed into the remote work. So I personally myself, haven’t ever experienced remote work before. Flexi work, yes. All this virtual conference and things like that, yes. So I come from a traditional background, coming back to your vision of building a future of work. Probably we can spend a lot of time, maybe educating me and also convincing me why this remote work might be something that we all should explore about. First of all, you mentioned that the company started with four people when you joined, right? Was it remote straightaway in the beginning, from the founder itself?

Gonçalo Silva: [00:11:06] Yeah, at the time Doist started, the founder was traveling across the world. So there was really no base for him. So I think it all started as a side project. And he was in Asia at this time. Eventually he returned back to Europe. He’s from Denmark. But he developed most of the early project in Chile. He was in Chile around the time of Start-Up Chile, this big program. He met a lot of the early people there. Like our COO, he met there. He was working on some other unrelated projects. Our head of marketing, she worked there. She was also part of Start-Up Chile at the time. And even this connection that I have with the founder was quite similar to this. So I have a close friend who was in Chile. When Amir was looking around for somebody who could build the Android app in a specific way, this friend said, “Hey, I know someone back in Portugal.” It was all very remote because Start-Up Chile was a temporary program. So people were eventually going to leave. Even those early bonds that only lasted maybe a few months, they were meant to be temporary. And actually the way Amir approached to building the company originally, this vision of the future of work was maybe even the more extreme in the beginning. So Amir thought he could, and maybe he could, Amir tried to build the company based off of freelancers. I’m going to hire a designer, a freelancer to handle design, a freelancer to handle the marketing, a freelancer to handle this and that, freelancers to build the apps. And I’m going to try to build a business like this. So he would honestly be the only employee. Well, that didn’t work. But still, it’s quite interesting, because I feel in some ways that’s maybe the most extreme version of remote work. Of course though, it’s much better when people are actually part of the company. They’re part of the culture. The incentives are aligned. It’s much different, but still the whole history of Doist is very remote centric from the very beginning.

Henry Suryawirawan: [00:12:45] I think the concept of building company with all freelancers. I recently read a book about Company of One. Maybe that’s the concept, all about it. Yeah, I mean like, it might work for some people, but certainly Doist didn’t go that route. So instead, you build a company by hiring a bunch of people remotely.

Remote Work Advantages and Disadvantages [00:13:01]

Henry Suryawirawan: [00:13:01] So maybe tell us a little bit, like what’s the benefit of having remote work?

Gonçalo Silva: [00:13:06] I think sometimes we focus on the obvious benefits. We talk about not having to commute. If you save half an hour every day, or maybe half an hour plus half an hour, so one hour every day, you’re going to save a lot of time across the week and across the year. And it’s going to be very impactful for you. You can be using this hour to do something else other than commuting. This idea immediately pops into our head. Another idea that I think is fairly obvious for most people, this is on the company side, is you have access to a global talent pool. You can hire anywhere across the world. And so suddenly, you don’t have to trust the location you’re in to find all of the talent you need. You can literally hire from everywhere. But I think there are other, maybe more indirect advantages that are worth considering. For example, you can have a really diverse team when you hire globally. You can have people from all across the world with all kinds of different backgrounds. And you can gain immensely from this diversity. In the way, this translates to everything you do, to your culture, to your product. And of course, you can have all of this diversity too in a specific place, but this requires people to move there. While this doesn’t really happen if you’re hiring locally. And another thing that I think is really important is, when you have access to this global talent pool, this improves the odds of small companies to be able to compete with larger companies. Hiring is tough, but you have access to really talented people in all corners of the world.

So, this levels the playing field a little bit. I’m sure if you’re in a technological hub like Silicon Valley, or maybe even the European ones like London. If you’re a big company, you generally are able to hire better than smaller companies. You have more funds. You have more reputation. It’s very different from hiring remotely. A lot of the big players don’t hire remotely. That’s changing now. But still, it’s quite interesting to think about leveling the playing field. And another thing that I think is super important is: remote work allows us to revitalize the local communities. So we don’t need to go and fight for space in various specific hubs, which becomes — we live in small places. We pay high rents. So economically, it doesn’t make a lot of sense. And by hiring remotely, by hiring globally, you are helping revitalize these local communities, which in the end, I think benefits all of humanity. So I think there are benefits for employees, for employers, and even for communities as a whole. Those are some of the areas I think are very impactful.

Henry Suryawirawan: [00:15:20] So maybe in that case, the flip side of it, what are some of the disadvantages, especially from people, maybe that you hired coming from traditional company background? Because we all can say, “Oh, so many things, maybe go wrong.” But maybe from those people who joined and then have experienced the traditional and transitioned into the remote work. Maybe you can share some of the disadvantages that they went through?

Gonçalo Silva: [00:15:39] I think human connection is tricky. Humans are optimized for communicating face-to-face and we have been improving our skills in this area for millennia. And suddenly, we’re sitting behind screens in some office or room, isolated from everybody else. And there’s a lot of signal we lose here. Body language, but even the connection, like the emotional connection that we feel towards other people. This is really hard to compensate for remotely. You can do a lot of things, you can think about a lot of ways to bring that connection back to the team. But honestly, in an office, it’s something you get for free. People are sitting next to each other. They collaborate together. There’s a water cooler. People have lunch together. And suddenly you lose all of this. And you have to have a whole team thinking very intentionally about this problem and designing ways to fight this disadvantage. One specific example I can give you is, we have at Doist, two yearly retreats per year. These are two opportunities we use to reconnect as a team. And one of these retreats is company-wide. Everybody gets together for a week somewhere in the world. The other of these retreats is team specific. Each team gets together in somewhere specific also annually. Because of the pandemic, we haven’t been able to do this. And we can feel that this has an impact. We feel less connected than usual. In some ways the human connection side of things is not only tricky. It’s fragile. And we need to think about it very consciously, because it can ruin our culture if we don’t uphold this.

Something else that also happens is: the way we work remotely is very specific. We have to rely on technology. Similarly to before where we’re not right next to another person, a lot of the communication we do in person is very high bandwidth. And we’re used to this type of communication. We enjoy it. We communicate in words. We speak very fast. We have body language. There’s enormous amounts of communication flowing back and forth. For some workflows, for example, when you’re brainstorming a new idea, this can be very productive. You can get a lot of work done in an hour, just by hashing some ideas out with somebody. The way we work remotely, generally speaking, is not very productive in these terms. Imagine having a very raw brainstorm over Slack. It’s a nightmare.

On the other hand, there are some workflows which are really good when you’re working remotely. Just the fact that you have all of this buffer to sit back, and think about your ideas and reflect about them and refine them and polish them. You’re kind of like editing before sharing, makes it so that most conversations are really high signal. There’s a very low noise. And this is really good, going back to the advantages of remote work. But for some things, remote work isn’t really suited. Because, we also usually speak a bit earlier than we should. We do this. It’s just the way we work. But for that early stage, when high bandwidth is really important, the lack of co-location is a disadvantage. And it’s not as easy. You can go on a call, but you still lose body language. Technology breaks down, as the things stop working. Sometimes you’re struggling with the tool. The whole workflow of “Can you hear me? Am I still here?”, instead of focusing on the actual idea. So there’s all of this friction that doesn’t exist when you’re sitting next to another person. It’s a disadvantage. You can design your workflows. You can design a lot of things to prevent and to fight back on this disadvantages, but they’re there by default. So I think those two things are quite big disadvantages — the lack of human connection by default, and also not being able to have very high bandwidth conversations, also by default.

Asynchronous vs Synchronous [00:18:53]

Henry Suryawirawan: [00:18:53] I guess I’m also quite intrigued, because by doing remote work, you can still have this high bandwidth. But I think that’s not one of the best practice, like maybe Doist and some other remote companies are doing. Because they always advocate asynchronous first. Because it could happen also like, you do remote work, but you still communicate through Slacks and maybe videos, meetings all the time. But that is actually one of the bad practices, if I understand correctly? And that you should prefer asynchronous first rather than synchronous.

Gonçalo Silva: [00:19:21] Yes. So we’re big believers of asynchronous work. We’re very inspired by, for example, Deep Work by Cal Newport. And we really optimize the way we work and our culture towards this. For example, we only have five core values at Doist. And one of them is independence. The thing is, the future of work, we feel it’s much more rewarding if you can block most of your day to work on something that’s very specific and tangible. You can reflect. You can do your best work. And you can be done with it. When you think about the regular workplace, and even the chat based workplace nowadays, it’s filled with interruptions. And interruptions break the flow for you. Flow makes you happy. So if you can’t achieve flow, you’re less happy, let’s say. Generally speaking, asynchronous communication promotes flow. And flow is generally what we’re all looking for. Not only because it’s more productive. Not only it’s because it’s within this state that we produce the best work. It’s also within this state that we feel the most fulfilled.

Asynchronous communication is really a way of promoting flow for us. And also ensuring that the work we do, as this connects to what we were discussing before, is very high signal. So when you communicate asynchronously, you communicate with very high signal. When you work with flow, your work itself is very high signal. So people are generally very productive, very fulfilled, and they can do their best work without being interrupted all the time. So there are many advantages to asynchronous communication that we promote. For the record, we think a synchronous communication has a place. It needs to be there. So usually talk about 90% of the time we should be doing asynchronous communication, 10% of the time we should be doing synchronous communication. It’s not a either-or situation. Because there are some workflows that are really suited for communicating synchronously. Of course, like all of the other teams, we have one-on-ones. And these things, we don’t really try to do them asynchronously. Because again, we’re looking for that human connection. Something required that human connection. And we want to make sure there’s room for those things. We have team meetings, which honestly, they are not very tactical. Within most of our planning, asynchronously, the team meeting serve a very specific purpose like this. They look tactical on the surface, but deep down, they’re just an opportunity for people to get together on a call, see each other every week, and talk a little bit about the work they’re doing. Again, it’s looking for that human connection. And there needs to be room for that. But by default, definitely asynchronous and optimizing for asynchronosity. When you’re working remotely, this is also the smartest thing to do. Because if you try to make things synchronous, when you’re remote, you’re going to struggle a little bit. You have people across time zones. People in different locations. The tooling is great nowadays, but it’s not fantastic, it’s not flawless. So if you can minimize this friction, everybody wins generally speaking.

Henry Suryawirawan: [00:21:59] So I get what you mean. But again, coming from the traditional background, my tendency will be, okay, asynchronous first. If I have something, normally, as a common employee, we would want to have a response as soon as possible. With this kind of setup, what would you think we should do? Let’s say if I request for something, and I have to wait for, I don’t know, a few hours, a few days, do you always have a, like multiple tracks that you’re working on asynchronously? Maybe you can share a little bit of light on that front.

Gonçalo Silva: [00:22:25] It’s a great question. Yes, this is something we’ve designed very intentionally for in our workflows. When we’re working with people, we’re blocked all the time. And if we are fully asynchronous, these blocks can last a very long time. There are a few things we do to work around this, so to speak. The first one is we are very conscious about having separate tracks, as you said. So officially, there’s only usually one main piece of work that we’re doing. But there’s also this idea of a backlog of things we can also do. So if you get blocked on something, you can switch to something else. And we try to master this workflow of context switching. It’s usually very expensive as you know, so we try to minimize it as much as possible. This is something we train people from day one. You will context switch. And usually there are ways you can tweak this to remain productive. For example, your secondary tasks should be something fairly small, attainable, maybe something you can do in two hours, fix a bug. So it becomes rewarding very fast. And this helps our brain be motivated to work on something else.

But we also do a lot of preparation work to ensure that we’re not blocked most of the time. So what this means is we had a stage many years ago, for example, where we didn’t think as much about this, where maybe we went into work without having thought out about how things should work like, what the design could look like. There was a lot of indefinition. And this lends to us being blocked all the time. And this was very detrimental to the work we did. So now we really try to anticipate as much as possible. For example, we work in squads, cross-functional squads to build things. And before we start doing the actual work, the squad usually starts discussing the work. So while they’re finishing off their previous pieces of work, they’re already thinking about and discussing the next thing. Like how should it look? What are the challenges? What are the edge cases? We try to predict these things, so that we can get them out of the way. On day one, when we start actually working on it, there’s a lot of definition from the team itself that will build it on what they’re building and how they’re building it. Of course, this still fails every once in a while, but just the fact that you’re very intentional about this preparation. In fact, the preparation is a secondary track of work, sometimes for people. It’s very important to make sure that your blocks much less than you would be by default. So I think it’s a mixture of these two things. Preparing as much as possible to avoid the blocks. And also training on “we’re going to be blocked”. Let’s assume that’s gonna happen. How can we minimize the impact of these blocks? How can we maybe even make them productive? For example, I think something we do fairly well is handle those priority two tasks that most teams struggle with. Because they often end up in that secondary track. So we slowly get work done that maybe it’s not as prioritized as the main bulk of work. So yeah, those two things preparation and also minimization of the impact are two things we invest very heavily in.

Handling Emergencies [00:25:10]

Henry Suryawirawan: [00:25:10] How about emergency incidents or support from customers? What would you do then? I mean, especially if it touches multiple teams.

Gonçalo Silva: [00:25:18] The thing that’s interesting about us and this is something I think is an area where we will still grow. So we separate those two things, incidents and user reports and requests. We have this role internally, we call the hero. We have one of these. There’s a hero per team, per functional team. And this person is constantly working with our support team in improving things for customers — fixing bugs, triaging bugs, providing technical feedback where needed. We have this permanent presence working with the customers. And this works fairly well, although it’s quite tricky. On one hand, one person is really not a lot of people working on this. But on the other hand, this type of role, it’s a bit like a black hole. The more people we put working on this, the more people will be like 100% utilized. So we have to balance this type of work.

On the other hand, you mentioned incidents. And this is an area where I think we lack some maturity, because we don’t have a really good setup for on-call. We don’t have good definition of how our incident handling looked like. I mean, we have policies just like every other company. But if I’m honest, we have very few incidents. And in some instances, this is unhelpful, because it doesn’t force us to build a great culture around this. We actually had an incident recently, with the last major incident before that was years ago. That’s like the state we’re in. We don’t have major incidents. But this also land us to not have to solve this problem you asked about. So I’m not sure. I’m not sure how we’re going to scale in this regard, how we’re going to nail this. Maybe it’s something around the way we tackle support- led work with the heroes. Maybe it will be something else. But I’m unsure to be honest.

On Meeting and Real-time Chat [00:26:48]

Henry Suryawirawan: [00:26:48] Well, if I have to choose, I would choose no incidence versus having to tackle it for sure. The other thing, for example, I also learned this from GitLab. GitLab is also one company who promotes this remote work. So one thing they have is about “No meeting”, unless you have a clear agenda, everyone agrees on something before they actually go into a meeting. And also chat, like Slack, or I don’t know any other chat, probably is prohibited in a sense. Does it work the same way for Doist?

Gonçalo Silva: [00:27:14] Actually, we don’t use any chat tool. We use our own tool, Twist, which is more optimized for a long-form communication. It still has chat built in, but it’s not front and center. For all of these other synchronous processes, meetings, as you said, we follow best practices. So all of the meetings have an agenda that’s prepared beforehand by everyone involved. All of the meetings have an action section, which basically every time you meet with somebody, there should be things you need to act on. You take notes on these. I will do this. You will do that. You kind of like split next steps with the other person. So we try to make them very actionable. We also limit their time. We have meetings which spanned from 30 to 45 and 60 minutes. We try to be very diligent with this. And again, it comes with preparation. Having an agenda, going through that agenda, and then figuring out the next steps and documenting all of this. So yeah, we definitely follow all of these processes. And we try something else, like GitLab also does that we also do, is we have a lot of internal documentation. If most of the meetings that would be related with understanding something that can be prevented because it’s usually documented somewhere. So it’s more about making documentation accessible and well organized, so that people can self-serve and find the information they need. Which I guess, circles back to how we approach synchronous communication and meetings, more specifically. We’re looking for that human connection, so it doesn’t really have a tactical value for us. Not most of the time, of course, exceptions.

Henry Suryawirawan: [00:28:38] But do you actually track your employees' tendency towards this meetings and chat, because it could happen organically, right? Like for example, I just joined a company. I just spread messages or invite people to meetings, but you actually are not aware about that. Do you actually track how much impact of these kind of behaviors and activities within company?

Gonçalo Silva: [00:28:55] No, we don’t track people at all. We don’t believe in tracking. What we try to do is we try to define this culture that I’m describing to you as much as possible. And we do this. I’m doing this here with you today. But also we write about this all the time, not only in our blog, but also internal tooling. And what we try to do is really get buy-in from people. We all need to believe in this approach to work. If somebody has a lot of meetings, we’re not doing a good job of explaining the culture and why and the benefits. So we see it like that, as an alignment of thing more than anything else, but we don’t track. And we definitely have a lot of room, because we’re all different. Even if we’re all aligned on the culture, if we all agree this is the way forward, even if there’s a lot of buy-in, two different people will have two different sets of needs and different sets of tendencies. One of these people, even if they’re fully aligned, one of these people maybe will prefer not to have any meetings. And another person will prefer to have a few meetings. We try to cater to these differences. And even be very mindful of this. For example, our team leads have mostly a fixed cadence for meetings with their team members. But there were a lot of individual optimization because we’re all different. For examples, individuals prefer that meetings have very heavy preparation beforehand, even if they’re a personal, like one-on-one type of meetings, writing down all of the topics, providing a lot of context, maybe even having pre-discussions before you actually meet with another person. While other people will be more type of wing-it. Yeah. Let’s get together. Chat, see each other face to face. And we’ll see what comes up. We try to be mindful of these differences, and not trying to force everybody into a single mold. But we don’t track it all, definitely. Not how many meetings we’re having. Not what people are doing or how they’re doing it. So in a way, if we’re not convinced ourselves of this approach to work, then it’s going to be very difficult to convince the world that it’s a worthy alternative.

Hiring and Onboarding [00:30:38]

Henry Suryawirawan: [00:30:38] It makes sense certainly. So touch on this next topic, which is how do you hire people? Because I’m sure not everyone will be suitable for this kind of work. So is there any specifics that you assess from the candidates? And after you hire them, how do you onboard them so that they are immersed into this culture?

Gonçalo Silva: [00:30:55] So something to note is, it’s definitely not all roses. And we have had cases in the past of people with whom we’ve done our best, or at least to the best of our knowledge at the time, and things didn’t work out, because remote work, asynchronous communication, all of that was not working. But still, I think it’s quite rare. I think if I was looking from the outside, I would be surprised at how little this happens, actually. Going back a little bit to the hiring itself, we approach hiring by publishing jobs online and relying a lot on the internet to find candidates. We don’t scout or hunt people as much, I think as most companies do. This is both good and bad. I guess we don’t do this more because we can’t afford the time right now. And also, when we were smaller and less known, frankly, sometimes it took us a long time to hire. It would be quite often to have a job posting up for many months, and not find the person who we’re looking for. So I just want to make that disclaimer, because don’t do what we did if you’re looking to hire fast, because that’s not going to work.

The way we look for people is we have a very strong definition of the culture we’re trying to uphold. And again, we do this via internal discussion and documentation. We have five core values. We have descriptions for these core values, and we try to use these in all of the decision-making we do, which also affects hiring. So when we’re looking for new candidates, we look for traits around these core values and making sure new people will fit into them. One of them, as I mentioned before, for example, is independence. We want people who are autonomous, who take ownership over things, and who generally act like owners of the things that they are doing. We also have another core value around communication. Obviously we need great communicators because communication is expensive when you’re remote. Expensive time-wise, it takes a lot of time to write, to think, to lay out your thoughts in a structured manner. And so we need people who are really great at communicating. We use the hiring process to probe for these traits, basically. So my recommendation would be to figure out what exactly you want to be as a company. That’s what we try to do. And also be very ruthless in prioritizing. At some point we had 12 core values. And when we realized that some people in the company didn’t know all of them by heart, also because they’re 12, that’s when we understood, okay, we need to change. We need to make this so easy to understand that we find ourselves using this all the time in our thinking and our reasoning, our decision-making. And that’s what we did. Also when you’re hiring and you’re probing for these core values, there needs to be some room for whatever technical skill you’re looking for. If you’re hiring an engineer, you shouldn’t only look for the core values themselves. You need to assess how technically the person is able to tackle the challenges you want them to tackle, and so on. I’m not presenting this as a exclusive way of assessing people, but it should be part of the process.

Regarding onboarding, we do some things to set up people for success as much as possible. One of them is having, again, going back to that earlier topic, having a lot of documentation available. So we want people to come in and be able to understand how we do things, why we do things the way we do. We want all of this information to be very accessible, very transparent to people. And then we also designed the onboarding process to make it a little bit easier to ramp up. For example, the first three months when people join Doist are generally very intentionally designed. Number one, to provide small wins along the way. And number two, to expose people to all kinds of work they will be doing in the future. There’s a lightweight version of course. But making sure, for example, I mentioned the hero role before, the person that works with support. New hires generally spend a little bit of time in the beginning being the hero. And something else we do is they have a mentor. So there’s an explicit point of contact for them to reach out to, for any doubts they have. This person is the default, right? So we try to be having a very open culture. Everybody’s accessible. But sometimes you hire somebody, they still don’t know everybody, they’re a bit shy. So to break down that wall from day one, there is a mentor. You have a mentor. You’ll be in contact with this person on a day-to-day basis for the first three months. When we’re not going through a major pandemic, we also have people actually fly over to either their mentors location, or have their mentor fly over to the new person’s location and spend a couple of weeks working together, building that initial connection. The mentor has a monumental role for us. For example, the workflow I was describing to you before, of having a secondary tasks that you can switch to if you get blocked, this is something we often have to coach people into doing. How to detect that you’re going to be blocked, how to prevent being blocked. And if you’re blocked, how to rather quickly jump into that secondary task, and then return. This is something that’s obviously very specific to remote work and asynchronous communication. And the mentor of a new person we’re hiring has a fundamental role in explaining, “This is normal. It’s okay. It’s documented here. You can read more about this here.” And share all of these experiences together with the person. I think designing the onboarding very explicitly to put people through what their day to day will look like in the future, and also set them up for success, aligning expectations, being very transparent about things, is very important.

The last thing is having milestones. When you’re onboarding in a company in a new culture, there’re things you’re learning. If you’re an engineer, not only technical things, but also how do things work around here. Having these milestones, for example, for us after three months, you’re over the trial period, but there’s also a monthly check-in on how things are going. This is super important. We all talk about having tight feedback loops. And there’s this super interesting concept, radical candor. There was a book around this, very popular a few years ago. You need to embrace this if you’re working remotely, because remote work can be very opaque, if you don’t make it very transparent. So you might be onboarding someone, maybe you’re having some doubts. Maybe there’s something they’re not doing that well. If you don’t communicate about this explicitly, most often than not, people will not know. This is another thing that in an office you can pick up body language, you can indirectly realize this is happening, even though, hopefully, that’s not the only way you get a negative feedback. But making sure that when you’re onboarding someone, you also have room for very explicit feedback. Like, these are the things you’re doing really well. These are things I think you could be doing better. This is super important to make sure that people are very aligned on how things are going. And then again, this is something we did struggle with at some point in the past, where we were maybe too asynchronous, too loose, too unstructured with how we were onboarding people. There were people who didn’t make it at the end of the onboarding process. And it was a surprise for them. This is the worst feeling, I think. When you notice something was not working. And you were not aligned in this expectation. This means communicated poorly. This means you didn’t give a chance to the person to adjust if they didn’t know. I’m glad that we haven’t had anything like this in the last few years. But we did went through a stage where we were not thinking intentionally enough about the onboarding process, and this was hurting us in the feedback stage. So for sure, I guess feedback is that last piece of the puzzle. Making sure there’s a lot of room for feedback. And making it very explicit. It’s okay to have awkward meetings where I’m supposed to provide feedback to you, but I don’t have much to say all is good. This is okay. But there is a checkpoint saying at this point we sync up and this is very important. In the end, onboarding should be about setting people up for success. And there’s many areas to this. Having them experiments all kinds of work they will be dealing with is important. Having a mentor for them, especially in remote is important, regardless of how accessible your team is and how transparent things are. Just having that go-to point of contact makes things very easy.

The third area is coaching. There’s a lot of aspects that will be specific to your team within remote work and asynchronous communication. It’s okay to coach people. If you have a lot of documentation, this really helps, but also that mentor plays a crucial role in saying, you know, this is normal or here’s how you can tackle this in the future. This is very important. And the last, as I said, feedback loops, making sure they’re there, front and center.

Henry Suryawirawan: [00:38:37] Yeah, I like the feedback aspect, because obviously even without remote work, asynchronous, sometimes like working from home, you sometimes tend to have lesser feedback, or maybe you don’t know the feedback straight away because it takes time. Or maybe you have to go through either chat or meeting or maybe schedule one-on-one and things like that before you can actually get immediate feedback. So I think, yeah, having such a feedback cadence will be important, nevertheless if you are working remotely or not.

Doist 5 Core Values [00:39:01]

Henry Suryawirawan: [00:39:01] So I’m also intrigued by the five core values. You mentioned independence and communication. What are the other three?

Gonçalo Silva: [00:39:08] The other three core values are mastery, impact, ambition and balance. I know this is a trick we’re using. You could say these are six. But we look at ambition and balance as a bit of a yin and yang. So one doesn’t exist without the other. I really liked the definition that James Clear uses of balance, where he defines a balance as being when you’re working those eight hours, you’re 100% working ruthlessly. And then when you’re resting, you are resting 100% ruthlessly. So that’s what balance really means. And we really liked that definition. The problem is, if we just write balance, it can be misinterpreted. Maybe a bit complacence notion. And we wanted to make sure this is like, we work hard and then we rest hard. That’s how we try to behave. Similarly with impact, it’s focusing on high impact things basically. There will always be more work to do than we can do. So being very explicit about trade-offs and prioritization is something we value very highly in people. And the last one that I mentioned is mastery. Yeah. I guess mastery applies to a lot of companies, but we really want to be good in our crafts. We want us and our people, like all of Doisters to have a craft and we want to be very good at what we do and be very ambitious moving forward.

We try to keep things simple to these five core values, because another advantage to having a small set of core values is that these ideas don’t necessarily compete with each other. Sometimes when you find list of core values that are larger, 15, 20, you will often find contradicting points. These core values can compete with one another in certain situations. We want to avoid this as much as possible. So for example, one of our core values is independence. So we do expect us to be very mature about handling work independently, finding ways to work autonomously, always striving to take ownership over pieces of work. This is expected and so other things like co-ownership, is something for example we don’t do as much. And I guess we will eventually discuss more technical things, including pair programming. These are things we don’t discard ever, but we don’t do them very often because they’re not aligned with our core values.

Role of Manager [00:41:07]

Henry Suryawirawan: [00:41:07] Before we go into technical discussions, one more question regarding this remote working culture. So what are the role of managers? Like how many managers does Doist have? And what are their so called core skills that they need to have for working remotely?

Gonçalo Silva: [00:41:22] Being a manager at Doist is a very demanding role, generally speaking. We have about 12 managers. And we’re about 85 in the company right now. The reason I say this is we’re structured in a functional manner. So we have a design team, an Android team, Apple team, etc. And we expect teams to have a very strong vision for their own function. There are many things which are specific to design, like, you know, design systems, how they’re built, how they’re led. We expect the design team to own these things. But even for the technical teams, our Android team, Android has a lot of new features every year that might not be directly related with our products, but we expect the Android team to have a vision about how to bring this into the product. So I say this management role is very demanding, because our Heads, for example, our Head of Android, he’s responsible not only to manage and organize the Android team, but also making sure that the team has a strong vision, and that we’re going towards that strong vision that spans not only technical traits, but also functional traits. And on top of this, our managers are mostly hands-on. Obviously not most of the time, in most cases, not even half of the time, but they are technical managers. So our managers are able to have technical discussions with the team, to support the team in technical ways, and even unblock the team. It’s super useful to have a manager that can triage work, that can get rid of that nagging small tasks that doesn’t get out of the way, so that the team can focus on the big things. So it’s really a tough job, I would say.

Technical Practices [00:42:47]

Henry Suryawirawan: [00:42:47] So let’s move on to the technical aspects. Because this podcast also has a lot of technical aspect of it. I’m quite intrigued as well. When you said just now pair programming is not something that you do quite often. It is one of the common best practices when people talk about building high quality software and things like that, right. So pair programming, co-location, and having a lot of interactions are typically the practices that people will mention in terms of building high quality software. While in the remote work, coming back to your asynchronous first and all the other working aspects of remote work, seems like contradicting. So maybe you can share your thoughts about this?

Gonçalo Silva: [00:43:23] To be clear, I have nothing against pair programming. I think actually it’s an amazing way to work. It’s just not very suitable for working remotely. And I want to reinforce that we have a team that spans the whole world. Even if there is some overlap of time zones, this is not guaranteed. And we try to work with processes that have some guarantees. We want to ensure we have processes that support this. So we don’t discard pair programming at all. If people want to do it, they should do it, but it doesn’t happen that often. Instead, we focus on things that lend themselves to working asynchronously too. So for example, we have a very fleshed out review process. We have very strong guidelines on how reviews should be approached. Our reviews are very thorough. For example, we’re not only looking at the code or the architecture. The reviewers also check out the code and test it and run it and look for edge cases and do a little bit of Q and A. We try to make sure that the code goes through this process where it is reviewed in a lot of detail. And honestly, the reviewer kind of becomes a co-owner. I am approving this. I know how it works. I know how it looks like. I know how the user will experience this. It has my seal of approval. And we have really good guidelines on how reviews should be approached, for example, to make them consistent across teams and across the company.

Besides this, we try to automate a lot of things. For example, we have very strong linting setups at this point, also to ensure that consistency. When the review time comes around, we are focused on the higher level aspects of the code and how it looks and how it works. Automation is a very big scope. But there are many big advantages to automating things, especially when you’re working asynchronously. If you define, I mentioned linting in passing, but basically what that means is you’re defining as a team, and this should be a team process, how you want the details in the code to look like, and you’re codifying this into some kind of tool. So you don’t have to do this over and over again. And that frees up your brain power to focus on other aspects. Similarly, there are other ends of automation which improve quality, for example, continuous integration. I think remote teams should really invest in their CI setups, so that you can get out of the way that things work. If you have good testing practices, if you have good CI, you will, of course, this doesn’t prevent all of the problems, but it actually prevents a lot of the problems. And it lets you, for example, do bigger refactors, more confidently alone. So it’s just optimizing for that working alone feeling, so that when you do have a chance to pair program with somebody, it’s a bonus. It comes on top. It’s not an expectation. And this is really important.

Something else we try to do as well that promotes working independently is, circling back to documentation, we have very strong, very thorough style guides. We have a lot of documentation on how the moving parts of our applications look like, and why they look like the way they look. Like, the higher level ideas. We try to document them as much as possible. We’re not there. And I wonder will we ever be there. But we want to get to a point where we hire somebody, they come in, and we can say, “Hey, there’s this section of our handbook. Look at it. And if you actually read all of this, you will know almost as much as we do.” We really try to invest in this self-serve approach to the technical side of things. The reason people peer review, not only because it’s fun and it leads to higher quality work, of course, it’s also because there are two people figuring out a problem alone. So the thing we try to optimize for is when you’re working alone, you don’t actually feel alone. Because there’s great support for the work that you’re doing in terms of documentation, in terms of the tooling. All of the setup around you is set up in a way where you’re not alone, where you are supported. We try to optimize for this. And then of course, we end with a very thorough peer review to bring that human element into the mix.

Henry Suryawirawan: [00:46:52] So I also assume that in the beginning, before somebody submits the work for review, there might be a definition of done of maybe checklists. Maybe you used Todoist to do that. I don’t know. But it’s like a checklist of, “Okay, here are the things that you need to check before you actually can submit for review.” Is that how it works as well? So that you minimize all these contradicting things that probably cannot be automated, or maybe it’s just too costly to automate.

Gonçalo Silva: [00:47:16] Yes. So this is part of our investment in documentation. We start most pieces of work with a spec. And I’m using this term very loosely. But what I mean by a spec, it can be a product spec, if this is a feature or a technical spec, if this is a more technical centered piece of work. We try to be very thorough in detailing: what are we doing? Why are we doing it? And what’s done looks as you’ve described. The thing to note is we don’t give this to engineers, so to speak. We actually wants the teams to build this themselves. So even the product team, as we work through a problem is more focused on what is the problem itself than maybe the solution. Because as I said before, we assembled squads, cross-functional squads to work on things. And we try to ensure that this discovery process is owned by the team itself, because this lends to our independence core value, we’re back at this again. And even technical pieces of work. Sometimes you can start a problem with “We have a lot of problems related with billing. We need to refactor billing.” That’s the problem statement. Then the engineer who will work on this will actually do some investigation work, some triaging, and figure out the scope of the work. This is the amount of work I think we should do to tackle the problem in an efficient way. Like of course we could spend years rebuilding biling all the time. And we could maybe do a small fix that doesn’t really address the underlying problem. Finding that balance between a long-term investment and a short-term investment, we also expect engineers to be making this calls. Again, because of the independence core value. But we translate this calls into specs. So we make the process very transparent. When we start work, it should be very clear, generally speaking. This is not possible sometimes. But most of the times, it should be very clear. What is the exact scope of work and what success looks like?

Prioritization [00:48:55]

Henry Suryawirawan: [00:48:55] So, I could also imagine, as a startup or any kind of a product company, you have maybe hundreds of features or bugs. And you mentioned you work cross-functionally. There’s like a product team. There’s also engineering team, which is subdivided by platform, maybe like Android web, and things like that. So how do you ensure this prioritization of, okay, which features should I do now? Because it seems like the engineer will need to come up with the investigation, the triaging, and turn it into spec, and the estimation, things like that. So how does this process work? Is this like you come up together in one meeting? Okay, let’s pick some of those things that we will do for the next few months or so.

Gonçalo Silva: [00:49:29] I guess like most teams, we have some conflict of prioritization. I mean this in a good way. We want to do more work than what we can do. But something we invest very heavily, and I’m unsure how much this will scale, but it’s working pretty well for us. It’s pre-allocation of effort. So as you can imagine, this is not only about which feature to work on. It has many ramifications, like which feature to work on, but also how do you balance feature and internal work? And also we have two products. How do we balance working on one product versus working on the other product? The thing we try to do as much as possible is just pre-allocating. And then making small adjustments as we go to make sure that we’re putting as much effort into things as we’d like. So for example, I mentioned to you before that we have one person per team, who is the hero, which is what we call the support led role. So we’re pre-allocating. In months where things are great, we have one hero. In months where we have, for some reason, a lot of issues, we still have one hero. And that’s just how it works. Even the split between Todoist and Twist, we pre-allocate. We have this rough percentage of efforts we should be putting into each of the products. And we have tweaked this in the past, mind you, so this is not fixed or static. And honestly, anybody can challenge this in the company. And often people do. And we adjust. But once we settle on a new more number, we commit to it, so we’re not discussing this all the time.

There’s varying degrees of pre-allocation. And we even try to do this around product work. Let me explain. We have a very transparent and democratic process around products. Luckily, we have a team that is very product minded. People have a lot of ideas on how to improve things. And that’s great. And we have a workflow where people propose their ideas, and they make a pitch like why we should do this. As you can imagine, we have a lot more ideas than we can actually execute on. But the thing we do is we have this high level themes that span many months, usually half a year and nine months, one year at most lately. And these themes help us filter and narrow down the things we should focus on. For example, this year for Todoist, we decided we would be working on visualization. Visualization of your data, of your tasks, and being able to slice and dice your data in useful ways. For example, we introduced the Upcoming view, which is like a never ending list of tasks for the future in all future dates. We introduced the Board view. So looking at your tasks in columns, instead of just being a task list. And now we’re going to launch something very soon, which we call Sorting options, which you know, is being able to sort and group your tasks by any criteria in any view. The reason I’m mentioning this is, this pre-allocation, pre-decisions, they really help us prevent a lot of conflict and honestly spend a lot of energy. Because if we don’t do this, we’re going to be arguing about what to do next all the time. And it’s not always going to be super clear. Now, the thing to note is we try to be very transparent about why we pick the beans we pick. Like we picked Todoist views, for example, and we have a documentation and a large internal discussion on why this is the best course of action for Todoist at the time. It has to do with our competition, the market, also because of the pandemic are resorting more to task management, and want to see their tasks in very specific ways. We’re all different. Giving all of these options to people will position Todoist very strongly in the markets against the competition, because it becomes very versatile. So we’ve decided to focus on this. And then we look at our backlog and see, “Okay, what fits into this theme?”

We extend this pre-allocation to engineering as well. At the moment, we try to have roughly 20% of our efforts put purely into internal type of work. Improving the foundations of our code. Improving architecture. Improving testing. Like things that don’t have necessarily tangible deliverable for the other teams in the company. They don’t have a design deliverable. They don’t have a product deliverable. They’re just purely internal. We try to put around 20% of our efforts here. And again, it’s a pre-allocation. As I’m sure, any listener can imagine, we have some code bases which are more modern than others. Some need more attention than others. But still we try to keep this roughly consistent and then just challenge the principles and be mindful of any changes we need to do. So if a team lead is looking at their code base and thinking, “we’ve been building this code base for 13 years”. And by the way, this is actually true for some of our code bases. So we have 13 year old code bases that were never rewritten from the ground up. They have been continuously improved. And sometimes 20% is not enough to keep up with modernization and making sure things are well structured. This ties back to the function of the team lead at Doist, which is supposed to flag this and say, “Hey, we’re not going in a good direction. We need more people here.” And then we make just a small adjustment, but we changed that pre-allocation. We’re not discussing this week “we need more”, next week “we need less” and then the week after “we need more” again. We try to avoid this as much as possible.

Doist Architecture [00:54:04]

Henry Suryawirawan: [00:54:04] Thanks for the thorough explanation. So just a little bit curious as well. How does the Doist architecture look like? Do you have microservices where you have each functional team having their own architecture and things to manage? Or do you have a monolith? Maybe you can share a little bit on that front if you can.

Gonçalo Silva: [00:54:19] Yeah. So generally speaking, we have a monolith. We call it internally, the majestic monolith, inspired by DHH post about Basecamp. But we do have a few services to be honest. Like there are some things which are very opportunistic and also because we have Todoist and Twist, some things really make sense in isolation. An example I like to use is the thumbnail service we use. So both of our products have a sort of comments in both of them. You can paste links in both of them. We want to have a preview of things and then take thumbnails, basically speaking. And these things live very well in isolation. There are a few opportunistic services we have, but generally speaking, we have a majestic monolith everywhere. And I also think this lends to our functional structure. We have a backend team, for example. The backend team owns the backend code bases. One for Todoist, one for Twist. So we really embraced this monolith approach to development. I know we could spend the whole day arguing about the pros and cons of monoliths versus microservices. I really think generally speaking, what’s important is that you have buy-in from the team. Both approaches have pros and cons. If you approach them in a mindful way, with mastery, tying back to the core values, you can have a monolith and try to make it a really good monolith. Just like you can have microservices and make sure you have a really good architecture around that too. I think that’s more important than any specific approach. But we use monolith for sure.

Henry Suryawirawan: [00:55:39] Yeah, certainly. I don’t see any problem with monolith as well. But, as you know, we all like this kind of a debate sometimes in the engineering, microservices versus monolith.

Remote Work Resources [00:55:48]

Henry Suryawirawan: [00:55:48] So maybe for people who wants to learn more about this remote working culture, or maybe some of the engineering best practices for remote work, is there any resources that is publicly available that people can look at?

Gonçalo Silva: [00:55:59] Yes and no, because I think you asked two questions. So we write a lot about remote work in our blog. I think Doist’s blog is amazing. There are contributions from all across the company from engineering to marketing to contents. There’s really, I think something for everyone. And we obviously talk a lot about the way we work and the way we see work. For anything related with remote work, asynchronous communication, or if any of the core values that I mentioned in the podcast resonated with people, there’s probably something about this in the blog. So, highly recommended. As for the technical side of things, unfortunately, we don’t do as good of a job. We have a technical blog in the pipeline, but I don’t have any ETA for this. But I hope in the future we’re more transparent about the way we approach work on a technical basis too. A lot of Doisters have Twitter. A lot of Doisters tweet about work. So that’s also an alternative to find more content about how we tackle the technical challenges.

3 Tech Lead Wisdom [00:56:54]

Henry Suryawirawan: [00:56:54] So Gonçalo, it’s been a pleasure talking to you. My last question, my final question, as usual, it’s about three technical leadership wisdom. Do you have the wisdom for you to share with all of us?

Gonçalo Silva: [00:57:03] I made some notes about this before the interview, because I knew this one was coming. My first advice would be to stay hands-on. By staying hands-on, it doesn’t mean you need to be deep down in the weeds, doing work eight hours a day. Management should not be a side job. If you’re leading a team, you should focus on leading that team. But staying hands-on means, first of all, it’s hard to say this, but you can provide a better service to your team. Because you can unblock them in certain types of work. You can help triage work when the workload increases. You can support them on a technical level too. And also you can use that knowledge, use that intuition that comes from staying hands-on to guide discussions and ask questions. I think a lot of the work of a leader is just asking the right questions at the right time. And if you have that technical background, it’s really helpful. And of course, since you’re not programming many hours a day, day in day out, you can even focus a bit more on R&D, for example, to stay sharp and make sure you have a great technical intuition. So I think that would be my first advice, to not abandon the technical side of things. I really believe it’s a very useful tool in the tool belt if you have it.

My second tip is about, actually something we touched on a little bit earlier around the monoliths and the microservices. I really think that most people in our field are very opinionated. And that’s a good thing. But having a vision in many instances is better than the vision itself. So I would say if you have a team that’s misaligned. Like some people want to do a monolith. Some people want to do microservices. That is honestly the worst situation you can be in, because this lack of alignment will lead to friction. It will lead to low-hanging fruit. It will lead to, honestly, low quality work. You will have high quality work that’s very disconnected from each other. So I think as a team leader, sometimes we will need to set your opinions aside a little bit to find alignments within the team. Because if you can get the team to align under one single idea, that’s when you’re going to get the best outcome long-term. And that’s what you should focus on. And I think a lot of people in technical leadership, they get there because they have great ideas. You have great ideas. You have great execution. So ended up leading a team. And then suddenly, there’s this disconnect because, okay, but now you actually need to put those ideas a little bit aside to hear your teams, see what they’re telling you and finding that alignment. This can be tricky, but it’s a really good tool to find longterm success. Having a vision is better than whatever specific vision you’re looking for.

And the last one is also something we, I think cover across the whole interview. I’m a huge believer in core values. And I talked about Doist’s core values, the five ones. But I also think engineering should have core values. Because here’s the thing. We can’t do everything we want with the amount of attention we want, to put into things. We are going to have to make trade-offs. And we’re constantly making trade-offs. Having core values as a team, even as a technical team, defining these core values can be hugely important for you, to make sure you’re making the right trade-offs. I think if we rely on our implicit ideas to make trade-offs, they will be good. But as you scale the team, they will disconnect. Some person will be, for example, they will value performance a lot. Their code will be super efficient. The UX will be amazing. The whole superhuman under a 50 millisecond thing. You’re going to have great work coming from that person. Maybe you have another person who is super keen on scalable architecture. So they will spend a lot of time designing the systems from a technical standpoint to be extendable, maintainable. Not necessarily have user-facing traits, but be very well thought out and put out. And these things, they don’t compete. But in some instances you won’t be able to do something that’s highly organized and maintainable, that’s highly performant, that’s really well tested and that also meets the deadline. So defining this core values, and again, see something you should be doing with your team. Let’s pick some things, and things we can remember by heart. So four, five, six, not more. And then use those things to make the right trade-offs, to define the identity of your team, and to define how you as a team approach work. Because when people are aligned and they’re seeing things in a similar way, and they’re approaching trade-offs in a consistent way, you’re going to get a lot of compounding benefits. Let’s for example, pick architecture. If you really want to build something for the next five decades. Let’s go really high here. And you pick maintainability as a core value. Something you always prioritize. If everybody’s doing this, you’re going to gain a lot because there will be no loose ends. If performance is a very important characteristic of your product, like it is for superhuman, and you have everybody ruthlessly optimizing the code that they write, you’re gonna get, again, compounding benefits, because there is no low hanging fruits, and you’re always building on top of other people’s excellent work in this regard. So yeah, I guess in the end, defining what success looks like on the high level, which usually can translate to core values, would be my third tip.

Henry Suryawirawan: [01:01:45] I really, really like all your wisdom. I think it’s really thoughtful for you to mention that and share with the audience here. Thank you so much for spending your time here, sharing your best practices about remote work. One thing that I learned personally, because I come from traditional background, as I mentioned in the beginning. So having to know all this, I think is also a good thing. Especially even if you can’t work in a remote work, still, within this working from home, there are aspects that we can take as well for our benefits. Things like, for example, pre-allocation, I think is also one thing that I like, because you don’t actually need to always come with a immediate response from your colleagues. So pre-allocating, some of the things that you can do at the side while waiting for the response. I think is really good. And some of other things. So Gonçalo, is there any other place for people to maybe find you online or interact with you if they want to know more?

Gonçalo Silva: [01:02:28] Yeah, I’m not really great at social media, but I do use Twitter. So if people want to connect with me, see what I’m thinking, I’m not super active, but I am active on Twitter, and will share wisdom. I will try to share wisdom every now and then.

Henry Suryawirawan: [01:02:41] Alright. So thank you so much, Gonçalo. I hope to see you again in future episodes.

Gonçalo Silva: [01:02:45] I had a great time. Thank you, Henry.

– End –