The VW Scandal as a Cautionary Tale – Cultivating Fear Always Ends Badly

culture of fear

For those who might have been taking a long vacation from reality, Volkswagen recently became embroiled in a scandal regarding some of its cars with diesel engines. It seems that when these cars where tested for emissions, a “defeat device” (a software program), would detect that the cars were being tested and change the performance accordingly. This led to claims that their diesel cars were better for the environment than their competitors. In all there appears that over 500,000 of these “clean diesel” cars are currently on the road, mostly in the United States.

vw emissions testShortly after this scandal broke, the finger pointing began. Under pressure from a United States House of Representatives Oversight and Investigations panel, Michael Horn, Volkswagen’s United States Head, stated, “This was a couple of software engineers who put this in for whatever reason.” While I find it very disingenuous and slimy to through your software developers “under the bus”, albeit one with flowers and the smell of Patchouli oil, the question that remains, assuming Horn was not involved, is why would these “rogue” developers decide to create something like a “defeat device” in the first place?

When I first heard of the “rogue” developer explanation, I realized there are two possible reasons – the developers do not care about their work or the developers acted out of fear for their jobs (or both). In either case the root cause is that there is a culture that discourages employee disengagement and fear. This means that while Mr. Horn might be accurate that it was “rogue” developers who are responsible for the act of creating the malicious software, the responsibility for corporate culture rests squarely with leadership. Since Horn was the top leader then he bears the brunt of the responsibility for the culture that would allow/coerce developers to make such a disastrous decision, one that could cost VW billions.

vw diesel engineThat is not to say that the developers who made the changes should be held blameless, but it is not unusual for corporate culture to treat developers more like minions than the professionals that they are, shielding them from making decisions we would expect respected professionals to make. Fear for their very jobs, while puzzling in an environment where good developers can pick and choose, was most likely the final calculation that allowed the developers to write this malicious code. And not only developers, but where was the Quality Assurance during this process? Again, it is poor culture that allows such misdeeds to flourish.

My educated guess received some support in a recent column in Road and Track by Bob Lutz, a former Genera Motors executive. Lutz placed the blame for the recent scandal directly on the shoulders of ex-Chairman Ferdinand Piech. Lutz stated that Piech’s tenure was distinguished by a style of leadership which was “a reign of terror and a culture where performance was driven by fear and intimidation.” Lutz described one exchange with Piech regarding the body fits of the new VW Golf where Piech bragged about his “recipe” for better body fits.

“I called all the body engineers, stamping people, manufacturing, and executives into my conference room. And I said, ‘I am tired of all these lousy body fits. You have six weeks to achieve world-class body fits. I have all your names. If we do not have good body fits in six weeks, I will replace all of you. Thank you for your time today.”

While this leadership style might work from time to time, it is motivational junk food. It creates a toxic culture where the long-term effects will one day negatively manifest themselves, in this case, with “defeat devices.”

Studies have shown that only about 30% of US workers are engaged in their work. That fact, along with dozens of years of experience, have led me to believe a huge percentage of companies use fear as their primary means of motivation. My advice to leaders is to pay attention to the VW scandal and heed its warning. You will most certainly reap what you sow, karma will catch up with you and cultivating fear will always end badly.

You Say You Want to Change the World?

Eye on World

Do you really want to sell sugar water, or do you want to come with me and change the world?

—Steve Jobs, recruiting John Sculley to become Apple CEO, 1983

We’re here to put a dent in the universe. Otherwise why else even be here?

—Steve Jobs

Changing the world. That’s some pretty heady stuff. I’d like to think we all want to change the world, to put our own dent in the universe. I know that when I talk about my work with SIS and 10XP Solutions I frequently mention that my goal is to change the world of staffing and change the world of software development. Both of these are laudable goals, but this merely begs the question, how does one go about changing the world?

The answer is deceptively simple, but, like so many things in life, it is hiding in plain sight. The problem is that most of us fail to approach the problem correctly. We believe that if we are to change the world that we have to perform some action on the world itself – we need to create something that didn’t exist, we need to convince someone of something new – but this is the wrong place to begin. If we wish to change the world, we must first change the way we view the world.

