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)