Skip to main content

Learning from our Experiences

It's not easy to admit defeat, probably in any context. As IT professionals, we can be so focused on the resolution that we may lose sight of the ways we can improve the user experience through openness and transparency. This is a story about something that happened in my personal life outside the workplace where I realized I failed to set appropriate expectations and ensure exceptional user experience through the kind of open education, transparent documentation, active listening, and compassionate oversight I've come to appreciate in my professional life. I'm sharing this experience so we can learn how to appropriately respond to the expectations we are bound by when we step up and take responsibility — even when the capacity of that support would be informal and outside the realm of our professional lives.

Without going into much detail, what happened is that a close personal friend for whom I had a managed a website wanted to switch web management services which involved rerouting the domain through a different platform. Long story short, we did not make the necessary preparations to ensure any loss of service was adequately planned for and a backup plan was in place to ensure any disruption was minimal. My purpose in mentioning this is not to focus on the user, any of the specific services, or even the particular experience. What I want to do is use this as a point of departure to discuss the ways in which we can ensure the best user experiences even when the capacity in which we serve would be informal. In this particular case, however, I have do have deep regrets for the way in which I let this user and friend down by not sharing my knowledge and experience prior to any of the inconvenience that ultimately led to frustration on both our parts and could have been largely avoided through transparency and planning on my part.

Before I begin, I want to have a note here about the ways in which we take on responsibilities outside the workplace. A common experience of IT professionals is that people who know we work in IT come to us to support specific technical problems or as a first point of reference regarding technology. What I've learned from the aforementioned experience and others over the years is that we cannot separate those informal experiences entirely from our professional lives. We may very well provide a different type of support in those kinds of experiences than we would in our personal lives — perhaps a kind of support that would be less restricted by professionalism, institutional guidelines, and enterprise level concerns. With that being said, the informality or casual nature of the support being provided does not divorce us from the same type of responsibility we take on when we provide support for any technology.

In short, people count on us to handle the technical side of issues throughout the lifetime of a particular issue, project, or relationship unless we specify otherwise. In other words, it's up to us to specify our scope of support.  In the absence of a clearly defined scope, it's best for us to assume that the user we are supporting would count on us to be the person responsible for ensuring that everything is setup correctly to result in minimal complications and a contingency plan in case problems do occur. The easiest way to alleviate confusion down the road is to establish a clear understanding on what types of situations we are willing and able to support, the types of situations in which we need to be involved given the support we've already provided, and the ways in which we can collaborate to ensure everything moves as smoothly as possible.

