How to build the market leading todo-app ToDoist

About Amir Salihefendić
Amir Salihefendić, is the CEO and Founder of Doist, the company behind the widely successful productivity app ToDoist.

Read the whole episode ""How to build the market leading todo-app ToDoist" (Transcript)

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: [00:00:00] Hello, and welcome to the Software Engineering Unlocked podcast. I'm your host, Dr. McKayla and today I have the pleasure to talk to Amir Salihefendić. Amir is the founder and CEO of Doist. Doist is the
company behind the widely successful productivity app ToDoist and the collaboration platform Twist. The slogan on their website says we create tools to promote a calmer and more balanced, more fulfilling way to work and live. And that's exactly why I'm following the company and also Amir's work already for years. Not only does he promote a remote work culture, but he also stands behind a more meaningful and self-controlled worklife. But before I welcome Amir, I wanted to invite you to become an early access reader of some of my draft chapters for my code-review book. Sooner I will give my last code-review workshop before my summer break. My next workshops are then in August, and in the coming month I will focus completely on writing the code review book and doing some original research around code reviews. So if you want to read what I write and follow the process, sign up on michaelagreiler.com/code-review-book/ , and follow me on Twitter. I also linked both in a description, but now let me welcome Amir, Amir thank you so much for being on my show.

Amir: [00:01:08] It's a pleasure. Yeah.

Michaela: [00:01:11] Amir, one of the questions that I wanted to ask you since, you know, forever is why and how do you actually start Doist, and I know you talked about this a lot, but I would like to know a little bit about this moment that you, you know, You're working for example, you're doing your computer science degree and you're working at a, at some companies part time. So why not join the, let's say normal workforce. Why not be a employee full time? Employee somewhere? Why do you go and create your own company, your own project? Why do you work on your own problem?

Amir: [00:01:46] Yeah. I mean, it's a very interesting question. And honestly, like I think I would probably be a very bad employee, so that's like, you know, I never actually, you know, like some people they grow up and they think like their dream is kind of like join this mega Corp. And for me, that was never really the dream. Like for me, the dream is this pretty cool stuff, doing it, like in a way that it's kind of compatible with. You know, the way that I think and the stuff I want to create in the world and also the culture I want to be part of. Yeah. So I think maybe it's like personality type and also like something to note is like, I got very early offers. I think one was like, I don't know, 23, 24 to join like Facebook. And then they had maybe probably more money than actually, like my current. Maybe not, I'm actually unsure I'm sure about that, but, uh, you know, I could have joined like these big companies very early on if I wanted to do that, but it was not like, it wasn't really something I was super interested in. I really wanted to like, create my own path and do my own stuff. Yeah.

Michaela: [00:02:56] But did you have this idea of, I want to have, or want to make a productivity App at that point or was it more, I want to be my own, my own boss. I want to you know, create my own endeavor, something like that.

Amir: [00:03:11] I mean, honestly, I think like, as a software developer myself, I don't really like, always has interest for me is kind of creating stuff. So, and I think actually like if you're starting out and you want to create your own company, then like, You know, creating your own company is the easy set. Uh, the much harder step is kind of like finding something that you want to work on. And maybe also much more productive step is kind of just like being passionate about a problem and trying to solve that problem before you actually create the company. So that's at least like for me, that has been, the journey is kind of like. You know, finding the problem, solving the problem, and then afterwards creating a company around it. I think a lot of companies have like a same journey, especially if you go from my God, you know, software developer to, like a company builder. That's usually the journey that is common. Like for instance, like the founder of Dropbox did a very similar thing. Yeah.

Michaela: [00:04:10] So one of the reasons why I'm so fascinated by your work is the mental mindset about. You know, the bootstrap business that are created to be substantial and somehow lasts forever. And, um,some of your recent articles that I read were that you don't have an exit strategy or that you, you know how to become a market leader in 10 years. I really liked that very much. And also this, this idea of. Balance and ambition, right? Because very often I'm also a little bit involved in a bootstrap and indie hacker community. And, and a lot of people want the success overnight, right. It's from, from I'm starting today and in a year, I want to have this really successful company. And then there you are with, with product, I think. That a lot of people would love to make and, and you made it to be a market leader, but it's not overnight. Right. It's something that you work on in 10 years or, or over that time. Right. And so you probably have a lot of knowledge in that space. And that really becomes a competitive advantage, I think, compared to all the others that, you know, either do it like larger corporation that have it just as their side business. Right. So maybe one, one part that they are not that ambitious about, or people that are, you know, that are investing maybe a year or something. Why, why do you have this mindset? What do you think? What shaped your, your beliefs in, in having this long breath and also, you know, setting up everything for sustainability?

