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

Creating Web Sites That are Reliable from a Usability Perspective

Comments on: Applying Kaizen to My Various Websites, Trying to practice what I preach...

Good job actually practicing what we recommend others do (kaizen, customer focus...). More management consultants need to do so. I found another thing I think can be improved, this screenshot shows how a floating box (to the left of the screen) blocks the main content:

That covering box moves as you scroll the page so it is always covering part of the content.

[Update: further testing showed this was a temporary glitch - it didn't replicate even on my machine. See comments on the original post for more details. Browsers are not perfect in executing code that is meant to be on the page, sometimes it doesn't quite download everything right, or it misses one action (such as onmouseout) and then behaves oddly...]

One of the big problems I see for web sites development is a failure to understand and test how a wide variety of users will experience a webs site. Often they are designed to look nice for the conditions that the designer has (perhaps huge screen, perhaps low latency, which can mask code issues for users that have high latency internet connections) and that they share with those who approve designs.

It is one thing, for a blog from 1 person to have less than ideal usability for a wide variety of user views. I can completely understand that. Granted I do believe those of us that encourage others to continual improve also need to do that ourselves. What I can't accept is how many web site with huge budgets have very poor coding that results in many users (given the very large user base) have to suffer from bad usability issues.

Those big budget sites should know better than to code in a way that fails to value basic web concepts such as the extremely wide variation in how users will view the web site (screen size, operating system, browser, window size, font size preferences of the user...).

We have an epidemic of bad coding practices that result in failures which then are excused by those responsible as edge cases. Good coding practices would avoid the errors. But instead we code using needlessly complex and error prone ways and then say that we can't deal with the edge cases that only impact a few people. The problem isn't that those few people are requesting some special feature. The problem is the practices used are creating solutions that look nice for some subset of cases but that are not acceptable for other users. Coding with the entire user base in mind from the start would avoid any need to treat those "edge cases" that were only made into edge cases because the coding solutions are not designed for the entire spread of variation in users needs.

The most cost effective and reliable way to deal with this is often to just avoid extra complexity. Having the popup box with additional content can be cool and it can be coded in ways that don't create the issue I see here. But to do that in a way that doesn't create bad usability for some users is complex. Sometimes you can rely on fancy Wordpress themes that have properly dealt with all those complexities. But in my experience, that is very rare. They do ok with a large set of the users but create really bad usability issues for users that don't fit what they considered the normal use case (and created "edge cases" that have bad usability). Or if you are a big budget site you can try to code all the extra complexity yourself. That can be done successfully but I find it fails often. They create fragile systems to deliver and then are overwhelmed at how to deal with all the users that don't fit their expectations for users and they just decide to let those users suffer.

I run across these bad usability practices on big budget website every single week. It isn't some rare poor practice, it is epidemic. It is similar to USA manufacturing practices in 1980: poor practices are so widespread that everyone thinks such poor practices are acceptable. Hopefully this epidemic can be replaced by much better practices fairly soon.

Related: Use Urls – Don’t Use Click x, Then Click y, Then Click z Instructions - Functional Websites are Normally Far Superior to Apps - Bad iTunes Usability and How to Submit a Podcast to iTunes - Usability, Customer Focus and Internet Travel Search - Making Life Difficult for Customers - Designing In Errors

Building a System to Reduce Interruptions for Software Developers

I feel strongly about the damage done by interruption to maker's focus. My appreciation for this damage to system performance was greatly enhanced as I became a software developer.

In my work prior to software development I could see that interruptions were not ideal but they were not so damaging to my work and they do also have value. But work that requires extra focus, and software development sure did for me, the damage increasing greatly.

Over 20 years ago at the Madison Area Quality Improvement Network they had a simple visual management sign at everyones office and cube. You could dial between various settings - GREEN available (free to interrupt)... RED busy, don't interrupt... There were 3 to 5 settings. It worked very well for them.

Of course such a system is highly dependent on the overall management system. Just putting that up in most offices would likely fail. MAQIN was an organization that embodied modern management practices (Deming, lean, respect for people, organization as system, etc.). It worked very well for them.

