Lessons in IT Leadership: Doing Less with Less and Failing for Success

Spring, 2011

Vol. 15, No. 1

Lessons in IT Leadership:

Doing Less with Less and Failing for Success

Mark Katsouros

The Pennsylvania State University

At first glance of the title, one might construe this as advocacy for lowering performance expectations and fostering failure. But, read on to get the real leadership message of proper resource utilization, task prioritization and planning, and a positive workplace climate.

Ticking Time Bombs

Most of us have felt the pressures building for some time now. The information technology demands and expectations of our customers continue to expand, while the resources at our avail, particularly human resources, continue to dwindle. The age-old mantra of “doing more with less” has been taken to an unprecedented extreme, whereby most IT organizations have become so single-threaded, and stressed in so many areas, that they resemble ticking time bombs. I’ve heard many essentially say, “we are beyond lean and mean; we are anorexic and vicious.”

One has only to look at recent events in the news to see the eventual results of doing more with less: New automobiles with “unintended acceleration” problems, children’s medicines with dangerously higher concentrations of active ingredients than specified, hundreds of millions of eggs potentially tainted with salmonella, and then, of course, let us not forget the oil crisis in the Gulf of Mexico. What is interesting, and sad, with all of these examples, is that spending more money on quality control and disaster recovery planning would have been so much less costly (in many ways) than the results of not doing so. Perhaps some of these corporations, in order to maximize profits, knowingly gambled that such unlikely events would never occur or would occur so infrequently that the overall financial impact of correcting them reactively would still be smaller than preventing them in the first place. Whether greed or survival is the driving force, the ticking time bomb of doing more with less will eventually, inevitably explode.

So how can we avoid such ticking time bombs?

Doing Less with Less: Thoughtful Planning and Prioritization

I started my IT career as a software engineer, and it was not long before I realized that effective and efficient application development involved approximately 90% planning and 10% coding. While that ratio may seem extreme for most undertakings, it is probably not far off the mark. And planning includes anticipating every possible path in the application—intended and unintended—and how to deal with each, proactively. The idea is to provide a reliable end-user experience and reduce the application’s support burden. Thoughtful planning maximizes the efficiency and effectiveness of our resources, and one can ill-afford anything less these days.

Most importantly, finite resources must eventually translate into finite service offerings, towards ensuring that adequate time is available to thoughtfully, thoroughly plan each service, from provisioning to support. For an IT services organization, that means several things:

(1) Prioritizing services – Services must align with the institutional mission. If a service is not contributing to that mission, either directly or indirectly, then it is time to consider outsourcing or just plain eliminating it.

Some look towards communication and collaboration as an area ripe for outsourcing and/or casting out to the cloud, but we must remain cognizant of the fact that communication and collaboration are at the very core of the higher ed mission, so you want to keep control of those services to more easily integrate them with the likes of your learning management, student information, technology classroom, research collaboration, and emergency notification systems. But consider services farther away from the institutional mission, and establish standards, to the extent possible in higher ed’s diverse environment, to avoid saturating resources with supporting lots of “one-off” services.

(2) Keeping services simple – Operational complexities are a resource killer. Services must be architected towards keeping them as straightforward as possible. That may mean sacrificing features and flexibility for scalability and troubleshooting ease.

This is a huge challenge for technical organizations that are understandably customer-service-focused (wanting to say “Yes” to every request) and that have the technical know-how to develop the most complex of solutions. But, as in the standards argument above, extraneous features that don’t serve the broad intent of the service (and the vast majority of its users) can greatly diminish one’s capacity to support them. Not too long ago, a group of small appliance designers were trying to figure out a way to keep toasters from burning toast. A hefty combination of various mechanisms and sensors were explored, ultimately greatly increasing the complexity (and cost) of their toaster, to the extent that it was too expensive and too difficult to use, and had too many points of failure. Recently, a far simpler idea came to fruition: A clear, glass toaster is now available, whereby one can simply see when the toast is suitably toasted. As the French philosopher, Charles Péguy, is known to have said, “It is the essence of genius to make use of the simplest ideas.”

(3) Documenting dependencies – It is critically important to fully understand dependencies among services in order to achieve the above two items. Services should be categorized in layers, from base infrastructure to applications, and their dependencies, including startup and shutdown sequences, fully documented.

This documentation must be readily available during change events, when documented dependencies are necessary in order to avoid surprises, but it is even more important to have this in the event of a disaster, when time is short and stresses are elevated. During Eastern Iowa’s flood of 2008, the University of Iowa’s Information Technology Services department was able to orderly shut down services, starting with the least critical, residing in a datacenter where uninterruptible power stores and availability became limited. This was accomplished thanks to a pre-documented list of critical and important services, and their associated dependencies.

(4) Leveraging the browser as the client – Whenever possible, utilize the web browser as your client platform. This shifts the burden of operating-system nuances (including those of mobile devices) from application developers (your staff) to browser developers (who are already addressing this challenge).

Of course, mobile applications will need to be designed specifically for smaller screen sizes, but avoiding platform specific nuances, in spite of additional capabilities, will hopefully aid in keeping your applications browser- (and smart-phone-) agnostic.

