Welcome to NoOffice, a podcast about work, technology and life from a remote company perspective. In Nozbe, we believe that work is not a place to go, it is a thing that you do. That is why, since 2007, we run our company 100% remotely. In Nozbe, there is NoOffice. The NoOffice podcast is sponsored by Nozbe teams, a to-do app that helps modern teams do great things. Go to Nozbe.com to learn more. Hello and welcome to NoOffice, a podcast about work technology and life from a remote company
perspective. My name is Rafal Sobolewski and today Michael is on vacation so I managed to invite to this episode our CTO Radek Pietruszewski. Hello Radek, how are you? Hey, I'm doing pretty well. Thanks for inviting me. Thanks for accepting invitation. You might know Radek from the podcast FM, our former podcast that he ran with Michael for five years I guess. Yes, 2015 to 2020. It's It's never been officially canceled. It's just on an unusually long hold.
- Yeah, and I know there are many listeners that asked for more episodes of the podcast, but that's what I managed to negotiate with Radek to invite him today for No Office podcast. So Radek, how many donuts have you eaten already? - Well, I've had one. There's one more waiting for me, and I don't know why, there's just two. So there will be more coming, but I'll have to leave the house for that.
- Yeah, I also had one and I have three more waiting for me because today is our special day in Poland. It's called Fat Thursday and we eat donuts that day. And our donuts are much better than American one, I think, because we don't have a hole inside. - Yeah, I never really understood the hole. Like, why do you take something that's perfect and then make a hole through which everything just oozes out? It's just so impractical. Don't do that. Don't make the hole, just don't make the hole.
- Don't make the hole, yeah. So today I wanted to talk with you about Kaizen stuff, about constant improvements, et cetera, because you are the guy that take care that we have the constant appetite, constant effort to do it regularly. And we have many benefits from this, but let's start that. How would you describe your role in our team today in 2022? Because it's all this years we are working together. It evolved to many different paths. And how is that today?
- Yeah, so I've had many different jobs over the years. They just happen to be, to have the paycheck coming from the same person. Right now, I'm the person responsible for all things technology in the new Nozbe app, except for the server stuff. I don't touch the server stuff, but the iOS app, the Android app, the web app, the Mac app, beta, and the Windows app coming soon. That's all under my jurisdiction. And essentially my role is to make life easier for the rest of the team building the app.
So I make the infrastructure, so the tooling, I prove out technologies that we use, set up guidelines, try out new things, make prototypes. I built a couple of open source frameworks that well, we use to build Nozbe and make it available on all the platforms and be fast and whatnot. I work on sync and I say from that, I do Kaizen, which we'll talk about and I do performance. So I'm working on making the app fast.
- Yeah, so essentially I think of myself as the person sort of on the side, helping out others actually build the features that people use. So most of my work is not visible directly for the users, but it underpins the work of, the great work of others. - Yeah, like I think I would describe to her that you make sure that others in the team can build feature fast and without any issues. So that's, you're kind of a catalyst or facilitator. Okay. - Yeah, maybe not just don't use the word catalyst.
That's just- - Catalyst, you don't know. (laughs) - No, no, no, catalyst. - You don't have positive connotation with that word? - Exactly. - Okay, so you said performance. So let's deep dive into performance aspect of your work. So because you are obsessed with the performance of our app, of our sync, of the start time of the app. And every couple of weeks I see in our Nozbeep that you announced that, "Oh, here's another batch of performance improvements.
Now the app should start faster, the sync is faster, the first login is faster, et cetera." But besides of the app, what else? Because like performance of app itself, it's not only performance, you are optimizing. So making software fast is a slow process, slow and tedious and frustrating, which is funny. But the thing is, there's a couple of constants in software development. One of them is that software tends to get slow over time.
It tends to get bloated as features are added, as years pass by, there's just more and more junk. And also from kind of the internal perspective, the quality of the code base, like the stuff that people work with, just tends to deteriorate, which makes it harder and harder to work on the app, to improve it, to make it faster. It's sort of entropy, you know, it's kind of law of the universe. It happens over time and you have to actively fight against it. - It's the same thing as spaghetti code?
- Well, if you don't do anything about it and let entropy do its thing, then eventually you end up with something that people would call spaghetti code, which is like all things tangled together, like impossible to disentangle and change into anything else. So this is sort of something that happens naturally. And the thing is it happens slowly, it happens over time.
And it's very difficult in companies and in teams to assign time and effort and money into making that better, into making the app a little bit faster, making the code base a little bit less bloated, you know, cleaning things up, removing features. Like no one wants to do that because it doesn't bring immediate obvious effect and it takes a lot of time. But what happens if you don't do it is that eventually, couple of years in, you sort of have to declare bankruptcy.
Like it's just very difficult to do something with it if you don't work on it constantly over time. So those are things that I spend a lot of my time working on because those are hard to appreciate at first, but it is a feature over time. It doesn't sell to say, hey, the app is not slow, it's pretty fast actually. Like it just doesn't sell the app. But over time, if you don't do anything and the app just grows slower and slower and slower, people don't wanna use it. Customers are unhappy.
You know, there's some other app with teams in the name that people seem to be really not like because it's floated and slow and so many examples. - Yeah, and adding new features and fixes are much harder to add because like, when code is bloated and when you add a new feature, you produce five other bugs in different areas of the app.
- Yeah, so as for performance, I just think of speed of the app as a feature and not very well appreciated one, but one that needs to be worked on to just fight the nature. - Yeah, but still you managed sometimes to by doing a performance work, you deep dive into the code to the like lower layers of the code. I bet you sometimes see some low hanging fruits that some features you can implement or improve.
Like for example, you implemented bulk edit mode very quickly, but we thought that would be, to take much more time to implement. The SMCU improved a lot our jump to. It's much, much performant. And on top of that, you add some features to that. - Yeah, I rarely work on like features like user visible things in the app anymore. And when I do, it's usually out of frustration. Like I hate this, why doesn't it work the way I want it to work? And so I just fix it for myself.
That's what happened with jump to and with bulk edit. What's also important to appreciate is that these things, they are hard initially and then they become doable.
So we'll talk about Kaizen in more depth, but essentially as you unload the app, as you work on it, as you look at all the nooks and crannies of the code base, you see certain problems, things that could be simplified, improved, things that are duplicated and there's like three different modules of ways of doing something like why did that happen why can't we have just one and and you start just entangling it you know pulling by by the the yarn and at first
you don't see any result you're just making yourself feel better that that you've improved something but you can't see the result but but as you pull on these threads and and improve things then suddenly something that was just so tangled up with many problems and hard to change and improve, suddenly
becomes easy. So you know with Bulk Edit, you know this is like the Nozbe app, it's a list of tasks that like it's a big complicated chunk of infrastructure you know the the list of tasks you know much more complicated than it looks and so as we add new feature there's bloat and then as you unbloat it like Like suddenly, hey, you know, adding bulk edit. That's not so hard anymore. - Actually that's your work. Like I can now really appreciate because like last year we shipped 46 updates to Nozbe.
Then it was Nozbe teams now it's new Nozbe. And that's pretty amazing comparing to all of these years we were developing Nozbe personal even. Like we were shipping, I don't know, like one update per two months in Nozbe personal in our high peak times. - Yeah, this is a completely different, it's a huge change in mindset and it's a big change in tooling and infrastructure.
So in the old days and what we did before was kind of the old days mentality was that every release is polished, every release is like it's something you start at features that you decide you need to add and then you polish it, bug fix, test and then you release it. And it's a marketing release. And these days, like the app has to be stable and polished at all times. And we do things and we add things and most of them are invisible for, you know, weeks or months, but every release is stable.
And none of the releases are marketing releases. We just add things all the time. We ship every week, no matter what, unless something is like really blowing up. And then when we're ready to actually show something to the users that we know when that feature is ready, not the release, the feature is ready, then we flip the switch, enable it, people see it. Hopefully customers are happy, but it happens when we're ready. Not because, hey, this is a 3.2.1.2137 release. No, no one cares.
You just want to use the app and get your stuff done, get your life organized, make your team more productive. Like you don't care about marketing releases. So, and this way, you know, when you have all the tooling automated, when you dog food the app all the time, it's always constantly being tested by machines and by us. Then, you know, there's no reason not to release. And so, yes, there's a slightly higher chance that we release some bug, you know, this week, because we shit this week.
But the upside is that if we mess something up, people see much earlier, much more quickly. Like every release is a smaller chunk of changes. So whatever happens is just a small chunk of change. And we don't change the fundamental things every week, but we add some new feature, not yet fully our full idea for this feature, but it already works. people use it, give us feedback, we improve it. Next week it's already a bit better.
- Plus we don't worry about even shipping bugs because when we ship some bugs and they are not critical, we know we will have LEDs next week. So we can fix that very, very quickly. And we are almost releasing that in this process for almost two years now. And I think we only had to do like hotfix LEDs in the same week like one or two times. So I think that's pretty good, good result. - Yeah, this is software, this is computers. It's not perfect, it's never perfect.
It has bugs unfortunately, and we can't avoid it. We do our best, but we can't avoid it. But it's sometimes better to ship just, you know, small, not that important bugs every week than, you know, a huge chunk of like new features and improvements and oh, it turns out, you know, it's just completely broken for people and customers not happy. - All right, so let's go to Kaizen.
Every Monday, you and one front-end developer that is currently on hand, which is Horizon Expanding Month, we will talk about it later, you have a Kaizen event. It's some kind of per-programming, or what's that about? - No, it's not per-programming. So Kaizen, this is an inspiration, one of many inspirations that I've introduced to Nozbe from lean manufacturing.
It's kind of this philosophy that's been taking hold in manufacturing world, starting with Toyota and Japanese companies thinking about a better way of running companies in manufacturing. And some of these lessons are applicable. So one of these ideas is Kaizen. Kaizen means continuous improvement. And the idea here is that you don't, It's actually kind of similar to us shipping every week.
You don't make these huge projects to, I don't know, introduce a new production technology or whatever, or just ignore things and just let things run and yeah, there's some problems, but whatever. No, you have to continuously improve to stay at the cutting edge to be the best company, the best technology company you can be. have to be on the cutting edge.
And so you have to constantly look for problems and not quality problems, like problems that customers are gonna see, but improvements to the process, the process of manufacturing, in our case, manufacturing code. And so every week we meet up, we have our list of ideas of things we can improve in the code base. And it's a little hard to explain to non-programmers, but we just notice things that are kinda hard to do, take a little bit more time than they should or things that we do all the time.
So in the app, we have a lot of menus. We have a lot of, I don't know, text inputs. There's certain elements that repeat over and over and over and over again. So we want to make them easier, like easier to use, faster to apply, to build a new feature using some sort of element. there's "poka-yoke". "Poka-yoke" means "full-proofing". So we notice where we make mistakes and try to find a pattern in those mistakes. And then we full-proof it. So we add a "poka-yoke"
to make doing the wrong thing more difficult. So for example, the app is translated into, I don't know, six, seven, eight languages. Whenever in the app there's some text that's we refer to this text by its identifier. And it happened in the past that someone made a typo in that identifier or the name of that, the key of that text has changed.
And then we shipped the app with, instead of, I don't know, it's saying single tasks translated into German, it would say, I don't know, underscore single underscore tasks, string, whatever. So, hey, we can change that. So we added a little bit of technology magic so that when you enter the wrong key, it just highlights in the editor as read like, "Hey, this key does not exist." This is just one example of thousands.
Literally every week we notice something else that we could make a little bit easier to do, a little bit faster to do, a little bit harder to mess up, or something that, hey, there's some duplication, duplication, hey there's some old stuff that we need to clean up, some stuff like internal stuff to remove, stuff like that. By doing this continuous improvement, you know, every week the end result, like the user does not see it and we notice it only a little bit.
But like imagine you improve your productivity as a team member by, I don't know, 1% every week. That's actually, when you think about it, 1% a week, turns out to be pretty outrageous. So it's probably less than that, but 1% a week. Now, you know, take 1.01 and raise it to the 52 power. So 52 weeks in a year, and it turns out that your proactivity has skyrocketed, right? - Yeah, and multiplied by our team members, because the most improvements you made are applicable for everyone in a team.
like at least for developers. - Yeah, so by making small changes, but continuously noticing problems and fixing them, thinking about how we can make this better instead of pretending that they don't exist, like, eh, it's not a big deal. Every week, over and over and over again, you just make the productivity of our team, the quality of the work that we produce for the customers better and better. And it's a tiny bit every week.
And yeah, by changing things, sometimes we break things, a little bit, but it's so much worth it. And I think you can see it, you know, being internally but not a developer, how we just, you know with the same number of people, we just become faster and faster and faster, you know, pushing out new features you know, faster and better and with higher quality from the start.
- Yeah, like, as I said, we shipped 46 updates last year and I'm still surprised how fast we can develop some base for the feature that actually already adds value and we use it and oftentimes we decide to ship it in that form. It's often like one week appetite time for a developer to develop it. And thanks to those constant improvements to those guys and events, yeah, we maintain our speed, our performance of developing the features. - Yeah, exactly.
- All right, let's take a break here and thank our sponsors this week, which is of course us. Yes, Nozbe. Nozbe is task-based asynchronous communication app for personal, family and business use. So let's hear what our customers actually say about the product. - When we've been around for about 10 years, our business has, and we've been using Nozbe for about eight of those years. And as we grew, we kind of got to the point I just couldn't remember everything anymore. I'm pretty organized.
I would just kind of keep everything in my head and with post-it notes and things like that. And it just got to be too much. And so I started looking around for some sort of project management software that could help me have a set up really trusted system. But really I just wanted a system where I could know that I had everything in there. I wasn't gonna forget anything. I wasn't gonna drop any balls for clients or missed deadlines - All right, and we are back.
let's go back to talk about Kaizen improvements. You spoke about like dev tools, the tools we developers using for producing a code, for writing a code. I also remember that recently we improved a lot our build server. - Yes, so this is one of the myriad of little technology pieces that are not user visible technologies, customer visible technologies, but-- Actually, I can make it visible as a podcast chapter art and display it on the video version. Yeah. Wow, that's ugly. I'm ashamed of myself.
Well, it's not a UI that customers see. True. Anyway, long story short, we build a lot of code. We have a small but very active team. And after every change, which we will make a lot, you want to run automatic tests on the code base and make builds. So with tests, there's like five different tools that we run on the entire code base to check for any errors that can be caught automatically without human interaction.
And for builds, we have the web app, the Mac app, the Windows app, coming soon, the Android app and the iOS app. That's five apps. And it takes a lot of time to build. Actually not that much time because one of the Kaizen events actions and my own time was spent on just making these automatic tools and the builds faster and faster and faster. And then we have Apple come out with new computers which are faster and faster and faster.
So again, in the old days, you'd make a smaller number of larger changes, larger commits in the tech lingo just because what you have to do afterwards was just painful and slow. And the idea here is we want to be nimble and very, very fast and make lots of tiny changes, changes that are easy to review, to test, to just ship to the users. And so we need the process of automatic testing and build making to be very, very fast. So that's what CI/CD means, that's automatic testing and making builds.
And we have our own server for that because it turns out it's less painful and cheaper to just have your own computer do that. And because we make iOS apps, we need to make our builds on a Mac, which is not ideal, but you know, it is what it is. So we got the fastest Mac Mini money could buy and just put it on the shelf with a fastest SSD, stuck it in a server room. other friends at the Warsaw Hackerspace, hackerspace.pl. We have a nice server room, our server sits there.
And you know, every single time someone pushes a tiniest change to the code of the new Nozbe, within four minutes and 30 seconds, there's five apps to download and test and all the automatic checks are either passed or failed. - It's like every change on every branch or only those branches that have open PRs. - Have open PRs, yeah. - So, yeah, and I can see that's pretty fast and already today I think we have like, as I can see on what output of our build server, we already have three versions.
Well, someone build it on 2 a.m. today, tonight actually. - Yeah, occasionally someone does that, I don't know why. - Not me. - Yeah, obviously. Yeah, you respect your sleep. So that's CI, is there some errors, a bigger area that you constantly improve besides those dev tools and CI and code? - Yeah, I think we talked about the majority of what I've been working on over the past year or two. So it is the improvements of the code base and then performance.
and performance is, sometimes it's like stacking a bunch of five, 10% improvements, which is like, doesn't sound like much, but you have five or 10% improvements and then suddenly everything is so much faster. And sometimes, some new technology that we can easily use becomes available. So we recently shipped something that's called Hermes on our iOS app. And that made it three times faster to launch on iPhones and iPads, and twice as fast to like move between like views in the app.
And it was just a few days of work. Like it's just something that became available and I could use it and bam, three times faster, which is a gigantic difference. And it's so fast. It's so fast that iOS doesn't even finish animating and the app is already launched. And you know, all these iOS native apps, they're not even that fast.
- Yeah, and what was really nice and actually surprised for me, like it would be even more surprised for me like two years ago, but now after releasing app every week, I see that like we just, there's new piece of technology, like external framework or like this Hermes, we include it in our code base, yes? And nothing blew up. - Yeah, right. - Yeah, that was strange, yeah? It's just worked. - Yeah, part of that is external technology getting better and better.
Part of that is our tooling getting better and better. Part of that is just our skills getting improved. But yes, in this case, I made the changes. Kamil and me just tested it ourselves for a week, just used the app with this change. And then we all use it internally for a week and then we shipped it and nothing blew up. - I can imagine a customer right now, - I rise up is crashing because-- - Yeah, my favorite, yeah, that's true.
My favorite thing was that the only error that Kamil, our QA person found, was that his plan, his Nozbe personal team, was valid until the year 2100. And it didn't say 2100, but 2099. - Oh, no. (laughing) - Yeah, yeah, so we stole a one year of premium account from him. - Exactly, that was the one issue. - Yeah, that was, yeah, that's the critical issue. But we fixed that, right? - Yeah. - So let's talk HEM, because as I mentioned, every week you meet with the developer that is currently on HEM.
- Yeah, which is Horizon Expanding Month. - Yeah, what's that about? What is the purpose of this? because this is like we have three front-end developers, not counting you. - I'm a three and a half. We can say three and a half. - Three and a half, yeah. Okay, you can be a half of a front-end developer, yeah? - Yeah. - And two of them are assigned to projects within a cycle to implement features usually.
And one of them is always on the scam and like 50% internally, 50% of his time he's supposed to spend on expanding his area of responsibility within the app. And the rest like for on Kaizen events or implementing small improvements that actually can be done within one day or fixing like major bugs, support, reply to support tickets. - First of all, if I remember correctly, I came up with the Horizen Expanding Month name and it was supposed to be a joke.
It was supposed to be making fun of corporate newspeak, but it stuck by accident, but we just call it Hem. Like when you expand the, when you expand the Hem, it just, gross name. I don't like it. Anyway, yes, so the idea was that, you know, it's great and all to build features and ship them to our customers and customers are happy when you see new features. The problem is that features is all that customers see. Like it's what they say they want most of the time.
But the problem is that there's many different things around the process of building software that are not directly visible to our customers. But if you neglect them, things deteriorate over time. and we talked about this already. For example, we found it somehow somewhat difficult to plan bug fixing. So sometimes there's just bugs in the app and bugs can be a lot of things.
Sometimes they're like, some of them are minor, some of them are major, but even the minor bugs, if something is just misaligned and just looks ugly, but isn't there someplace deep down that almost no one ever sees, then that's one thing. And then you can call the bug "minor", but you see it every day and it's really annoying. So what that means is that over time, the list of bugs, the stuff we could possibly fix just grows very large, even though the app is mostly fine.
Like, yes, there's a couple of things to fix, but it's mostly fine. And yet there's a long list of bugs and you have to decide which of them to fix. It's often not easy before you start working on it to decide how easy it is to fix. Sometimes a major bug will take 15 minutes to fix once you get around to it. Sometimes a minor thing that you can just ignore and no one will notice would take hours or days of work.
And that's part of the reason why it's kind of difficult to assign developers to work on fixing bugs. So improving quality in that way, by removing errors, imperfections. It's just hard to schedule, it's hard to pick what to work on. So that's one of the reasons why we thought, okay, we need to do that. Like we need to spend some time working on that. It can't be the only thing because we could just be fixing and fixing and people wouldn't see that it's getting better.
So we need to be fixing things. Then there's technological aspects like the team members, they have to be growing, they have to be improving and learning new things. It can't be like it can't be me building all the infrastructure. Yeah, I'm in charge of all the infrastructure, but there are certain areas that while I have to delegate. So each team member has some extra responsibility that's like purely in terms of technology. But it takes time to learn and improve.
And the learning and improving and experimenting with things in that technological area, like it's not something you can easily schedule. You know, you can't say, oh, you work for two weeks on that to build X. Like it's kind of an open-ended endeavor, right? It takes time, you know that, but you can't, like with features say, we're gonna work on a week on that feature and whatever comes of it, we ship. Hence, HEM, right?
We rotate between the team members and so that everyone has time, like dedicated time to improve their skills in that area, experiment with new things, bug fixing, the person on ham plays a larger role doing code reviews. Everyone does code reviews, but the person on ham has slightly more time that can be easier to find to do reviews. And then Kaizen. Yeah, it's me, but there's not enough of me to do all of that. And also this is a thing about culture, right?
It's not just about spending time to continuously improve. It's people need months to start changing their mindsets and start noticing the things that can be improved instead of doing things the way we've been doing them for years. So it's important that these sort of extra responsibilities, that everyone does some of that. And the reason why it rotates is because it's kind of hard to be like, "Hey, you have an appetite of one week "to work on that feature."
But then also, "Hey, you can't be focused 100% "on that task, like that specific and time-bound task, "because also, you know, do the code reviews, "oh, check out this bug to fix, "and hey, are you coming to Kaizen today?" Right? - Yeah. - It's just hard to be, It's hard to simultaneously be in the mindset, in the mode of mind of focused task-based work. This is the task and this is the timeframe. And in the mindset of open-ended improvements and learning and exploration and stuff like that.
It's just two different types of work, types of mental activity. Hence, it is easier to rotate that between every team member, then have people split their days or their weeks between these responsibilities. - That's really healthy too, because we have three front-end developers, as I mentioned, and we work in five week cycles, so. - Three and a half. - So it's three and a half, yeah. We work in five week cycles, which is almost a month. So that's why it's horizontal expanding month.
So each developer has one ham per three months. Yeah. So that's, I think that's the healthy balance. And also you mentioned that takes months to change habits, to teach our developers better habits, to figure out places that can be improved. And I can see that in my work, like when I remember how we used to develop Nozbe Personal, I was so much needed to giving feedback to developers every day.
And now I'm just needed in the week when we plan the cycle actually, and a day after in the next week when we do kickoff meetings. And after that, developers are leaders of the project and they really make great decisions, not only like from the technical point of view, but they grow in sense of design decisions also. And I'm really glad how the whole process works. - I think I lied. I think it's like years, not months. I'm really proud of our team and how far we've come with this.
It is very easy to create in companies these bottlenecks, these decision bottlenecks, where people are just waiting on a designer or a manager to decide on something. And it doesn't just slow things down, but it just creates worse outcomes because you're a person doing the work. It might be development, but it can be any industry, right? Any job. You're doing the work. You're spending weeks just being immersed in it, understanding the problem, how to solve with possible approaches.
And then you're waiting for that one guy who spent hours and not weeks working on it. And they might not have the full picture. Yeah, they might be specialized in design or management. They know things, they're experienced in things you're not. That's true. But as the person doing the work, you tend to have the broadest picture of, hey, okay, I could do this and it would be a good result, but it will take me one week to get this done.
Or I could do this and it's almost as good, but I can get it done in an hour, right? And when you have these decision bottlenecks with these extra decision makers, it again slows things down and creates worse outcomes because it's hard to compress your weeks of experience working on something into something you can quickly express to a decision maker to approve or disapprove. But at the same time, just people are really not used to leading and making their own decisions in organization.
People are employed and they see, okay, I need to know my place. You know how companies, organizations, institutions are like, people are very territorial, people are in a hierarchy. So people are not used to leading, making decisions. they might have experiences that when they tried, didn't end up well for them.
So it really takes a lot of effort, not just empower people by saying, hey, you can do it and you should do it, and you're the best person to make that decision, but to actually convince someone and show them and give them the opportunity to have experience with making these decisions, to show them that, yeah, you can do it. So I feel like we've talked about like these sorts of ideas for years. And it took us years to somehow something changed and it kind of clicked.
And like we made some process changes, talked to people, explained it to them, explained it over and over and over again until they got it. And they just run with things. And I don't need to be bothered all the time. you don't need to be bothered all the time. Michael certainly doesn't need to be bothered all the time with just minutia of building a new feature. It's fine. The developer can get this done. - Exactly.
And even if they had initially when we started to encourage them to make their own decisions, even in short term, the first decisions weren't good, but it's a long-term investment. they learn how to make better decisions. And yesterday when we had a kickoff meetings about calendar improvements, we want to improve some of our calendar view in the app. And actually, yeah, the people want to have easier access to calendar. So the obvious thing is to add a possibility to have calendar in favorites.
But for some technical reasons, because task list is a very complicated form of living in the cold. Yeah. So it's not that easy. But actually, Miho, who is the leader of this project, just made an idea, "Okay, what if we do X? It will take 15 minutes, and it might have a high chance to actually do the job." And that is exactly what we want.
make good decisions, they are not afraid to experiment and see if even, okay, let's see if something that takes 15 minutes, one hour can do the job instead of doing something that can take one week, as you said. Yeah. You know, as I'm listening to ourselves talking about these different ideas, I think it's important to say that they're not exactly completely independent ideas. they form a coherent whole.
I hate to use this word because it's overused in the corporate newspeak, but it's a different paradigm of organizing our work. It's a different paradigm of building software. It's like with, I mentioned lean manufacturing, Toyota has been doing that for decades and they're doing fine and people are having a hard time copying them because you can take a la carte different ideas from it and they help, they're interesting, but when you have the whole, it really starts to make the most sense.
So here, notice how it plays together with us shipping every week. Like those are not two disparate ideas. They form a coherent idea of how you want to work. A developer makes their own decisions and we ship, we ship Chippo in small chunks. We don't design and build the best version of a feature that we can come up with because that takes a disproportionate amount of time.
So some decisions might not be the best at first, or like, we stumble, but okay, we've spent a week working on that feature and that's it for now and it's already better. And yeah, this decision, that was bad, we shouldn't have done it this way, but guess what, it's fine. It's not like someone made some decision And that got us into a six month project. And at the end of it, we ship.
Like, no, we've worked on something and sometimes it's great, sometimes it's fine, sometimes it's eh, but we ship every week and we'll get to it again. So this idea of, you know, him and developers being leaders of these feature projects that plays together with Kaizen, it plays together with us shipping every week. - Yeah, but the funny thing is that Kamil, our QA person, he was always like to test everything before shipping, et cetera.
And now he is the person responsible for driving our shipping process every week, actually. - Yeah. - Yeah, so. So he actually shipped 46 updates last year. All right, I think we can slowly wrap up this episode.
So Radek, tell me, because as we said, your role in our company in building current Nozbe, our main product right now, evolved through all of this years so you had a big impact on design, how Nozbe works, and now you have a huge impact on the whole technology stack and our dev tools and how the code base is organized, et cetera, et cetera. This Nozbe is really, you can say it's your child, but what's your favorite feature of Nozbe? - Well, you know, you're not supposed to have favorites.
(laughs) - I guess. - I don't think I have one favorite feature, but something that I really care about deeply is these little power user improvements. So not things that every customer is using, but something I'm using because I use the new Nozbe everyday for the last four years, right? Well, since its inception pretty much. And so I love the keyboard shortcuts and there's more keyboard shortcuts coming.
And then you jump to, which I think will ship next Monday or we've already shipped, I don't remember. - Yeah, it's already shipped actually. The one thing we didn't ship is highlighting. - Highlighting, okay. - Highlighting for search and fuzzy search. - So I recently made some improvements to the jump to feature, which makes it so fast and so fun to just go to different places in the app. I don't have to click around, look for tasks.
If I remember the name and I just hit Command + K and I type in like two or three or four characters, not just the full name, but a few characters that match that's called fuzzy search. And we have this highlighting that will ship, I think next Monday, that kind of shows why the search results show up. And it's very fast now. And so, within two seconds, I can go between tasks and projects and just places it in the app without moving my hands off of the keyboard. And it's glorious.
- Yeah, I really liked that too. and I started to using even more after your recent performance improvements. Yeah, I would say now it's my second favorite after incoming, because incoming is just a magic. I think that's it for this week. Tadek, tell me what day is tomorrow? - Tomorrow is a mighty Friday. - Exactly, mighty Friday. So make a, do your weekly review, plan priorities for next week, and to learn something new to have a great weekend.
We actually recently launched a new website about our Mighty Friday, so you can check it out on nosbe.com/friday. And if you enjoyed this episode, please feel free to help support this podcast, either by sharing it with a friend, leaving us a nice review in Apple Podcasts, or by just signing up for our Nozbe app. And that's it for today. Say goodbye, Radek. Bye! This episode has not been created in the office, because in Nozbe there is no office.
Your hosts were Laphroso Sowolewski and Ladosławie Trushevski. All the links and show notes you can find on no office.fm/36. The whole production process of this episode has been coordinated in a project in Nozbe app. Control is good, but trust and transparency are so much better. Thank you and see you in two weeks. Remember to have a mighty fly day! (upbeat music) (upbeat music) (upbeat music) (upbeat music)