When building a software development team I tried to protect developers from interruption while having very open communication between developers and program managers (product owners). As is often the case, the real roles didn't line up exactly. In our organization, the people that needed us to develop software (to varying levels) didn't want to take on the responsibilities that agile would suggest (setting priorities etc.). Nor did the that organization want to deal with the conflicting priorities of the various people in their organization had for software development. As part of making things work, I took on a bit of the priority setting roles.

One of the things I did was explain to those that had us do software development was why it was critical to allow software developers to have uninterrupted time to focus. I shared various articles and reports over time and would talk about this as I interacted with them. I encouraged people to talk to me first (at that time I had transitioned from developer/software-development-program-manager to nearly entirely a program manager role).

We also had weekly meetings (when it made sense) with the "product owners", me and the developers working on the software. We scheduled additional meetings when necessary.

I also encouraged people to use email when possible to just check on things, ask simple questions, ask to meet. Again I explained how just going up to talk to the developer could impose significantly higher costs to them being able to focus of their work than there were for interrupting my work or others that had work that could more easily be interrupted with lower consequences.

When there were very important deadlines I would increase these instructions not to interrupt the software developers. And I would talk to the developers about how things were going and if the developers wanted help pushing back a bit I would then do so - mainly by trying to work on the system (provide a set time to allow needed discussions, coach the "product owners" on the difficulty caused by interruptions etc.).

As you might expect this worked better with some people than others. It made a significant difference though. And in our organization it was actually a bit less effective because the software developers were all so nice. They could say how interruptions damaged what they could do systemically but were always super friendly whenever they were interrupted. I was by far the most willing to actually disappoint people face to face in the name of improving overall performance.

It is very hard to overestimate the systemic nature of all of this. By delivering great results we were able to reinforce that if we followed the modified Deming/agile methods we were using were important. Those needing work from us ranged from very skeptical to accepting of those ideas but our performance (both in meeting their desires for software and for interpersonal interactions) made them willing to go along with the methods we said were important.

Related: Deming and Software Development - Mistake Proofing Deployment of Software Code - Creating a Culture that Values Continual Improvement

The Value of Putting Pen to Paper

Comments on Learning by Writing… by Hand

The psychology behind the learning advantage of handwriting is starting to be understood... [Carol Holstead] "It turned out my theory was right and now is supported by research. A study published last year in Psychological Science showed that students who write out notes longhand remember conceptual information better than those who take notes on a computer."

I am also a fan of technology. And also a fan of learning and paying attention to research. Pen on paper has advantages for learning that technology has yet to equal. At the same time technology has many advantages also.

We seem to understand the advantages of using technology fairly well but under-appreciate the advantages of pen on paper. To make sure we don't lose out due to this bias we should think before we accept that pen on paper isn't worthwhile.

From a post I wrote in 2005, Measurement and Data Collection

I believe, it is better to focus on less data, really focus on it. My father, Bill Hunter, and Brain Joiner, believed in the value of actually plotting the data yourself by hand. In this day and age that is almost never done (especially in an office environment). I think doing so does add value. For one thing, it makes you select the vital few important measures to your job.

Lots of data will be kept in computers and that makes sense. But putting pen to paper has value that we too quickly dismiss.

Related: Experience Teaches Nothing Without Theory - The Illusion of Knowledge - Write it Down to Improve Learning (Ackoff)

Replying to Tweets Usefully

My response to: How can I reach out to Twitter users who have an immediate need for my services? I can see local tweets from great prospects but a reply would be spam.

I do not agree replies would automatically be spam.

I suggest you provide links to useful information. If you have a blog or web site that provides useful information that can also share that your services may be of value.

Certainly responding could be done in a spamming way. And that should not be done. But you can respond by being helpful. And rely on some of those seeing that you provide useful information wanting to learn more.

A measure of if you are providing useful replies see how often it is retweeted. I am very surprised how often mine are. I would guess it is over 50% of the time that I (@curiouscat_com) suggest a link would be useful they retweet it.

