A podcast by Nozbe about running 100% remote company and building a product. Hosted by Michael Sliwinski (CEO) and Rafal Sobolewski (Chief Product Officer).
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)