Everything is a process, whether we document it or not.
I wrote about automation recently, and ever since I published that post, I felt like I should have written this one first.
In order to automate, you need something that benefits from automation. Here come systems and processes. A system, by definition, consists of many processes that work together to achieve the same goal. I love approaching things in the smallest possible way, an approach I borrowed from the Tiny Habits book. When you complete one process, you can always jump to another until you have covered the whole system.
In IT companies and fast moving startups, where requirements change daily and pivots happen weekly, it is hard to define processes. Let's take deploying code to production for example. This is a system composed of many individual processes, starting with code merged into the deployment branch. The code goes through several different steps including testing, building and packaging an artefact and then deploying that artefact to a server/cloud infrastructure. Some cloud environments skip parts of the process and help us deploy code faster.
By documenting processes we are able to stand back and identify the holes inside of it. If our deployment fails at one step more often than not, for example because we sometimes (but not always) need to run some post-deploy tasks, how can we make it pass every time? I'm a great fan of checklists and numbered step by step instructions in IT and in "real life".
Put yourself in a situation where you are responsible to train a few people to install and configure a new workstation. I know this is a relic of the past and mdm solutions exist, but stay with me. One way would be to show someone how you do it, then letting them do the next themselves under your supervision. This approach is very fragile because you might know something you did without thinking and the other person won't catch it.
The other approach would be to go through the task yourself and write down every step of it. We can clean up those steps later and add checkboxes next to it:
- [ ] Install this OS version
- [ ] Install this database version
- [ ] Framework version X
- [ ] Patch version Y
- [ ] etc...
This way we have documented our process and can take a look at it from an objective standpoint. And the person you are teaching it to just follows your checklist.
I like the lessons from the E-Myth Revisited book, where the author wants us to think of our business as a franchise. We can think the same of our processes. As you grow in your role, you start delegating your regular tasks to juniors or people that come to replace you. If you leave the company you work for, imagine your handover being: "Here's my process handbook, where everything is documented and you don't have to 'think' a lot". We could call it an OPS manual of sorts.
If you are an owner of the company, it is in your best interest to encourage mapping out these processes. You want to be able to achieve the same results with the same effort put in. In other words, to have consistency. You want to do this as an employee as well, since it will improve your thinking and problem solving skills, increase your value to the company (and on the market) and make it super easy to handover your work in the case you get promoted (or leave the company as I already mentioned). Because life isn’t a zero sum game, it will make the company more resilient by reducing the dependency on you. So if something were to happen to you, things would go on smoothly.
Having clearly defined processes in one place serves as a source of truth, instead of keeping the knowledge inside people’s heads. There is a great book called The Phoenix Project on how these undocumented processes can run the company into the ground.
I'm against burning bridges and leaving a past employer stranded because you don't think very high of them. That’s a very juvenile approach. Yet, there are situations where they have lied to you, you suffered mental or physical abuse and in those cases you should keep your own processes to yourself and let the company fuck themselves into the ground.
Thanks to Hrvoje for his help with proofreading/editing.
Top comments (0)