The Importance of Providing Context for Data

Data in Everyday Life: How Serious is the Student Loan Debt Crisis?

Did you know that 1 in 4 Americans have student loan debt? In the United States, there are more than 44 million people who collectively owe $1.56 trillion in student loans.

I thought 25% seemed too high. Thankfully this post also provides the number, 44 million. The USA population is currently estimated at 330 million. 44 million is closer to 14% than 25%. My guess is that the 25% is of some subset of the USA population (people between certain ages maybe)?

I think a point about the importance of providing the proper context when showing data has also been made in this post. There is certainly a sensible argument for why 25% of certain ages is a more useful figure for understanding how widespread student debt is (rather than saying 14% those in the USA have student debt). But in the case where that decision is made the details should be spelled out.

Related: Operational Definitions and Data Collection - Data Can’t Lie (data can be wrong) - Poorly Stratified Data Leads to Mistakes in Analysis - Understanding Data

Take Risks to Learn and Improve, But Do So Wisely

My edited comments on: The Limits of Learning From Failure

Failure can be a great learning tool, especially if it is planned. Create an environment that supports and learns from failure, but also use the scientific method, coupled with experience, to understand and mitigate the risks.

I agree, I wrote about this on my blog: Accept Taking Risks, Don’t Blithely Accept Failure Though

The goal is to maximize innovation and improvement. To the extent we need to take risks and accept some failures to achieve this we should accept failure. But that doesn’t mean we don’t continually try to improve our management systems to reduce the costs of failure. Even while we take risks we want to do so intelligently.

It is true many organization are so fearful of being blamed for failure that sensible risks are avoided. We do need to create management systems that allow taking sensible risks but we need to learn while still limiting damage from failures. Do experiments on a small scale, iterate quickly and expand the scope as you learn.

Related posts: Learn by Seeking Knowledge, Not Just from Mistakes - Risks Should be Taken Wisely - What is the Explanation Going to be if This Attempt Fails?

Outside the Box Thinking

comment on: Is Thinking Outside the Box Out of the Box Thinking?

I remember Russel Ackoff* telling a story about that 9 dots problem where his daughter shared a solution to cover the dots in 1 line. She folded the paper to the dots were all lined up and drew one line that went through all of them. The teacher said that was wrong! Great teaching about "outside the box" thinking there. But it is a great illustration that just saying "outside the box" isn't the same as adopting that mindset.

* It has been a long time, I might be be wrong but I think it was Ackoff that told that story.

Related: The Psychology of Change is Often the Trickiest Part of Process Improvement - Children are Amazingly Creative At Solving Problems - Innovation Strategy

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