I got a real aha moment when I saw this graph:

The blog post where I saw it was talking about "management by ..." but I think it also applies to the motivation that individuals are moved by. That is, relative newbies to a job tend to do things a certain way because those are the rules. As they progress over time, most of them move on to "this is the method I use" and then to "my team's objectives are" and finally "this is what my team values." I think this is a hugely important progression to understand.

Let's take one little thing, say source control behaviour - do you check in too often, not often enough, are your comments any good, are your changesets too big or too little, and so on. If I want to direct your source control behaviour I need to know what zone you are in.

• If you're in the "rules" zone, I must tell you the rules for source control. I need to write a long document with lots of examples and if there are exceptions, or different rules for different projects, I need to elaborate them all. Whenever you do something "wrong" I will probably hear that you were just following the rules, and I will need to update the rules to attempt to prevent that problem in the future.
• If you're in the "methods" zone, I must cover source control in the documentation of my methodology, put it into context, show you why we use it and how things you type at step 17 will be used by someone else at step 35. The rules don't need to be so black and white or so detailed, but there may need to be different methodologies for different kinds of projects or circumstances. If I correct you I am still likely to hear that it's because the methodology is flawed.
• If you're in the "objectives" zone, I need only remind you that we need to be able to pick up projects again for a version 2 long after we shipped version 1, or that we need to be able to recover from two people editing a file at once, or that we need to be able to explain to clients which files are different in version 2.3.4 than they were in 2.3.3. The detailed rules can go; you will choose your changeset size and your comments knowing which of our objectives you are supporting when you do so. If you make an incorrect decision and I point it out to you, your response is most likely to be "oh" and then you will adjust your own internal set of rules and methodologies accordingly.
• If you're in the "values" zone, it's even simpler - we value making money on each project, and serving our clients well, and you know that, and you have the capability to make the right decisions in order to support those values. I barely have to manage you, just provide you from time to time with information.

In contrast to the blog where I found this graph, I don't see it as just being a matter of how managers choose to manage their projects and people. I see that some people cannot be motivated by values alone, or objectives alone. Either they lack the career maturity to recognize that supporting the team's objectives is always in their own self-interest, or they lack the skill and knowledge to choose correctly (should I check in now? or wait till I have tested? or wait till I do those other changes?) knowing only what outcomes are important to the team.

I personally don't care for the rules-oriented phase. Writing out exhaustive "if this happens do that" documents is not really fun work. Hearing that a flaw in the document is why something went wrong also doesn't really work for me. Yet it seems all team members (and by this I mean not just my own staff, but my clients and their staff, other vendors, and so on) need to go through this phase when adapting to a new process. Well, knowing it's going on makes it easier for me to cope with it.

Kate