(5) Documenting your vision – It may be cliché, but a strategic plan is critical towards knowing where your organization needs to be going. Creating a vision with your leadership team and documenting that vision is necessary to ensure that everyone is working towards the same goal(s). A unified team is a productive team.

This is most certainly one of the most important undertakings upon which your organization’s leadership can embark. The aforementioned decisions on priorities, and service simplification and standards, not to mention every other decision you and your employees make, should be guided by what has been documented as the direction and priorities of your organization. Otherwise, your organization’s reason for being should, and will, be questioned.

(6) Separating engineering and operations – To make progress on your strategic plan, you need to ensure that the burning tactical demands, which must be addressed (operations), are not a constant excuse to ignore what you need to be doing—essentially “engineering” your strategic plan. Leadership gurus call this “managing the important over the urgent,” and it seems obvious that this is much more easily accomplished by explicitly, organizationally separating the two.

IT service organizations seem to be reorganizing fairly frequently these days. Some of these efforts attempt to make customer contact points more clear. Some try to combine like units in an attempt to take advantage of functional overlap and reap greater economies of scale. And some are simply misguided attempts at keeping employees “change resilient,” with no real end benefit resulting from the disruption. By far, the most effective reorganization that an IT services organization can undertake towards making real progress on its strategic plan is one that helps cleanly segregate the operational support side of the organization and the side that is responsible for engineering, architecting, and evolving services towards achieving the plan’s goals. One provides service care and feeding, and the other defines the services requiring care and feeding, and how that care and feeding should be performed. ITIL (Information Technology Infrastructure Library) standards and practices provide an excellent framework for this separation.

Failing for Success: Coaching vs. Persecuting

There is another critically important aspect of competent leadership, and that is allowing people to fail—not as in the above catastrophic “recent event” failures that are essentially a result of negligence in the form of poor planning, misguided resources, shortcuts, and/or a lack of proper documentation/oversight, but rather as in an individual’s failure in spite of that individual trying to “do the right thing.” And this is in the context of reactive, not proactive, behavior. Obviously, a good leader should not just stand by and let (significant) failure happen when stepping in to help can prevent it. Rather, allowing people to fail, in this context, means not persecuting people for failure after it has occurred. The most successful people in the world did not succeed because of a lack of failure, but rather they succeeded because of the powerful lessons learned from failure itself. You want employees to innovate, take reasonable risks, and leverage their uninhibited creativity. The greatest innovations towards new efficiencies and increased effectiveness, thereby maximizing the resources your organization does have, come from employees who are not afraid to do these things.

In order to create such a culture, you, as a leader, must look for the opportunity in failure. The old expression, “Kiss a winner, hug a loser,” applies tremendously here. Failure provides an amazing leadership opportunity: To embrace the lessons, together—as coach and coached. A constructive approach to this will yield a positive outcome. Lessons will be learned, remembered, and likely not repeated. A destructive approach to this will yield a negative outcome. Sure, lessons will be learned, remembered, and likely not repeated, just the same. But the problem is that the innovation, reasonable risks, and uninhibited creativity will end, with their marvelous benefits never to be realized. One approach builds up, the other tears down. One is encouraging, the other is discouraging. One is supportive, the other is undermining. Great leaders maximize the opportunities for learning (and thus improving), focus on the positive, and eliminate the harsh persecutions.

Embracing, and learning from, failure may be the single most important behavior that a leader can exhibit. It will undoubtedly help define the culture of your organization, directly impact the creativity, confidence, and dedication of its employees, and ultimately mark the difference between a healthy organization and an unhealthy one. The healthy organization is one that continuously evolves and stays relevant, not so much by reorganizing, unless truly necessary/appropriate, but more so as a result of the continuous optimization achieved by the aforementioned employee creativity, confidence, and dedication. The unhealthy organization is one that is likely doomed to fail by creating an environment in which the boundaries of “safe” (i.e., risk-free) activity become so restrictive, that sustained progress and evolution are not only impossible, they are also simply, and very dangerously, feared and thus undesired.

Learning from the Leaders of Your Past (and Present)

Learning from past failures is certainly not the only way to succeed as a leader. Most all of us have worked (or do work) for some great leaders and some not-so-great leaders. Think about the attributes of each, and focus on the positive ones. The great leaders are great because they are able to unite and inspire people to work hard towards a single mission. They make expectations clear, and praise often, with genuine appreciation. They are transparent—sharing information, fostering open communication, demonstrating integrity, and building trust. They are positive and have a high emotional intelligence quotient, or EQ—the ability to empathize with others and truly relate to people. They exercise humility over hubris. And they know to use “we” vs. “I” in reference to successes.

Happy employees make better, more efficient and effective employees, and are obviously much easier to retain. Happy customers continue to choose your services and often provide free marketing, as people often enthusiastically share good experiences. Your job as a leader is to aggregate viewpoints towards setting the organizational direction, to work on (vs. in) the organization in order to get there, and to ensure the happiness and satisfaction, to the best of your ability, of your employees and customers, within the confines of that direction.

In summary, plan, prioritize, forgive, learn, and relate. Do these things, and your organization, as well as you as a leader, will ultimately succeed.

 

Mark Katsouros is the Director of Network Planning & Integration at the Pennsylvania State University. The opinions expressed in this article are his and are not necessarily shared by the University, but they just might be, as PSU is a pretty awesome institution.