Imagine Toyota factories, back in the 1950’, when Kaizen ideology was maturing among the crowded factory lanes, Japanese workers were hustling around the conveyor belts and every one of them was personally engaged in observation of the work environment around him and thinking how it could be improved. “Maybe If we clean up the mess on the floor, we would be able to walk faster without fear of tripping over something?” “Does the machine needs oiling to maintain a good condition?” Continuous improvement, proactively carried out by everyone, was the key factor that contributed to the Toyota’s domination on the global car market.
This is exactly how we should be working too. Programmers, like blacksmiths, have the ability to improve or replace every tool they use. Does any technical impediment slow down your work? Does any organizational process that you take part in is inefficient? Change it, that’s what you are paid for – programmers are the people that solve problems.
Well, at least it sounds easy. In my case, the harder I thought about what needs to be improved in my job, the more guilty I felt for not doing anything about it. Continuous improvement surely is necessary, but there are five reasons that comes to my head for why it’s easier said than done:
- You feel like there is something wrong, but you don’t know what exactly.
- Everything is imperfect, so even if you come across something, you forget about it after 5 minutes, or you feel overwhelmed thinking about all of it at the same time.
- You don’t know what to do with all of these problems. You don’t even know if they can be improved, let alone the How part.
- In your culture people have to act like everything was ok and they don’t have any objections. Or you fear that you will expose yourself as incompetent if you start complaining about things that you are part of.
- You just don’t know when is the right time to take care of it.
I have been working for years in the condition of “I can’t make any significant progress and my everyday work is extremely daunting, but I can’t tell you exactly why”. I wanted to change it somehow and I wouldn’t be myself if I didn’t write down any process for it 😉. I present you The workplace improvement framework (I’m not sure if this name is adequate, because it’s not tied up exclusively to work, but nothing better comes to my head).
It goes like this:
- Every time you said to yourself “What the f…”, or had an urge to complain about something, write it down in your favorite ToDo app.
- Before you totally forget what was it about, add three pieces of information about each of it:
- Context (e.g. “I was assigned a task to block the possibility to edit the survey if it has ‘global’ attribute. The only solution coming to my head would involve making multiple changes in different source files”)
- Precisely, what is the problem? (“This solution would be time-consuming and the system would become less maintainable in the result of this change”).
- How it should be resolved? (eg. “Refactor the application architecture in such a way, that this task would require the change in only one place. Talk with your team leader about the problems in the architecture of your app.”) Don’t panic if you don’t have any solution yet, you can as well just write “schedule some time to learn how I could achieve this task without introducing duplicated code into the system.”
Someone could say “Wow, Marek, you are such a genius. You’ve invented a brand new methodology”, except I haven’t invented anything. That’s just an old, well-known structure of design patterns.
But wait, there’s more! When you gather problems, described in such a format, you can prioritize them (by a combination of severity, incidence, solution difficulty, etc.), reserve some regular time for “removing impediments” and start resolving them, day by day.
In other words, I’m treating my personal problems as if they were bugs in software - I write them down, gather in a backlog, prioritize and allocate regular time to solve them, starting from the top of the backlog.
I will go back now to the 5 reasons why it was hard to start solving my problems and try to answer how The workplace improvement framework could help:
1. You don’t know what exactly is wrong.
If you will be focused on writing down everything, you will start perceiving more and thinking more critically. Just start taking notes next time you:
- are annoyed by something,
- encounter a code smell,
- have to wait for something
- have the gut feeling that some process could be done better.
2. There are too many things that could be improved.
Divide and conquer: Write it down to get it out of your head. Prioritize to decide which one you should take care of first.
3. You don’t know how to solve the problems.
I think that most of the problems can’t be easily solved. There are four steps of recognizing the problem:
- Being aware of it,
- Knowing if it can be improved (or if it’s worth the time),
- Have some plan for it,
- Start doing something about it.
I think that it’s already valuable to have only the first step. The solution plan can emerge slowly, it’s still better than not doing anything. You can ask more experienced peers how to solve it, or even publish your problem on the internet and let people discuss about it.
4. Your culture.
That’s a hard one, but you can:
- Pick one of your superiors and schedule a meeting on which you would talk about the problems you’ve found and ensure you are taken seriously
- Start writing about the problems in style of a “blog”, for example on your organizations’ confluence. That way you will make the problems visible, but won’t be so vulnerable to backlash as in real conversation.
- Convince your team to start making regular retrospectives.
5. You don’t know when is the right time for taking care of it.
You can schedule a regular time for “removing impediments”. If you worry that your boss wouldn’t like it, I recommend you to read Mark Seeman’s blog post about who’s decision it should be.
When I started writing this post, I wrote such a paragraph:
Is your build process taking too long and wasting your time? Utilize this waiting time in researching the build tools and improving it. Is your team working inefficiently, wasting too much time on unnecessary meetings? Introduce them “Gettings things done”, or some lean management framework. Do you spend too much time reading mail discussions? introduce Slack to your team leader and suggest that you should be using it.
But I think that in this post I’ve managed to explain it better than that. What do you think about it? Is it worth the time? Would you try to do it yourself? Do you have any other way of improving your workplace that really works?
Sincerely yours,
~Marek