We all start out trying to be proactive. We plan to control our lives. We make the plans and somewhere during the execution phase we get off track. We run into some unplanned snag or snarl. We slip into a reactionary mode to address the problem. We try to get back into our planned, proactive mode of operation but sometimes the next issue comes along and we're off to react to it.
Although there are areas of IT that would seem incapable of escaping the reactionary rut such as, for instance, a help desk, the truth is that we can all influence our areas into more proactive and therefore less frustrating modes of operation. Let's explore what being proactive is, why it's important, and how to get your group back on track.
Why is proactive is better?
While I firmly believe that control is an illusion, it's a useful one. Assuming a proactive stance to try to control, or at least influence, the future into a positive direction is effective at reducing the overall workload. That is an addition to reducing stress caused by unforeseen circumstances. While being proactive, like anything else, can be taken to an extreme, in most cases proactive time spent preparing for a problem, developing an approach, or understanding the environment is immensely powerful in terms of its ability to save time in the future.
There are clichés that describes the power of proactive thinking. Perhaps the most famous, "a stitch in time saves nine" and "an ounce of prevention is worth a pound of cure" seem to make no allowance for anything but savings when taking a proactive stance. The opportunity to solve an issue before it becomes a problem can be greatly beneficial.
However, the realities of today's economy and the need to maintain a lean organisation mean that we can't afford to go to an extreme with being proactive; we cannot be prepared for every eventuality. We must do our best to find a balance between proactive planning and a reactionary fire-fighting mode. We know that proper planning can prevent much of the impact of a problem, if the problem comes along. However, if the problem never happens the time spent doing the planning is lost forever.
So when efforts are focused on understanding, planning, and preparing for situations which will probably come to pass without action to stop them and ones that can be difficult to be successful in, proactive thinking is essential. In planning for the case that will never happen, it's like buying flood insurance when you live on the top of a mountain. Still, on balance, we as IT professionals don't do enough planning as evidenced by our long workdays, or late schedules and our budget overruns.
Balance or trap
In today's economy every team is expected to have both a proactive planning component and a ready, reactionary component. Team members who are nearly always proactive are seen as unnecessary overhead because they're not solving the real problems of today. They are sometimes seen as idealists who never seem to be around when problems occur. Conversely someone who is always reacting and not proactively planning is seen as someone who is working hard but not necessarily working smart. In other words, their diligence is rewarded but the fact that it is necessary due to lack of planning is shunned.
The trick with being proactive is, therefore, not in being proactive all the time but in finding a balance between proactive periods of time and reactive periods of time. The problem is that being reactive prevents proactive behaviours. Being proactive requires a state of mind that psychologists call flow. It is a deep meditation or focus on the problem or on evaluating what the problem is. In other words, you need flow time to be proactive; time to become deeply involved with the problem. When you're reacting to the problem of the moment, you can't develop that flow
In Peopleware Tom DeMarco and Timothy Lister spend an entire chapter, Brain time versus Body Time, on the impact of interruptions on being able to get a deep involvement in a problem, called flow. They illuminate the problems caused by continuous interruptions as a common theme throughout the entire book. It's difficult to overestimate the impact of never having a time and place where you can enter flow and be proactive.
That is inconsistent with the reactionary fire-fighting mode that most of us find ourselves trapped in. We have little or no time when we can take a step back and evaluate the overall context of the problems we're firefighting to see if there's a way to solve all of them at one time. We don't have a chance to get into the flow of solving the problems.
Here in lies the trap. If you can't ever get into the flow then you can't really spend proactive time working on the core problems that you face. If you can't work on the core problems then you're doomed to chase your tail — spending all of your time reacting to the effects of the core problems that you can't ever identify much less solve.
In the introduction I introduced an area of IT where reactionary behaviour is the core of what must be done. Help desks are by their very definition reactive; they receive calls and react to them. However, there is another side of the help desk. It's a pattern finding aspect which seeks to classify the calls that are coming in and devise solutions or partial solutions to reduce the number of calls. Consider how many help desk calls can be eliminated by allowing users to reset their own passwords — or letting managers reset passwords for their employees. Or, how many calls can be saved by simply providing better instructions if there's a problem that many users have when printing a document?
So even in what would seem to be the perfect trap for reactionary behaviour there is the opportunity for proactive patterns. It is this way with every role in IT, especially...
For more, click here...
