Why SLA's need to just go away

During my years working in IT, I've had several stints where I've worked on the pure customer service side.  That's not to say that there's not a customer service piece to a highly technical role, or a management role, there is, and we ignore it at our peril. However, in areas of IT that are more customer facing, like a help desk, or desktop support, there's always more focus on customer service, and tools and metrics that help measure service and satisfaction.

Which brings me to today's subject, the service level agreement, or SLA.  My theory is that SLAs are evil and should be dispatched back to the bureaucratic hell from which they were spawned. Okay, that's a little harsh.  However, what I observe is that SLAs are divisive, and introduce an unnecessary element of contention into the relationship between customer service provider and customer.  And I think that's especially true when it's an internal customer service organization, like an IT help desk. 

So why is this?  The first issue is that SLAs are usually developed entirely within the customer service organization without any input from the customer. Think about it, did your internet service provider consult you when they decided on their SLA?  Did they include you in the decision to create four hour windows when they might show up to provide whatever service they're providing. I think not.  Now the reason customer service providers do this sort of makes sense.  After all, they know their resources, and  they know how long it takes to perform a particular customer service function, so it's a simple mathematical calculation.  And really well run customer service organizations adjust the SLAs based on feedback from (usually irate) customers, or lessons from other organizations. For example, the cable TV companies used to routinely have a full day window when the cable guy might show up, replaced by the four hour window that we typically now see. And some companies even have a two-hour window!

We also exclude customers from the development of the SLA because we're concerned that they'll ask for something unrealistic like immediate help. Well of course they will!  After all, who doesn't want an IT person at their beck and call?  But having a conversation helps us understand when that immediacy is critical and when it isn't, and it helps the customer understand our constraints. So if you must have an SLA, at least include the customer in the development or review of the agreement. 

The other issue with the the development of the SLA is that customer service organizations want to develop SLAs that they can meet a high percentage of the time. So let's think about how the conversation might go when developing an SLA for something as simple as a desktop support request.  "Okay, so the user emails a request, and it might take use 4 hours to get to the request because of our queue, then it might be a more specialized issue, so we might need Joe, and he's super busy, so we need another four hours, oh and what if he's on vacation, and then we might need to order a part from a vendor, and that takes overnight, and then it has to get through our Receiving department and then we have to schedule time with the client to change out the part.  5 days, that's our SLA, we can make that almost all the time". The thing is, we're developing the SLA for a worst case scenario that doesn't (or shouldn't) happen often. So most service requests actually are completed in a much shorter amount of time,  because they don't need Joe, or a part. But the customer hears that you have a 5-day SLA, and what they interpret is that when you call that team, they'll get back to you in 5 days. And frankly, that just opens your team up to ridicule.

My final issue with the SLA is that it is used in a defensive way by service providers. I was recently in a fairly contentious meeting between two groups on my campus.  The "customer" in this case has a well-earned reputation for letting things get down to the wire, and this situation was no exception.  They were handing something off to a service provider, and it was really at the last minute, actually, beyond the last minute. The service provider reminded them that they had a 5 day SLA, and basically said, if you don't get it in by X, you won't get it until Y. What the customer heard was, I'm not even going to try to do this in a way to accommodate your needs.  I decided I have 5 days to do this and I'm going to take every minute of those 5 days.  In fact, I'm fairly confident that the service provider more often than not beats the 5 day SLA significantly.  Even using different language would have helped in that case. 

I was recently in a meeting with a potential vendor and we asked about customer service. The presenter never once mentioned an SLA. What he said was, we resolve 1/3 of our calls within an hour, 1/3 within a day and 1/3 take longer, because they're more complex. I think that this is a more sensible approach.  So rather than providing an SLA, measure and publish your stats. It seems more reasonable to the customer. And it gives your team something more challenging, while still realistic, to aspire to.  So have an SLA if you must, but don't wave it in front of your customer.  Instead share your stats with them.  It's more realistic, and probably looks better too.  If it doesn't, well, then you have a different issue to address.

