Every so often, I stop and evaluate where CaseySoftware is going, how our various projects are doing, and what I'm doing personally. Outside of my role within dotProject and our growing dotProject work, I find myself assisting a number of long-term customers in initiating change and creating new policies and practices. In the past, people have called this “Change Management”, “Change Agent”, or a variety of other management-ese terms that grate on most developers' nerves. I prefer to call my role a “Chief Agitation Officer”.
What is a CAO?
First, I see it as someone who starts conversations. As an acolyte of the Cluetrain, I believe fervently that you don't know what's going on without asking people. This means everyone. Talk with customers, talk with developers, talk with managers, talk with random people who try your products. Especially talk with the people who turn you down… whether it's a customer who chooses your competitor or a developer who takes a different offer.
Next, it's someone who is a realist, not an idealist. If you are talking with all of those people, you can't pull punches or gloss over deficiencies. You have to take the opportunity to identify them up front. It's painful, yes, but if you can list your weaknesses at the beginning you do two things immediately: a) you demonstrate a willingness to be self-critical and make yourself available for improvements and b) you can encourage them to be more open and honest with you.
While I was with one of the local Federal contractors, I had a number of annual reviews. The first one with a boss was always a bit rough. You had an idea of how you and the project were doing, but you weren't always sure of their hot buttons. But I'll never forget my second one. After spending 30 minutes reviewing my status (performance, role in the project, areas for growth, etc), my manager turned it around to himself. Since this was my second time with him, I was prepared for it and was able to give meaningful feedback with specific examples that actually resulted in some policy changes. It fostered an environment where problems and issues could be brought up the chain of command immediately without concern for reprecussions and know they'd be addressed somehow.
Finally – and this is where the “agitation” part comes from – it's someone that occassionally shakes things up. People don't like change. Whether you're talking about new tools, policies, people, etc, they simply don't like change… even if they receive an immediate tangible benefit from it. Alright, so you've deployed a [choose: wiki, version control, blog, project management, group calendar, etc, etc] system and no one is using it. Or even worse, you've just hired a system admin and everyone still wants root access.
There's no easy way to get people to take the right route other than possibly disabling the old route. But that's not foolproof, look at the “shadow helpdesks” deployed by the US Navy in response to EDS.
This is where all three points come together. If you've demonstrated that a) you're listening to the various people and b) you aren't trying to gloss over the real problems, people are more likely to give you the benefit of the doubt…. once.