Synchronous, communication, promotes flow and flow is generally what we're all looking for. Not only because it's more productive, not only to because it's within this state that we produce the best work. It's also within the static, we feel the most fulfilled. Hey everyone. My name is Henry Surah one. And you're listening to the tekhelet journal.
The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello, my friend is really great to be back here with another new episode of the taglit journal.
With me Ojos, Henry, Surah one. Thank you for tuning in and spending your time with me today, listening to this episode. If you haven't joined any of the Tecla 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. I've 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 by 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. So 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 to what 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 Gonzalo Silva. The CTO of do is the company behind the popular productivity app to do this. And the communication app. Twist do is has been a remote first company practically since the founder started working on to do is in 2007 and became officially fully remote.
When it hired its first remote employee in 2011 do is has a mission of building the future of work by creating tools that promote more fulfilling ways to work and live do is has also been promoting the They work, which they call the future of work by publishing and sharing lots of great articles on their famous block, ambition and balance.
In this episode. I learned a lot from Gonzalo about DUIs and it's remote, working history, and culture, including some advantages and disadvantages of remote work. We also discuss at length about having a synchronous 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 Gonzalo. Then shares about Dewey's core
values. The Cornerstone of every single thing that do is dust as a company from creating processes to decision-making and also recruiting towards the end. Gonzalo. Also shares some engineering and Technical practices that do is dust especially the ones important for a successful remote team, including the importance of pre, allocation and prioritization to avoid being block. 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 long-term Avid user of to do is having this conversation with Gonzalo, 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 podcast 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. Are you start up in software development Which is less than
five years old. If yes our sponsor at jetbrains have a 50% startup discount offer, which allows that Ops 2 Chase multiple products and subscriptions for up to 10 unique licenses over a period of months to find out more search for jetbrains startup discount offer or you can check out the link mention in the show notes. Hi Gonzalo, good to see you.
It's great really to hear some things about to do is 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 it's sharing the best practices and I'm really excited to see you and talk to you about remote work today. Hi, I'm Ray. Thank you for inviting me. I'm very excited to be on the podcast today as well. Thank you. So Gonzalo, maybe.
First of all, can you brief us? What is your company doing? Do is right. Yes. So, our name is due West, we're building two products that people know about. So, to-do list 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 Says on asynchronous communication along form,
thoughtful communication. But ultimately, what we're doing at do is, is we have this Moto 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 a synchronous communication. So we're really trying to make a dent in the workplace.
Also, by leaving our idea. Also, this comes through our tools and also the way we work specifically before we start. Obviously as usual. I will ask my guests to share their courage and he so maybe Gonzalo. Can you share with us your career Journey? What are some of the major highlights are turning points? What made you start it working in the remote company.
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 back started comes from open source software, so I was lucky my first Player. 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 access paranoid permalink who 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 do This comes into my background. Do it was one of my clients actually my last client. They hired me, Android app at this time, due east had four people in total together with a friend who was working with me on this project. We build 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. Jacques, I think I struggled a lot with the reward mechanisms. For example, I think we weren't 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 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 chakra me was, when I changed from managing people to managing managers in the CTO role. And honestly, sometimes people say that the biggest shake-up a
person can have in their career. 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 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 to 14 years. And I think remote work has been always been very core to my way of working. What, even when I don't realize when it's not very explicit. Like it is today at doest. So if I understand correctly, you have never worked in the typical corporate and the price
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, internal projects, just like everybody else, but most of my attention was in the open source contributions. Is because the company used these projects. So I was tasked with improving them as well. Even though I was in this more carpet environment. I was spending a lot of time working with the community which was around the world.
Thanks for sharing. Your story. Definitely is very interesting. Somebody who came from open source, do freelancing quite a bit before fully immersed into the remote work. So I personally myself, Heaven 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 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 is not work. Might be something that we all should explore about. First of all, you mentioned that the company started with four people when you join right? Was it remote straight away in the beginning from the founder itself? Yeah. At the time just started the founder was traveling across the world. So there was really no basis 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 startup, Chile. This big program. He met a lot of the early people. They're like our CEO. He met there. He was working on some other unrelated project, our head of marketing. She worked there. She was also part of startup 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 I'm here, was looking around for somebody who could build the Android app in a specific way this friends at Hey, I know someone back in Portugal. It was all very remote because the startup 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 I'm your approach to building the company originally this vision of the future of work was maybe even more extreme in the beginning. So I'm here thought he could and maybe he could. I mean, tried to build the company based off of Freelancers. I'm gonna hire a designer a freelancer to handle design a freelancer. Handle, the marketing and Freelancers and 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, still has 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 doest is very remote Centric from the very beginning.
I think the concept of Building Company with all Freelancers are 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 do is didn't go that route. So instead you build a company by hiring a bunch of people remotely. So maybe tell us a little bit, like what's the benefit of having remote work? I think sometimes we focus on the obvious benefits, but we talked about not having to
commute. If you save half an hour every day or maybe half an hour plus half an hour or so one hour every day. You're going to save a lot of time across the weekend 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 Community. This idea immediately pops into our head, another idea that I think it's 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 to in a specific place, but this requires people to move their. Well, this doesn't really happen
if you're hiring globally. And another thing that I think is really important is when you have access to these Global Talent pool, this improves, the odds of small companies to be able to compete with larger companies hiring is tough, but you have Says 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 do repeating ones, like London, you sure are 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 our
local communities. So we don't need to go and fight for space in a very specific hubs, which becomes real live in small places and we pay high rents. So economically doesn't make a lot of sense and by hiring remotely by hiring globally, you are helping Revitalize. This 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.
Very impactful. So, maybe in that case, the flip side of it. What are some of the disadvantages especially, from people, maybe that you hire coming from traditional company background because we all can say, oh, so many things, maybe go wrong but maybe from those people who join and then have experience a traditional and transition into the remote work. Maybe you can share some of the disadvantages that they went through. 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 Percy. In 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, 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.
Getting very intentionally about this problem and designing ways to fight this disadvantage one specific example, I can give you is, we have a tourist to eerily 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. Acted than usual. In some ways that 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, 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 a Our most 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 the 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, Think about your ideas and reflect about them and refine them and polish them.
Your kind of like editing before sharing makes it so that most conversations are really high signal. There's 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 a student 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 colocation is a disadvantage and it's not as
easy. You can go on a call, but you still His body language, technology breaks down is the thing stopped 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 disadvantage, is the lack of human Connection by Alt and also not being able to have very high bandwidth conversations also by default. I guess.
I'm also quite intrigued, right? 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 do is and some other remote companies are doing because they always Advocate asynchronous first because it could happen also like you do removal but you still communicate through slacks and maybe videos meetings all the time, but that is actually one of the best practices if I understand correctly and that
you should prefer. I synchronous bus rather than synchronous. Yes. So we're big Believers of asynchronous work. We're very inspired by for example, deep work by call Newport and we really optimize the way we work in our culture towards this. For example, we only have five core values at duelist. 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 achieve flow you're less happy. Let's say. Generally speaking a synchronous, communication promotes flow and flow is generally what we're all looking for.
Not only because it's more productive, not only to because it's within this state that we produce the best work. It's also within the static, we feel the most fulfilled asynchronous communication is really a way of promoting flow. 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 Flo 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 eight synchronous communication has a place, it needs to be there. So usually talk about Scent of the time. We should be doing asynchronous communication, ten percent of the time you should be doing synchronous communication.
It's not 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 would require 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 with the Our planning asynchronously the team meeting serve, a very specific purpose. Like 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 a synchronicity when you're working remotely. This is also the smartest thing to do, because if you try to make things synchronous, when your remotes you're going to struggle a little A bit you have people across time zones people in different locations. The tooling is great holidays, but it's not fantastic. It's a Flawless. So if you can minimize this friction, everybody wins
generally speaking. So I get what you mean, but again, coming from the traditional background, my tendency will be okay. I synchronous 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? Please have a like multiple tracks that you looking on asynchronously.
Maybe we can share a little bit of light on that front. It's a great question. Yes. This is something we designed very intentionally for in our workflows when we're working with people where 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 Is 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 task should be something fairly small. A chainable may be something you can do in two hours fix the book. So, it becomes rewarding very fast and this helps 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, when 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 in definition and this lens 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 People 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 of course this. Bill 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 is very important to make sure that you're blocked 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 blocks and also training on. We're going to be blocked. Let's assume that's going to happen. How can we minimize the impact of this 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 how about emergency incidents or support from customers? What would you do then? Especially if it touches multiple teams? That's interesting about us and this is something I think it's 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 protein, per functional team and this person is constantly working with our support team in improving things or customers fixing bugs. Trajan box. Providing technical feedback, where needed? We have this permanent presence working with the customers and this works fairly. Well, although it's quite tricky, run, onehand. 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 would 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 look like.
I mean we have policies just like every other company, but if I'm honest we have very few incidents and in Instance, if this is unhelpful because it doesn't Force us to build a great culture around this. We actually had an instant recently with the last major incident before that was years ago. That's like the state worryin. We don't have major incidents but there's also lenses 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. Well, if I have to choose, I would choose no incidents versus having to tackle a player for sure. The other thing for example, I also learned this from gitlab gillip 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 do? He's actually we don't use any chat tool. We use our own tool twist, which More optimized for a long form, communication.
It still has checked 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 somebody, there should be things you need to act on you. Take notes on these, I will do this. You will do that. You can like split next steps
with the other person. So we try to make them very actionable. We also Emmet their time and we have meetings which span from 30 to 45 and 60 minutes. And 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. I did live 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, they 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 looking for that human
connection. So it doesn't really have a tactical value for us. Not most of the time, of course, exceptions, but the 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 me. Meetings. But you actually are not aware about that. Do you actually track how much impact of this kind of behaviors
and activities within company? No, we don't track people at all. Don't believe in tracking. What we try to do is we try to Define this culture that I'm describing you as much as possible and we do this and 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're trying 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. I mean the culture and what, and the benefits. So we see it like that, as an alignment 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 by into different people will have two different sets of needs and different sets of Tendencies.
One of these people even if they're fully lined 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. Pilar team leads have mostly a fixed Cadence for meetings with their team members, but there are a lot of individual optimization because we're all different examples. Individuals prefer that meetings have very heavy preparation or hand.
Even if their 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 a chat, see each other face to face and we'll see what comes up.
We try to be mindful of these differences in not try to force everybody into a single malt, but we don't track it all definitely not how many meetings were 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. It makes sense to certainly so such 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 Civics that you assess from the candidates. And after you hire them, how do you own board them? So that they are immersed into this culture. 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 scold or hun people as much as 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 we were
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 the 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 the people will fit into them. One of them as I mentioned before, for example, is independence. One people who are autonomous to take ownership over things and who generally act like owners of the things that they are doing. We also have another value around communication. We obviously, we need great communicators because communication is expensive when your remotes expensive TimeWise.
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. Now are thinking in our reasoning decision making, and that's what it 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 should 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 do is start generally, they're 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.
It's 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 explicitly 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 is 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 and you'll be in contact with this person on a day-to-day basis for the first three months when we're not. 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 How to rather quickly jump into that secondary task in that return. This is something that's obviously very specific to remote work and asynchronous, communication and dementor of a new person were hiring has a
fundamental role in explaining. This is normal. It's okay. It's documented here. You can read more about this year 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 and learning expectations, being very transparent. A parent about things is very
important. The last thing is having Milestones, when your onboarding in a company, in a new culture, there's 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 3 months, your over to 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 the super interesting concept.
Radical Candor. There was a book around this very popular a few years ago you need 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 negative feedback, but making sure that when your onboarding someone you also have Room for a 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 two asynchronous to lose to 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 the sex, Station. This means communicated poorly.
This means you didn't give a chance to the person to adjust. If they don't know. I'm glad 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 you 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 occurred 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 with 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. You will be dealing with is important. Having a mentor for them. Especially in remote is important regardless of how
accessible your team. He's 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 the 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 in the last, as I said, feedback loops making sure they're there front and center. Yeah, I like the feedback aspect because obviously even without remote work asynchronous, sometimes, like working from home, you sometimes tend to have less of 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 or things like that before you can actually get immediate feedback. So I think, yeah. Having such a feedback Cadence or will be important. Nevertheless, if you are working remotely or not. So, I'm also intrigued by the five core values, you mentioned Independence and communication. What are the other three? The other three core values. Our 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 Once as a bit of a yin and yang. So one doesn't exist without the other. I really like the definition that James Cleary uses of balance where he defines a balance as being when you're working those eight hours, your 100% working ruthlessly and then when you're resting you are arresting 100% ruthlessly, so that's what balance really means and we really like that definition.
The problem is if you just write balance, you can be misinterpreted maybe in B complaisance notion and we wanted to make sure this is like we work hard. And then we rest. Heart. That's how we try to behave, similarly, with impact. Its 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 privatization 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 craft. We want us and our people like all of do is tears 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. Both of 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 we find a 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 a 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. Before we go to technical discussions. One more question regarding this remote working culture. So what are the role of managers? Like, how many managers does do? We have?
And what are there? Support core skills that they need to have for working remotely. Being a manager do is is a very demanding role. Generally speaking. We have about 12 managers and worry 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 and 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 the, you know, Design Systems how they're built out their lead. We expect the design. Team to own these things. But even for the technical teams, are 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 is responsible not only to manage and organize the Android team, but also making sure the team has a strong vision and that we're going towards that strong Vision. That spends, not only technical traits, but So 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 teeming technical ways and even unblock the team. It's super useful to have a manage that can try at 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 so, Us 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, colocation 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 Well, it seems like contradicting. So maybe you can share your thoughts about this 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 spends 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 car programming at all. If people want to do it they should do it, but it Happen that often instead, we focus on things that lend themselves to working asynchronously to. 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&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 Co-owner. I'm approving. This. I know how it works. I know how it looks like. I know how the user will
experience this data. Has my seal of approval and we have really good guidelines on how reviews should be approached. For example, to make them consistency across teams and across the company. Besides this, we try to automate a lot of things. For example, we have very strong linking 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 linking in passing, but basically, what that means is you're defining as a team and it should be a team process. How you want the details in the code to look like and your coded flying 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 there CI setups so that you can get out of the way. That things work. 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, refractors 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 remotes 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 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 supporting 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. So I also assume that in the beginning before somebody submits the work for review that might be a definition of done of maybe checklist may be used to do is 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. Yes. So this is part of our Investment in documentation, we start most pieces of work with a speck and I'm using this term very Loosely but what I mean by aspect it can be a product spec if this is a feature or technical spec if this is a more Technical Center 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 described, the thing to note is, we don't give this to Engineers.
So to speak. We actually want the teams to build this themselves. So even the product team as we work through a problem. Um, is more focused on what is the problem itself, then maybe the solution because, as I said before, we assemble 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. We building. 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 tragic. 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 building all the time and we could maybe do a small fixed, 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 these calls again, because of the independence core value, but we translate these calls into the 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? So I could also Imagine as a start-up. So any kind of a product companies you have maybe hundreds of features or bucks and you mentioned, you look cross-functionally. There's like a product team. There's also engineering team which is subdivided by platform using Android web and things
like that. So how do you ensure this privatization of okay, which features should I do now? Because it seems like the engineer will need to come up with the investigation to try aging. In this bag and estimation, and 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, I guess, like, most teams. We have some conflicts 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 not sure 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. Khan. 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 we're putting as much effort into things as with 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 let roll. So we're pre allocating in,
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 two 2s and three, sweep reallocated. You have this rough percentage of effort. 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 an Umma 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 product. Luckily. We have a team that is very products 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 these high level themes that spent many months, usually half a year and nine months one year.
Most lately and these themes. Help us filter and narrow down the things we should focus on. For example, this year for to do is 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, that it's we introduced the board's view.
So, looking at your task 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 of you. 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 to the rest-- views, for example, and we Documentation and at large internal discussion on why this is the best course of action for to do is that 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 to the wrists, very strongly in the market against the competition because it becomes very versatile. So, we decided to focus on this and then we look at our backlog and see, okay? What fits into this theme? We extend this reallocation to engineering, Ring as well. At the moment. We try to have roughly 20% of our effort, put purely into
internal type of work. We improving the foundations of our code improving architecture and proving 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 to Liberal judges purely, internal. We try to put around 20% of our efforts here. And again, it's a free 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 tried to keep this roughly consistent and then just challenged the principles and be mindful of any changes we need to do. So if a team lead is looking at your 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 called bases that were never Rewritten from the ground up.
They have been continuously improved and sometimes twenty percent 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 doest which is posed 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. Thanks for the tour explanation. So just a little bit curious, as well. How does the do is 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? Share a little bit on that front, if you can. Yeah, so generally speaking, we have a monolith would call it internally.
The Majestic monolith inspired by dhh posts about base camp, but we do have a few services to be honest. Like there are some things which are very opportunistic and also because we have to do is stand 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 take some Um Nails 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 lens to our functional structure. We have a back-end team. For example, the backend team owns. The backend code bases, 1422 is 14 twist. So we really Embrace 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 at pros and cons. If you approach them in a mindful way, with Mastery, tying back to the Corvallis. You can have a monolith and try to make it a really good long life 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 monoliths for sure. Yeah, suddenly. 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 microswitch, service business model. It. So maybe for people who wants to learn more about this remote booking culture, maybe some engineering best practices for
remote work. Is there any resources that is publicly available that people can look at yes or no? Because I think you asked two questions. So we write a lot about remote work. In our blog, I think do is plug is amazing. They are contributions from all across the company from engineering to marketing to contents. There's really I think something for everyone and we obviously talked a lot about The Way We Were.
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 recommend it as for the technical side of things and fortunately, 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 where more transparent about the way.
We approach work on a technical basis to a lot of. Do Easter's have Twitter, a lot of doing stirs tweet about I work. So that's also an alternative to find more content about how we tackle the technical challenges. So, Gonzalo is been a pleasure talking to you. My last question. My final question, as usually, it's about three technical leadership. Wisdom. Do you have the wisdom for you
to share with all of us? 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 saying hands. On doesn't mean you need to be deep down in the weeds doing work. 8 hours a day management, should not be a side job. Leading a team. You should focus on leading 19,
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, try to work when the workload increases you can support them on a technical level 2 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 Apfel 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 in 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 them on Ali. 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 you will need to set your opinion.
Beside a little bit to find alignment within the team. Because if you can get the team to a line under one single idea that 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 to end 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 team. See what they're telling you and finding that alignment. This can be tricky, but it's Really good tool to find long-term success. Having a vision is better than whatever specific Vision you're looking for. And the last one is also something we, I think covers across the whole interview.
I'm a huge believer in core values. And I talked about DUIs 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, that ux will be amazing. The whole superhuman under 50 millisecond thing. You're going to have great work
coming from that person. Maybe you have another person who is super cute. Non 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 performance. That's really well tested.
And that also meets the deadline. So, defining these core values. And again, this is something you should be doing with your team. Let's pick some things and things we can remember. Or by heart so 456 not more and then use those things to make the right trade-offs to define the identity of your team and to defining 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. Like 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 rights, you're going to 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 Corvallis. This would be my third tip. I really really liked all your wisdom.
I think it's really fun. 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.
And within this working from home, there are aspects that we can take as well for all benefits. Things. Like, for example, pre allocation. I think it's also one thing that I like because you don't actually need to always come with a immediate response from your colleagues so pretty. I look at things. Other things that you can do at the site while waiting for the response, I think it's really good and some of other things. So, Gonzalo.
Is there any other place for people to maybe find you online or interact with you if they want to know more? 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 we'll share. Wisdom will try to Sure wisdom every now and then. Alright, so thank you so much. You can sell. Oh, I hope to see you again in future episodes. I had a great time. Thank you, honey.
Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts better. You can also find the full show notes of this conversation on the episode page, at Tech Legion
of the death website. The full transcript, interesting quotes and links to the resources and mentions from the conversation. And lastly, make sure to subscribe to the shows mailing list on package, you know, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.