When I just send a reply without a link they are retweeted rarely. Also when I just post links to useful stuff I find those are retweeted much less often than my direct replies (I imagine if you have tens of thousands of active readers, not just "followers," this data would be less useful because everything you tweet someone retweets...

Another measure would be if people reply by saying you are sending them spam or wasting their time, etc. I have had 0 of these.

The combination of these results has led me to offer suggested links more often. I was nervous at first about people seeing it as spam. 90% of them are links to my blogs because those blog posts are what I know well enough to link so often (I also suggest other articles, blogs or products but less often).

Related: Your Online Presence and Social Networks for Managers - The Benefits of Blogging - Networking is Valuable But Difficult to Quantify

The Tendency for Lean Experts to Distrust Technology

My thoughts on Why can't we use technology to accelerate Lean adoption across my company? [the broken link was removed]

I think biggest objection is how often and badly technology efforts fail. This makes a knee jerk reaction against jumping to technology fairly wise.

I think the second reason is technology expertise is often not found in the same people that have lean expertise (it can be it just isn't super common). Combined that with number 1 and the fact that making technology projects successful requires great system (rare) or can be made more likely with a deep understanding of technology and management systems (but I just said they often don't have the tech expertise) so again a reason to shy away from tech.

If a good lean consultant saw the organization had great system for making technology projects, countermeasures etc. successful they would support such efforts even if they were weak on tech. I'll also say most lean consultants aren't great. They don't understand lots of stuff about respect for people, management systems, customer focus, gemba etc.. Due to fear I think many that don't have strong lean understanding will shy away from technology.

I think technology solutions can be great. There is nothing wrong with them, when conditions are right. Conditions are almost never even decent - forget right. Technology projects and efforts are much more likely to be messed up due to bad systems and lack of expertise.

Technology solutions can have huge impacts - there are many good things possible with technology. The problem is so often technology wielded inside organizations (human systems) fail for many reasons very closely tied to bad management practices. The better the management practices the less likely technology will backfire in my opinion. The stronger the management system the more likely technology projects will be managed sensible, tested at the gemba, adjusted by people with a strong understanding of the gemba, project managed by people with an understanding of lean thinking practices (deliver working code fast etc.)...

The fear of technology projects is those reasons and more. Things like the same problem with brain-dead implementations shoving down a horribly inflexible ERP program or shoving down a 10% across the board budget cut and many other such efforts. Technology efforts really are no different than others but there are some difficulty in the problems of technology often being more difficult for people to see.

Technology also is often seen as this wonderful simple quick fix by executives - letting them avoid the gemba and just put hope in a essentially magic bullet solution.

The whole effort to make problems visible is much less likely to be done well around technology (which has to do with some issues with the domain but also with the lack of technology expertise [especially software development] of management and decision makers). Lots of the efforts in lean software development and agile have very good practices for technology efforts.

Related: Deming and Software Development - Involve IT Staff in Business Process Improvement - Mistake Proofing Deployment of Software Code

Email Isn't the Problem

"Email is a tyrant. Combined with Personal Kanban, it can be a great way to receive work." [the broken link was removed] - Jim Benson

I find there are plenty of times when email is a great tool (for example: providing background material in advance of discussions). Yes, often email is misused and there are plenty of bad processes around email. But it isn't very sensible to say we shouldn't use a hammer (email) because when we use it to cut paper it isn't very useful. We shouldn't misuse a tool; that doesn't mean we shouldn't use the tool properly.

Yes, fix the problems with how emails is used and how you integrate email into your daily work etc. But I think way too often people think email (the "tool") is the problem when I rarely see it that way.

Killing Email Interruptions: Personal Kanban using LeanKit, Gmail, and Zapier [the broken link was removed] provides details on a way to manage the process of dealing with email.

Related: Process Thinking, Process Email Addresses - Effective Communication is Explicit

Hopefully Other Countries Will Save Us From USA's Attempt to Sell Us Out to Aid Big Political Donors

The Trans-Pacific Partnership has been atrocious.  Essentially the USA has been strong arming other countries into secretly selling out their citizens to provide benefits to large USA political donors.  The Obama administration has once again done the opposite of being the open and honest organization candidate Obama promised.

The hopes of stopping the corruption of the USA political system, in this case, wrests with other countries protecting their citizens (and the citizen's of the USA from the corrupt practices.  Vice President Bidden seems particularly focused on paying off his donors and friends with this horrible treaty.  The USA administration realizes the selling out the innovators and rights of citizens for large political donors is so toxic it would likely not survive if there was the transparent government candidate Obama promised.

The TPP should be stopped.  I would not trust politicians that don't speak out against it publicly now.  Politicians have become adept at hiding what they promote behind secrecy and misdirection.  Many are hoping they can hide behind the secrecy around the trampling of innovators and citizens in the TPP to pay off their donors while claiming the appose the horrible policies of the TPP.  If they are not speaking out now, all they are doing is taking advantage of the secrecy the Obama administration has made its policy for trying to hide government action that harms the country from public view.

The Trans-Pacific Partnership being pushed by Washington is nothing more than a corporatist power grab by William Pesek.

American lawmakers and civil liberties groups have complained for some time about the opacity surrounding the treaty's terms. Mild grousing turned into outrage last month after WikiLeaks did what Barack Obama's White House refuses to: share portions of the document with the public. The draft of the intellectual property rights chapter by Julian Assange's outfit validated the worst fears - that TPP is a corporatist power grab.

Rather than heed the outcry, the US doubled down on secrecy, refusing to disclose more details.

Hasn't the US wondered why so many of east Asia's most promising democracies have avoided the treaty? The popular excuse for why Indonesia, the Philippines, South Korea, Taiwan and Thailand aren't among the 12 TPP economies is that they aren't ready or are trapped by their own timidity. A better explanation is that their leaders realise that truly transparent and accountable governments, to borrow Kerry's own words, shouldn't be leading their people into the unknown.

The root cause of this situation is the corrupt USA political system. At a bit less abstract level the TPP seeks to worsen the deadly diseases of the broken patent and copyright system (and also worsen the broken health care system). The TPP is an attempt by those that understand systems thinking to mold the system in secrecy to benefit those giving USA politicians lots of cash. We can only hope that other countries are not willing to do the bidding of the USA in this case (though the USA is willing to provide incentives and threats to allow it to deliver for those giving USA politicians cash).

Related: Intellectual Property Rights and Innovation - The People We Elect Recently Are Dramatically Falling Us - Cash for Votes subreddit (political corruption) - Why Copyright Extention is a Very Bad Idea

Providing background material in advance of discussions

One place I see for improvement is an actual underuse of email. In meetings when lots of data is provided on some issue, that normally would be better handled by an email in advance (or could be some reporting system or whatever - but an email to look at urls of certain data...) to let people review the data.

Also preceding an urgent face-to-face, cell phone... with background info is often more helpful than trying to talk about stuff that is best digested by someone sitting and thinking. When on the phone or in the presence of others we often have a tendency to need to feel the space with noise/talking and deep thought is not likely, unless you already have deep thoughts on the topic and are just thinking of how to tweak those based on comments.

I see a systemic failure to provide background material in advance of discussions in many organizations.

Posted in response to How can you bring standard work to communication [removed broken link]?

Related: Process Thinking: Process Email Addresses - Better Meetings - Effective Communication is Explicit

Lean Thinking Aids Innovation Even if Poor Management Labeling Itself Lean Doesn't

Response to LinkedIn discussion asking if lean and innovation can co-exist (closed access and I don't think LinkedIn understands how urls work anyway so links wouldn't help):

I would say we too often criticize lean based on very poor applications called "lean." Studying Toyota is what gave us the name lean. Toyota has significant investments over the very long term in robotics; they innovated to create the Prius (and still dominate the hybrid market) and invest in research on things including home building, biotechnology and a thought controlled wheel chair.

It isn't lean thinking that is the problem with long term thinking. It is normally other bad practices (having nothing to do with lean) that create these problems. Sure plenty of places saying they are doing lean also have stupid practices like cost centers, short term ROI needed on everything, MBO... None of those are lean.

Innovation and lean can work great together, as can other measures to improve the performance of systems (in this case systems around innovation). Innovation comes from those close to the process and those outside the system. It isn't limited to one or the other. 

Yes, lean thinking can be applied to new situations with specific adjustments. Lean software ideas take lean thinking and provide some common practices that are often useful for those involved in software development. Toyota was definitely a follower in applying lean thinking to software development not a leader. Which shows even a company doing as many things right, as Toyota does, has plenty of room for improvement.

What is a Project Manager?

Response to What is a project manager?

Often PM role is to cope with weaknesses in the current management system.  While you might say just fixing the system is better I think that is often unrealistic.

I see the PM as someone shepherding the project which often means

  1) making sure the pieces proceed properly to meet deadlines (making sure they, or whoever should, make decisions on what to do if things need to be done).  I see the PM often making sure it happens but if the system has a good method that is working fine the PM just watches that.  So if there is good agile software development, the process is working and things are done in order no big surprises sitting around… then fine the PM doesn't have to worry.

   2) dealing with institutional issues so others can focus on doing their jobs.  If the software developers are frustrated with whatever phb action, the PM takes care of it somehow…  That kind of stuff.

   3) improving the system - again this is best done by setting up the system so others can.  This is a bit outside of the scope of the existing project.  The PM (to me) is also responsible for making the system for delivering projects good.  If something new is needed, look at putting it in place.  Develop people as part of this.  Again if management is doing their job this is happening.  Often management isn't though, then I think the PM should.  This is stepping a bit far from what most everyone else thinks though.

  4) coaching people and arranging coaching.  This is probably more for #3 than for meeting the current project needs, but it is also to meet the current project needs.

  5) protect people from blame and give people credit.  Again this is often just dealing with poor current management systems.  Blaming people is ineffective.  If there are failures figure out what is wrong with the system and improve.  When people are trying to blame others (which happens a lot) don't let that be done and instead focus the thoughts on how to improve.  In organizations where business managers run roughshod over others (developers, testers…) don't let them.  In that case communication goes through PM.  If the communication is good then it is better for the developers to communicate directly…

