Shared Principles for Managing People Engaged in Diverse Tasks

This post expands on my response to Michael Sweeney's (Cloud Infrastructure Engineering for Salesforce) comments on Linked In:

This is a great blog to follow [Curious Cat Management Improvement Blog] if you aren’t aware of it. I agree with John, in general, but in this post I felt the missed one basic thing that I’ve seen in my own career- software is not physical and people who write great software and people who make great physical things MUST think (and therefore be managed) differently. The crossover between Agile and Lean thinking, to me, is the ability to identify non-value added activity (waste) in the Toyota sense, and empower small teams to make decisions and charge forward in the Agile sense. Getting a combination of software and hardware thinking together will be the key to winning the Cloud Wars and moving into the Fourth Industrial Revolution.

Thanks for your comments. I do agree that the system within which people are operating determines how they must be managed. There are definitely features of software development that are significantly different than manufacturing scalpels or basketballs or tables. As there is a difference between a surgical team in an operating room, road construction, mining, editing books, investment banking, manufacturing industrial robots, researching new drugs, manufacturing drugs, teaching in a university, maintaining plane engines, coaching an athletic team...

I see universal principles of management (respect for people, customer focus, continual improvement...) that cross all different human enterprises. How those principles should be manifest in a particular situations depend on the work being done, the management system that is in place, the individual people involved, the specific focus of the effort right now... The way those principles are manifest will look very different in all the varied types of organizations we create and the different work and processes used within those organizations.

John Hunter, presenting at a Deming management seminar in Hong Kong

It is interesting (on the software v not software divide) to note that 100 years ago what was manufactured didn't contain software elements. And the manufacturing process also didn't involve software. That isn't very often the case today. Think of all the manufactured things you use and a high percentage (measured by the cost of the manufactured goods) have software components (cars, phones, appliances, speakers...) and they are built with a great deal of software involved in the manufacturing process.

In addition, the sales process and other processes involved in the organization doing the manufacturing rely heavily on software. As you say "Getting a combination of software and hardware thinking together" is indeed key today and will be continue to be in the future. While relying on software as part of the manufacturing process (and in the supporting processes) isn't the same as developing software the thought process on how to use software within manufacturing systems and how that software should work, be adjusted... is very different from the work of manufacturing tires 100 years ago.

I also discuss related ideas in: Deming and Software Development.

Related posts: How to Manage What You Can’t Measure - Create a System That Lets People Take Pride in Their Work - Good Process Improvement Practices - The Importance of Management Improvement - Thinking Required, No Simple Management Recipe to Follow -Unpacking the Components of Hard Work to Design Better Work Conditions - Do We Need to Find Management Ideas from Our Industry? (No) - Avoiding Difficult Problems

Code Software to be Robust and Easy to Update Quickly

Comment on: Correction vs Prevention in Software Development

I think both prevention and designing the software and management system so that rapid correction is possible are important. While rare events may be difficult to prevent when looking at each instance there are styles of coding that make more "edge case" failures more likely. Coding so that the system is as robust as possible is wise but you should also realize those efforts will likely not be perfect and so designing in visible notifications of failure and coding so rapid correction is possible is necessary.

In addition to the need to update quickly for bugs, software should be easy to update due to changing requirements and to aid in continual improvement efforts.

Related: Improving Software Development with Automated Tests - Software Supporting Processes Not the Other Way Around - Building a System to Reduce Interruptions for Software Developers
- Use Urls: Don’t Use Click x, Then Click y, Then Click z Instructions