Escape Velocity of Change in an Organization

I was recently measuring how long it took for an idea to move through our organization. I compared several ideas over the last 3 years. I Looked at why some seemed to hit some critical mass and then just take off, while others required constant care and feeding and took a long time to be adopted. Reviewing the changes with my boss, he said there seems to be some escape velocity for ideas in the organization. Of course this made me want to investigate this more. At the suggestion of my boss Bradley Mitchell, I opened up wikipedia and took a look at the definition of escape velocity. This is what I found out:

1. Escape velocity changes depending how far away from the surface you are.
2. Escape velocity decreases with altitude.
3. It is the speed at which an object will not fall back to earth.
4. An object at any speed as long as it has propulsion, can escape the earth’s gravity.
5. If propulsion is removed on an object that is below escape velocity it will fall back to earth.
6. If an object is at or above escape velocity it has enough kinetic energy to “escape.”

There is also a formula that allows us to measure the escape velocity of any object.


G = gravitational constant
M = the mass of the planet or star
r = the distance from center of gravity.

So if we apply this to organizational change we get some interesting observations that seem to be true.
G = Change Constant
M = the size of the organization
r = how close to core values that change are.

So if the organization is large (large M) it will take more velocity to get the organization to change. If the change is far from the changing fundamentally core values of the organization then the escape velocity is smaller than if it profoundly affects core values. This seems to make some sense. I also think we can play with the Change Constant and say that it is not constant but corresponds to how old the organization is. The older an organization the harder it is to change and therefore the escape change velocity is higher.

Let’s look at these principles and see how they might apply to change in an organization. So how can I use escape velocity observations for escape change velocity?

1. The further you are from a profound change to core values the easier the change.
2. Change is easier for smaller changes.
3. To make a change permanent you must achieve the escape change velocity or it will fall back to earth.
4. Adding constant pressure to a change, will eventually make it stick.
5. If a change is launched without enough velocity to escape, it will revert back to its current situation.
6. If a change has enough velocity at launch, it will not need constant pressure to succeed.

As you can see the engineering side of me wants to put an equation to describe how I can help an organization change. But it is never that easy. Human beings are unpredictable and in a large organization with hundreds of individuals it is closer to chaos. The key is to try and determine what things can help control the chaos during the change. Finding the perfect velocity of change for the organization is a combination of the amount of change and the size of the organization.

DWP

Someone to Watch over Me

In my work as well as at home it is always nice to have someone help me get my todo list done. Whether it is a honey do list or a work breakdown structured list from work, it is nice when I have the chance to have another set of eyes to make sure I did everything. Of course I didn’t think this applied to my honey do list, but my 6 year old son taught me something interesting this last week. I have been trying to fix our trash compactor for the last month or so. The problem is it is just hard to open the door. First thing I did was pull all of the garbage that fell behind the trash bin. That seemed to help some, but it was still really hard to open the door. Next I took the bin out and made sure all of the tracks were working fine. Then I started taking apart the wheel assembly. Putting it back together and tightening all of the screws. It was better but still hard. I was very frustrated and out of patience with this appliance from the underworld. Then my 6 year old son flipped the red switch that said,  “locked” to “unlocked,” and everything worked fine.

So, like a typical engineer I was looking for a hard problem to solve instead of looking for something obvious. This tends to be the case not just at home with household appliances, but at work as well. This could not just be for us engineers either. In the software engineering world there is a big movement to perform something called Pair Programming. Basically two people sit down to one computer and write code together. One person typing the other making sure the program is working, typed in correctly ,etc...

Can you imagine someone looking over your shoulder making sure you are typing correctly? Sounds annoying and it can be at first. But the results are huge according to some research that there can be up to 50% decrease in the number of mistakes (bugs) made in the code. Two people tend to consider more design alternatives, find bugs faster, and fix problems right the first time. I have used pair programming a couple of times in my career and in every case I have seen great improvement in hitting timelines, with higher quality.

However, I have also seen engineers not wanting to work nicely together. Maybe it goes back to elementary school when we are graded individually. Not as a group or team often. It is kind of funny. We teach kids in kindergarten to play together. By 3rd grade you are not allowed to share answers with your classmates, that is cheating. In fact one of the largest complaints about pair programming is who gets the credit. Especially when annual reviews come around. Somehow we have to overcome the social barriers that have been ingrained in us to not share or work together.