I see communication as part of #1.  It is important.  It becomes even more important as the organization fails at it.  That is often my view the PM is to see where there is weakness and deal with it.  Maybe it means getting more resources.  Maybe it is assuring better test coverage is included.  Maybe it means arguing this project needs to be scoped way down as it isn't a priority given the business needs…  This requires knowledge of the organization, business thinking, software development (for software projects) practices, coaching...

My whole way of think is very Deming based.  So I see improving the system as a big part of everyones role.  It isn't surprising I see it that way for a PM too.

To me the main PM roles are

 #1 manage the existing system to achieve the result for the project
 #2 improve the existing system

Always-On: Trivial Urgency

I think the problem is in expectations of responsiveness. People focus on the trivial "urgent" instead of the important, as Covey said.

One of the issues I have with the complaints of "always on" is looking at my father. He was always on for his whole life and had no downside. He loved what he did. He thought about it when he was taking a shower, or walking to work or having friends over for dinner or raking leaves in the yard. It never was a matter of being burdened by work. He was a professor and consultant. I think it is a mistake to see the problem as always being on. Expectations of responsiveness to thee trivial urgent though I can see as a problem.

I think there is a difference between being also on and energized by your work (that is pretty much how I am, and my father was - I am working for myself, I can work whenever I want) and feeling burdened by being expected to be always on.

