Category Archives: Popular

Most Popular Posts on the Curious Cat Management Improvement Blog in 2020

These posts were the most popular posts on the Curious Cat Management Improvement Blog in 2020 (as measured by page views recorded by my analytics application).

I wrote very few posts for this blog last year. The historical Curious Cat management RSS feed provides a feed of all the past posts about management (I also provide other Curious Cat RSS feeds).

This year 15 posts are repeats from the 2019 top 20 list. Of the new top 20 posts 3 were published in 2006, 1 in 2010 and 1 in 2011. The long term value of good blog content is overlooked by many people. I hope you continue to enjoy this blog, both the new content and the content I published many years ago.

photo of John Hunter at the Borobudur Temple

John Hunter at the Borobudur Buddhist Temple in Indonesia.

Continue reading →

20 Most Popular Posts on the Curious Cat Management Blog in 2016

These posts were the most popular posts on the Curious Cat Management Improvement Blog in 2016 (as measured by page views, as recorded by my analytics application).

John Hunter, Frijoles Canyon, Bandelier National Monument, New Mexico, USA.

Continue reading →

20 Most Popular Posts on the Curious Cat Management Blog in 2015

This is a list of the 20 most popular posts on the Curious Cat Management Improvement Blog last year (as measured by page views, as recorded by my analytics application).

John Hunter with snow covered mountains in the background

John Hunter, Hurricane Ridge Trail, Olympic National Park

Continue reading →

Toyota Posts Record Profit: Splits $15 million in Pay and Bonus for top 21 Executives

After posting record profits of $17.9 billion Toyota proposes to increase the pay and bonus for the top 21 executives to $14.9 million. That is not as you might expect just the increase in the bonus to the CEO. That is the entire pay and bonus for the top 21 executives. That places all 21 together below the top 50 CEO paydays in the USA.

Toyota’s net income for the year surged 89.5%. While the profits are partially due to good management at Toyota the decline in value of the yen also greatly aided results.

Management Pockets A 19% Raise As Toyota Racks Up Records Profits

Toyota proposed 1.52 billion yen ($14.9 million) in combined compensation and bonuses to 21 directors, including President Akio Toyoda, in a notice to shareholders Tuesday. The Toyota City, Japan-based company paid 1.28 billion yen the previous fiscal year.

By comparison, total pay for union workers increased 8.2 percent [this was linked to an article as a source but the link was broken, so I removed it] on average from last fiscal year. The carmaker granted the union’s request for workers’ average bonus to rise to 2.44 million yen, the equivalent of 6.8 months of salary.

The company forecasts a 2% slip in net profit to $17.5 billion for 2015.

Toyota continues to generate cash flow extremely well and has over $20 billion in cash at the end of their 2014 FY. They are also increasing the dividend to stockholders and buying back more stock.

Less than a handful of USA CEOs that is took more from their companies treasuries than all 21 off the Toyota leaders take together led their company to greater earnings than Toyota (only a few companies earned more: Apple, Google, Exxon…). The thievery practiced by senior executives in the USA is immoral and incredibly disrespectful to the other workers at the company and the stockholders.

ExxonMobil did earn more and their CEO took $28.1 million. I think Chevron and Wells Fargo may have earned more than Toyota with a CEOs taking $20.2 and $19.3 million respectively.

Alan Mulally, Ford CEO, took $23.2 million while the company earned $7 billion. If you can ignore his massive and disrespectful taking what he doesn’t deserve he has been an acceptable CEO in other ways.

Continue reading →

Building a Great Software Development Team

Elliot: I worked with some of the best programmers I’ve ever known at the tiny, obscure ASEE

Adam Solove: Why do you think that happened? They hired for passion, rather than experience?

If I had to pick one thing, passion would likely be it but really it is a complex assortment of things. Passion for the right things, based on what we aimed to be, mattered a great deal. That took the form of being passionate about the user experience, being passionate about good software development practices, being passionate about good software itself, being passionate about treating each other with respect, being passionate about learning and improving.

