I am fortunate this year to participate in many seminars and conferences. I just finished IMPACT and on June 5th I’ll be in New York for the WSMQAdmin seminar there. The following week I’ll be in Zurich for the TI&M WebSphere Messaging and Web Services Security seminar. Later this year are four more WQMQAdmin seminars and IBM’s WebSphere Technical Convention in Berlin. Sometimes when I ask people whether they will attend one of these events the response back is “I’m just too busy. I can’t find the time.” If this describes you, then I urge you to reconsider. Please let me explain why.
Prior to joining IBM I worked at a bank where my team and I were responsible for 24×7 Production support and more than 30 active development projects. We had over 400 queue managers and we did all this with just 4 guys. If that seems like a lot, let me tell you it surely was. But we had a guideline that no matter how busy things got everyone was expected to spend 20% or more of their time on strategic activities such as training and problem prevention. It was this continual skill building on our team and the training we supplied to the project teams that allowed us to cover so much with such a small team.
When I started the team I had four queue managers in Production and an active development project wanting more. I was the only administrator and I was swamped. We had different versions of MQ, our channels would not stay running and we had constant poison message problems. But the bank sent me to the conference and to the formal training sessions and soon I figured out how to tune the channels. We upgraded everything to MQSeries v2.1, which was brand new at the time, so the whole network was at the same version and fix pack.
The network doubled in size each year and I eventually got to grow the team to three people. But each year I went to the conference and as soon as we added staff I took one of them with me as well. Soon we had eliminated poison messages entirely by working closely and early with the project teams to make poison message handling a functional requirement on all projects. Part of the service agreement with the developers was that my team could at any time drop a message on the queue with a payload of “If found, please call you MQ administrator at…” The application was required to requeue or consume and log any message it did not understand. If we didn’t get that call, the app didn’t go to Production. Period. No exceptions.
We had quite a number of development standards besides just poison message handling. There were requirements for reconnect logic, security, exception reporting and more. We also had infrastructure standards such as the names for QMgrs and objects, specific initial settings on the QMgr, certain SupportPacs we always installed, etc. We had tools to manage the network centrally and to perform ad-hoc queries and global commands. But my point here is that we would never have known to do all those things if we were not regularly attending training and taking a day a week from tactical tasks to spend on strategic activities.
Stephen Covey (of 7 Habits fame) likens this to logging a forest. It takes a LOT more effort if you are too busy sawing to stop and sharpen the saw once in a while. Worse, once you convince yourself that chopping down the forest is more urgent than sharpening the saw, you’ll never complete the job. You just fall further and further behind. Most shops try but fail to brute-force themselves out of that hole. You can’t work at 125% capacity forever and hiring your way out is a stop-gap measure at best. If all you ever work on is urgent tactical tasks, the work grows to fill the capacity on the team – and then adds 25% more. Years can go by with no significant improvement in either the number of incidents or the duration of outages. The only way out is continuous improvement of skill, quality and performance and that requires stopping to sharpen the saw.
The worse things are, the more important it is to make time for strategic activities such as education, tooling, diagnostics and infrastructure. Being too busy to attend technical education in your specialty is the best possible evidence that you need to attend.