Amir: [00:05:40] Yeah. I mean, honestly, you know, I'm actually unsure, like what has shaped my way of thinking, but something that I think is very problematic is kind of like if you're thinking in short term, then I think like also this decision you make are going to be for the short term and they are not going to be great. So for instance, like if my goal is to sell the company, You know, I will probably not focus that much on like the lonesome culture that we'll be creating or the sustainability, you know, off it, or like the people that we actually are going to hire. Yeah. Because, you know, you know, at some point you're basically exit this, but if you come to stuck to this like forever then I think, your mindset shifts, and then you're much more like, you know, reflective or, you know, what kind of products do you focus on? What kind of culture do you have? What kind of people do you have? So for me, that's kind of like just a, like a forcing mechanism to actually you know think better and make better decisions. Yeah. So, and another thing is basically like this notion. And I think like David from base camp has stated, is kind of like work on your best idea. So a lot of people like they actually like postpone, you know, you have like a great idea, but you're basically stuck in some kind of like local, Optimum, like maybe you work for like a huge company or whatever, and you don't have like a time to actually focus on your best idea. So for me, it's kind of like, what are the best idea that I have? And like, for me, the best idea I've had so far. And of course I, it's not only my idea, but like company's idea is kind of like a tool to organize like your work and your life. And then also like a team communication app. That's kind of like mindful. And that, you know, helps you like both of these help you live a better life and do some better work. Yeah. So, so I hope I kinda answered this and like this kind of like mindset is very uncommon in our industry. Like a lot of people they want, you know, overnight success. They want, like, you know, short-term thinking of like short some project that can basically make your wealthy. But what I'm thinking about is like, okay, if I need to work on this for like 30 years, you know, then, or 40 years or 50 years, you know, it becomes like a very different mindset that you go into this and also like a very different timeline. Yeah.

Michaela: [00:08:07] Yeah. So one of the strengths that you have with Doist or ToDoist is that you're actually profitable. Right? And so I think this was also one of the things that you had in your mind very early on to have this profitable business that you are not. Really, depending on funding of others. But when was the time that you got to this point of profitability? Was that, was it immediately, or did you invest like a year or two before, you know, ToDoist was actually bringing in some, some revenue that you could actually live off and sustainably build that product.

Amir: [00:08:41] Yeah. So basically it took me about like six months to actually create like a business model for, for ToDoist and actually like, make it profitable. So
basicsally beginning, like you just covered the center costs, but you know, it was all very, already profitable for me because I was just like a student and like it, and to me some money on the side, but I, before I actually started to work full time on ToDoist, it took me almost four years. Where it was just like a side project. Yeah. And I would definitely not recommend this. So what I would recommend,is kind of like try to like, think about the business model from the get go. Don't really think about VC funding. Like that's another problem. I think a lot of people think about is kind of like the goal is gone to raise money. No, the goal should be to kind of like build a sustainable business because that also gives you a lot more options. Like if you want to raise money at some point, you know, you can do it. But the strength is really like building something that people want to pay for. And like building this very early on and then like creating like a sustainable business for yourself and for your team. Yeah. So that at least would be my recommendation in this regard.

Michaela: [00:10:00] So one of the things that I always also admire is this foundation of you call it balance and ambition. And I'm for example, a very, very ambitious person. And I really admire balance. I'm really, I am not very good in getting it into my life. Somehow I always feel like a little bit defeated by my own ambition. And so I noted you talking a lot about like the, the wellbeing of your employees and that, you know, they should be healthy and they should eat well, and there should be enough time and flexibility and things like that. How are you as a person? Right? How are you as the founder and the CEO? Able to get that in your own life. Do you feel that you are having this balance between ambition and, you know, relaxation or as a, as a CEO, you're more on this, you know, stressed and ambitious side.