World SculptureThe world only exists as we perceive it. This perception exists regardless of whether there is (or isn’t) an objective reality. Of course, we should try to passionately and unwaveringly pursue objective reality, but we should always acknowledge that our view of reality might not be correct and the way we behave, as a result of our perception, might not be optimal. Therefore, when contemplating the qualities that will allow us to be the leaders that change the world, we must never forget humility or curiosity. Our world will never change until we allow the freedom for our perception of the world to change.

When we look at those things that we say have changed the world, what, in fact, has changed? Is the world really radically different or is it our perception that has changed? I think if we give it any thought at all we would easily conclude that the world really doesn’t change much, but when new things, whether products or ideas, come our way and these allow us (or force us) to see the world differently, then the world itself has changed.

World in my handThe first step then when we want to change the world is to first change our own world by changing the way we view the world. Once we have changed the world in that manner the next step is to figure out how to lead and convince others that our worldview is the correct one. This is where the advice from my last blog, “You Can Be Right or You Can Be Successful” comes into play. We need to help people see the new world, not because we are right, but because we have made the fundamental mental shift ourselves and find that the new worldview is more successful.

Steve Jobs made monumental changes to the world; he certainly made his dent in the universe. It is my opinion the reason he was successful was because before he changed the world, he changed himself and his view of the world. If we wish to follow in his footsteps and the many others who have changed the world, we need to have the curiosity to keep seeking, the humility to acknowledge that we don’t have all the answers and, once we have seen the world change by the new views we hold, the patience and compassion to lead others to see the world as we now see it.

You Can Be Right or You Can Be Successful

success

I recently had lunch with one of my friends and we spoke about some issues that one of his teams was having. As a new team, they were still in the storming and norming stages and they were having some fairly heated discussions around some philosophical issues of software development. For those not familiar with software development you might think there is not really anything to get all worked up about, in which case you would be surprised at the level of intensity some folks have. The discussions the team was having bordered on “a holy war” and there appeared to be little hope for compromise.

I asked my friend a simple question, “would you rather be right or be successful?” This question is one I like to use and is a variation of the quote “you can be right or you can be happy” which I have, until I did the research for this blog, incorrectly attributed to Dr. Phil McGraw (for those who care, the quote is from Gerald Jampolsky). Basically, there are times when we can be right and we can be happy but often we have to make a choice. The same applies to success at work. There are times when we can have it all, but sometimes we need to choose whether we wish to be right or effective.

Recently there has been an outbreak of measles in the United States due to the fact that some parents have not been vaccinating their children. The reason these parents were not vaccinating was due to false science that has since been refuted. In other words, the truth is unequivocal; vaccines do not cause the reactions that anti-vaccination parents fear. These parents are 100% wrong.

Since these parents are 100% wrong and not vaccinating children can lead to adverse health issues in the community, it makes sense that public health officials would try to change the minds of the “anti-vaxxer” parents. They did try. Their first approach was to try and convince the parents by presenting the scientific facts. They theorized that by knowing the true facts, people would make the correct decisions. That effort failed. It seems that merely presenting facts did not change peoples’ minds.

