Random Thought: Standard Labor Rates to Support Software Development Automation

Ok, here’s my scenario: I’m a software developer that does a good bit of consulting. This means I often end up performing similar tasks and building similar programs for multiple customers. As an engineer of course I want to automate these tasks to save myself time and reduce the risk of human error, but this automation is in conflict with the business model of consulting.

Allow me to explain using the analogy of a mechanic as an example (any mechanics reading this - if I’m getting it wrong please reach out and let me know).

When you take your car to a garage for most general maintenance work - getting oil changed, brake pads replaced, etc. - many garages charge a ‘standard rate’ for this work. A standard rate is a generally agreed-upon amount of labor that a job should take. This standard benefits both the mechanic and the customer - customers are not overly penalized if a job takes longer due to a mechanic being unfamiliar with their vehicle, and mechanics that are experienced can get more jobs done in a given timeperiod, allowing them to earn more.

As a consulting software engineer I feel this is currently a one-sided arrangement. Customers want the benefit of ‘standard rates’ - costs that are kept low due to the engineer (mechanic) being experienced and having the right tools - but customers don’t allow the engineer any benefits - with an hourly billing model the faster the engineer can do the work the less money they can earn.

Automation is particularly problematic as a consulting software engineer - most customers will not pay for automation to be built, but all customers want the benefit of it. As a consultant if I want to automate a process I must invest non-billable time to create and maintain the automation, and the result is that I can get more done and bill less time.

I propose the following as a compromise that has upsides for both, much like standard labor rates for mechanics: consulting software engineers should determine standard labor rates for tasks they come across consistently enought to automate. Rates should be determined by an average after completing the task manually in varying scenarios. Once a standard rate is established and a task automated, customers should continue to pay the “standard rate”. The automation will give the customer a better experience by giving them a fast turnaround time and predictable results less prone to human error, and the engineer will benefit by earning enough to justify maintaining the automation.

I believe this model could also be adopted when using open source. As an engineer I often leverage open source projects to benefit the projects and customers I work with, but again this results in earning less money, making it difficult for me to find time to contribute to the open source software I use. If I could determine a standard rate for the open source software I use for customers, not only could I potentially earn enough to contribute to those projects but that money could even be passed on directly to the maintainers.

This is something I want to explore further. There are definitely some challenges to it, such as the subtle nature of every software system being just a bit different, making true standardization rather challenging.