Amir: [00:10:53] Yeah. I mean, the thing is like, I have actually tried to just be focused on the ambition and it was actually like, I have co-founded another company, a social network where I almost got like burned out because there was basically a zero balance. You know, I worked all the time. I was basically like a train wreck, like in terms of stress, So I have been on the other side and like, it's not really a good side to be in, especially if you want to do this for like 40, 50 years, you know, you need to kind of have sustainable way of like living. Yeah. And honestly, that's, again, like something that it's unconventional in our industry, because a lot of people are like promoting this hustling, like working all the time. But I think actually it's like, it's not, I don't think it's actually more productive. I think like the people that are actually happy and, you know,
satisfied in real life will produce better work and especially better work, like in long term. So that's something that I really value and focus on. And I think it was like, we can learn something from like athletes on this. Like if you look at some program of like athlete, for instance, like Federer or whoever else. Like, they're not playing tennis all the time or like their sports all the time. They are playing, like in intervals where, you know, they go in and they train or play and then they relax and recharge. And I think like, it's the same thing with like mental work is like, you can't be on all the time. You need to actually have like off switch and be able to disconnect or else like you will burn out or like you won't really perform that well. Yeah. So that's at least how I think about this. And especially, you know, like the work that we do isn't factory work? You know, it's, it's very creative and you actually need to have like peak performance that it's like really great. It's not about like, you know, grinding it out like 14 hours per day. Like maybe you, if you had like three hours where you could like, you know, Create a great algorithm or create a great solution. It's much better spend like 14 hours just like, you know, banging on a keyboard or whatever else, like, yeah. So, so that's at least like the mindset I have when I go into this and why I think like ambition and balance is important. I mean, this said like, you know, I'm a super ambitious person as well.And a lot of people actually mistake our like ambition and balanced to think that it's kind of a relaxed environment or that we don't expect the best out of people like we do. And, but we think actually like you reach the best by, you know, having an off switch and having a balance in your life. Yeah. So that's how I think about it.

Michaela: [00:13:40]Yeah, I totally agree. I also think that this is how you're getting enough energy and enough also freedom on a little bit in your, in your thoughts, right? In, in your, in your, some space to think also, but how do you for yourself, what are some of your maybe tricks or some of your mechanism that you can actually turn on? This switch, right? This is something that is, for example, hard for me. So I have to go and, um, bike for example, or, you know, do some other sport. The best is being out in the fresh air to really clear my mind and getting out of this, you know, work habit or, you know, work mind, race thing. So what works for you. Is that just something that you very. Very easily can turn on and off and you know, now work, stop the name, you know, I'm relaxed. Or do you have some, some things that you're doing to make this transition from ambition to balance?

Amir: [00:14:34] Yeah. I mean, I'm going to be honest here, like, you know, my default more like, I love what I do. I'm really passionate about the work that I do. And I have like a really hard time switching up as well. And I think like a lot of fleet, like if you really love what you do, like you will have a huge problem doing that. Yeah. So, um, you know, we have been stuck in this like Coronavirus nightmare for the last three months on a lockdown and it's suddenly getting better in Chile. So, you know, what I do right now is kind of, not really that reflective of what I do usually. So for instance, for me, like swimming is a great way. To, to shut off like going to a park with my son without my cell phone is another great way, playing football as well. Like I actually, like I have found out that I really need, you know, that to switch off. I really need to kind of like get out and do something active. Yeah.

Michaela: [00:15:30] Very much like I do.

Amir: [00:15:32] Yeah. And honestly, I think like you can combine those things, you know, for some people that works from some models, like. Maybe, you know, they play some games or whatever else, like they do to kind of relax or see some shows. But for me, like the best is kind of like to actively like do something. And that kind of switches my mind off, like when I'm in a football match, you know, I don't really think about like the, the work stuff or the same thing is like, when I'm in a park playing with my son. Like, I don't really think about the work stuff.

Michaela: [00:16:05] So one of the things that I'm very, very passionate about is software engineering practices. So I would like to learn a little bit more about what you're doing at Doist, so do you do code reviews? How do you test your systems also? What is your tech stack and, and how do you combine that with within remote work? Right. So how is the remote work also shaping your software engineering practices? And did they change, do you think that. Did they look a little bit different because of this as a asynchronous communication, for example?

Amir: [00:16:37] Yeah. I mean, honestly, I think like remote first. And then combine that with like asynchronous first communication. So it means like we don't actually chat chit chat all day long, but like we use, you know, long form of communication, mostly of course, like we do some meetings here and there, but like most of our communication is written, like in long form. This is kind of like, I think the ideal situation to create like really great software. Yeah. And so that's the first step, and I think there's like multiple layers to this. So first of all, you know, a lot of the problems that we handle in software is very, very hard. So, you know, like if you ping me about like really on Slack, for instance, or Microsoft teams about a really hard problem, like, it's very unlikely that I will just be able to answer it right away. Or maybe if I can answer it right away, it probably will be like a suboptimal solution. While if I actually like ask you something and you have like a day to sleep on it, then may at least likely that you will come up with a much better like solution to the problem. So that's kind of like the work that we promote, this kind of deep work. Ability to like really focus on hard problems and solve them. And also like do this , like pull requests. I think an amazing invention that makes this much, much easier to do. And I think it creates much better code and much better systems. So I hope I can like answer this in like a very holistic way.