succes04If presenting facts does not work, public health officials concluded the reason for the resistance was emotional and that emotional arguments would be more effective in convincing parents to vaccinate their children. That effort failed as well. (For a more details analysis see http://web.missouri.edu/~segerti/3830/Pediatrics-2014-Nyhan-e835-42.pdf).

This was surprising. Furthermore, not only are people not convinced by facts or emotion, but that when presented with factual or emotional arguments, the anti-vaxxer parents in the study were LESS likely to vaccinate their children. Evidence suggests that once someone has a strong belief in something, anything (or anyone) contradictory to that belief is seen as a threat. People who are threatened will cease to listen, much like a child will put a finger in their ears. People will erect walls to keep you out.

Knowing this, should we just give in to despair? Of course not. We need to stop trying to be right, whether presenting factual or emotional arguments, and concentrate more on being successful. The question is – what works in convincing people with strong beliefs to change their position? There is something that has been shown to work, something that lowers peoples’ walls and defenses and that thing is listening.

Instead of telling or implying people are wrong, we need to take the time to ask them about their position. We need to stop threatening them. Given the space to explain their position, people will not only feel less threatened, but also they will have to defend their own position and when tasked with defending their own position, people will slowly be able to see that they might not be the experts they think they are. This is where the walls and defenses are lowered so that other arguments might be entertained and listened too. Furthermore, showing respect to individuals and spending time with them will also make it more difficult to not listen. We listen to our friends not our antagonists.

A study of midwives in India found that arguments did not work with them either. What did work was “the rule of seven touches” which marketers know well. You must have meaningful contact and get to know someone (seven touches) before they are willing to trust and listen to you.

succes03This applies to my work of transforming companies from waterfall to agile approach. While I may be 100% correct and it may make me feel good to be right, by presenting my viewpoint as THE way, I will not meet my objective. If I choose to be successful then I must take a different approach. I need to get to know the people involved, understand their concerns, not threaten their ideas, but allow their defenses to be lowered by listening to their ideas and then, and only then, if my ideas are truly right will I have the chance to convince them of or, better yet, guide them to the truth.

In the end you can be right or you can be successful. You can’t always be both.

Technical Debt on the Balance Sheet

Mind the GAAP

My recent article on the high cost of “low cost” software seems to have struck a nerve with lots of views, comments, likes, shares, etc. A lot of software development professionals feel the weight daily of the tendency to chase the lowest price of software development and have added to the conversation I started last week. Below are some of the comments:

There is always a price for “free.”

In the end, it’s all about understanding the nature of software development in order to make wise decisions.

As the saying goes: “if you believe a senior developer is expensive, wait till you hire a Junior”.

Another aspect of poorly written code is the inefficient use of hardware which it runs on … leading to negative user experience .. Resulting in losing $$ in terms of user productivity .. Adding to the higher cost !!

My unscientific guess is corporate America is wasting billions each year on “low cost software “.

It’s funny how there never seems to be enough time to do it right, but always enough time to do it twice.

The technical debt gets worse when you add an army of developers to it.

The old saying “you get what you pay for” rings true.

Perhaps the most interesting comment came from Jason Ross who stated:

It’s often the case that people get “value” and “cost” confused. Technical debt is a very debt that must eventually get serviced. In the same manner that debt service kills cash flow and becomes a drag on the balance sheet, so does technical debt deprive an the ability to deliver new features and effectively update the code base as new technologies arrive that could be leveraged. In the long run, the maintenance and upkeep costs becomes the dominant factors in many things, and especially in software, they are often entirely neglected as factors.

Balance SheetWhen I read his comment and saw his mention of “a drag on the balance sheet” it reminded me of an article I had read a few years back from Israel Gat for his blog The Agile Executive titled Technical Debt on Your Balance Sheet

Israel’s assertion is now that there are ways to rather easily assess technical debt (like SonarQube with SQALE plugin), technical debt could (and should) be added to a company’s balance sheet. I applaud and support his efforts.

Unfortunately, it appears that any efforts to include technical debt on a company balance sheet might run into some accounting industry standards that would make this not currently possible. In his post, Clear Costs and Technical Debt, Trent opines

Accounting standards don’t allow provisions or liabilities to be shown for “not performing enough maintenance” or similar intangibles. There needs to be a present obligation before a liability is incurred and a present obligation is only usually formed through a contract.

In his scenario, financial wizards will chalk up the lower cost of software development as a savings.

The accountants will note a(n)… asset on the books, congratulate themselves for saving … capex and chalk up the increased opex of maintenance as the cost of doing business.

AccountingMy guess is this is precisely what happens now. If Trent is correct, then the issue facing companies developing software is that current accounting practices are inadequate and need to be modified. Technical Debt can be measured and tracked and is a very real liability.

The question remains: can there be a new GAAP around technical debt or can an existing GAAP be instructive? While I am not a CPA, I have done work in accounting in the past so I know “enough to be dangerous.” My line of thought is that technical debt probably resembles something that currently exists in GAAP. After doing some research I think that maybe GAAP around warranties may prove helpful. In reading about warranties in an article GAAP Accounting for Product Recalls. I noticed some similarities:

Product warranties present manufacturers with a bit of a conundrum. …The manufacturer is actually responsible for the product for the length of the warranty. In accrual accounting, the finality of the transaction does not occur until the period of responsibility ends. However, warranties … present a bit of an exception to the rule. (Emphasis mine)

Notice how, like technical debt and the Total Cost of Ownership (TOC) of software, the complete transaction is not final until the period of responsibility ends. I can see that the life cycle of software (and liability of technical debt – present or future) is like the life cycle of a product with a warranty attached. Even I can see how warranties could cause accounting headaches. However,

Rather than being on the hook for the cost of the product for the entire life of the product or throughout the product’s warranty period, manufacturers can instead follow the generally accepted accounting principles regarding products under warranty. … Under GAAP, product warranties and recalls can be reasonably accounted for with the initial sale of the product by estimating the potential warranty expense of a return or recall.

I can reasonable see how it might be possible to substitute an estimate of Technical Debt liability for the similar liability of estimated warranty expense. For example, with each release we classify software as a capital expense (CapEx). At this point we could also include on the balance sheet an estimation of technical debt as a long-term liability.

In the case of warranties, the actual accounting mechanism under GAAP is done by

 …making two separate entries, one a debit and the other a credit for the same amount. These are entered into the ledger as a warranty expense and a separate entry as an allowance for warranty costs.

What is to stop a company for entering two separate entries for technical debt – one a debit as technical debt expense and the other a credit under allowance for technical debt? I certainly see this as in the realm of possibility. This way GAAP can be followed AND technical debt can be raised to true financial visibility. It is this visibility that will allow companies to begin seeing the true total cost and guard against the high cost of “low cost” software development.

Accenture Ends Annual Review (and Admits Earth Orbits the Sun)

planets

Recently I read an article from the Washington Post titled “In big move, Accenture will get rid of annual performance reviews and rankings” which was in a section called “On Leadership”. I like my headline better (though it has probably blown any shot I had to work at Accenture).

To classify this as somehow a bold or “big move”, place it in a section titled “On Leadership” only highlights the complete lack of scientific understanding of what actually works and does not work. This is not leadership, but a damning indictment of the lack of leadership in the workplace. The real issue is this is “big news” and it takes companies so long to not only admit the obvious, but to act on overwhelming scientific evidence suggests some of their unquestioned practices are utterly wrongheaded.

orbitIn the case of annual reviews we have such a wealth of evidence they do not work it is amazing so few companies have actually done away with them. Daniel Pink, in his book Drive, states

…performance reviews are rarely authentic conversations. More often, they are the West’s form of kabuki theatre – highly stylised rituals in which people recite predictable lines in a formulaic way and hope the experience ends very quickly.

Pink’s book has been out for six years now, but it is based on scores of science that was conducted years and decades prior to its publication. We don’t need to look farther than W. Edward Deming, who wrote way back in 1986, in his seminal book “Out of the Crisis”, that annual reviews are “Deadly Disease #3” and

The performance appraisal nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, nourishes rivalry and politics… it leaves people bitter, crushed, bruised, battered, desolate, despondent, dejected, feeling inferior, some even depressed, unfit for work for weeks after receipt of rating, unable to comprehend why they are inferior. It is unfair, as it ascribes to the people in a group differences that may be caused totally by the system that they work in.

whyWhat amazes me most about this annual “kabuki theatre” is everyone intimately involved with the system (managers and front-line employees) literally hates this process. Even if the people at the top of the company bury their heads in the sand when it comes to real, scientific evidence, how can they fail to acknowledge the tidal wave of anecdotal evidence from their own people?

Steve Jobs was once asked how he learned to run a company in his early 20s since he had no formal business training. His answer sheds a great deal of light on why only 6% of fortune 500 companies have gotten rid of annual reviews and rankings though the evidence is overwhelming that they do not work.

You know, throughout the years in business I found something, which was I’d always ask why you do things. And the answers you invariably get are, “Oh, that’s just the way it’s done.” Nobody knows why they do what they do. Nobody thinks about things very deeply in business. – Steve Jobs – The Lost Interview

So, if Jobs was right, as I believe him to be, then a plausible explanation would be that even highly compensated CEOs are unable to properly ask the “why” of things or perhaps top-down control has led to a culture where why is not asked out of fear or complacency. I would guess the CEO of Accenture, since he is quoted in the article, was the decision maker of the “big move.” While he might think himself progressive since he is on the vanguard with respect to his peers, the more appropriate “why” to ask would be “why did it take so long?” and “why haven’t others made the change?” or maybe “which CEO will be next to admit that the world is indeed round?”

One Effective Interview Question for a Scrum Master or Agile Coach

reading

I have had the good fortune to be involved with Agile software development for close to a decade now. During that time I went from a somewhat skeptical Director of Software Development to someone who now makes his living helping others create great software by applying the Agile philosophy as an Agile Practice Director. One of the things I have noticed during this time is, as Agile (and especially Scrum) have become more mainstream, the quality of individuals calling themselves scrum masters and agile coaches has become more variable.

The problem is certainly not new or particular to Agile Scrum Masters and Coaches, However, I feel that that, given their centrality to software development teams, the fact that Agile is new to many organizations and in many cases these individuals are expected to aid in transformation, having an ineffective Scrum Master or Coach can lead to disproportionally negative effects. For example, a single inadequate developer can be a real drag to a team, an ineffective Scrum Master can be detrimental to multiple individuals and multiple teams and the same inadequacy at the Coach level can lead to wholesale bedlam for large parts (if not the entire) organization.

BookThe problem is further exacerbated by, as I (and others) have pointed out in the past, by a weak and inadequate system of certification. It is good business to mint as many scrum masters as possible from a two-day training, but it does the outside world no service. This begs the question – in a world where every former project manager with a CSM calls themselves a scrum master and every scrum master with a few teams under their belt calls themselves a coach, how can I really assess those who have talent from those who do not?

Of course, one could use someone’s resume to assess the breadth of work. How many different teams has one worked with? How many years has one been involved with scrum? How many different organizations has one coached at? Unfortunately, individuals looking for work have a tendency to prevaricate at times so how is one to know if that time was really spent doing Agile or did I conveniently reclassify this work because it was not “entirely waterfall”?

A good deal of my current work is trying to make these kinds of judgments. If you too need to assess the ability of a scrum master or coach, let me share the question that I have found to be most effective:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

If you are merely a paper candidate who has relied on the minimum set of qualifications (ie you have a good number of certifications) then this question is very difficult to answer. Being a scrum master or coach requires a level of passion that transcends merely implementing a small set of learned behaviors. It requires an active mind that is constantly seeking new ways of thinking,, new experiments to try, new behaviors to model – any and everything that one can do to truly be a servant leader. Passionate people always want to improve. There is no better indication than reading as a means of improving one’s ability.

Library of BooksThe question not only shows ones ability to think critically, but it also indicates a higher level of maturity. To read something that changes ones view requires the ability to realize ones knowledge is never perfect or complete. I have to acknowledge that something I hold to be true today may not be true or that I have a true ignorance of certain things.

Agile and scrum are about continuous improvement. We should not expect our scrum masters and coaches to have all the answers any more than we can expect our teams to function perfectly. There is always room for improvement and it is the good scrum master and coach who is not only able to admit this, but also has taken the steps necessary to improve. One of the most accessible ways for this improvement is to read books and to apply this knowledge. So the next time you are asking yourself “Is this scrum master or coach any good?” perhaps you might want to ask them this simple question:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?