Skip to main content

Toyo...duh!

Last week's blog entry seemed to resonate with the precious few readers that I have. In addition to the lone comment that was posted, I received a number of emails that said how "spot on" the message was.

To re-emphasize the need to take responsibility for one's actions, it should be noted that there is now a shareholder lawsuit that has been filed. In the article on MSNBC.com, it was reported that this is a response to the recalls and the seemingly deliberate, misstated reasons for the safety issues in the first place. To put it another way, Toyota is accused of knowing full well that the reasons they initially gave for the cause of the problem were nowhere near what they were saying internally. To quote the article:

"...top Toyota executives have known for nearly a decade that faulty electronic throttle controls caused vehicles to sometimes careen wildly out of control but covered it up to protect the company's reputation for safety — and its stock price."

This lawsuit should not be a surprise to anyone unless you've had your head in the sand during the past month or so. Reading the hemming and hawing by Toyota to the American public and Congress quickly left me with the impression that either they were hiding something or were incompetent. But you don't have the top selling mid-sized sedan for 8 years if you're incompetent so you do the math.

If you're Toyota, it's easy to understand why you would want to hide the scope of the problem. But in the end you have a moral obligation to do what's right, namely: a) disclose everything that you know and b) devote every possible resource to the task of figuring out the problem. Apologizing for not doing this after the fact does not resurrect the San Diego Patrol Officer whose Lexus accelerated on its own and eventually killed him and three family members.

Instead, they fret and fear about public reaction if their weaknesses were made public. And they aren't alone either. This past week, a Chinese graduate student in Engineering found out he's a target in the scope of Congress. His offense? He published a paper that discussed the vulnerabilities of the American electrical infrastructure and how a terrorist could possibly take out the entire electric grid for the U.S.

Here's a hint to Congress: if you're so damned worried about publications that describe infrastructure vulnerabilities then fix the vulnerabilities so that there is no risk in the first place. Let's take some of the bank bailout money and put it to good use instead of allowing the larger financial institutions to take a slap on the wrist without actually affecting the standard of living of their highest officers. Alan Greenspan noted this (the link goes to the NY Times article reporting on his recently released 48-page analysis on the financial meltdown) when he said the following:

"To be sure, the senior officers of Bear Stearns and Lehman Brothers lost hundreds of millions of dollars from the collapse of their stocks...But none to my knowledge filed for personal bankruptcy and their remaining wealth allowed them to maintain much of their previous standards of living."

If you aren't going to use TARP to fix the vulnerabilities in the financial system, use it to fix them in the electrical infrastructure. (Or maybe we should address the continued gouging of the American public by the oil companies. Don't even get me started on that topic...)

And if you do fix the big problems looming in a variety of areas, be sure they are fixed instead of deluding yourself into thinking the problem will go away simply because you click your heels together three times while repeating, "There's no place like home." Stock traders seem to be doing this right now by saying that
, "steadying home prices are good enough for now."

Wake up people. You're starting to sound like Mary Meeker during the Dot Com bubble in the late 90's. Home prices are not good enough for now. They aren't even close and won't be until the backlog of foreclosures that have been intentionally stalled by the banks themselves gets cleared.

Let's recap, then: be upfront about what you know; fix the problems; and then be sure they are fixed before declaring victory. Toyota is finally learning this lesson the hard way. Maybe, then, we can avoid looking like idiots (as I reported last week) for simply observing the errors of others instead of looking at ourselves in the mirror to ensure that we aren't guilty of the same problems.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