Michaela: [00:18:17] So especially code reviews are one of my favorite topics and pull requests, especially I think ToDoist, or Doist is using GitHub for your PRS, for your pull requests. Do you feel that this is really the best. Way of doing this communication is collaboration. Or like, I imagine that if you are a person, you know, that that's designing software and designing productivity apps, maybe you have this lens of looking at other software flows or tools, especially engineering tools as well and thinking well, is that really the optimum way to do that? And I always wonder, so I actually see a couple of things that you could improve in the, in the PR, flow, and in the way we are communicating through PRs, for example, at Github or Gitlab. Right. Is that also something that comes to your mind? Do you think this is actually a pretty good for, for how we are using the tool?

Amir: [00:19:10] I mean now, you know, like I grew up without Git, and like these PRs, like I grew up with some version like CSV, so I know like how much it sucked before, or even like before that, like sending, you know, zip and dips, that was like really a nightmare. So I didn't like the current, like, we are really, really fortunate with the tools that we have in software development. Of course, like they can always be improved, but it's like just lightyears ahead off what other, you know, fields have. And even if you look at like the history of Git, it's kind of like history, like, you know, the Linux kernel is kind of like remote first team spread around the world. So it's kind of like optimized for this kind of like remote first structures in like asynchronous communication structures, because most of the communication is done like we are mailing list there. Yeah. Yeah. So of course, like we can improve this, but honestly, like I'm very, very happy about the current flows. And also something we use is like we use Twist, which is also asynchronous communication. As kind of like a glue between like Git and Github. So for it's like, if you want to ping somebody about like a pull request or an issue, like you would basically do that on twist and then, you know, they will go to hit Github,you know, solve the issue, like look at the specific problem or whatever else. Uh, yeah. So I still think you kind of like need to another layer. Like a lot of teams use Slack. Like we don't. So like our stack is mostly like asynchronous and this helps a lot. Yeah.

Michaela: [00:20:53] Yeah, Twist is definitely something I want to talk with you about. Well, it's sort of very similar to it's a communication platform, similar to Slack, but has a different focus, right? So it's really designed for asynchronous communication instead of synchronous chats. And so what was your idea behind Twist? Why did you come up with this idea and why? Why go for a very. For this broad problem of communication and collaboration, it's not very specific to, for example, pull requests and the way that we communicate there. Right. It's very focused. Well, now we have this goal in mind where I guess Twist is similar to Slack is a universal tool that it can use for any communication, any collaboration, or did you have something in mind, like really engineering teams that are using it for a specific, you know, way of communicating?

Amir: [00:21:42] Yeah. I mean, the way that everything about this, like, you know, like that's where ambition comes in. Like we really want to use like tools that change how we organize and how we communicate on our global level. And not only for like, developers. So this is kind of like a mindset. And also, you know, like we're also like very focused inside this and other aspects such as design, like we're very design driven. As well as engineering driven, we also like always take like a more broader look. And look at like the, the problem, the general problems that like a lot of teams are facing and not only like what developers are facing. Yeah. So that's basically how we look at this aspect.

Michaela: [00:22:30] Okay. And so I know that at Doist is actually working in squads or at least you used to I'm pro are you still working in, in terms of like collaborative, interdisciplinary teams? And why did you choose that, that way of collaborating?

Amir: [00:22:49] Yeah. I mean, that's a great question. And honestly, like the thing about Doist is kind of like, we do stuff a lot differently than most others, and we are always like, you know, trying to think from the first principles is just instead of just like copying others, of course, like we have tried to copy others. It almost always not, does not really work for some reason. So, like our structure is very unique in terms of how we work. And it's also like, I think from that side, it might sound a bit insane. So basically, like we have dynamic squads that are assembled and reassembled every month. Like depending on sometimes they are running for multiple months and we call these cycles. So we basically have like monthly cycles where for instance, like you can have like a cycle phase, like one of the cycles right now, it's kind of like creating a better composer for Twist. And usually like this, these squads have like a designer, some engineers in them, maybe a support person or marketing person. And they are basically like self sufficient that they can actually go in and solve the whole problem space, like from, from start to finish and deliver that. And then apart from like these dynamic squads that are assembled, we also have like teams, so the iOS team is I think, seven people.And the Android team. And then we have backend and frontend and, you know, basically they're, they're kind of like focusing more on like the holistic view of the code basis. Yeah. So that's kind of how we work. And then we also have something called internal Dues, which is based like team specific. We call them Dues, which is based on projects that, for instance, like iOS-14 is an upcoming Due and it's only affecting the iOS team and they basically have like some, a person allocated. Sometimes it can also have the two persons allocated for that. And apart from those, so we basically have like a, you know, Product squads. We have these like internal squads and then we also have personal Dues, which is based like one person, like having a personal project that maybe isn't like even adding something to our product. Um, for instance, like our, one of our designers did like internet for Doist. Where he based like designed and coded everything in the cycle and, you know, so that's how we work. And I think really this is probably a very unique way. And I, I at least, I don't know many that do it like, like we did, but yeah, I really like this structure. And of course, like it has some pros and cons, but in general, like, we are very happy about how we do this.

