-
Three factors must be present for meaningful organizational change to take place. These factors are:
D = Dissatisfaction with the status quo;
V = Vision of what is possible;
F = First, concrete steps that can be taken towards the vision.
R = If any of these factors are missing or weak, then you’re going to get resistance. -
It is important for leaders of organizations going through change to realize the ‘lag time’ between where they are in the process and where others in the organizations are in the process.
The higher a leader sits in an organization the more quickly he or she tends to move through the change process. Because they can see the intended destination before others even know the race has begun, senior managers can forget that others will take longer to make the transition: letting go of old ways, moving through the neutral zone, and, finally, making a new beginning.
links for 2009-02-19
Published
Striving for greatness 
Great, yet another guy turning obvious facts into silly formulas. Also, because R is defined based on D, V and F (“R = If any of these factors are missing or weak, then you’re going to get resistance.”), writing D*V*F>R is pretty silly since R can then be expressed as a combination of D, V and F. This silly formula could much easier be told as simply one paragraph of normal text but the bad thing about doing that would be that everyone would realize mr. Beckhard actually has nothing new there to say. Anyone having read their history knows from the example of revolutions that this is how things work.
As for the Marathon model, well. We all know that managers not only lose grasp of how slow things change on the low level but also start forgetting how things work at all on the low level. There’s a huge risk of a boss who got so interested in leadership and management to forget how the technology actually works that he will start changes without consulting the people working for him who actually could’ve provided him the information he needs to make his decisions. The more hierarchy there is, the further away the boss ends from the actual work which is dangerous for opensource communities and the less likely he is to be capable of seeing the big picture without the help of an advisory board or similar. The working way for opensource doesn’t in my opinion come from companies, it comes from Universities. You don’t kick people out of projects, you arrange them mentors so they learn their things and can eventually perhaps teach other people. In fact, a good mentor system could cause the “lag” in shifts reduce significantly.
Yeah, the equation in itself isn’t that interesting. It’s just nice to get an idea of what factors to consider when you’re trying to change something.
I agree with some of your commentary on the 2nd post. I do think it’s important to keep the “front line” in mind, although I also think that it’s possible to think about the big picture even without that. Even in a university research lab, people sometimes get fired when they show themselves unable to work within that group.
About the Marathon model:
The problem for the lower ranks is that moving to the new beginning means additional work with little if any additional reward. Often this creates a situation where lower ranks have to do twice the work: They have to support the old ways (because the new ways arent satisfing alll requirements) and in addition have to work on the new ways.
One of the important things for the lower ranks is recognition for the additional work. The only way I can see this work is clearly separating the maintainance of the old ways and the development of new ways.
Create an “assault detachment” whose job it is to only care about the new way. Let them work out their stuff, and switch over to it when its ready.
One (gentoo) project that worked pretty well in that regard is OpenRC – and it pretty much followed that pattern, IIRC.
Donnie,
I actually referred to the actual education system.
Also, a slow developer shouldn’t slow down an opensource project down per se, someone else can eventually partially or fully replace the slow developer *if* there is a more competent available. (And even then it’s fine to keep the slower developer in the background in a hope he’ll eventually do something. I mean, you’re not paying anything to him so it doesn’t matter)
Sure, if the programmer repeatedly sends out bad patches that break a lot of things, you could think of sacking them. Also if the project has some distinct milestones that should be followed and a developer repeatedly and grossly violates them trying to make turn the project into something completely different, one could tell him to fork off. (pun intended) A developer who writes 20 (fully or partially) bad patches and ten good patches might be worse for the project than the one who only writes five good ones during the same time period because he wants the patches to actually not break anything else.
My standards aren’t so much about quantity as they are about quality, so I think we’re on the same page.