Create a continuous process flow to bring problems to the surface.
While the first principle was generic enough to apply to many different situations, this second principle is not as easy to apply to system administration. So what is the idea behind it?
In a production environment, according to this principle, pieces of work should flow through the factory, being handed from one worker to the next without interruption. The goal is to link worker’s processes. This way unproductive idle time (from the point of view of the workpiece) is minimized and eventual problems surface immediately, meaning that they interrupt the flow, so that everyone understands they need to be fixed. How can we translate this idea to system administration?
One difficulty is, that in a factory, many identical workpieces are created by following one and the same process over and over. In system administration, we seldomly have this situation, examples would include deployment of desktop machines or adding a new user to your system. Often we have to deal with more or less new situations like deploying a new service or dealing with an unknown problem for our users. What simplifies our situation compared to a factory is, that we often work solo on a task and don’t have to link up with someone else. Therefor we can deal with all these situations in the same way. Once you commit yourself to a task, work on it until it is done or can be handed off according to process flow. This minimizes work in progress and task switching overhead. When you recognize an infrastructure problem on your way, stop and properly deal with it, if it relates to you current task. Otherwise just open a ticket for it, to not get distracted from your objective.
To sum it up, working in a continuous process flow translates to singletasking until done.