--- title: "How to plan and influence change at your company" url: "https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.md" canonical: "https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html" published: "2009-12-10T05:59:51+00:00" updated: "2011-04-04T22:49:37.787000+00:00" tags: ["Influence", "Self-Leading Phase", "people patterns"] author: "Roy Osherove" description: "In the book “Influencer” , the authors describe six forces that work together to influence any particular human behavior that we might want to change. The forces that influence behavior are: Personal Motivation : Why should someone care to…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to plan and influence change at your company In [the book “Influencer”](http://www.amazon.com/exec/obidos/ASIN/007148499X/iserializable-20), the authors describe six forces that work together to influence any particular human behavior that we might want to change. The forces that influence behavior are: 1. **Personal Motivation**:   Why should someone care to behave a specific way? 2. **Personal Ability**:         Can they literally do it? 3. **Social Motivation**:       Is there peer pressure push for this behavior? 4. **Social Ability**:             Do people around me support my behavior and help me out with it when i need help? 5. **Structural Motivation**: Are there rewards\\punishments for good\\bad behavior? 6. **Structural Ability**:       Does the physical environment support this behavior? Thinking more about these forces, it’s easy to understand why so many of us are finding it so difficult to influence _real change_ in our company. plenty of times we have no problems with influencing items #1 and #2 but the moment we leave our _immediate surroundings_ we find that there is lack of social motivation (in fact, there is social motivation to behave differently!) and thus social ability. in some cases, #3 and #4 are somehow made possible, but the way the organization and the environment we work in are designed prevents us from completing our change strategy. here are some examples of common failures to implement change I've encountered. now i have a sort of dictionary to try and explain where we needed to exert influence and did not: > Implementing TDD at a large company failed partially because project managers did not agree to allow more than 20% of overhead time to write automate tests for the system. on top of that, C++ developers had a horrible time testing legacy C++ code, and could not\\would not refactor it for testability. in this case, #2 was lacking (we needed better tools, or better training to teach the difficult parts) but sometimes #1 was lacking as well when people did not want to touch existing code. that also touches on #3 (social motivation) since people were not having any kind of collective ownership of the code and so did not want to mess with someone else’s code. lastly, we have #5 fail: project managers did not allow enough time to write tests,, resulting in actual “punishment” for such behavior. ### Start out by finding the vital behaviors you want to change Another eye opener for me was that the authors clearly explained that when you want to influence change, anywhere, you want to change no more than 2 or 3 _vital_ human behaviors. find these behaviors, and you have the key to making real change happen. for example, you feel that you consistently produce very low quality of released software with many bugs at the customer site. how do you know which behavior needs to change? what causes this? one way the authors state is to _look for the uncommon results_ in the crowd. for example, you may have a specific group or component that consistently presents the _good things_ that you’d like to achieve for all other groups in the company (low bug counts). find out what is different in the behavior of that specific team of individual programmer that produces that different outcome. maybe they do Test-First development? once you’ve uncovered this behavior(s) it’s time to find out why no one else is doing them. ### Find the forces, Luke. One of the sentences that has stuck most with me is the following: > Every behavior you see has been perfectly influenced by a world that was perfectly designed for this behavior to happen. That means that in order to change a specific behavior, you need to first find out why this _bad_ behavior (avoiding tests) exists in the first place. if you don’t fully address all the forces that made this behavior a reality, you will likely fail in changing that behavior. You may find that there is just one, or all six forces at play here. In the problem of automated testing, you may find that people don’t know how to do it (_can i do it?)_  and might not even want to (#1) . not only that, their managers do not believe in this system, and so will kill any attempt to do this. if you were, say, trying to push for better communication among team members as a behavior that’s missing, you may find that #6, the physical environment is actually something to address – perhaps the team is split in different rooms – putting them in the same room can help minimize communication cost. > Again, an important key here is that if you only address _some_ of the forces that affect the current behavior, it is very likely that the quest for change will not work. you need to deal with _all the forces_ that affect that current behavior. ## The silver bullet Doesn’t exist. Sorry. But with the six forces we now have a good language to talk about when dealing with implementing change in an organization. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/