It's been a few weeks since my last post (I've been away from the office), but I plan to make up for that with a veritable deluge of information this week. First, a few updates:

• Bugs Online: As with most projects of this magnitude, there've been a few unexpected hang-ups. In particular, the process of preparing the bug synopses for public consumption is taking considerably longer than we expected. I've been personally involved in that effort, and the drill goes like this: Read the bug synopsis, read the detailed bug notes, and make sure the synopsis is an accurate, complete and comprehensible representation of the essense of the bug. We've had teams of people putting in extra hours towards this effort, and we're working our way through them... and let me tell you, it's about as much fun as trying to get a GPS reading inside a sewer system. But you won't have to wait until we finish: we'll be releasing Bugs Online once a good majority of the bugs are ready to go, and we'll finish prepping the remaining bugs after that. Thanks for your patience, and don't worry, we should have Bugs Online up and running well before the end of summer.
• Support and Screen-Sharing: Starting next week, some of our Support analysts will be participating in a trial run of an updated version of the screen-sharing technology mentioned in my last post. If you're lucky enough to get to experience the updated screen-sharing process, please make sure to fill out the Customer Survey that will appear at the end of the screen-sharing session. We'll be using your feedback to help determine whether and how to proceed with the upgrade.

And last but certainly not least, I recently had the pleasure of talking with Aaron Zureick, Operations Manager for ESRI Support Services, about his position and the recent reorganization that ESRI Support has gone through.

Interview with
Aaron Zureick
ESRI Support Operations Manager

Jason: Thanks for taking the time to chat with me today, Aaron. Maybe we could begin with you telling us a bit about your history here at ESRI.

Aaron: I've been with ESRI a little over eight years now. I started out as an analyst supporting ArcInfo Workstation with AML, and then moved on to support Desktop when ArcGIS Desktop first came out. After that, I progressed into other areas, primarily ArcSDE and geodatabases. That was really where I spent my time as an analyst, more or less. I’ve also held several other roles in ESRI Support: I was a founding member of the Premium Support Group, a Team Lead for one of our support teams in the old Technical Support Department, the Assistant Manager of Technical Support, the Manager of Technical Support and now, after the reorganization, I’m the Operations Manager for ESRI Support Services.

Jason: That’s a lot of ground you’ve covered. Since you’ve brought it up, let’s talk about the reorganization of ESRI Support. Not too long ago, support was organized somewhat differently. Can you talk a little bit about how support's been organized in the past, how it's organized now, and why the change was made?

Aaron: Way back when, we had one support group, known as Technical Support. As our product line grew and as our user base grew, at some point it became necessary to have support that was specific to our customers who were developing their own GIS solutions using our products. To answer that need, ESRI created another support group, known as Developer Support. For a number of years we had Technical Support and we had Developer Support, and they both had clearly defined responsibilities and it was clear which group would handle which support calls. However, as our user base grew and as our product line matured, the line between what those individual groups did and what their purpose was became more and more blurred. So we ended up with two support groups that were big, that were basically doing the same support but moving in different directions in the way they did that support. That caused a lot of problems and was one of the main reasons we decided to look into reorganizing both groups into a more comprehensive and focused entity.

Jason: Okay. So Technical Support was doing things one way, Developer Support was doing them a different way – and the users were experiencing this difference?

Aaron: Yes, absolutely. Users could get different experiences every time they called Support depending on the product or question that they had. There were different call back times depending on which products they were calling on, there was a different experience for how the analysts interacted with the customers. There was a different depth or level of support that was given. The processes for escalating calls or pushing calls through some sort of QFE or Hotfix process differed. The ways we collected and processed feedback to development and sales and other departments was different and inconsistent. The list goes on and on.

Jason: So we fixed all that, right? (laughs) Seriously, though, it sounds like these may have been some of the main problems driving the effort to reorganize ESRI Support?

Aaron: With the reorganization, we wanted to put ourselves in a better position to interact with all our customers in a consistently effective way. It was confusing for customers when we had two different support groups with two different types of support contracts. It was also confusing internally here at ESRI – our own [non-support] staff weren’t sure which Support group to contact for help with internal or client projects. As an example, the folks in ESRI's Sales and Marketing departments had to go to one support group for maintenance issues, and the other support group to discuss add-on support for certain developer products. It was confusing and a barrier to a lot of folks. Also, the organization within each of the old groups was fairly flat and wasn’t scaling well as the groups grew.

Jason: It sounds like all sorts of problems may have been solved by the reorganization of ESRI Support. So now, support is a single group called ESRI Support Services… but in a strange case of déjà vu, it has two groups: there’s the Operations Department, which you're the manager of, and then there’s also a Business Department. This is somewhat surprising, given the problems that arose from having two support groups in the past – can you talk about the new structure and why it was chosen?

Aaron: The new structure ties in with scalability and effectiveness. Yes, we still have two groups in support, but they are focused on very different aspects of Support, as their names suggest. In the past, both of the old groups had a primary responsibility of helping and being responsive to customers. But we found that when call volume increased, other responsibilities started to fall by the wayside. These were secondary responsibilities that in some way helped the customer in a more indirect fashion, usually by helping ESRI Support function in more productive or efficient way. Those secondary responsibilities always gave way to the primary responsibility of directly helping customers with their technical issues. For example, organizing and evaluating and planning for the Support Center web site used to be someone else's secondary responsibility, and when the calls got backed up, something was going to go on the backburner and it wasn't going to be our responsiveness to the customer.

Jason: Right. And now that particular secondary responsibility is someone’s primary responsibility, namely, mine.