Working Together
Perhaps the underlying factor in any instance in which conflicts or unsatisfactory user experiences occur when practicing IT is a lack of understanding. Breakdowns of communication can develop when we fail to gain agreement with users on the issues occurring, but also when we're not transparent on our expectations of the users. On that point, we are often so focused on what our users expect from us that we are not aware or clear on what we expect from our users, but we always have some kind of expectation. For instance, the most basic expectation any IT professional would have of users in almost any context would be that we would be contacted first before attempting a certain level of troubleshooting on one's own. The boundaries of that kind of troubleshooting would depend on the context of the specific area being supported and type of relationship with the user, but we almost have some kind of point where we might be inclined to respond with "Why didn't you contact me, first?!" However, I'd recommend avoiding that kind of accusatory tone at all costs since it would most often yield the kinds of unproductive dialogues that can escalate quickly and inverts blame in a manner not warranted. If we weren't contacted when we thought we would be, that's a failure on our parts as IT professionals to clearly communicate when our support should be expected, required, preferred, or perhaps even advantageous. It's a two-way street and it's up to us to set the expectations. The best way we can do that is maintaining an atmosphere of transparency and openness regarding our practices and principles.
With an emphasis on team-oriented approaches becoming standard in today's IT field, a focus on collaboration would not be a particular novel approach. However, what we can sometimes overlook in all that planning would be our users. Team-oriented approaches work best, in my experience, when they include our users as part of that team, not just as supported clients, but as collaborators that help us improve and grow as a team. The only way we can include our users, however, is by maintaining transparency as much as possible. Remaining transparent helps avoid confusion in any context, even in more traditional client-professional relationships that are less focused on teams or collaboration. When we're transparent, it helps us communicate effectively and holds us accountable. This transparency includes outlining our scope of support as much as possible, but also incorporates relaying information of what was done, what's being actively managed, and what can be expected going forward. This openness would allow us to avoid situations like the one from my experience that served as the impetus to write because our users know when they can count on us and our relationship for support is clear enough to be agreed upon by both parties. In the absence of transparency, we may enjoy the illusion of more autonomy and increased responsibility, but we limit our chances for success by preventing the capacity for everyone to collaboratively plan for the future. This is crucial because as the world becomes more technological and people of all backgrounds become more reliant on technology, we cannot possibly know everyone. We need the insight of the users we support to improve the level of support we can provide. What we can do, however, is establish best practices and standards of support which will benefit from and ultimately contribute to our overall transparency.
Ensuring & Maintaining Standards
Perhaps the most important role of a modern IT force is to outline the types of situations that should be disallowed to ensure security and reliability while clearly outlining the practices that should be encouraged and implemented to contribute to an overall experience that benefits the most users. These types of guidelines are typically presented in terms of "best practices" or a general computing policy, but they form the basis of most enterprise-level support in which both the user-level experience and the system-level concerns are being actively addressed through responsible management and oversight. By definition, this role of IT professionals could be considered paternalistic in so far as it does depend on the IT department or practitioner to know what's best for the users or the system. With that being said, I think these kinds of standards are best developed through regular communication and insight with the users to identify important practices and concerns. It ultimately cannot succeed without any such communication and I would lean on the more feedback the better for everyone involved. At the same time, this paternalistic nature often today faces a tension with the more independent-minded BYOD ("Bring Your Own Device") policies becoming all the rage these days in offices from Silicon Valley to liberal arts colleges in Midwest farming communities. The advantage of BYOD is clear to users because it provides an element for choice, but it creates more complications for maintaining security and reliability in an increasingly unpredictable environment. With that being said, both concerns can be addressed by maintaining an atmosphere of openness in which IT professionals set guidelines and best practices that are inclusive of user concerns and priorities.
Supporting the User Experience
Ultimately, the users are why we're here supporting technology in any context. I often joke that my profession is one part therapist and one part troubleshooter, but it is very true that customer service is unavoidable reality of what we do. Of course, any large IT team has many different people that would focus on different teams and perhaps a first tier of support designed to handle most user interactions and support. In more informal and casual environments, we are likely the person providing both the user and the system level support unless we can outsource that support through a third party. When we're supporting the users, we can't do that effectively (unless we can mind read) without engaging in continuous and effective dialogue regarding what's expected on both sides and how we can work together to ensure that everyone's expectations are met as best as possible. Of course, technology support are always accompanied by situations we can never forecast or predict. That unpredictability is, of course, why we must do our best to clearly communicate the expectations we have and collaborate with our users to develop a plan to ensure reliable user experience from the present through the future as much as can be possible to maintain.

That's why ultimately what we can do to avoid sources for conflict with our users going forward is to communicate effectively. The type of communication to which I'm referring includes listening as much as explaining. We need to hear what our users are saying, what's important to them, and it's up to us to relate those concerns to practical solutions we can implement. If we are not the right person for the job, there's no shame in admitting that up front. We can avoid a lot of stress and disappointment down the road if we just let people know when we're approaching our limit, when we're beyond our expertise or comfort zone. Those kinds of situations are best navigated when we can provide an alternate solution such as "I'm not the right person for this, but I can point you in the direction of someone who is." In this sense, we can be supportive of our user concerns by recognizing the ways in which the users are best served even if that means referring to someone else. Ultimately, our greatest responsibility as IT professionals is clearly articulating where we stand, what we can offer, and what we expect. If we can expect the same of our users, we can foster relationships that be mutually beneficial and lead to the most productive environments.