The problem is I keep reading about how thinking about work all the time is horrible for people. Well in my experience that isn't true (granted it is a small set of people). But it points to, I think, an issue that the "problem" is imprecisely defined and therefore inaccurate. I do think there is an issue expecting people to be available for trivially urgent matters.

Related: Carve Out Time to Think - Circle of Influence

Quick Mistake Proofing Ideas for Preventing Date Entry Error

I found a new failure mode for online bill pay. I had an electric bill due April 24. I mistakenly entered May 23 as the pay date 

So, by April 30, I had a late payment termination notice from the electric company. Kudos to them for the fast cycle time on getting those out. I paid the bill via credit card on their website. 

I’m not sure how to error proof “wrong date.” You?

It is easy to put in a filter that checks and then puts a big flash message:

  “The date you entered is after the due date. Are you sure you don’t want to put in a date prior to that...”

You can also make the data entry bias toward a on-time payment: require an extra step to go beyond the due date, default the value to be the due date... How you implement this would depend on the entry method.

It is really easy to do well if you are using calendar point and click – grey out all the post due date entries, if click on a greyed out entry, pop-up a message that says “that date is after the due date are you sure...” It gets less effective/cool if it is just text entry...

Even with text entry thought you can popup the message on submit of the form if the date is too late (so they enter the wrong date but you catch it before the action is completed).