Aaron: Exactly. We took those things that were secondary responsibilities and we made them the primary responsibilities of the people in our Business department, separating them organizationally from the Operations department, which contains the analysts and managers who are focusing on the incoming calls.

Jason: What else goes on in the Business department?

Aaron: Besides the Support Center, there’s our User Advocacy Group, which analyzes issues and trends in our software and feeds those back into the software development process. Beth G. is heading up the UAG, and she works with our Development Technical Leads [DTLs] – these are new positions created during Support’s reorganization. DTLs work for ESRI Support Services, but they sit with our development teams and help prioritize issues and manage communications between Support and Development. The Business department also includes staff dedicated to documentation, internal reports, International Support, Offsite Support, and metrics and standards.

Jason: Let’s talk about your department, Operations: how is it organized, and why?

Aaron: We chose to organize Operations in much the same way as our Development teams are organized, to help our relations and communications with Development. We basically have four Units based on technologies: Desktop, Geodata, SDK, and Server. Each of these Units is organized the same way; they each have the same types of positions, and they're built to be scaleable as we continue to hire more staff. The new structure also creates more advancement opportunities for the people who work here. In the past, if you were an analyst and wanted to be a technical person and develop a technical career, your choices were to remain an analyst, or leave Support. If you wanted to be a manager or supervisor, your choices were to wait around for a Group Lead and/or Manager position to become available, or leave Support. With our new structure there are many more options for movement and advancement while remaining a part of ESRI Support Services.

Jason: That’s a nice aspect, as I can personally attest to. You said that each Unit has a similar structure – what does that structure look like?

Aaron: There's a Unit Manager who's responsible for the overall health of their Unit, including operational efficiencies, how well we're doing supporting the customers, the quality of the support that we're giving, the health and attitude of the analysts and other staff in the Unit, and career development and long-term career development of the employees. Each Unit Manager also has two technical leads, there's a Senior Support Technical Lead and a Development Technical Lead. The Senior Support Technical Lead [SSTL] is the internal support expert for their Unit. They help develop overall curricula for their Unit, they help new analysts build expertise, and they're a point of contact for technical communications between the different Units. As I mentioned before, the Development Technical Lead [DTL] is a senior analyst who actually sits with the development team and participates in the development team's processes. The DTL focuses on identifying and lifting up software quality issues that we see here in Support. The DTLs from each Unit work together in the User Advocacy Group to prioritize bugs and enhancements, they do trend analysis on issues that customers are reporting, and they’re a point of contact for technical communications with Development. The rest of the Unit is organized into Groups; each Group has a Group Lead who acts as both a direct supervisor and a technical resource for the analysts in their Group. Each Group has between four to eight analysts, ideally. Some of our Units have as many as four Groups already, and they're meant to scale, so that regardless of how big a Unit gets, any supervisor should only have to manage somewhere between four and eight people.

Jason: I see. That’s a pretty deep organizational structure – certainly much deeper than it was before.

Aaron: Yes – it’s scaleable, and it really opens up a lot more advancement possibilities for our staff.

Jason: Great explanation. That should help paint a picture for our readers of how support is now organized, and the reasons for the change. So how's the new organization been working out so far – has it been fairly successful?

Aaron: Yes, absolutely. Like with any major change in an organization, there've been some bumps as people have grown into their new positions, but we're definitely seeing, internally, a lot of improvement in efficiency and in the supporting processes. It's been a good eight months since we've reorganized and we're starting to see some of the intended benefits. Our relationship with other internal departments is getting much stronger, our ability to do things quickly for the user and for the analysts are improving. We’re getting better at cataloguing the information that we get back from the users and turning it into knowledge base articles so it can help other users. One of our primary goals here in the Operations Department is to be able to get back to the customer the same day they log a call with us -- in some areas we're able to do that and in some areas we're not there yet, but we're making changes and looking forward to put ourselves in a better position to be able to do that.

Jason: Okay. I was going to ask what objectives you had for support operations for the future. That sounds like a good one. I'm sure all of our users would give that a thumbs-up. What other aspects of performance does Support measure and strive for?

Aaron: Sure. There's quite a few metrics we look at for operational excellence. Obviously, one of them is the time it takes to get to a user after they log a call. Our primary goal is to have an analyst ready to speak with the user right when the user calls in, and we aim to provide that kind of service for a certain percentage of the incoming calls. That analyst may or may not be able to actually solve the user’s problem, but at least the user is talking with someone who’s in a position to help them out. In cases where this does not happen, getting back to the customer the same business day is our goal. Another metric we look at is the percentage of those calls that are directed to an analyst that are actually resolved on first contact – we look at both “time to ownership” and “time to resolution”. We can't always control whether a resolution is possible or whether it's well-received, but we can certainly look at resolution times as an overall statistic for calls and see how quickly we’re getting accurate information back to the user. We also look at surveys. Regardless of whether there was a solution or not, we want customers to have had a good experience with support. Did we do everything we could? Did we do the right thing for the customer? So we review the customer surveys and investigate into any low marks we receive. In addition, we perform incident quality evaluations on calls that come through Support. And we feed our findings, the good and the bad, back to the analysts so they know where they’re excelling and where they need to improve. There's a lot of internal ways we monitor how our customers are being handled.

Jason: To wrap up, is there anything that you’d like to say to the readers of the Support News blog about support?

Aaron: I’d like to assure them that our overarching goal is to help them be successful using our software. We've been mostly reactive in the past, and we’re working towards being more proactive. We're constantly looking for ways to change and adapt so we can provide a better service. We know there are rough times and we're bound to run into issues now and again, so if you experience problems with our service, please let us know, and we'll continue to refocus our efforts as necessary.

Jason: Thanks very much for your time, Aaron.

Aaron: Thank you.