I think there were several other important factors, such as: the skill to turn a passion for good software into actual good software. This required intelligence, interest and knowledge about software development but didn’t require specific experience (computer science degree, 2 years of Ruby on Rails development, certification or any such thing). Hiring based on experience is a big mistake. In my opinion hiring based on capability and potential (which is based partially on experience) is wise.

Another factor is that we had people (those first few hires were critical) that were really knowledgable about programing good software and that became a self reinforcing process. The gaps one person’s ability and knowledge could be filled by someone else helping them understand and get better.

The expectation was that we found great solutions. If we didn’t we kept looking and asked each other for help (another factor in creating a great team). We didn’t just accept that we were confident the solution wasn’t very good but couldn’t find any better options so I guess this is the best we can do.

We were interested enough in good results that we would push for better options instead of just accepting something that was kind of ok. This shouldn’t be such a big deal; but in practice it is huge. So many places just end up avoiding conflict to the extent that it is a huge detriment to results.

Without confidence, honest debate about ideas is suppressed as people are constantly taking things personally instead of trying to find the best ideas (and if doing so means my idea is criticized that is ok). Our group was great at this. It is something I find it a bit silly to say a workplace was “great” at but in most places I find the fear of someone being concerned stifles discussion to an unbelievable extent.

This is also one of many areas where the culture within the team was self reinforcing. As new people came on they understood this practice. They saw it in practice. They could see it was about finding good ideas and if their idea was attacked they didn’t take it nearly as personally as most people do in most places. I sought to understand if people we looked at hiring would be comfortable in such an environment.

Continue reading →

Deming and Software Development

I am sometimes asked about how use Deming’s ideas on management in a software development context. My belief is Deming’s ideas work extremely well in a software development context. The main issue is often unlearning some assumptions that people might have about what the Deming management system is.

It really is surprising to me how many “knowledge workers” respect Deming ideas but then say his attempts to treat factory workers as thoughtful people who should be respected and involved in improving their processes doesn’t make sense for them because they are “knowledge workers.”

There are many good things being done to improving the software development process. I think many of them are very Deming-like in their approaches (but to me miss out on aspects of the Deming management system that would be helpful). I think Dr. Deming’s approach to software development would focuses on the system of profound knowledge (the 4 inter-related areas below):

Understanding variation – software development has quite a bit of variation, some probably innate [unique work] and some due to not having good procedures, batching work, not fixing problems right when they are seen, quick fixes that leave the system vulnerable in the long term (when you make one simple change to the code it has an unanticipated consequence due to poor practices that could have been eliminated), etc.. Many good coding practices are effective strategies to deal with this issue. And building an understanding of variation for managers (and business process owners/product owners) is very helpful to the software development process. The ideas in agile and kanban of focusing on smaller delivery units of work (one piece flow, just in time, cycle time…), customer value, maintainable code, sustainable work conditions, etc. are directly found in a Deming management system.
Appreciation for the system of software development. Don’t just complain about bugs. Examine the process of development and then put in place mistake proofing efforts (don’t duplicate code, use integrated regression tests, don’t put artificial constraints on that result in system distortions – unrealistic targets…). Use things like kanban, limited work in progress, delivering value to customers quickly, think of success in terms of getting working software to customers (not meeting internal delivery goals), etc. that take into account our experience with systemic software development problems over the decades.
Theory of knowledge – how do we know what we know? Are estimates reliable? Lets look at what users do, not just what they say (A/B testing…). Software developers often appreciate the value of usability testing, even though they rarely work for organizations willing to invest in usability testing. In my experience when software developers object to usability testing it is normally really an objection to overwork, and the usability testing is just going to give them more work or criticize things they were not allowed to spend the time they needed to do great work. That won’t always be the reason but it is the main one in my experience (I suppose their is also fear and just the psychology of not wanting to hear anything negative about what has been created – even if the usability testing shows tons of great results people will often focus on the negative).
psychology and respect for people – This pretty much seems like it is the same for software development as everywhere else.

