Part 1 can be found at The Confessions of a Serial Change Agent: Part 1 Overview
Introduction
This is the second half of a two-part blog discussing the rarest of creatures -- the serial change agent. Last time, I covered the characteristics of being an excellent change agent.
This month, I will talk about some of the things that I have done as an APM change agent. I will start from an individual level and work up.
Seven Steps
1. Ask questions
Never stop asking why things are they way they are. Try to understand the various challenges and skill sets of key stakeholder organizations and players. This helps to determine the best way to make changes. The KB on MTP and TIM compatible releases was one such recent result.
2. Identify gaps and do something about them.
A wise manager at CA said to me, "Anyone can point out something's wrong in a situation. Far fewer hear the call and try to resolve things." An example of the former is the fictional character from Saturday Night Live: Oscar "Fixit" Rogers. I have taken my ex-manager's words to heart. If I see something is not correct, then the next immediate step is an actionable item for improvement.
3. Document like crazy.
Since 2006, I have documenting through emails, Tech Tips, Tech Docs, knowledge documents, blogs, internal presentations, and cases the various best practices in APM to produce stable, scalable environments. This sizable body of knowledge has enhanced the APM administration experience.
4. Look for like-minded individuals.
They are the ones that raise key issues and then do something individually about it. Keep talking with each other and good things will happen.
5. Form ad hoc project teams to get things done.
With #2 in place, small teams can be created to quickly implement needed change deliverables. Then when the work is done, end the team. Repeat again when the next opportunity forms itself.
6. Form "permanent" teams as needed.
I took over running the APM Documentation Board which meets each month. This group has quietly improved long-standing documentation shortcomings and works hard to make APM technical documentation better suit your needs. Examples include adding the APM Troubleshooting and Error sections, providing a link to the MTP documentation on span ports, and much more. Have an APM documentation concern and want to make sure the right people hear about it? Feel free to drop me a note at hallett.german@ca.com
There are other efforts as well that may be a subject of future blogs.
7. Address concerns across products.
From my experience with the Problem-Solving , Knowledge Management, and Search Engine cross-product projects this year, I have seen how conversations and linkages across products leads to better customer experiences through streamlined processes.
Conclusion
In summary, change what you can today, change even more tomorrow. The rapid pace of transformation in the world means that we can longer afford to be comfortably on the sidelines. You are going to be here for some time. So, might as well make a difference. no matter how small. I hope these two articles inspire some one to get out of their comfort zone and help transform their universe in some way.