The Challenge of Making Technical Decisions
One of the largest clients I’ve worked with over the years was a paper producer that owned numerous paper mills in Wisconsin that had lost most of their IT staff. It continuously produced several paper types, and if IT operations stopped for more than eight hours, mills would shut down. When a mill shut down, there was a complicated restart operation that was, to put it mildly, very problematic. A shutdown cost millions of dollars, quite understandably making the papermaker’s operations manager highly sensitive to any outage.
Countless times the phone rang late at night with an operator calling to report a problem; most weren’t serious but all needed attention. There were three rotating operators, all of whom acquired their manager’s paranoia, so the first step was to calm them down and gather facts while logging on to their system. In short order, I’d learned the system’s characteristics, and I made a point to ask for any relevant information from the operator console because I couldn’t access that from home.
Three of my staff members also provided this client support, and I divided support responsibilities based on skills. I sent each one to different software classes (they already had experience in their respective specialties), along with a user group called SHARE, where they attended sessions of their choice, filling out areas they felt they needed. We were well prepared, and we backed each other up, always ready to pitch in even if it wasn’t our specialty.
When one of us got a call and performed an initial assessment, that individual either determined and dispatched the right technician for the problem, or passed it on to me. Our support areas included OSes and related components, database/files and related utilities, third party products, and online systems and hardware. While this was a useful way of dividing support, each of us had substantial overlap, and two or more of us usually ended up working on the problem.
This skill-based design served us well for problem resolution as well as product installation, maintenance, tailoring and implementation. Our client retained responsibility for application development and support, and we interfaced with them regularly regarding function and debugging/performance. The client primarily used vendor software, but there was a lot of tailoring to make the products work the way the client wanted. We would occasionally help with this.
Technical Decisions and Technological Decisions
When it comes to big decisions in an IT enterprise such as the aforementioned paper producer, I believe there are two types:
- Technical decisions. These decisions are tactical, requiring solid knowledge of IT hardware, software, network, operations, procedures, applications and more. When making technical decisions, a manager needs a limited working knowledge of problem resolution, performance management, project planning, system character, backup/recovery, component interrelationships and interaction, priority of business processes, and other unique organizational characteristics. Lower management levels usually make technical decisions.
- Technological decisions. Technological decisions are strategic, requiring in-depth knowledge of company charters, business processes, strategic objectives, financial structure and working business plans. IT facets include thorough knowledge of IT operations, industry trends and projections, IT budgets, capacity planning, cost/benefit analysis, early installation programs, IT strategic plan, existing contracts, user agreements, UIs, and most importantly, leadership. Upper level management makes technological decisions.
A Good Organization Begets Good Decisions
The papermaker engagement I described earlier serves as a good model for managing an IT enterprise; it’s a solid foundation for making good technical decisions. A good analogy is a professional sports team, where you recruit a group of highly skilled individuals, compensate them well based on performance, give them an opportunity to excel and establish goal-based objectives like pursuit of excellence, teamwork, commitment, and tenacity.
The first step to making good technical decisions is to recruit, define, evaluate and/or optimize the technical support infrastructure, and then determine staff qualifications and steps to achieve those necessary qualifications. Having a strong, committed and well-trained staff who is given clear software, hardware, applications, and operations support roles is the cornerstone of good decision making. These individuals will empower a good manager if the manager empowers them, too.
The next step is to gain in-depth knowledge of IT software, hardware, the network, applications and business processes your unit will support. Asking your staff to present these items is informative, and it’s a great way to get them involved with the components. It can also initiate a camaraderie that leads to a strong sense of teamwork, and can spark ideas for improvement, new procedures, and enhanced operations.
Quality Technical Decision Making Is an Art
The day eventually came when we had the big outage we’d so dreaded; a hardware failure shut all computer processing down, and I spent most of my time mollifying the papermaker’s operations manager, who was calling every five minutes. My staff and I couldn’t fix the problem, because we had neither the training nor the necessary parts, but IBM treats a situation like this as the highest priority.
Within four hours, IBM had flown in the parts and got the customer engineers onsite. Within another hour we were re-initializing IT systems and didn’t even come close to shutting a mill down. Just like all other outages and difficulties, system upgrades, or application enhancements, we made technical decisions that worked. Teamwork, education, respect, good pay and experience can result in the right technical decisions.
You’re Only as Good as Your Staff
One of the biggest mistakes I’ve seen IT managers—and managers in general—make is the arrogance to go it alone. Getting promoted is great for the ego, but not when it results in bad decision. Besides, other staff members have information or insights a manager doesn’t. When a manager doesn’t turn to others, it can lead to uninformed decisions with long-term and adverse consequences for everyone involved.
Education invigorates a department’s members to become a trusted, invaluable tool in technical decision making. The discipline we work in is very intellectually challenging, but IBM and other IT vendor education is excellent. When I joined IBM, I completed several months of education early on, and I went from neophyte to expert in the product set I supported. User groups like SHARE are even better, because attendees can select what sessions are really pertinent, they get a chance to rub elbows with their peers and they can pick up invaluable recommendations.
Establish an Atmosphere of Trust and Teamwork
A department functions best when it’s collective, and encourages a feeling of family—a lesson I learned in my IBM days. I did everything I could to see my department flourish during my papermaker engagement, and this attitude extended to the client’s remaining systems programmer and manager until they finally left the company. We depended on each other, we bounced ideas off one another, we brainstormed and we shared the dismay of an outage, doing everything possible to eliminate them.
This is not to say I or the papermaker manager didn’t make decisions on our own; indeed, snap decisions had to be made and they were. There were times we disagreed, and in this case I usually deferred to my client and overrode my staff when necessary, with caveats as appropriate. But we were still a team, we always respected each other and we always treated each other as professionals. It’s amazing what people can accomplish when they pull together.