Increase Buy-In on Your Software Team
Leverage the Commitment and Consistency Principle to Evangelize Your Message
The basic premise of commitment and consistency is that humans have a deep ingrained need to feel consistent to their particular system of beliefs. People who aren't consistent are viewed as "flakey" and untrustworthy. This need to be consistent is so deeply ingrained, that people will go to great lengths to appear so. Often, a small application of logic would clearly demonstrate the folly of a particular decision that was based strictly on the one's need to be consistent.
Consistency is the reason you feel so conflicted when you receive the telemarketer call. They may first ask you whether a particular cause is honorable. It may be saving kittens, children, dolphins, rainforests, etc. Once you are on record supporting a particular cause, they hit you with the consistency pitch. "Would you like to make a small donation to this cause?" While your initial agreement stating that the cause was honorable seemed innocuous, it set you up for their following question. Failing to make a donation would make you appear inconsistent to your previous statement.
The important aspect was that the salesperson first extracted a public statement in which you agreed that a particular cause was worthy. They were then able to leverage your commitment and your need to be consistent as an effective way extract a donation from you. This is a commonly used tactic in the sales industry.
Consistency/Commitment is Effective Tool to Drive Behavioral Change
Commitment and consistency is an effective mechanism for getting people to change their behavior. How often have you heard "if you want to accomplish a goal, you should write it down?" The simple act of writing it down significantly increases the chance that you will accomplish that goal. Making it public further improves your chances. The more people you inform of your goal, the more committed you will be, especially if you inform those who you know and respect. You will go to great lengths to achieve your goal simply so that you don't appear as inconsistent to your friends.
Practical Application in Software Development Teams
There are a number of ways to leverage the commitment/consistency principle within your software development teams. You may recognize a number of the following ideas, though you may not have realized why or how they work. Understanding this principle will help you analyze these ideas within their psychological context, and leverage them as a means of creating a change in behavior and practices within your team. I would suggest that you read
Influence: The Psychology of Persuasion, Revised Edition
Visual Management
You may have noticed visual management as one of the latest management concepts that seems to be cropping up in various large organizations. The logic of visual management is a sound practice based on the commitment/consistency principle, but it often goes awry in its implementation.
A common implementation of visual management is to make sure a team's commitments to finish a project or set of tasks are made visible for themselves and other teams to see. This can work well if the goal or team objective is transparent and easily understood by the team doing the work, as well as the other teams who may not be participating in the effort. However, each member of the team has to be personally committed to the goal. If any of the team members feel like their goal was arbitrarily set by management, without their full commitment to accomplishing, they won't have same level of commitment and effort to the team objectives.
Visual Management Done Wrong
One common area of mishandling visual management is the displaying of arbitrary measurements. One particular company had the practice of displaying the number of story points that were completed by a team in a particular sprint. The number of story points assigned to a task is extremely arbitrary and varies widely between differing teams. However, by making a visual display of the number of story points accomplished, it created a focus on the number of story points rather than the application functionality that was being delivered.
Since the focus was more on the number of points, teams started inflating stories points. Tasks that used to be considered 3 points soon were counted as 5 points. As teams inflated story points, it created the impression of increasing velocity.
Story Point Mechanics
Management was often known to state the number of story points completed over the previous months at various company meetings. This further perpetuated the myth that story points actually had some meaning beyond an arbitrary number.
And while the "increase in velocity" was viewed favorably by management, it was something of a running joke among the development teams. The reality was that work was being accomplished at the same rate, but by creating a focus on the wrong measurement, management created the appearance of progress.
Commitment/Consistency Only Works With Real Commitments
The inventors of Agile Scrum were attempting to leverage the commitment/consistency principle when they dictated that individual development teams would decide how much work they could finish in a particular sprint. Teams that are granted full autonomy of how much work they can commit will go to great lengths to make sure they honor their commitments. The consequence of seeming inconsistent is usually enough to motivate them to extra effort when necessary.
However, there is one mistake that is commonly made regarding this practice. There are often times when management will dictate that a particular feature or product needs to be done by a particular date. They then ask the development teams to work backward from that date (just figure out how to get it done on time). Often this is accompanied by some threat or consequence, implicit or explicit.
The problem is that when a threat accompanies an objective, the motive changes. Compliance will only be gained as long as the threat can to be enforced. If you are interested in a more in-depth analysis of this concept, read the Commitment and Consistency chapter of
Influence: The Psychology of Persuasion, Revised Edition
Authoritative Force is a Short-Term Solution
This is a significantly different approach than telling your team that they have to make this date, and that "failure is not an option." By stating that they have to finish by a particular date, you are removing the decision and the commitment from your team. They may work late every night because you said they need to finish on-time. However, since they didn't mentally commit, they are likely wasting significant amounts of time surfing the internet and doing other things. However, if you grant them the autonomy to choose what they can accomplish, they'll attempt to get as much done as they reasonably can, and to honor their commitments in every way possible.
The Greater the Effort Required to Make a Commitment, the Greater the Effort the Honor the Commitment
The more effort that is required to make a particular commitment, the more likely a person will honor the commitment. Additionally, the more public the commitment, the greater likelihood for continued compliance.
Create an Initial Trial Period
For instance, if you were trying to get your team to adopt a new development methodology, you might suggest they try if just for a couple weeks (a very small but significant commitment, easy for them to agree). Once they agree to try it out, get them to sign a paper stating they'll remain fully committed to the idea for the next two weeks (getting people to sign their name is proven to be very effective compliance tactic). Once they've completed a couple weeks under this new methodology, you could ask each of your team members to write a blog post on your internal website outlining the benefits of this particular methodology (a public statement).
Create Public Support to Increase Commitment
Once they've agreed to try out a methodology for a trial period, it'll seem inconsistent to deny your request to write a blog post. Once they write a blog post, they'll be significantly more committed to the methodology because they are making a public statement of support. Additionally, it requires some amount of effort to make this statement. Furthermore, if you have them forward links to their posts to other developers in the organization, they'll be even more committed to their idea (even if they didn't totally like the idea to start out with). Additionally, you might have them give a talk evangelizing the concept to other teams. These activities will go a long way toward driving the behavioral change that you are seeking from your team.
Are you interested in leading change in your software team? Then continue reading...