Michaela: [00:25:34] So how I imagine when you're describing it, how I imagined it is like, well, every squad now is a little self-sufficient little startup sort of, right? So there's like, I don't know, five people, maybe five ambitious people that have all different, you know, talents and skills and they're coming together and realize one thing in a very autonomous way. And I can see that this can be very, very impactful is there, is there a final rule approval staff, for example, this every, you know, every feature that they, for example deliver, does this go through the final approval by you or by, you know, a team of owners or something like that, or is that completely, um, independent from, from start to end?

Amir: [00:26:21] Yeah. I mean, honestly, like we don't have like final approvals. We actually don't really have a lot of like hierarchy inside this, but I mean, for instance, like something that's like very critical for us is kind of like code reviews are also just like, you know, design reviews getting input from, from others is kind of like the alpha and beta testing. You know, so, so, so before, like something gets out, like it will get like a lot, a lot of eyes on it and a lot more like the feedback will be given to a specific thing. So usually, you know, like when we are ready to release something, like it's usually very rock solid and it has been like true. A lot of like, like a review and testing periods. Yeah.

Michaela: [00:27:06] And so can I imagine that, for example, for the code reviews, you would have like a squads and on the squad, there is one developer or maybe two developers, but they are getting code reviews from other squads, or is that always within the same squad? How do you, how do you do that?

Amir: [00:27:21] Yeah, so, so basically they will get like reviews from the team. So for instance, like if I'm an iOS engineer and I do like boards, Then like boards get reviewed by, you know, somebody else inside the iOS team. And maybe it would be like multiple people, like over a time span. And so that's how we do it. I think like the beauty of this is kind of like that you have a lot of collaboration and you also have like a lot of insights and input coming from other people that are maybe not fully into like the, the problem space that you're solving. And it also means that a lot of more people who actually know the code base better. Yeah. So, you know, I know our approach could be that you kind of have like just internal reviews inside squads, but then you can just like, have, you know, a very constrained, like maybe two people or whatever that can actually understand something. Yeah.

Michaela: [00:28:17] So when I look at your company culture and how you communicate it and the values that are setting, I wonder what about, for example, career letters? How do you see them? Do you have like titles at ToDoist, and if you have titles, what are, you know, how, how do you, how do you advance your career? Is there a concept like that, that you're, you know, getting more responsibility in promotions and how does that work at ToDoist.

Amir: [00:28:46] Oh, you know, you touch a very, like a very present topic. Like this is something that we're working on right now. And honestly, like we have worked on this for like almost two years. And the problem for us is like, we don't really want to add regular career paths. Like we are 80 people right now. And it just like, feels very wrong to do like the regular, like things that most companies do, because I think it kind of creates like this high hierarchal structure where you have like these fancy titles and like people, you know, wanting to advance their titles, but maybe not really, you know, their skills or like their contribution or whatever else that that is maybe more important than , like a title. Yeah. So, so right now, honestly, like we don't really have any titles, so we have like, Yeah, we have three titles. So we have like a CXO, which is basically a C level person. So we have like Gonzalo who's our CTO. Then we have heads and this can be like head of iOS. And then we basically have Doisters, which is basically like everybody else. And we have about 80 people. And honestly like this, this feels, this feels like the, the right, uh, approach for like our culture and the ethos of the, of Doist itself. But, you know, we still want to like have a system where people can grow and like, you know, mastery for us is very, very critical. Like personal growth is very critical. This is like why we invest. Like so much into like these personal Dues and, you know, think about it. Like we, like every year we invest about 80 months of just like personal improvements for people. And I don't think many companies do this, but of course, like we kind of like want to have it like this career paths, but it should really be focused on like mastering something and helping people grow and not like all of this, like bullshit with titles and like, You know, growing like your career in, in, in, in the normal sense. Yeah. So this is kind of my input. Like it's a very, it's a very, a sensitive subject inside a company. Honestly, we have been like, we, I think on the revision for like, we call it career paths, version four, we have not rolled this out yet because we are not kind of like, sure how to do this. So we have not really found like this healthier solution where we are just like, you know, this makes a lot of sense, like this. You know, and this fits the company that we want to build in the culture we want to build a, yeah. So I hope, you know, at some point we will find this and, you know, we will also definitely share it with others. So other companies could follow and maybe also like, think, you know, differently around this than just like these standard career ladders that you just copied from Google or whatever. Yeah.