As I learned with my trash compactor, pair programming helps find solutions that would be otherwise overlooked. Even a 6 year old can see the obvious things that years of my domestic appliance repair was overlooking.

Patience and Patents

About 7 years ago I went through a patent harvesting exercise with my employer. It was 2005 and there was a big push in the software industry to patent everything they could. So they could be leveraged in licensing technologies between companies. The lawyer and my team submitted 14 patent applications and the waiting process began. About a year later I left the company and pretty much forgot about the patents. One day about 2 years later I got an email from one of the members of my former team. To my surprise,  we had been award 4 patents. Over the next year 2 more patents were approved. Not notice from my former employer. I found out thanks to “Google Scholar” monitor  (very cool tool that monitors your name and publications you have). Then silence; Nothing happen for 4 years and all of a sudden in the last 3 months 3 more patents were awarded.

I have lots of questions about the patent process. Maybe someone that has experience in this can give me some ideas.

• Why has it taken so long?
• Why does there seem to be some renewed interest in 7 year old patents.
• Do patent applications expire sometime?
• Is the high tech sue happy atmosphere today affecting number of patents filed and the time it takes to be reviewed? (Samsung and Apple for example)

With all of the renewed interest in my old patent applications, it reminds me of the old team I worked with, the cool technology we created, and the fun we had. So I guess the benefit of a long patent process might be nostalgia. I have lots of questions

DWP

Learning to Ride a Bike (for the eighth, ninth and tenth time)

Three of my kids are learning how to ride a bike right now. Since my wife and I have already done this 7 times, we thought it would be easy. It has been 7 years since we have done it, but teaching someone to ride a bike should be the same as riding a bike. Once you do it, you never forget. So we lined our  5, 6 and 7 year olds up with their hand me down bikes from their older siblings and started their journey from little kids to big kids. We knew that these kids all  have different personalities with some  less coordinated than others, some are more fearful than others, and some are more stubborn than others. But we had years of experience teaching kids to ride bikes. We knew the routine, an hour of tears, some crashing, scrapes and bruises with Toy Story band-aids.  My wife and I both played our roles. I would say, “Stop crying and get back on the bike.”  “Everyone falls you just need to do it again.” And my wife with the, “I know it hurts, let me kiss it better”, “You did so good”, “You're ok, lets try again.” Both of us taking turns with the video camera and running behind them on their bikes.

You get the picture. We noticed a couple of things that were impeding my kids from just picking up the bike and riding it. They are what I call “barriers to riding.” Being the software engineer with an MBA, I need to have a buzz word or phrase to explain things. I will show a graph later with success in the upper right hand corner of the page. Funny thing is that I see similar things when it comes to engineers and teams evaluating and using new tools. In previous blogs, I have mentioned to find out what motivates people and how to play to those motivators. I have been reminded that we also have to look at “de-motivators” or “dissuadors”.  Here are some of the things that dissuade trying out new tools or learning to ride a bike: fear, complexity and complacency.

Fear
Fear is one of the most powerful, “barriers to entry”, there are.  Our society does not seem to help the situation. Look at kids learning to ride a bike. We completely cover them in helmets, knee pads, elbow pads, etc... We basically scare our kids and teach them to be afraid to ride a bike. We predisposition them that falling is going to hurt and may kill you. No wonder they are very scared to try and ride. We do the same thing in business. I don’t think if the new build system fails to build, will kill you, but we put the fear of trying and failing into annual performance reviews, development metrics, and tight release schedules. 

After my kids all fell once or twice, they found out that it only hurts a little bit. They weren’t going to die.  They got the comfort they needed from their mom, the motivation from their dad and they kept trying. We did not reward them for trying and quitting. We encouraged and adjusted our approach based on the results we had before. The key was showing them that it was safe to fall and encouragement to keep trying.