You can also follow up with (using this method alone is better than nothing but it is pretty lame so I wouldn’t suggest it as the only method unless nothing else can be done reasonably) email saying “you entered a date after the due date in your last bill payment, if you don’t pay before that late fee…

Anyone what to hire me for a few minutes at a time to think of ways to make it harder to make an error just let me know. I don’t like processes that allow errors so have become fairly good and thinking up ways to make it harder pretty quickly :-)

Related: Mistake Proofing Deployment of Software Code - Improving Software Development with Automated Tests - Poka-Yoke Assembly

Customer Focus is Central to Lean Thinking

Agile UX vs Lean UX – How they’re different and why it matters for UX designers by Anders Ramsay

Good design is good design, regardless of if we are living in an Agile or Lean or [insert new term] universe. The only real difference when adopting these methods is in the How.
...
So, while there certainly is a lot that UX designers can learn from Agile thinking on software delivery (such as to automate everything that can be automated), the real pay-off for UX practitioners is in the collaboration part.
...
Lean UX, on the other hand, is really a reference to Lean Startup a la Eric Ries (and Steve Blank, basically the godfather of Lean Startup, and creator of concepts like Customer Development and GOOBing), which extends Agile ideas to include methods for ensuring that there in fact is a market for the product you are doing such a good job designing and shipping early and often.

Lean is also very concerned with customer value. From that perspective usability is directly relevant and fits perfectly in the lean context. Lean focused on the ideas of usability for customers in the world of physical products. Usability of software fits with this perfectly.

The focus of reducing waste in lean context is to look at the "value stream" and eliminate what doesn't add value to the customer. The primacy of user is there (though some applying lean don't understand this).

Dr. Deming said the customer is the most important part of the production line. He understood the customer (end user) had to be the focus of your efforts to improve. Toyota took Deming's ideas and created the Toyota Production System (Shoichiro Toyoda, Honorary Chairman and director of Toyota: "There is not a day I don't think about what Dr. Deming meant to us. Deming is the core of our management.". Lean manufacturing is the name given to the practices of Toyota as Jim Womack and Dan Jones as they researched the company (and wrote The Machine That Changed the World.

Avoid Bad Technology Non-Solutions Using Agile and PDSA

Automation is Not Always the Answer, in Retail or Healthcare

I’m not anti-technology. I just believe strongly in the “Toyota Way” principle that states: “Use Only Reliable, Thoroughly Tested Technology That Serves Your People and Processes”

Very good post. I am a big proponent of technology. My career path was basically from helping management improve organizational performance to IT program manager doing that same thing. I did that because there were so many opportunities to improve using technology.

But there are big problems. Many technology solutions are lousy. If people applied PDSA thinking they would be much better off. agile software development does this to a reasonable degree (I think they could do more in that vein but it is decent now). A big reason I moved into technology myself was because getting IT solutions implemented properly (even half way decently) was nearly impossible. And this is true all over.