Michaela: [00:31:41] Yeah. The interesting thing with career ladders is also, well, first of all, we have like this, as you said, hierarchy, but then also you have very often you, if you want to advance as an engineer, for example, you're advancing into a different role. You're advancing into a management, for example, and suddenly you're not engineering really anymore. You're, you're doing a lot of people management. And, and so for example, what. Companies do like automatics. They have those two very separated. So if you've become the engineering leader, which I don't know if this is similar to the hat that you described, but if you, if you do that, you're not, you know, you're not one step further than for example, an engineer you're on a complete different track. You have a different, you have a different career path and this is not a promotion. And I find it also very interesting because I think. Especially for, you know, people have very different interests and maybe also different skill sets. And I'm saying, well, if you want to advance in your career, you have to become, you know, a manager for example, and do very different things. It's interesting concept, a little bit strange concept as well. How do you think about that?

Amir: [00:32:49] I'm that is so spot on. And that's definitely how we think about it as well is, and honestly, I think it was like the status of like
becoming a people manager. I'm getting a higher salary than people that are doing individual work. I think it's also like float, especially like in our industry. So we did like, and you also should not really force people, you know, to go into these like areas, for instance, like people management, where, maybe it's not really your strength, you know, a lot of people don't don't have that strength don't have the passion, um, for this, I mean, honestly for me, myself, like I would also say like, you know, I like to work a lot more with systems than like, people issues. So even for myself, like it's not really my strength to be like this, you know, like people like only managing people. So that's why I actually still do some, some coding on the side because like, I would just find my job very, very boring. If I was just like stuck. Uh, in meetings and like people issues all day long. Yeah. So, so I can definitely relate to this, like on a very personal level. And even like, I think for myself, like if there wasn't like a call to me, like to be the leader and to be CEO, I would probably also be individual contributor because, you know, that's probably where my focus would be. Or like my happiness would be best. I think, but of course, like, you know, as a founder and as a leader, like people really expect me to step up in this role. So I'm kind of like forced to this, to do this, but yeah. You know, I would probably also, so I have like a lot of respect for individual contributors and I think this would definitely be a path and it should be, you know, as recognized as like the, the management people management path.

Michaela: [00:34:42] So one of the things that really fascinates me are those values that you promote in your company, company values. And I wonder, do you have like similar dedication also to engineering values? Do you have, like that defined in, in this very clear way, do you have revisions of that? Do you reflect as a company on the engineering values that you have? What means engineering rigor? For example, for us, what is, what is a very high quality code base? How do we, you know, how do we get to that space and things like that. And what are your thoughts about engineering rigor and values in that space?

Amir: [00:35:19] I mean, that's a great question again, you know, and honestly, like something, we have been very bad at during our history is kind of not focusing too much on that. And this becomes like a really big issue once you grow and you have like, you know, a lot more people, a lot more systems, a lot more code. Like if you don't have like the core value set, if you don't have the core practices set, then it basically becomes like a wild, wild West. And that's where I feel like we have actually slacked off and not really prioritize this enough. So like our CTO and engineering team are actually like doing this clean up now. Where we are basically like, you know, like for instance, like setting like a handbook for engineering, where we have like all of the like processes documented where we have like core value set, like, you know, what do we value from the engineering standpoint? And like, like company values, like you can value everything and you also like need to like prioritize stuff. So for instance, like if performance is a core value. You know, it has some impact on other stuff, if testing is a core value then like you're probably be slower to actually develop stuff and to ship stuff. So you can like have two core values are kind of like a competing these other like phrase, like ship fast and, you know, like, test a lot. Like those things are probably like in, you know, in conflict with each other. Maybe that's not a best example, but you know, like, I'm pretty sure, like you can find some core values that are kind of like in conflict with each other. So you have to pick very carefully, like, you know, what do you want your engineering organization to prioritize then some other stuff. And I think this is something that we have improved a lot. Like at last, at least for the last year is kind of like code linting and like the tools are getting like really ridiculous good they're like this, like in a code review, like you should never go in and comment about like code stats because code stats should be dictated by tools and not like Humans. So that's again, I think they can actually automate. So that's what we do right now. And we are also like automated testing. So for instance, like you can't really push on the frontend without having the test suite passed. So it also like, you know, makes the code review much easier because you know, you're not even going to be able to create like a pull request if the code does not really pass. So, so I think like, honestly, there's a lot of stuff that you can do there. And right now you're just like, are trying to become a better testing in general, like automating testing a lot and doing it like also on the frontend client side teams. Which is historically much more difficult than like the backend. Yeah. And I wouldn't say like, we are perfect at this. Like we are just starting out, but I can definitely see like this being like a major competitive advantage and just, you know, have the ability to kind of create much better systems and much better products in the end. And, you know, that's what it's about.