We need to foster the same kind of atmosphere in our work environments. Encourage people to try new things, learn new techniques and use tools. We need to be okay with failing and learning to eventually succeed. We need to make sure that we don’t reward failure. We cannot remove the natural consequences of failure. Like my kids, they had to fall a couple of times before they could figure out how to balance. When we fail we still need the sting of hitting the pavement and skinning our knee, or we won’t know we are headed in the wrong direction and we cannot correct the path we are on.

Complexity
Everyone that rides a bike knows that it is easy. It is not that complex. Tell that to a 5 year old, or an engineer that has only used vi or emacs and cannot see moving to a windows based IDE where they have to use their mouse to get things done. (I fit into that category). To ride a bike it requires balance, hand eye coordination to move the handle bars, strength to push the pedals, coordination to move your legs in a new motion, etc.... For a 5 or 6 year old this can be very hard to figure out. Throw fear in there and you have something monumental to overcome.

One of the tricks we learned was to break down complexity, remove some of the factors that make it complex. Whether it is holding on to the back of their seat, (removing balance), or removing the pedals, (removing the leg motion and strength requirements).  This worked like a charm, and as they built up their confidence and coordination, they have progressed to riding their bikes all of the time. It has become second nature to them.

Same thing applies to adopting a new tool or process. Don’t do everything at once if it is too complex. It could be very difficult for an individual or organization to swallow all of the complexity at once. But remember, the end goal is to have the complete system in place. You need to put the pedals back on the bike to actually ride the bike. If you don’t, you can’t go as fast as everyone else riding their bike.

Complacency
My 5 year old told my wife and I that he can walk and that he does not need to ride a bike. Ok, this is actually true, but we had to show him the benefits or riding a bike compared to walking everywhere. First, so we can have fun with our friends; his response,  “I can ride my scooter.” Second, we can get to places faster; his answer was to drive a car. Third, we can go places on our bikes that our cars cannot go; his creative juices were flowing now, “We can use super hero powers and fly there.”

We run into the same problem in our organizations that don’t want to change. It is comfortable and familiar in a world that seems to always change. Most people want something that is always the same. So what do you do? Fight complacency with a plan and develop a sense of urgency. In the case of my 5 year old, our plan was to ride a bike and show him all of the steps we were going to take to teach him. Then, we had to give him a sense of urgency. So we planned some family bike trips to the park. One of his favorite parks. The urgency was there and the plan was in place.

Organizations need the same kind of strategic plan and urgency that my 5 year old needed. Without an end goal and a timeline to meet the goal with some kind of consequence, the people on your team might wonder why they are making the change. “Change for change’s sake” will be the mantra for the week, and the effort will be undermined by complacency. 

Results
When a substantial change is made in an organization, you need to celebrate. There needs to be a reward for the change. Many times we forget to point out to our teams the benefits that have been realized from making the change. Don’t forget to point out the natural consequences of the changes. Many people need to be reminded. A celebratory pizza party helps sometimes as well.

As of this date we have 2 new bike riders in our family. My 5 year old is still holding out, but this next week may be the week for him. Like I said. We learn from our failures not our successes. Anyway it may give me more ideas for another blog.


DWP

Saggy Pants and Pointy hair: Motivating Teenagers and Bosses

I have a very unique situation. I have been climbing the executive ladder for years and finally reached the executive level. Recently, I moved into an individual contributor role where I try and influence an organization for change from the side of the organization, instead of from the boss position. It is a very challenging, role but at the same time very fun.  Trying to figure out  how the organization operates,  how it changes and what motivates it to change.  I also have another unique situation in that I have 10 kids. That is not binary for 2. That is the number TEN, and having a blended family with that many kids feels much like my job. Influencing the children with different ages from 5 to 23 years old, is just as challenging as helping an organization through change.  I have found some interesting comparisons:

Family	Work
One child can make an 8 hour road trip to grandma’s house completely miserable for everyone.	One person can torpedo the role out of the greatest process improvement.
What motivates my 5 year old son, does not work for my 17 year old sons.	What motivates the CEO is different from  directors, managers and individual contributors.
Not everyone can be heard at the dinner table when everyone is talking at the same time. But everyone wants to be heard.	Some of the best ideas for change can come in the ranks of the organization. At all levels.
Mom and Dad need alone time as often as they possibly can to recharge.	I got nothing here.