If you use PDSA, systems thinking (Deming's view not computer systems) and agile software development methods you will avoid the all too common technology messes and instead take advantage of technology. You also need people that have the right skills and knowledge - knowing how to use technology properly seems to be less common that you would think given all the technology around us.

Related: Involve IT Staff in Business Process Improvement - Information Technology and Business Process Support

Zipcar: Systems Improvement

Zipcar Customer Experience: Variability, Utilization, and Queueing

Late returning of cars appears to be a problem and long-standing theme with Zipcar. In fact, for late returning cars, the customer is charged a substantial late fee of $50. With such a high late fee rate, one can only surmise that late returning cars is a large enough of a problem and Zipcar’s response to this is to change the behavior with a large penalty.

Good stuff. Without knowing the situation (myself) couldn't a high late fee be the solution? The high late fee makes those renting cars very likely to return them on time to avoid the fee. It isn't clear if you have data that the high late fee is just a penalty that doesn't make the system perform better or not (to me reading this anyway). I agree, I think zipcar is an interesting innovation. It would seem to me real time (internet enabled communication) would help a great deal - notify of bottleneck, report cars needing service, tell user that car is late but these 5 nearby location have a car... Some of this is just trying to make the problem have a lessor negative impact.

I really like innovative ideas like zipcar especially that find solutions that are more efficient. Zipcars can reduce the waste of cars sitting around unused in millions of driveways.

Related: Zipcar Innovation (2008) - Traffic Congestion and a Non-Solution - Customer Focus and Internet Travel Search

Stop Letting Technical People Get Away With Social Ineptitude

Stop Letting Technical People Get Away With Social Ineptitude

it’s often believed to be true because there are so many engineers and technical personnel with poor people skills. I never have seen statistics to support the notion that the ratio is higher in these professions than in others, yet employers often find that people filling these roles with poor people skills are still employable. This needs to stop.
I’m of the opinion that every position is customer-facing.

It seems fine to me to wish everyone you hire is strong at every aspect of work. I think it is a bit unrealistic but maybe my standards are too low (this is the opposite of what most people find who know me though). It seems to me people that are very skilled (have skills that are not easily found) have leeway to do poorly in other areas and still be a net gain to the employer. This is true for divas, athletes and technical people. There are lots of technical people that are great working with people. My experience though, is you often have trouble finding only them for every single technical job (though I am sure the more demand there is for working at your organization the more possible it becomes).

My belief is most technical people could be better in this way if they wanted to. They just can get away without and so do. yeah it isn’t great, but the real world often has things that are not as the “should be.” If you want to work at Trader Joe’s and want to be anti-social they can just move on to the next person and find plenty of people that are great with people and have all the skills they need.

One thing that comes into play also is the desire of technical people (and academics) to challenge ideas and pick at weaknesses. This is a very beneficial trait. Some people can’t distinguish criticism of ideas and being mean to people. It is not wise to set a standard where people taking offense to ideas being criticized is protected over sensible critical discussion of ideas.

I do agree with your mindset, I just think a bit more flexibility may be warranted. I would agree the corporate culture should be one that expects and coaches everyone to customer friendly and that works well with others.

Related: Understanding How to Manage Geeks - Respect People by Creating a Climate for Joy in Work - Respect for People – Understanding Psychology - The Manager FAQ

Google's Fight to Keep Talent

Google and Pay Raises: Turns Out, She's a Lot Like You.... (the broken link was removed)

Google attempted to do what your company either 1) has done, or 2) would do if you had the means:

1. You would try and buy your way out of a retention problem by giving everyone an across the board raise. Turnover is hard to figure out and stop. Sometimes you just have to throw money at everyone and hope that the turnover stops. It rarely does.

Google is managing people, just like every other organization, so you would expect lots of stuff would be the same. I don't actually recall other companies giving everybody a 10% raise (Google probably has more money than your company). I agree, that this is not likely to do much to turnover.

The possible impact in Google's favor is forcing others to pay so much that they can't afford to do so, and shrink or even go bankrupt. Especially small organizations. Yes they will use options, but salary is also part of the requirement.

I think also, anyone taking away that Google's other moves don't matter is making a huge mistake. Google's moves to create a great culture, let people work with other great people is helping Google. The draws of leaving for so many great people are high. If Google were to be less proactive in other areas the problems retaining people would be much harder. Some people seem to take the idea that people are leaving Google as a condemnation of their tactics. I think that is the wrong thing to take away.

Related: Google's Answer to Filling Jobs Is an Algorithm - Google's Innovative Use of Economics

IT should focus improving the system

IT should focus on doing its part to improve the system (in systems thinking terms) of the organization. In the short run a big part of that is likely in improving process type activity, supporting others in doing their jobs. There also should likely be a role for building the capacity of the organization. Information technology is critical to long term success. Most organizations today do not have the knowledge they should have in management ranks, and elsewhere. IT should be working on that in various ways. One way is by helping people find and use good technology solutions today (this not only can improve results today but builds the capacity of the organization to further exploit technology going forward).
Here are posts on my blog about IT and management

IT should help build sales by providing good tools to those in the organization and by providing good tools to customers and potential customers. Make it easy to buy. Make it easy to find what you might want to buy. Make it easy for those in the organization to learn what customers might want (mine what they are searching for, where they seem to abandon the web site...).

Re: Where Should IT Focus?