Michaela: [00:38:36] Yeah, I'm a really big believer that if you have very clear engineering values, like you have very clear company values, those really shape your processes, your culture in your company, and shaped very much also your product. And as you said, there are, you know, people want to have all the values. Like I want to be good in everything, right. But you have to prioritize and this shapes and. Shapes really how, how you develop your product and how your product will look like in the end. And there are trade offs and you have to make a choice for some of the things, right? What is number one? And what's this number two and things like that. One thing that you touched on a little bit, but I wanted to ask you before I let you go, is how do you keep the code base up to date? I imagine like when you first started working on this code base, is, is that still, is that code still part of ToDoist for example, at the moment, or have you changed the code base completely? Have you thrown away old versions of the software system and how do you keep it, you know, up to date modern and also maintainable?

Amir: [00:39:41] Yeah, I think I can tell you, like, you know, I coded a lot of the early stuff myself and especially like for instance, on the frontend, Like most of our code was based at custom Javascript and extra. I created like our own JavaScript library too, to do that. And that is basically like a very, very like bad code base, because it's basically very outdated and you have like much, much nicer tools right now, uh, to solve like the issues. For instance, React is a great example, Redux. On just like an architecture level. So for instance, on the frontend team, what we have done is basically we have re-written everything to React and Redux, and we actually still, like, we have some, some parts are still missing, but that's basically what we had done. And there's still some code that I have written long time ago there, but, you know, it's very minimal and I'm very happy about that. And the, the. Like it's just much more maintainable, especially with a much larger team. Yeah. On the backend, I think, We have actually done a worse job. Like we have not innovated enough or like moved away enough or adopted like better like abstractions and systems. So that, that is, is I think more problematic. And honestly, I think its much more harder to. Like rewrite or like redo the abstraction layer on the backend because on the frontend, like, you know, you do something, it just affects one client. On the backend, you do a refactoring and suddenly you need to like, migrate like millions or for us, it's like hundreds of millions of projects, you know, billions of tasks. It becomes very, very unmanageable. And like each migration, like if we want to do a schema update, you know, it takes days to do that. So it's not like as fast to actually evolve the backend as it is to evolve the frontend. And I think this, this is holding us back and the team is kind of like fighting with this on a daily basis. And what we are currently trying to do right now on the backend is kind of like. Rewrite our models from scratch and then basically migrate our old data to the new models instead of like this constant, like patching of like broken abstractions, because I think that is not, a good way forward. Yeah.

Michaela: [00:42:12] Yeah, I can, I can see how that it's, as you said, it's easier on the frontend because you have less dependencies and less compatability issues than on the backend. So I would like to ask you a couple of questions to wrap that episode up that people actually ask me on Twitter to ask you. And so one question was now that we have, especially with this pandemic, even more companies are somehow even forced into remote work. Right. And they're relying on synchronous communication platforms like Slack And Teams ,now Twist is this asynchronous, um, communication platform. How can we envision that? What does this mean? How does the communication work with, for example, Twist and, and what are your thoughts about those two differences in the way of communicating with each other?

