Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/28/d121201466/htdocs/holistechwww20121/wp-includes/post-template.php on line 284

I.T. Team Basics: Understanding the Wiring of Your Team

The I.T. Service Desk Example

The I.T. Service Desk. What an institution. In some organizations the I.T. Service Desk might be the first level of customer support serving thousands of public customers. In other organizations it might be made up of a single individual who actually has to work on many projects in addition to answering phone calls, emails, message boards, chat requests, etc.

If you ever want to know the real story about how an organization operates, the good, the bad, and the ugly, just talk to the person who works at the services desk. No matter what comes their way, whether it is gracious or venomous, they are required to respond with a smile. They often interact with customers when customers are at their worst. While I don’t believe that there is ever an excuse to spew wrath on another individual. I do understand that a certain level of tension and trauma is to be expected at the service desk. After all, a customer doesn’t usually call the service just to chat or talk about the whether. They call because their plans and/or actions have been blocked by a perceived failure in a piece of technology or service that they are using. They call because they need help. With this in mind, knowing that it is inevitable that people will be calling in need of urgent support from time to time, how can we bring some order to the messy world of the service desk. I have found that the service desk professional requires a unique mix of technical aptitude and relational intelligence.

Engineers and Social Workers

Many of us already know that building excellent teams starts with quality people…duh. “You need the right people in the right seats of the bus”, etc. etc. This is true. I would expect that as an I.T. leader you are already screening carefully for high quality, hard working people. I think where we fail much of the time is that we drop the ball on matching the “right people” in the “right seat” when it comes to I.T. service desk or I.T. customer service. Most of the time the I.T. service desk is just an entry level position. It is the place where people just out of tech school can ramp on to an organization. Don’t get me wrong, I do think that it is appropriate for larger service desk organizations to have some positions categorized as entry level. Furthermore, I think that even senior level software or network engineers should have to rotate into service desk positions periodically if for no other reason than to remind them that they serve humanity not technology.

I recommend, as a general best practice, that the same level of care and scrutiny go into the process of selecting a relationally intelligent service desk team member that goes into selecting a technically competent senior software engineer. Let’s face it, people who are wired for engineering are not necessarily wired for customer service. I have watched too many amazingly talented engineers get ground up and disillusioned because they took a promotion to a management position that required extensive customer service and/or service desk skills. Conversely, I have watched too many service desk individuals become discouraged because they feel like they are undervalued with nowhere to grow. I don’t have enough time to go into this topic in great deal here. Perhaps, I will write more on this subject of getting the “right people” in the “right seats” in the future. For now, I would simply recommend that if you are looking to fill a service desk position in your organization that you don’t stop at assessing technical aptitude. I would recommend that you invest an equal amount of resources for assessing relational intelligence and people skills. If I was tasked with filling  a solitary servicedesk position at an organization, of course, my first choice would be to fill the position with someone who is highly skilled technically and relationally. However, the reality is that I.T. managers are usually faced with a choice between the two strengths. Given this choice, I would test for technical and critical thinking aptitude and relational acuity. In other words, I would error on selecting someone who may be trained as as social worker, has an aptitude to learn technology and is energized by working with people.  I have experienced much greater success in equipping an extrovert who has technical aptitude to have technical skills than I have had trying to mold a highly skilled technical engineer into a “people person.”

Don’t all technology pros have to work with people?

The short answer to the question above is, Yes. All technology pros have to work with people at some level. However, I have found that applying the Pareto principle (80/20 rule) can be very helpful in matching technologists to their “right seat” in an organization. For instance, As a technology manager, support technician, project manager or any other position that works directly with people on a day to day basis, I would expect to be either interrupted by or to proactively interact with people at least 80% of the time during my day. Eighty percent of the value that they would add in one of these roles to the organization that warrants a salary would be directly related to their ability to perform under these circumstances.

Conversely, If I am fulfilling the role of a telecom engineer, software developer, database administrator, technical writer, network engineer or any other role that requires a significant amount of focused and detailed attention on a day to day basis, I would expect to be interrupted by or to proactively interact by with people no more than 20% of the time. Furthermore, I would argue that structuring organizations so that engineers can focus on completing engineering tasks with limited interruptions will reduce incidents/interruptions and improve quality.

Please note: As I mentioned above, I would recommend that even senior engineers rotate into some level into direct customer service interactions from time to time. Professional who are excessively sheltered from customer interactions have a tendency to lose sight of their overall purpose of helping people. The key is in finding the right balance between assigning the right people to the right “people roles” and “technology roles.” I have found that applying the Pareto principle in the way that I have described above helps I.T. managers avoid extremes and communicate expectations when assigning these roles to I.T. pros.

 Wouldn’t it be more productive for me to assign an engineer to a service desk position?

I would love to answer this question with yes. The thought behind this method of service desk management is that if you assign an engineer to a service desk position, they will, fix the underlying solutions to problems more effectively than traditional service desk solutions. I have found that even if you find an awesome technical genius  who is equally wired to work with people and technology they would rarely be able to focus enough time on engineering solutions to root problems. In most cases I have found that there even organizations who employ senior level engineers at their service desks require focused engineers behind the scenes to implement solutions with fewer interruptions from service requests and incidents.

Conclusion

Understanding how the people of your I.T. team are wired and assigning them according to how they are wired can really promote the success of your team. There is a great deal of frustration that can be avoiding when I.T. leverage the “wiring” of their team appropriately and cultivate a deep appreciation for the different kinds of strengths that exists on a team.

Further Study and Resources

If you are interested in learning how to understand how your teams are “hard wired”, you might want to check out http://www.influenc.es. They offer some pretty cool assessments that can help you maximize the strengths on your team.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *