How Production Lines and Software Engineering Processes Relate: A Takeaway from Andrew S. Grove's 'High Output Management' Book

One of the great takeaways from Andrew S. Grove's "High Output Management" book, which I read a couple of years ago and am reading again now, is that it sheds some light on the common similarities between production or assembly lines and software engineering processes. Accordingly, whether you are working on a task from scoping phases to shipping production, hiring a new engineer for your team, or even making breakfast, each of these has a predefined and, preferably, planned set of activities that should be followed for execution and measured for performance tracking and improvement in a great deal of cases.

The fundamental elements of any production line (or software engineering process) include inputs, execution phases, manpower or tools that perform the execution, timings, limitations, quality control, outputs, observability tools, and tracking measures. The primary objective of each phase is to produce the desired and expected outcomes in a timely manner while minimizing capacity waste and maximizing resource utilization.

That said, it is essential to be able perform early inspections in order to identify problems and roadblocks as soon as possible. This enables you to address these issues in the early stages of the process, rather than waiting until the end, when it would be much more expensive and disruptive. The book frequently uses the example of running a breakfast diner, where it would be more beneficial to detect a rotten egg before boiling or serving it, as undertaking so would consume resources and take more time to get another egg, especially if you want to keep up with the expected time from placing orders until they get served to customers.

In reality, the majority of software engineering processes are comparable to serving breakfast. Detecting a functionality or user interface bug during the development phase is a good problem to have, as it gives the team more time to implement the right fix. If this issue found its way to the UAT (user acceptance testing) phase, it could take longer and put the actual delivery date?at risk.?Let alone?the negative consequences of identifying such issues on any production environment because it was overlooked during the development and testing phases.

A further example is the recruitment, hiring, and onboarding process, which includes numerous phases, such as sourcing, screening, coding assessments, technical interviews, squad-fit interviews, offering, onboarding, probation periods, and setting success expectations for new members. I believe you can now begin to think of it as a production line in which early detection could save a significant amount of money, effort, and time for everyone and every resource involved in this lengthy and time-consuming process. If you have a poor and average interview process, you may hire a candidate who is not particularly solid. Also, if your onboarding process is disorganised and shallow, you take the risk of having an employee who is unsettled and unaware of what's going on around them, which makes it more difficult to evaluate him accurately during his period of probation, and even more difficulty if you come up with a decision to let him go after all of these wasted efforts and money plus the time it took from you to detect a problem and fix it.

Measurements are essential to assess how well you and your team are performing in the execution of your processes. However, having the correct measurements is a requirement for improvement, but having the wrong ones hasn't ever been better to having none at all.