A few weeks ago I attended the Java Posse Roundup 2010, an Open Space conference hosted in Crested Butte, Colorado. There were many interesting conversations and ideas that came up during the conference; one topic I found particularly interesting was hearing accounts of how people had introduced change in their organization.
A few weeks ago I attended the Java Posse Roundup 2010, an Open Space conference hosted in Crested Butte, Colorado. There were many interesting conversations and ideas that came up during the conference; one topic I found particularly interesting was hearing accounts of how people had introduced change in their organization.
Two folks from the Java Posse had done something very different from "business as usual" - one started using Scala to write production code at his company, and the other changed his work environment so that he worked entirely from home.
Their strategy? When faced with an impossible (or just plain difficult) task, such as "Deliver this product by <some date>" they proposed the new practice as a way to solve the problem. For example (I don't remember the quote exactly, so it's my own recollection here) "The only way I can meet that deadline is by writing the code in Scala, since it helps me write code more quickly."
Of course, they were both pretty confident that they could actually pull it off when they suggested their ideas! They were also quick to volunteer that if they had failed with the new practice, they would have lost a lot of credibility with their colleagues.
Oddly enough, this topic was discussed at last year's Roundup as well - I stumbled across an interview Bill Venners did with two developers from Twitter. In the interview, Bill mentions another strategy:
Last week at the JavaPosse roundup people were talking about how they tried something new out, and a theme emerged. The advice was to try it on something you care about, but not something necessarily business critical. Something that you care enough about that you'll keep going, but not something that if it fails, you will go out of business.
So there are both high-risk ("the only way to meet the deadline") and low-risk ("something you care about … but not something necessarily business critical") ways to approach this problem. Each approach has its merits, and which one to choose depends on the people involved, the organization's risk tolerance, and situation at hand.
For more information, Chip and Dan Heath, authors of "Made to Stick", have written a book entitled "Switch", which is all about making changes in both our personal and professional lives. I'm looking forward to reading this book, as I found "Made to Stick" a fascinating and helpful read.
How have you introduced change in your organization or life?
User Comments
The "something you care about … but not something necessarily business critical" approach reminds me of the JUST DO IT strategy in the book "Fearless Change: Patterns for Introducing New Ideas" And the "only way I can meet that deadline is by writing the code in Scala, since it helps me write code more quickly" approach reminds me of the TAILOR MADE strategy.
You may want to check out our book for other change strategies (patterns). A summary can be found at: http://www.fearlesschangepatterns.com