Continue reading →

Managers Are Not Non-Leaders: Managers Need to Practice Things We Classify as Leadership Traits

Saying “Managers care about efficiency and leaders care about effectiveness” is like saying “Doctors care about theory and nurses care about patients.”

Managers that don’t care about effectiveness are lousy managers.
Leaders that don’t care about the gemba are lousy leaders.
Doctors that don’t care about patients are lousy doctors.
Nurses that don’t care about theory are lousy nurses.

Your role in the organization (and for the particular situation in question) and training and the situation will impact how you contribute. But the attitude that leaders are visionaries that think big thoughts, make decisions then tell everyone what to do (act as the brain for the organization) is outdated. Every list of what traits are for leaders that then contrasts them with managers that I have seen shows leadership traits managers need.

Seeking to separate leadership and management is a bad idea. If you want to have a few leadership traits that you want to focus on at various points (creating engagement, communicating a vision, building consensus, setting organizational direction) that is fine. But those things are traits managers need; they are not traits reserved for some separate leadership cadre.

And disconnected leaders that don’t understand the organization, the organizations customers etc. are not going to lead well (normally the contrast lists have the managers doing all the hands on stuff, at the gemba, with customers etc.). Nurses may not have as complete an understanding of the theories behind medical treatment decisions but they need to know a great deal of theory to do their jobs well. Everyone contributes and has different roles to play but I don’t see value in the contrast of leaders and managers mentality.

From what I have seen mainly the manager v. leader comparisons seem to be about belittling managers and elevating leaders; but leaders are this vague concept that isn’t well defined. Who are these leaders? Are they only senior executives? They can’t be managers because you are contrasting them with managers – by the contrasting model used they can’t be leaders and managers.

Continue reading →

Stated Versus Revealed Preference

My father provided me a good example of the flawed thinking of relying on stated preference when I was growing up. Stated preference is, as you might deduce, the preferences voiced by customers when you ask. This is certainly useful but people’s stated preference often do not match there actions. And for a business, actions that lead to customers are more important than claims potential customers make about what will make them customers.

His example was that if you ask people if clean bathrooms in a restroom is required for a restaurant they will say yes. Potential customers will say this is non-negotiable, it is required. But if you eat at many “ethnic restaurants,” as we always did growing up, you would see many popular restaurants did not have clean restrooms. If the food at atmosphere was good enough clean restrooms were negotiable, even if customers stated they were not.

Now I think clean restrooms is a wise move for restaurants to make; it matters to people. Instead of creating a barrier to repeat customers that has to be overcome with much better food and atmosphere it is wiser to give yourself every advantage by giving the customers what they want. But I think the example is a simple example of stated versus revealed preferences.

McDonald’s gets a great deal of success by doing certain things well, including clean bathrooms, even if they miss on things some people think are important for a restaurant. McDonald’s really gets a fair amount of business for people driving a long distance that really want a clean bathroom and a quick stretch of their legs and quick food. This is a small percentage of McDonald’s customer visits but still a very large number of visits each day I am sure. Understanding, and catering to, the problem your customers are trying to solve is important.

The point to remember is what your potential customers say they will do is different than what they do. It is sensible to listen to stated preferences of customers just understand them for what they are.

We need to pay more attention to revealed preferences. Doing so can require putting in a bit more thinking than just asking customers to fill out a questionnaire. But it is worth the effort. A simple restaurant based example would be to have wait staff pay attention to what people leave on their plate. If you notice certain side dishes are not eaten more often, look into that and see what can be done (improving how it is prepared, substituting something else…).

94% Belongs to the System

I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special.

Page 315 of Out of the Crisis by Dr. W. Edwards Deming.