Amir: [00:43:04] Yeah, I mean, it's a good question. And honestly, like that's something that we find very broken in the current culture is kind of like this real time focus. And, you know, we have been part of this ourselves. Like we were one of the early adopters of Slack and we think like this creates, you know, much more stressful environments and actually produce much worse, like code or designs or products. So that's why we kind of are very focused on like this asynchronous way and like focusing more on deep work than this shallow work that is promoted. Yeah. And honestly, like most of the current companies are not really focused on this and we think it's a huge error. So, you know, what kind of implications this will have, I think are significant, because if you have one team that can actually solve really hard problems that can deep work really. And the deep, deep work is kind of like the default way. Like I think they will outperform a team that's basically stressed out. That is basically chit chatting all day long and just like doing shallow work and shallow solutions most of the time. So that's at least how we think about it's like, it's a huge, competitive advantage, especially when you combine like asynchronous first,remote first like you can actually hire great people from anywhere in the world. Then it becomes like a significant competitive advantage.

Michaela: [00:44:39] One of the things that I was really happy when I left my corporate job was that I don't, I'm not forced to be part of those instant synchronous communication that completely over overflowed my buffer more or less. Right. So I was completely stressed out that I cannot, you know, Keep up because I like to read everything and this is not possible, and you have all these interruptions. So this was definitely something that I'm really happy that I don't have to use, you know, Slack channels. I don't have to keep, you know, keep this pressure off being up to date. I recall when I was working. At Microsoft. For example, I had this habit of looking at my emails only at certain times during the day, because I didn't want, you know, to, to be distracted all the time. So yeah, I can, I can also see how that this deep work culture and this mindset of, you know, that you, you don't interrupt the other person all the time and they are not there. It's a way of, of rethinking your work day, right? If you're, if you're rely on that, that somebody is. Responding within the next five minutes, you're working in a very different way than if you're no, actually that, you know, it might take four hours until you get a reply from somebody. But I think it creates for the person that's not interrupting. It creates a lot of space and a lot of. As you said, deep work opportunities. And so this is really cool. So there's the last question Amir that I want to ask you. And I think a lot of my listeners want to know is how do we get a job at Doist, right. So I think it's one of those companies. And I think you've talked about it before that you're getting a lot of applications. And so what are some of the things that you're looking for in a potential employee and a person that you would like to have join your team? What are some of the skills, the traits , the personality that you're looking forward, where you think, well, this is actually a good fit for our company.

Amir: [00:46:39] Yeah. I mean, that's a, that's a good question. And honestly, I think something that we are very fortunate about as a company is kind of like this remote first aspect, you know, we can hire people from anywhere. And usually like when we actually do a job posting, we get like thousands of applicants. Uh, so actually getting into Doist is really, really difficult at this current time. Of course, like it may change as like more like these huge companies are moving into Remote territory. And what do we look inside for a person? I mean, honestly, like, first of all, it's really like important that they are very passionate about the problems that we solve. So instance, like, you know, organization and team communication, like you really need to be passionate about that. That's one aspect, another aspect is like really, we really love people that are kind of like really great at their craft and really focused on the growth so like the best people we have a hired are kind of just like, you know, uh, they grow a lot and they are really focused on like mastering their, their crafts. A third, maybe is also like, like really loving, like what you do. And a lot of our developers for instance, have done like personal projects, open source projects on the side. And this for us, it's got like a great indicator that somebody like is so passionate about like this, that they actually like we'll work on stuff like open source stuff without actually being compensated for it. And even myself, like, you know, I have done open source projects and I also have published my VMRC on GitHub. So I think this is also like a very important aspect of the general culture is kind of like, you know, We really love what we do and we want to become like really, really great at it. Yeah. So I, you know, those were like maybe three tips I could share. Yeah.

Michaela: [00:48:42] Okay, thank you so much. Well, Amir I think we are at the end of this, um, interview, I was really happy that you have been here on my show. Is there something that you would like my listeners to know? Maybe, um, I will link obviously your website. I will link your Twitter, but is there something else that you wanted to share with my audience before we wrapping up?

Amir: [00:49:03] I think it's a difficult time for most of us and, you know, I hope staying safe and, uh, yeah, it also seems like the, the problems, at least in Europe are getting better while some other places are getting worse. So yeah, I hope everybody's safe. And the, if you want, uh, I think the best way to actually stay connected with me is at Twitter, I'm a quite a regular user. And also like if you have any other like specific questions here, You know, welcome to and tag me and I will try to respond to it.

Michaela: [00:49:35] Okay. Thank you so much. So enjoy the rest of your day. Amir, thank you so much for joining my show.

Amir: [00:49:41] Thank you for having me. It was a pleasure. Yeah.

Michaela: [00:49:45] Thank you.Bye bye. I hope you enjoyed another episode of the Software Engineering Unlocked podcast. Don't forget to subscribe. And I'll talk to you again in two weeks. Bye.