Culture Shifting the Titanic
In June 2009, one of the largest and most iconic companies in America filed for Chapter 11 bankruptcy. General Motors was at one point the bellwether of US economic might, as the saying goes “what is good for GM is good for America.”*
The reason GM even exists today was a total reorganization plus a $50 billion bailout by the US government. In total, US taxpayers lost $11.2 billion. Decades of poor strategic mistakes, financial foibles, punishing union contracts, and inability to change led GM to the brink.
But in the 1980’s, GM did not see any of this. Sure they produced horrifically bad cars, had progressively lost market share to foreign imports, and were unable to produce cars customers wanted, but they were still king of the automotive world.
Which made the news in 1984 of an alliance by GM somewhat astonishing. Two fierce competitors came together to open up a shuttered manufacturing plant in Fremont, CA to produce cars together. On one side was GM, the heavyweight market share leader and global icon. On the other side, Toyota, the Japanese upstart making headway building smaller, more fuel efficient, and better quality cars.
The joint venture was called NUMMI, combining an American workforce with Japanese production principles. Known later as The Toyota Way, it was a set of 14 principles for giving people the tools to continuously improve their work. When these principles were put into action, it allowed people to work more collaboratively towards a greater goal.
The results were dramatic. Before NUMMI, the Fremont plant had regularly rolled out hundreds of cars with defects, such as having no steering wheels or brakes, only to have to go back later and at greater cost to fix them. Quantity trumped quality. At NUMMI however, the cars coming off the line were getting near perfect quality ratings. Absenteeism dropped and workers were now proud of their work.
This new way of working had the potential to save GM billions per year. Estimates stated that implementing the Toyota Way would require 50% fewer workers. Quality of cars would approach the Japanese standards, improving both customer satisfaction and market share, which had already plummeted to the mid 30’s in 1984 from 50% of the market in 1970.
So what happened from 1984 to 2009 at GM to cause a near catastrophic corporate death? Why didn’t the lessons learned change GM’s fate?
There are many reasons and I do not wish to simplify a complex situation. However, a consistent theme that emerged in the aftermath of GM’s collapse is that the workers and the managers did not want to change. With an organization of hundreds of thousands, shifting the culture was like trying to steer the Titanic. It started to happen by the 2000’s, but GM lacked the organizational trust to move faster.
I regularly have conversations with IT leaders about culture. There is overwhelming support for wanting to foster a more collaborative developer culture and they recognize the benefits across hiring, employee retention, and productivity. And yet, there is little action taken, even when the benefits are not only obvious but backed by research through efforts like the Accelerate State of DevOps Report.
The funny thing is that developers themselves would welcome a change in culture and embrace a supportive community. By their nature, developers want to solve problems and find ways to be more productive. The way most organizations are structured however creates unnatural silos that limit collaboration, communication, and teamwork. It destroys the “trust layer”.
But the question is “how” to build that community and establish that “trust layer”. Here are a few ideas that you may want to look into, all of which we have implemented for the various enterprises we collaborate with.
- Commitment by executives to change — this is critical in gathering the support for further culture shaping initiatives, executives have to financially & politically support change
- Create an environment of active learning — build in a training budget that does not get gutted and allows developers to tap into it to choose the training they want
- Invest in community events — give developers time and latitude to attend industry conferences and local meetups or to even organize and present at their own events
- Establish shared learning sessions — this could be in the form of lunch & learns or AMA sessions or internal team talks
- Host cross-functional hackathons — give developers opportunities to work across groups to collaborate on ideas and hacks to challenging problems
- Launch an online collaboration community — connecting messaging apps, code repositories and community platforms together gives developers a platform to freely share and help each other
- Send weekly update newsletters — use email communication and other channels to keep developers in the loop, praise good work being done, and share lessons learned
- Schedule regular town halls & fireside chats — have leaders from IT and other groups to openly share their vision and what they are working on
- Start an internal developer conference — this is an all-day conference where outside and internal speakers can share perspectives on relevant technology topics
There are many other ways one can start to establish a stronger and more collaborative developer culture. When you see the level of trust build, amazing things happen.
“They couldn’t believe that responsiveness. I can’t remember any time in my working life where anybody asked for my ideas to solve the problem. And they literally want to know. And when I tell them, they listen, and then suddenly they disappear, and somebody comes back with the tool that I just described. It’s built, and they say try this.”
The above was from an interview about NUMMI. The key is responsiveness, collaboration and working as a team. When the employees at the NUMMI plant trusted each other, it completely changed how they viewed work and the results they achieved.
Do you have the tools and systems in place to foster trust and collaboration in your company? What one thing do you feel would make the most impact?
P.S. Do you ignore the footnotes in books? Don’t! Chances are you will find something amazing, like the podcast I referenced for this essay, found in the book Accelerate (great DevOps book).
* This was not real quote. From Wikipedia, “because for years I thought what was good for our country was good for General Motors, and vice versa.”
Simple explanation of Continuous Integration
As I am here for the DevOps Enterprise Summit and all …
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.