the system that people work in and the interaction with people may account for 90 or 95 percent of performance.

Dr. Deming’s quote from the introduction to the Team Handbook

I think, in looking at the total of Deming’s work, that the point he is trying to make is that looking to blame people is not a good strategy for improvement. The impact due solely to a person’s direct action (not including their interaction with the system and with others) is small in comparison to that of the system within which they work. So, Deming (and I) want people to focus on improving the system; which will achieve better results than searching for what people did wrong.

What did Deming want people to take from his statements?

Did he want us just to accept bad results? No. He was not saying it is the system there is nothing we can do just accept that this is how things are. He wanted us to focus on the most effective improvement strategies. He saw huge waste directed at blaming people for bad results. He wanted to focus the improvement on the area with the greatest possibility for results.

Did he want to say people are just cogs in the machine? No. Read or listen to most anything he said at any significant length (a full chapter of this book, a full article he wrote on management, an hour from one of his videos) and it is hard to maintain such a thought.

Pinetree Trail, Frasers Hill, Malaysia by John Hunter

Did he believe that people were not important? No. He was trying to direct the focus of improvement efforts to look not at the fault with one person but to look at the system. I believe strongly he was correct. If you blame a person as the root cause of a problem, my first, second and third reactions are why? why? why? It is possible the person is to blame and there is no benefit to exploring system improvement instead of settling for blaming the person. But that is rare.

I have written about the importance of developing people to build the capability of the organization. My father wrote about it previously, “American organizations could compete much better at home and abroad if they would learn to tap the potential information inherent in all processes and the creativity inherent in all employees.”

I wrote about the importance of the ideas behind Deming’s quotes here, back in 2006 – Find the Root Cause Instead of the Person to Blame

Continue reading →

Keys to the Effective Use of the PDSA Improvement Cycle

The PDSA improvement cycle was created by Walter Shewhart where Dr. Deming learned about it. An improvement process is now part of many management improvement methods (A3 for lean manufacturing, DMAIC for six sigma and many other modifications). They are fairly similar in many ways. The PDSA cycle (Plan, Do, Study, Act) has a few key pieces that are either absent in most others processes of greatly de-emphasized which is why I prefer it (A3 is my second favorite).

The PDSA cycle is a learning cycle based on experiments. When using the PDSA cycle, it is important to predict the results. This is important for several reasons but most notably due to an understanding of the theory of knowledge. We will learn much more if we write down our prediction. Otherwise we often just think (after the fact); yeah that is pretty much what I expected (even if it wasn’t). Also we often fail to think specifically enough at the start to even have a prediction. Forcing yourself to make a prediction gets you to think more carefully up front and can help you set better experiments.

PDSA Improvement cycle graphic from my book – Management Matters

An organization using PDSA well will turn the PDSA cycle several times on any topic and do so quickly. In a 3 month period turning it 5 times might be good. Often those organizations that struggle will only turn it once (if they are lucky and even reach the study stage). The biggest reason for effective PDSA cycles taking a bit longer is wanting more data than 2 weeks provides. Still it is better to turn it several times will less data – allowing yourself to learn and adjust than taking one long turn.

The plan stage may well take 80% (or even more) of the effort on the first turn of the PDSA cycle in a new series. The do stage may well take 80% of of the time (when you look at the whole process, multiple turns through the PDSA cycle) – it usually doesn’t take much effort (to just collect a bit of extra data) but it may take time for that data to be ready to collect. In the 2nd, 3rd… turns of the PDSA cycle the Plan stage often takes very little time. Basically you are just adjusting a bit from the first time and then moving forward to gather more data. Occasionally you may learn you missed some very important ideas up front; then the plan stage may again take some time (normally if you radically change your plans).

Remember to think of Do as doing-the-experiment. If you are “doing” a bunch of work (not running an experiment and collecting data) that probably isn’t “do” in the PDSA sense.

Continue reading →