I would like to look specifically on what motivates. I am starting to understand what motivates my 5, 6 and 7 year olds. Treats and trips to the park. My teenagers are a bit harder, but it mostly has to do with electronics. My older kids are motivated by pure cash mostly because they need it for college or fixing their car. Organizations are somewhat similar and finding out what motivates individuals is key to effecting change. So what motivates you, your boss, or your boss’s boss?

Individual Contributors - Money is a good motivator for most individual contributors, but that is typically only the case if they feel they are not being paid enough. What I have found is a better motivator is, do they enjoy their work? Is it fun, is their voice heard, can they make a difference?  For some it might be the camaraderie of working in a great team.

First-line Managers – Many first line managers want to be directors and they want to climb that leadership ladder. So they want to make sure their team is successful according to what their director or senior manager wants. They are trying to make sure that themselves, and their teams, look good. They are building their careers. Then there are some first line managers that want to stay where they are. So they want things that are stable, quiet and secure.  When trying to effect change with first line managers you need to find out the type of managers you are dealing with.

Directors and Senior Managers – Power and influence. This is all about your team. The more successful your team is the more successful you are in the eyes of the executives. You have influence over more people, budgets and schedules. Being able to predictably deliver products or services from the organization is the key success factor of these people.

Executives – Motivators for public company executives are very different than motivators for private companies. Public companies live and die on quarterly revenue and profit.  Private company executives typically are motivated by long-term sustainable profit. How is a change in my organization going to affect my revenue and profit this quarter for public companies or longer for private companies? This of course is not always true and there are some executives with other motivation than the bottom line, but again you need to find out what motivates or de-motivates an executive to change.

Of course these are sparkling generalities and cannot be applied to every organization. The key is for you to find out what motivates people to change in your organization. Write it down. Then develop a plan to motivate your organization at all levels.

DWP

An Argument for Software Coding Standards

I have had the unique opportunity of co-authoring three books. Each book was very unique in the way that it was published.  As you would expect, by the time the third book was published, it was much easier than the first. However, you might be surprised why that was the case. Let’s take a look at what happened.

In 1999 I began co-authoring magazine articles for  Rose Architect, a small magazine that talked about all things Rational Rose. This quickly grew into writing for several different trade magazines and publications. The main topic of the articles focused on software development tools and processes. After about 50 articles, my friend and co-writer, Christian Buckley and I decided we should put these together in a book.  What an endeavor!

Our first decision was to self-publish the book. We found a printer, designed the cover, decided the size of the book. ( There is no standard size for technical books. They are all different sizes.)  We gathered all of the articles together, categorized them and divided them into chapters. Next, we wrote introductions and conclusions for the chapters, transition paragraphs, a preface, a conclusion chapter and even rewrote some of the articles.

We had all of the content, text, graphics, bibliography, everything we needed for a book. We then spent the next 4-5 months working on the format so it was consistant and would fit on the size book that we wanted.  We spent more time formatting and moving graphics, so they fit on the same page as the text, than we spent writing the content for the book. Our grand masterpiece finally went to the printer and we had the book in hand. Secrets of the Change Agent: Strategies for Software Development was born and we were the proud parents. Of course you can buy our book on Amazon. (Shameless plug)

Although the book did not make us the JK Rowlings of software engineering geeks, it did land us a book deal with a real publisher, Addison-Wesley. They wanted us to re-write our book to focus on Rational ClearCase Deployments. More specifically, how to use a system engineering approach to deploying ClearCase environments. This was the beginning of our next book:  The Art of ClearCase® Deployment: The Secrets to Successful Implementation.  

Now that we had a real publisher, we had to fit our writing style into their templates so their printer could automatically take the book and print it in their standard sizes, standard fonts, and font sizes. It took us sometime to learn the new template format and since much of our content was written in a different format, it had to be converted. Looking back we probably spent about 1/3 of our time formatting this book into this well defined standard from the publisher.

Within months of our book hitting stores, Addison-Wesley commissioned us to write a third book. This time on another tool from IBM-Rational. The tool was ClearQuest. There wasn’t a book out there yet on the tool and they liked the perspective we used in our other books. I had used the tool before, but was not an expert. By the end of writing the book, I would be.