Great customer service? Or scary?

Several years ago, I attended a customer service training that was conducted by Dennis Snow.  Dennis is a former VP of Customer Service at Disney who is now a speaker and consultant.  His website (http://www.snowassociates.com/) talks about "creating magical user experiences".  He is a great speaker - if you ever get a chance to see him, jump at it!  He just talks about customer services topics, and really gets some key messages across.

One of the things I remember most from Dennis's sessions was the concept of "a moment of wow".  At Disney, Dennis says, they teach "cast members" to create moments of wow for their "guests".  That's what sticks in people's minds; not the great attractions, or the shows.  It's the little things.  For example, if a cast member sees a family where one person is taking a photo of the rest of the family, they're trained to go up to them and ask "may I take that photo for you" so that everyone can be in the shot.  It's the little things - the moments of wow.  Dennis challenged us to try to create moments of wow for our customers every day. 

At that time, I was in a high-level IT role at a university.  A few weeks after that training, we had an email issue that resulted in email being unavailable to a fairly sizable group of users.  Rather than communicate via voicemail or through a website (since we couldn't email them) I made a decision to get a list of the impacted people, divide it up amongst several people in the IT organization and actually call them.  We each ended up making 10-15 calls.  That's pretty easy.  And people really appreciated it!  When I called one person to let her know what was going on with her email account, she told me that I had given her a moment of wow by actually making a call instead of something less personal.

I decided to try this approach again more recently.  In this situation, we have a project to encourage people to change their passwords.  We've had a communication campaign with some success, but we still ended up with a set of people whose passwords didn't get changed.  Some of my team suggested cutting off their access to network resources.  That's so draconian.  Not saying that we would *never* do that, I just don't think it's the first place to go.  I suppose I'm more for diplomacy first and then war rather than the other way round. 

So I decided to do what I had done in the past.  We took the list of outstanding non-password changers and I started to make some calls. This time, though, it was less of a "moment of wow" feel for the people I called.  After all, in the previous example, I was calling them to apologize and give them an update.  In this example, I was calling them, well, sort of to nag them.  Most of them felt the need to apologize.  I could almost hear them turn to their coworker when they hung up saying "I can't believe the CIO had to call me to get me to change my password!". 

So I guess the moral of the story is to consider the message or personal situation when you're using the personal touch.  In the Disney example, if the cast member walked up to a guest right after they discard some trash and said "let me put that in the trash can for you", it wouldn't feel like such a wow moment.  I don't think my example was quite that extreme, but it had a somewhat negative feeling for people.  Live and learn!

The Consumer Digital Technology Footprint and its impact on enterprise IT

Last week, I attended Web Summit in Dublin, Ireland, where I participated in a panel to discuss this topic. The panel was part of Web Summit's EnterpriseX session, which focused on leaders in more traditional enterprises, rather than start-ups. Earlier in October, I attended Gartner Symposium, where this topic was addressed through many Gartner analyst presentations. At Symposium, Gartner presented their annual CIO Insights, developed from an extensive survey of almost 2500 CIOs across the globe.

According to Gartner's research, CIOs will need to focus on building Bimodal capability, or running a two-speed IT organization. This theme was raised repeatedly at my EnterpriseX panel. Consumer Digital Technology is highly fluid, and is in a constant state of change. For example, one of my fellow panelists was Chris Satchell, the Consumer Technology Officer for Nike. Chris is responsible for all Nike's consumer technology, including things like Nike's apps and Nike+. Chris's team had almost 4000 releases in 2013. This is a much different way of working than most traditional IT organizations. Hence Gartner's bimodal capability concept, or the advent of two-speed IT. The advent of consumer digital technology requires a very agile approach. After all, if there's a problem with Nike's app, the fix has to come fast - waiting months for a future release is simply not an option. On the other hand, ERPs are going to be with us for a long time. We do have to run back office functions, and that's not going to be handled by an app any time soon.

So how can we address the need to work in two different speeds? Gartner's research suggests that CIOs have begun to do so by exploring some Agile methodologies to meet these challenges. My panelists at EnterpriseX had some interesting perspectives on Agile. In some cases, even Agile isn't agile enough! And in other situations, applying Agile methodologies to a more traditional project has simply added an additional layer of management and oversight that hasn't really helped. One of my co-panelists described this as "using Scrum as a weapon". Other ideas included focusing on accuracy rather than precision. Traditionally, IT organizations have focused on the "perfect" solution at the expense of timeliness (and often never getting there). In the new digital world, perhaps we should focus on "good enough" where we can. As an aside, I find this concept of accuracy vs. precision to be highly applicable in the data world also. In traditional data warehousing, having exact data was highly prized and there was a real focus on data preparation, which naturally meant that it took time to provide that data to the enterprise. With big data, the focus is more on "good enough" - we're really looking at large amounts of data for trend purposes, so accuracy, rather than precision, works.

Ultimately, though, the discussion at my panel turned to how we might use things like cloud solutions to more efficiently manage the traditional functions, freeing up resources to invest in the digital technologies, which are fundamentally different. The concept of skunkworks-type teams was floated, teams that can deliver solutions without the weight of governance and change management that is truly necessary for enterprise solutions. Gartner's research suggests that business leaders want more growth and innovation, but IT budgets are not growing; so approaches like this seem like a realistic approach.

During his presentation at Web Summit, Lew Cirne, the CEO of NewRelic suggests using software to impact the top line of the business, and not just the bottom line as we traditionally have. "Use software on offense" was Lew's advice. In considering all these thoughts, it seems to me that we are moving to a two-speed IT, the "bottom line" software speed and the "top line" software speed. Not only are they two different speeds, but they're different approaches, and may require the introduction of new teams in the traditional IT organization.

So what does that mean for CIOs? Most of us are where we are because we've been successful in at the bottom-line speed, with a focus on precision. Now we need to focus on the top-line speed focused on accuracy. In my opinion, most CIOs embrace this challenge. Reading Gartner's research confirms that for me. CIOs recognize the need to renovate the IT core in order to make room for the new disruptive business models. According to Gartner, CIOs have big concerns around the availability of the talent required to execute these innovations, and I would agree that this is the major issue. As Gartner notes, there's no substantial new funding, so we won't be adding staff, and even if we were, these talents are in high demand and are expensive.

I don't have any real answers to these hard questions, I wish I did! But I do know that if CIOs don't find ways to operationalize this bimodal approach, IT will become less and less relevant in our organizations.

Leadership tips from a famous historian

This week I took the time to attend Educause. It’s a lot of time out of the office, so it’s important to get as much as possible out of it. This year, I enjoyed networking with my colleagues, meeting with vendors, hosting a poster session, being engaged with the Women in IT Constituency Group, and, of course, the sessions. But I probably got the most from the keynote by Doris Kearns Goodwin. I’ve seen her speak before. As an historian, she has studied several presidents, including Lincoln, LBJ, Teddy Roosevelt and FDR. She presents leadership tips from these presidents. This year, she came up with 10.

1. Motivate yourself in the face of frustration. Lincoln had failed at numerous things before he became President. Learn from failures and don’t give up.

2. Recognize the challenges that exist in the time and circumstance that you’re in and deal with them. Lincoln and FDR had to lead the country through wars. On the other hand, Teddy Roosevelt didn’t have that particular challenge, but he recognized that in his time, industry and conservation were the challenges that needed to be addressed. He recognized that and used his leadership in those areas.

3. Surround yourself with smart people who have different perspectives to yourself. Read Goodwin’s book “Team of Rivals” to see how Lincoln filled his cabinet with his rivals.

4. Take criticism with grace. Teddy Roosevelt listened to the criticisms leveled against him by the media of his day. He never took it personally; and still made time for even his harshest critics in the press.

5. Learn from your mistakes, and reflect on them.

6. Learn to laugh at yourself. Lincoln, in particular, had a great sense of humor.

7. Stay connected to the constituencies you represent. Don’t end up in an ivory tower. Make time for everybody, and above all, be accessible.

8. Timing. Know when to hold back and when to act.

9. Know how to relax. During the war, FDR had a cocktail party every night where discussions of the war were strictly prohibited.

10. Speak plainly. Communication is a critical skill for leaders, and communicating in a way that all people can understand and relate to. Storytelling is a great skill for leaders.

So there you have it. Good tips.

Presentation tips

This week, I found myself presenting to Faculty groups four different times. I also saw a lot of other people present, while I was waiting for my turn. We were presenting to groups that had generally been in long meetings - a half-day or a full-day - and were just seeing one presentation after another. So it was pretty easy just to make their eyes glaze over, which I did at least once! Here are some tips I got from this week's marathon presentation sessions.

Don't use Powerpoint!

Seriously, don't. People hate Powerpoint. And Prezi is no better. If you have things to say, just say them. Don't put them on a slide and project them, and then either read or reiterate them. If you want people to have a takeaway, do a handout. There is one exception. If you have images that are relevant to your topic, show them on a screen. For example, our Vice President for Campus Planning showed lots of campus maps and images of buildings that are in the works. So his main content was spoken, but augmented with images that brought it to life. And it was excellent - nobody glazed over during that. So I guess I'll amend my tip to don't use slides with just words on them.

Practice

When people are going to take their time to hear you speak, you should take the time to prepare. Especially if you're going to follow my last piece of advice and use few or no slides. You're essentially giving a speech. So practice. Give your speech over and over again. My family heard my presentations repeatedly during the week. I got all my tripping-over-words out of the way with them. You can also time yourself during practice. If you're given 10 minutes in a day long event, you should honor that. The only way you know if your speech stays within the 10 minutes is by speaking it. On a similar note, when I was interviewing to be CIO, I practiced my presentations repeatedly with my family. As a result, I am pretty sure my 18-year-old daughter can nail any CIO interview question!

Don't hide behind the lectern

In fact, don't stand back there at all. That thing is a barrier between you and the audience. Pick up the mike, if you need it, and come out from back there. If possible, walk around and mingle with the audience. In one of my presentations, people were sitting at round tables of 8 or 10 people. When I got a question from a table, I walked over to it and listened to the question and answered from there. It felt much more interactive and almost like a conversation. And nobody's eyes glazed over.

Be sincere

This is pretty obvious, I guess, but only say things that are true and that you believe in. And say them with conviction. It'll come across.

Think about your appearance

It's important to feel comfortable. So think about wearing something that feels comfortable, but that you also feel is appropriate for the setting. You don't want to be up there worrying about how you look. That might drive you behind the lectern! You also don't want to feel physically uncomfortable, as that will totally distract you. For me, the challenge is footwear. I need to find comfortable shoes that look professional. So give your dress some thought well in advance. Since I had four presentations this week, I actually planned my wardrobe out the weekend before so I didn't have to think about it and could instead focus on my content.

Don't be afraid to use a gimmick

Okay, I actually have some reservations about this one. But if you have a very dry topic, it can be hard to hold the audience's attention, especially if you follow something a little splashier. One of my fellow presenters told me that he would have a moment in the presentation that nobody would forget. So I stayed around to watch his presentation. It was a pretty dry topic, about testing and evaluating students. However, he pointed out that in the music department, students might be tested by being asked to sing. He then called on a music faculty member who actually sang a snippet of an aria on the spot! If anyone had glazed over, they snapped out of it. It was a little gimmicky, but it was appropriate for the topic, and it illustrated that not all testing and evaluation is the same. So be a little careful with this! Make sure that it's relevant to the topic, and it can really work.

Taking responsibility, quickly and publicly

This week I had a learning moment that I'd like to reflect on. I'm particularly proud of the way one of my managers handled a problem that I learned from and that I'd like to share.

It all started late on Wednesday afternoon when I received a call from the campus legal counsel. Now usually, when a story starts with a call from legal counsel, that's a bad thing, and this certainly started badly. It appeared that a student had sent a message to all faculty on campus. The content of the message was inappropriate, although not in any sort of salacious way, but enough to generate some excitement. Since our email lists are moderated, we needed to figure out what had happened. Perhaps the student had broken into one of our systems? Impersonated one of our admins? Of course, it turns out to be much more simple than that. The student had followed process and requested that the message be sent to all faculty, a request that should have been denied, and one of my managers inadvertently approved it. Simple human error. Tons of drama.

So what did my manager do? He immediately contacted me and told me what had happened. He took full responsibility. No excuses. Didn't talk about how busy he is, or how bad the user interface is. He just said, I screwed up. He also noted the irony that he trains people on this interface and he routinely stresses to them to be eextremely careful and cautious, and then he didn't follow his own advice. And he told me that he learned that he needs to be careful and cautious too. He took full responsibility and he learned from it.

I was extremely impressed with his professionalism and his honesty and I told him so. You get a lot of credit for being honest, and a lot of respect. So I took his lesson and immediately applied it. I sent an email to the faculty, acknowledging the mistake and apologizing for it, within 24 hours of the initial email. I received several emails back from faculty thanking me for my honesty and leadership. I owned up to a mistake, something that doesn't happened that much, and I earned respect as a result. All in a days work.

Good advice from an old friend

I've been in my new position about 7 weeks now. Last week, I went to a conference where I ran into an old friend, a CIO at another institution, and he gave me three pieces of great advice. So good, that I thought they were worth sharing.

Helen the engager vs. Helen the decisionmaker.
My friend, let's call him John, because that's actually his name, reminded me that in my prior role, when I met with people, I wasn't necessarily expected to give an answer or make a decision on the spot. I could always say "let me check with the CIO". Now when I meet with people, they're expecting a decision. This can sometimes get in the way of engaging with people. So he advises me to think of what role I would like to take during that interaction. If I'm there to engage, think of myself as Helen the Engager, and defer a decision to later when I'm Helen the Decisionmaker (or the Decider, depending on your point of view). So I need to let people know that I'll get back to them later after I've had some time to think about it, rather than make a decision on the spot, just because it's expected. It is important, of course, to actually get back with them with a decision in a timely fashion. I think I've been doing well in this area, usually taking the time to reflect. But his advice reminds me to clarify it for my colleagues who really want to see me make the decision right there.

Own your calendar. When you're new, everyone wants to get some time with you. John reminded me that it's really important to own my own calendar - don't let others, whether it's my team, the Deans, Faculty or some other group - take control of my schedule. It's important to make sure that there's time to focus on the things that are priorities. So be ready to say no to some meetings, or to schedule them further out. This has always been hard for me. I see my role largely to engage the campus community and my staff, so being available to those constituencies is really important. But John is right, I have to have some control over my own schedule or I just won't make progress on the things that are true priorities.

It's lonely at the top! Relationships are important, and peer relationships are especially important. This is a group where you seek advice, bounce ideas around and sometimes just commisserate about the way things are. We learn a lot during conversations with our peers. When you're in the CIO role, you have no peers inside your organization, so you need to look outside to find this group, and that's important. Sometimes it's your peers on campus - other leaders at a similar level to yourself. But it's also really important to reach out to other CIOs. The great thing about our CIO community is we are willing to engage with each other and to support each other. Take advantage of that and make time for peer networking. While still owning your celndar, of course!