Monday, August 28, 2017

My Top-10 Leadership Lessons: From My Hindsight to Your Foresight

My Top-10 Leadership Lessons
From My Hindsight to Your Foresight
Mark Katsouros
August 18, 2017

For 30+ years, I’ve been leading people, and I’ve had some great leaders, and some not-so-great leaders, myself.  These are the most important lessons I’ve learned over that time period (and, believe me, I’m still learning):
  1. Do what you say you’re going to do.  Be careful about sharing half-baked ideas that may be misconstrued, but default to transparency.  Above all else, demonstrate trustworthiness.  Without trust and integrity, you will not survive as a leader.  Heck, you may not survive as a human.  Live your values and ensure they’re aligned with those of “the business,” otherwise you’re in the wrong job or, more accurately, working for the wrong employer.
  2. Be accessible to, and genuinely, authentically, deliberately care for, your people.  If you can’t do this, you’re simply not qualified for people leadership.  This requires emotional intelligence and empathy.  These are learnable skills, but you have to desire them.
  3. Provide the vision (“the what”) and empower your folks to find the road to get there (“the how”), helping them manage hurdles (removing hurdles for them) without micromanaging them.
  4. Don’t do “more with less,” but rather do either “less with less” or “more with more.”  This means that you have to prioritize and/or justify additional resources with data.  It doesn’t mean that you don’t do everything you reasonably can to optimize and constantly improve efficiency, but, let’s be real, the calculus of doing “more with less” is that you’re eventually trying to do “everything with nothing.”  Align with strategy.  Insist on resource sustainability.  For example, approved CapEx, to stand up a service, without approved OpEx, to run/sustain it, is deadly.
  5. Demonstrate humility vs. hubris.  Give credit and take blame.  Pro leaders know which pronouns to use, and when.  (Hint:  Default to “we” unless talking about blame, which should always be “I.”)
  6. Aggregate viewpoints vs. dictate decisions.  This is why diversity is so critically important.  It is our differences—our different cultures, experiences, knowledge, perceptions, and perspectives—that help create the most complete views and ultimately foster the best decision-making.  And there’s a balance between building consensus and making reasonably prompt decisions.  The key is to be clear up front about the process (e.g., “voting” vs. “advising”), and to own your decision, especially if it turns out to be the wrong one.  (See #5 above.)
  7. Teaching is learning, and growing others fosters self-growth and a culture in which people want to work/stay/perform.  Coaching (helping your employees come up with solutions on their own) and mentoring (helping your employees leverage your experiences and learn from your mistakes) are inherent responsibilities of leaders.
  8. In any profession, but perhaps most especially in IT, subject-matter expertise demands constant evolution/training.  So, stewardship of skillsets is part of our overall resource stewardship responsibility.
  9. Help your folks maintain a healthy work-life balance.  Work ethic and job passion are great, but performance has to be sustainable.  Happy, healthy, balanced employees are your best performers.  Burned-out employees are obviously your worst.  And YOU’RE at least partly responsible for which one each becomes.
  10. Even with balance, you and your employees spend an inordinate amount of time together at the workplace.  Help your employees have some fun there.  I’m not talking about forced platitudes here, but rather simple perks that demonstrate you care (e.g., leaving a candy bar on someone’s desk for his/her birthday, or bringing donuts to a project meeting), genuine celebrations that help build team comradery (e.g., an annual picnic), team recognition events that sincerely show your gratitude, and simply injecting humor (without overdoing it) to keep things light.  Tell stories, help people relate what they do to something positive, make fun of yourself.  Humor reminds us that we’re human, fosters humility, and provides a far healthier emotional outlet than, and can even replace, conflict and workplace politics.

Ultimately, your job as a leader is integrity, empathy, vision, strategy, portfolio management, prioritization, resource optimization, humility, knowledge aggregation, employee stewardship/empowerment/recognition, overall sustainability, and aligning employee growth aspirations with the needs of the business.  Sure, it’s a long list, but your employees and the business need all of these things.  Don’t let them down.

Mark Katsouros is the Director of Service Design & Development 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.

Sunday, November 3, 2013

7 Things You Should Know About Emergency Notification Strategy

As the CIO at her university, Emma is expected to be the IT service provider of emergency notification, not only towards her institution’s Clery Act compliance, but also to support the institution’s goal of keeping its community as safe as possible.  The institution is a large, public, research university, with tens of thousands of students, faculty, and staff, so an on-premise solution seems unrealistic, given how taxing it would on the institution’s own infrastructure to initiate notifications for such a large constituency.

As Emma and her IT team, along with representatives from University Police, Public Relations, Risk Management, and General Counsel, search for the right technical solution to meet the institution’s emergency notification requirements, it soon becomes apparent to everyone that the technology is actually one of the easier components of this undertaking.

With the stakes as high as they can be, valuable lessons are learned, not only along the road towards the technical implementation, but also in terms of defining the actual policies, procedures, and roles surrounding this critical function.  Learning from these lessons results in a robust, optimally effective emergency notification implementation and set of procedural best practices, keeping the institution’s community informed of threats to public safety and thus as out of harm’s way as possible.
Multi-Modal vs. Single-Modal
Some of the hosted, or SaaS (Software as a Service), emergency notification solutions focus solely on text messaging, in the form of mobile phone text messaging, or Short Message Service (SMS), and email.  While SMS/text might be the most reliable, scalable modality, it should not be the only one upon which your institution relies.  With a broad range of available messaging options and notification technologies, providing a multimodal solution dramatically increases the chance of reaching more people sooner, not only because of the diversity of individual communication preferences/capabilities, but also because of the greater resiliency achieved in not relying on only one or two communication infrastructures.  In addition to text, consider landline and cellular voice, indoor and outdoor loudspeakers/sirens, digital signage, websites, social media, and others.  In addition, all of the modes should be controllable from a single console (or as few control points as possible) in order to reduce the time it takes to initiate a multimodal notification.
Emergency Only vs. Casual/Other Use
No spam!  And, even if people opt in to receive non-emergency messages, “mixed messages” dilute the most important stuff.  There are plenty of other mechanisms for non-emergency announcements, such as LISTSERVs and websites.  Reserve your Emergency Notification System (ENS) for emergencies only, so people will treat those messages as having the utmost importance.
Templates vs. On-the-Fly Wordsmithing
There is no time for a well-thought-out, well-crafted message during an emergency, so do that in advance and in the form of pre-approved templates for ease.  You’ll want to establish a broad collection of templates, that account not only for all foreseeable emergency scenarios (e.g., active shooter, armed suspect, bomb threat, earthquake, flood, hazmat, hurricane, tornado, winter weather emergency, etc), but also for the various modalities (e.g., email, enunciated voice, text, tweet, etc).  This also affords buy-in on the wording from all major stakeholders, from Legal to Public Relations to Risk.  Choose an ENS that supports easily-used templates.
Text-to-Speech-Enunciated vs. Recorded-Speech Notifications
Just as wordsmithing an appropriate message from scratch is difficult during an emergency, trying to record a calm, cohesive voice message during an emergency can be equally challenging, and variable scenario specifics, such as location, prevent you from recording in advance, so leverage text-to-speech enunciation, which has come a long way.  Some systems do support a pre- or sponsor-message, which can be recorded by a voice of authority, like “This is University Police Chief John Doe; please listen to this important alert.”  This tends to add some credibility to the machine-generated message that follows.
Opt-out vs. Opt-in
This is the difference between having a near-100-percent subscriber base and a near-zero subscriber base.  Default to having everyone signed up, for all modalities, and have them opt-out where they want.  When their actions do not mimic their intentions, your constituents are far less vulnerable having not opted out vs. having not opted in.
Policies and Procedures vs. Just Technology
Again, the technology is the easy (or at least easier) part.  Fully developing and documenting your emergency notification policies and procedures, including identifying who is authorized to initiate notifications and who is trained in the mechanics of sending them, is critically important.  Well-documented communication and marketing plans, testing procedures, and overall notification policies are critical to ensure consistent on-boarding, a verifiably functional system, and a clear understanding of when and how the system will be utilized.
Consistent and Explicit vs. Irregular and “War of the Worlds” Testing
Notifiers should literally test at the start of every shift by sending a test message to themselves, and those messages should never mock a real emergency scenario, just in case they somehow are distributed by accident.   This regular testing ensures that notifiers have the access and the familiarity they need to competently and swiftly initiate a notification, and that the system, with all of its complex integrations, continues to function as expected.
This work is licensed under a Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 License.

EDUCAUSE is a nonprofit membership association created to support those who lead, manage, and use information technology to benefit higher education. A comprehensive range of resources and activities are available to all EDUCAUSE members. For more information about EDUCAUSE, including membership, please contact us at or visit

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.

November 2013

Friday, November 16, 2012

IT Service Metrics 101

IT Service Metrics 101

What to Measure, and How, When, and Why to Measure It

Written by Mark Katsouros.

November 13, 2012

As IT service providers, we all know how important it is to develop good metrics.  Without meaningful measurements, how are we to gauge our level of performance, and thus how we improve, at delivering the services most needed by our customers?  And, yet, it seems that so few of us are doing this correctly, if at all.  In order to deliver the most value to our institution, we must know which services will do that in the first place (something that is always shifting), how efficiently and effectively we are delivering those services in order to be competitive with alternatives, and how adequately we are managing/monitoring services in order to maximize our provisioning and support capacity, and respond to growth in demand.

Know the Vernacular:  Metrics vs. Measurements

These two terms are not interchangeable, and a lot of people get them confused with each other, but it is important that we are all speaking the same language.  This is really straightforward, actually.  Metrics are the things you want to measure—the variables.  Measurements are the actual data—the values.  As a simple example, height is a metric, and 6’2” is a measurement.  That example metric, and the measurements taken over time, can be used, for instance, to determine how fast a child is growing (or to identify some other trend).  Trends are the real value in all of this, and are discussed further below, in more depth.

The Four Critical Categories of Metrics

While some might argue that there are more, I have found that most every meaningful metric falls into one of four high-level categories:  (1) Capacity, (2) Performance, (3) Relevancy, and (4) Satisfaction.  The first two types are typically gleaned via operational measurements—instrumentation, monitoring, and logging.  The latter two types are best gleaned via customer feedback—subscription rates and satisfaction surveys.  They are all truly critical, and are somewhat interwoven, but let us look at each one independently:
  1. Capacity generally refers to quantity—how much of a finite resource is being consumed.  In the case of IT service metrics, this resource is a service (or an identifiable, finite piece of a service, such as infrastructure).  How much bandwidth is being consumed?  What is our CPU utilization?  How much disk space or memory is being utilized?  (And, of course, how fast are these numbers growing?  Again, trends are discussed further below.)
  2. Performance, in the context of IT services, is mostly about uptime and reliability, but it is also often used to measure how “healthy” (fast, error-free, etc.) a service is.  How many nines of uptime have we achieved?  How quickly did the data arrive?  How many packets were lost?  What is the quality of the service?  Are we meeting the performance expectations identified in our service level agreements?
  3. Relevancy gauges how dependent your customers are (or their work is) on a particular service.  This metric is most critical in terms of distinguishing levels of importance, and thus prioritizing services—which ones you should continue to provide and, perhaps more importantly, which ones you should not (or which ones you should change to better meet your customers’ needs).
  4. Satisfaction should be pretty self-explanatory.  This is how satisfied your customers are with a particular service—how they perceive your delivery of it, or their level of gratification.  Without this metric, you are only guessing at how well your service delivery is received by customers.  Of course, this metric is only applicable to the services that customers deem most relevant to them.  (No need to ask, obviously, how satisfied someone is with a service having little importance to his/her job.

The Importance of Continuous Measurements towards Trending

Metrics are the means to an end, or, rather, the means to a trend.  While each of these categories is critical, it is the slope of the lines plotted across time from which you can learn the most about your services.  Is the service moving towards more importance or less?  (Is it time to dedicate more resources to the service, or plan its end?)  At what rate are the service’s resources being consumed?  Are we getting better or worse at delivering it?

Taking a measurement in time, for example, of a satisfaction score might yield an average score of seven on a scale of one to 10 (with one being poor and 10 being excellent).  While seven might seem like a decent average score on its own, it could be a sign of serious trouble if the past several average scores have been nines and 10s, or a welcomed sign of great improvement if the past several average scores have been extremely low.  Which kind of attention (or celebration) to give that average score of seven is totally based on the context gleaned by the trend.

Knowing when to end services (one of the most significant challenges in IT organizations), how to manage just-in-time (optimal) resource growth, how much to focus (resources) on improving service provisioning and/or customer service skills in general, and understanding the overall fitness of your service management (and service portfolio management) processes all comes down to metric-based trends.

A Valuable Tool:  The Service Survey

As mentioned previously, service subscription rates and customer surveys provide the best metrics for identifying trends to gauge service relevancy.  And, essentially, the only surefire way to know what customers think about your organization’s ability to deliver services is to ask them.  A simple, consistent, regularly-scheduled survey, that asks two critical questions for each service, is all you need.  Those two questions are:

Ask these two questions for each service that can be ordered from your service catalog.  Additionally, depending on how centralized your IT organization is, you may want to ask some questions to segregate the results into appropriate demographics.  For instance, if you are the central IT service provider for your institution, you will likely want to specifically differentiate between the feedback of your institution’s other IT service providers (who might serve as liaisons between you and their department’s end-users) and that of true end-users.  You might have totally different staff serving these two very different constituencies, or a very different provisioning process for each of them, so looking at this data separately likely makes a lot of sense.

“What’s the Frequency, Kenneth?”

Dan Rather references aside, the frequency by which one takes measurements is critical to maximizing the meaning of the trends produced.  If measurements fluctuate dramatically (i.e., have a high standard deviation), they need to be recorded more often to minimize the likelihood of drawing the wrong trending conclusions.  More importantly, you want to ensure that you can appropriately react to trend changes in a timely manner.  So, the frequency of your measurements needs to account for the time you might require to sufficiently take action (e.g., increase capacity, add redundancy to deal with an availability issue, improve customer service training, or even kill a service).

In terms of the above relevancy and satisfaction survey, one should balance the need for frequent measures with that of not asking too much of one’s customers (by over-surveying them).  One solution is to divide your customer base into 12 groups and survey one group per month, thereby surveying every individual only once per year, but still gathering monthly points on the graph towards more rapid trending.  Of course, this assumes that your customer base is substantially large—large enough so that one twelfth of it would still provide reasonably large sample sizes, and thus un-skewed results.

A Fifth Metric Category

In addition to the four critical categories of metrics above, some count costs among the set of formal metrics that help expose important IT service trends.  IT cost metrics can include financial measures such as labor, software licensing costs, hardware acquisition and depreciation, and data center facilities charges, all mostly from general ledger systems, and combines these with operational data from ticketing, monitoring, asset management, time tracking, and project portfolio management systems to provide a single, integrated view of IT costs by service, department, GL line item, and project. Costs should further be broken down between capital (one-time) and operational (ongoing) cost elements.  In addition to tracking all of these costs, combining them with usage and operational performance metrics can provide a measure of value or Return on Investment.  Costs, budgets, performance metrics, and changes to data points are tracked over time to identify trends and the impact of changes to underlying cost drivers in order to help managers address the key drivers in escalating IT costs and thus improve planning.

Storing Measurements and the Grand Scheme of Things

Besides collecting, and gleaning meaning out of, metrics, one of the challenges many IT organizations seem to face is being able to summon and share those metrics when needed/requested.  This is a critical part of utilizing metrics successfully, as IT organizations are often large and complex, with completely different employees or groups supporting different services.

It is important to recognize the hierarchical relationship among metrics and two other fundamental service resource layers, (1) the service catalog/portfolio and (2) Service Level Agreements or, often, commitments / Operational Level Agreements (SLAs/OLAs).  To be clear, the service catalog is a public-facing menu of orderable services and the service portfolio is a more-internal superset of the service catalog that contains services (internal, retired, etc), service attributes, and detailed data, not typically present in the catalog.  SLAs are the performance and response commitments made to customers of the service, and OLAs are agreements between IT service providers that address roles, responsibilities, and response commitments.  Metrics should be leveraged to support SLAs/OLAs, and, of course, also support other service measurements more directly.  The aforementioned hierarchical relationship is a one-to-many-to-many structure:
In addition to storing detailed metric data in the service portfolio, a higher-level view of metrics and metric trends are often made available in the service catalog.  In essence, they demonstrate that you are meeting the service levels to which you have committed, and measuring other important aspects of the service.  Perhaps equally important, this provides a single authoritative source of metrics for both customers and service owners.

A Few Words of Caution

There are two risks, even dangers, of which you must be cognizant:

First, developing metrics, towards enabling better, data-driven decisions around a service, needs to be approached in a top-down fashion—with service level agreements/commitments (and perhaps other service goals) driving what you collect.  One of the major rookie sins of defining and gathering metrics is to start with those that are simply easy to gather, in which case you can certainly end up with voluminous amounts of data, very little of which may actually be useful.  Instead, start with your service goals—SLAs/OLAs, provisioning efficiency, customer satisfaction, and so on, and then identify the metric data that will help you gauge how well you are meeting those goals.

Second, developing the processes and structures for gathering, storing, analyzing, and sharing metric data requires a fairly monumental effort.  The very last thing you want to do with respect to metrics is to not respect the metrics, i.e., go through all of this effort, only to end up not utilizing the results.  More than just a waste of time, this will create a huge morale suck for those employees involved in the effort, as well as those service subscribers/customers who would likely benefit from it.  Act on the metrics and metric trends you expose.

Limited resources demand that our actions have a purpose, and that our purpose results in action.


Identifying appropriate metrics, taking reasonably-frequent measurements, and monitoring for trends, particularly changes in trends, is the only truly-reliable way to not only improve services towards meeting customer demands and expectations (and ensuring that you are meeting service level agreements/commitments), but it is the only way to know which services deserve your focus and resources, and which ones deserve to be placed on the chopping block (to free up focus and resources for more important things).

Capacity and performance metrics are typically gleaned via operational measurements—instrumentation, monitoring, and logging.  Relevancy and satisfaction metrics are best gleaned via customer feedback—subscription rates and satisfaction surveys.  Cost metrics, both capital and operational expenses, are obviously best gleaned from financial systems—general ledger, payroll, order/trouble tracking, and service and project portfolios.

And do not gather a bunch of metric data just because you can.  Gather it in support of service level agreements/commitments and other specific service goals.  Then deliberately and visibly act on them!  In other words, start with your high-level service goals and then identify the metrics that can help gauge how well those goals are being met.  Again, action without purpose is as detrimental to good service management (and employee morale) as purpose without action.

Finally, remember that those trends and trend changes tell the real stories, are what help us adequately grow (or shrink) services, and ultimately maximize our effectiveness and efficiency in delivering the important services on which most every business process of the modern enterprise so depends.

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.

Wednesday, December 1, 2010

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.