We wrote the book from scratch. Nothing had been written before hand. We started with the template that Addison-Wesley gave us and started writing. Something amazed me this time. I spent no time at all worrying about formatting. I was already familiar with the writing standard and template they gave me. It was like second nature writing in that template. I focused all of my time on writing content for the book and making sure I understood the tool well enough to write about it. The book only took us six months from the first time we started writing to the time we were at the printers, three months shorter than the previous book. Our book: Implementing IBM® Rational® ClearQuest®: An End-to-End Deployment Guide is still considered the definitive guide to deploying Rational ClearQuest.

So what does this have to do with anything? I found it interesting that the final product was the same, a book. But the effort and time I spent on the actual content of the book compared to the formatting and style of the book overtime decreased and the quality of the book increased. My focus in the last book was the content. All of my creative energy was spent on the things that mattered, the content not the format, font size or color of the book.

I have found in my career when there is a well defined coding standard, development process, and tool chain, software engineers produce higher quality code in a more predictable manner. Their creative energy is focused on delivering the product not on the process of delivering the product. When teams have an ad-hoc coding standard, process and tools, the engineers tend to spend valuable time figuring out trivial things like: where to indent their code or what tool to use to share their code with their team.
Just my random thoughts.
DWP

Agile Methodology: Yet another fad?

Throughout my career, I have seen several fads come and go in software development methodologies, tools and processes:

• Structured programming, Object-oriented Development, Aspect-oriented development
• Methodologies like Waterfall, spiral, iterative development cycles, Agile, SCRUM, CCM
• Fully integrated development environments like visual studio, eclipse.
• Languages like ADA, Fortran, C/C++/C#, Java, Groovy/Grails, .....

After years of management and organizational behaviorist trying and figure out how to harness the ever changing requirements of product development, dynamic competition, and the innovative energy of software engineers, they finally gave up! Gave control to the engineers! And we always deliver on time, with high quality, and with all of the features the customer wants. Ok not really, but with some of the new methodologies like Agile and SCRUM appear that way at first glance.

Agile is really not that new. The Agile Manifesto came out in 2001. Just after the great Dot Com boom and bust. The group that came up with the manifesto came from several different software anarchist individuals that wanted to give more power to the engineering teams and get away from the arcane methodologies that produced more paperwork than source code. Words like self-organizing; cross-functional, adaptive-development came out of this group of 17 software developers. The key values that the Agile Methodology focuses on are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Many of these values fly in the face of micro-managers of the middle management ranks today. Think about the last time you sat down with your manager or director and they said they wanted a plan, documentation on how everything was to be done and then you could start doing your work. These software engineers came up and told management enough we know if we focus on these key items then we can deliver.

This great experiment in software development started to take hold and there are several case studies out there for agile development in small teams < 20 people. The same is not true for larger teams. Products that have large teams suffer from too many communication channels, distributed teams, and too many moving parts to keep control of. Although it appears that agile breaks down with larger teams, there are some groups trying to introduce agile methods and principles into large teams by mixing Methodologies. This is still a very new area in Agile and organizations are still trying to figure out how to make it work in a predictable manner. With companies being so data driven that is probably why it has not moved as quickly. Also many of our teams are larger than the 20 or so that agile seems to work best in. When was the last time you saw a development/validation team that was < 20 people. It does not happen very often.

One of the ideas that is floating around is a hybrid plan that allows for high-level planning, architecture and design, and allows for the smaller teams to value the four key values of agile, like working software, customer collaboration, responding to change and valuing the individual. The idea behind this methodology is to break the product up into components that can be developed, tested and delivered independent of each other. The combination of components together makes up a complete product which is delivered by an integration team that is agile itself. This is not an easy endeavor and requires great communication, face-face team, tracking of component and their progress, and trust. Let me say again Trust. Trust that all of the individual development teams are gathering requirements from their customers, other development teams, or the integration team. Trust that teams will deliver on time and what they said they would deliver.

I am working on writing up our experiences from this hybrid approach which should be coming in anthor blog soon.

Helpful links:

• Wikipedia Agile
• Agile Manfesto
• Large Scale Agile Development