Speaking up when you find something
From time to time we’ll find something wrong in the systems we support. While dealing with it is important, spreading the word is also critical to success. Sure, it might be nothing, but it could also be a lot worse, and you’ll want folks ready to help.
If we’re really lucky on projects nothing will ever go wrong. Many of us, however, never get that lucky… Instead, we find ourselves looking at an issue or a challenge that blocks our project. Many times when this happens we shrug to ourselves and start trying to figure out a solution. This approach may result in us solving the challenge, however, it has a lot of problems.
Ideally when we find a problem we take a few steps before we start trying to solve it. These steps help ensure that we can solve the problem while minimize risk.
Let other folks know
As soon as we’re aware of a problem we should let other people know. While the exact folks we alert may differ based on the project we’re working on, our company culture and some other factors, we still need to reach out. I default to telling my immediate manager and anyone else working on the project, but other stakeholders may be included as well. This helps prevent them from being caught unawares, either by finding it on their own, or by having someone else tell them about it.
This also sets us up to get help in case we need it. While the problem may seem to be something we can handle at first blush, it’s always possible it will be something we can’t. While we can certainly ask for help after something has blown up, it’s easier to ask for help before things get too crazy.
Share information
Letting others know that something broke is the first step, but we also need to be proactively sharing what we’ve discovered. Initially this may be a short message along the lines of “I found XYZ error code in the system”, but as we go we need to keep sharing information. Providing regular updates has many of the same advantages as just letting others know; they won’t be surprised when someone else talks to them and they’ll be able to help.
This approach also lets us divvy up work, for example you can have other team members handle communicating with stakeholders while you handle the fix. Sharing information, especially with stakeholders, is also important to keep them calm. It’s highly likely that stakeholders don’t understand the technical ins and outs and just know “it doesn’t work”. Sending out regular updates helps maintain your relationship and makes them feel connected.
Keep Sharing Info
As you go through the process of fixing the challenge, keep sharing information. It’s really hard to provide TOO much info when something breaks. Continually updating throughout the life of the problem means no one is unaware of your progress, or if you need other resources for help.
Order Pushing
Non-technical partners need to be careful to partner with their tech teams… many times they end up just sending orders to their technical partners. This not only results in a weaker relationship, but many times results in a weaker end product.
I picked up a great bit of advice from a recruiter - “Recruiters aren’t order takers, they’re partners”. The intention behind this is you shouldn’t go to a recruiter and say “find me a lawyer” then walk away. Instead, you should sit down with your recruiter and talk with them about what you need. What problems are you trying to solve? Why are those problems, well, problems?
This discussion helps the recruiter figure out what you REALLY need… not what you *think* you need. The difference between the two can be finding a great candidate, and not finding anyone. By partnering with the recruiter, instead of just putting in an order for something, you raise your chance of actually solving that challenge.
The same paradigm exists with technical teams (and I would imagine with ANY relationship). Many times we’re just told to install some system or make some modification by a partner team. The thinking is that the technical partner is there to take care of the technical stuff… which is obviously to install that new system. This approach, however, drives us nuts.
Instead of just telling, or even politely asking, your technical partner for XYZ solution, it’s a much better idea to start a discussion with them. Let them know more about what pain you’re experiencing, what solutions you’ve identified, and then ask what the best path forward is. At the very least this will build your relationship with your technical partner; they’ll see you more as an active partner in the relationship and less of a burden. At best, this will enable your technical partners to find better solutions… in many cases solutions you didn’t even knew existed.
Changing from order pushing to partnering can be challenging, but, like many things, it gets easier with practice. The next time you have something you need from your technical partner, schedule a quick meeting with them. Let them know you’ve got a challenge you need their help on and provide some background before the meeting. This will likely intrigue them, especially if they’re used to being order takers, and give them a chance to understand what you need.
Instead of approaching the meeting in a “Here’s what I need” mindset, approach it in a “I need your help on X” mindset. This will shift your perspective a bit, but more importantly it will show your technical partners you’re seriously about partnering. Instead of phrasing things as a definitive - “we need X solution by Y date”, phrase it as a question “So we’ve heard X solution would be a good idea, what do you think?”. This opens the door for your technical partners to provide their ideas.
Most importantly this approach will demonstrate that you value your technical partners’ experience in their area. This goes a LONG way to building a positive relationship that will pay off in the future.
Self-Awareness
It’s easy to learn a system by exploring it… just click around and learn. Learning yourself, however, is a bit more complex.
Being aware of ourselves is one of the most important skills that we can learn. That said, from my experience it also happens to be one of the harder skills for people to learn. Figuring out a new technology or sales technique is easy - we attend the training or we tinker with the tool. Figuring out how YOU work, what makes you frustrated, what your habits are, however, doesn’t have a class or a seminar. It’s not something you can REALLY tinker with or take apart. Instead, it requires a level of critical thinking and truthfully examining yourself. This is, to say the least, a bit daunting.
On the up-side, there are many versions of things like the Meyers-Briggs (you know, that one that tells you what color you are, and how your color interacts with other colors?) test to help teams uncover their inner operations. (Or maybe that’s the MBTI, I always get them mixed up…). These types of exercises are useful, however I find they usually can’t get deep enough in some areas to really dig into self-awareness. These exercises help point out how an individual may interact in a professional setting, but it ‘s up to the individual to figure out how to apply that across the board.
This makes sense, since many of these assessments are intended to help groups of professionals work together. They both provide a common language with which to discuss how people work (“you’re an WRST? I get it now, I’m a BEST!”) and also some general guidance for the individual on how to operate. This works great for groups that all take it together, however, I’ve found them a lot less useful for individuals.
Choices
Work presents an interesting version of this since we can’t really choose who our co-workers are… we’re kind of stuck with whomever’s there at the time. This differs greatly in our personal lives. We are, to some extent, stuck with family, however, we do have a great deal more control over those relationships, and who we choose to socialize with. This makes understanding how, and why, we will/do react in specific ways even more important… we’re consciously choosing to be with these folks instead of being ‘forced’ to.
The same techniques teams use at work to improve themselves can be tweaked to help out in our personal lives. Some ideas include:
Regular Retrospectives - Make time each week to reflect on the week and any areas you want to improve. How did certain conversations go? Do you understand why you get easily annoyed at something?
Focus Time - Set aside specific time to take a deeper dive on one area of yourself. I find journaling is a great approach for this; something about writing things down helps get them out.
Active Feedback - Find someone you trust to talk over what a blindspot might be or how to improve something. This helps break down any mental preconceptions of yourself you have, but does require a lot of emotional trust in whomever you speak with.
This isn’t to say it’s easy… even admitting something to yourself (let alone someone else) about how you think/feel/act can be hard. That said, it’s certainly worth it. Getting a better handle on how you will behave in any given situation both makes you more effective and also reduces any surprises on your end. Over time you’ll also learn more about yourself, in turn making future improvements a little bit easier.
Priority Zeros - Everyone’s got ‘em (sometimes several)
Finding a way to prioritize work is critical to success. The one approach that should NEVER be taken is to have the tech teams determining the priority… they’ll almost always get it “wrong” and end up agitating partner teams.
Priority Zeros. Everyone's got one, something dozens (which I always find amusing - how can there be multiple highest priority items?…). These items are the highest priority and most important item for any given group or individual. It's a great thing when a team can truly determine what these are as it allows them to direct work. It's a much less great thing when tech teams are given them without a structure in place the help manage them.
Collision alert!
Once you get to the point where you're regularly identifying P0s you’ll (hopefully!) start looking at how to accomplish them. This generally involves passing parts of the ask to other teams to do the work. Depending on the ask this can span large swaths of the company, or just a small targeted group. Given today’s information-rich environment, tech teams are almost always impacted by these asks. While it’s great that tech is thought of as being needed, a very serious challenge begins to emerge - What happens when tech gets a P0 from Finance and one from HR?
In an ideal world this balancing has already been taken into account where a designated person or group determines the actual priority (Finance then HR, or use some semi-objective ranking system, e.g. which one costs the most to implement). I won’t delve too deeply into what that process looks like, but this group should be ordained by the business to make, and defend, those decisions so the tech teams can focus on execution. This approach is great since it removes any pressure on tech to determine which should be done first and provides clear guidance on what order stuff should be completed in. It also helps ensure the business know’s what tech is up to, and when they are doing any given item (other very common challenges with prioritization).
More frequently, however, the decision is dropped on tech, and tech has to figure it out.
This is a terrible idea.
I dunno, that one first?
It's terrible because tech doesn't know which item is more important to the business. If we’re lucky we can sometimes make an educated guess, but this is very much a mystical art from the tech standpoint as is it very rarely objectively clear cut. For a vast oversimplification (many tech projects span months if not years), is it more important that an alert goes out from Legal or a finance report has a column added? Tech can guess (I’d hazard towards Legal on this one?), but at the end of the day it’s not your tech team’s job to determine priority of this type of work - it’s IT’s job to execute on the decision that is made and to ensure that it is executed properly.
In addition to potentially the “wrong'“ item being worked on, it’s terrible because no matter what order tech completes the items in it will be 'wrong’ to one customer or the other. If we go with the “Legal” option above its highly likely that Finance will come back at us more than a bit unhappy. Tech can try to justify why they chose a specific course of action, but at the very least this takes away from time better spent working on the item. Even if there is some justification Tech uses, it’s likely that Finance will disagree with the criteria (e.g. why are alerts weighted more than reports?). This ties back to having an ordained group or individual that all groups trust - it helps eliminate frustration down the road.
But we don’t have that…
There’s a variety of reasons why that ordained group or individual doesn’t exist yet. Maybe your company cannot afford to dedicate a single headcount to it (yes, this is a full time job). Maybe your company wants to, but has higher priorities (a bit ironic that). Regardless of the reason there are some steps you can take to help bridge the gap / mitigate the damage. This will require some amount of process / procedure, however, it will help protect your tech teams and avoid frustration from the business.
The intention of this individual is to provide a source of truth for the order of your tech teams work. This requires this person to be familiar with everyone on the tech and the business side, and have a working relationship. This person also needs to understand how the tech teams operate and what their capabilities are. A person like this may already exist on your team (or on the business side). This may be a finance expert who wants to learn more about tech, or a techie who wants to get a better feeling for how the business operates.
You’ll also need to get leadership buy-off on this stop-gap. Figure out who the decision makers are on the business and tech side and grab some time with them. Explain you want to dedicate X amount of someone’s time to helping prioritize and order tasks (with input from both teams). It shouldn’t be too hard to get buy in as they are likely feeling the pain of not having this role, but you can always point out the time/heartache savings by having an objective to-do list. You’ll also need to setup some kind of regular update/meeting with this group so they feel comfortable trusting your designated individual, but this is good since it will help keep you honest and get you feedback.
It is definitely an iterative process, but once trust is developed and the wheels start turning more easily marked improvements in efficiency and grey-hair will start to show up.
Same team!
It’s REALLY easy to fall into the trap of blaming the business or the tech team for a failing project or take out frustration on them. At the end of the day the most important bit to remember is everyone is on the same team. Tech teams don’t have anything to do without the business (except watch server lights flicker) and the business will have trouble improving without tech (there’s a limit to gSheets). The challenge is in bridging the gap, in helping the tech side understand the business’s priorities, and the business understand the tech teams capabilities. Providing a single point of truth for what should be worked on is a huge step in that direction, and one that you can start taking without breaking the bank.
When should Tech be involved?
Frequently technical resources are pull into projects at the last minute. This deprives the project team of a valuable viewpoint and raises blood pressure all around. Tech should be included as early as possible to best leverage their skills and avoid last minute scrambles.
Very commonly companies have to make important decision about what they should do. These decisions typically involve a number of different departments (legal, HR, finance etc), all of which provide an important and necessarily piece of input to the Decision. For some reason Tech seems to be frequently forgotten about during this step in planning.
Failing to plan….
Due to the expanding info-tech nature of work it is critical that technical considerations are taken into account during planning. This includes things like giving tech a seat at the table, including team members in planning meetings, and ensuring they’re included in updates. You wouldn’t, for example, not include Legal in a big decision, why is IT any different?
Planning is a very important thing (citation needed). Even the smaller projects or initiatives need time to be shaken out. Schedules need to be determined, resources need to be found (or borrowed… or stolen…) and communications need to be setup. There are a ton of moving parts that need to be managed, such as figuring out what teams are involved, and who is responsible for what. Many projects share some amount of requirements, for example having a unique email, that tend to be better understood by the project teams. Almost every project, however, can benefit from additional technical expertise, and this is where a breakdown frequently occurs.
While many pieces can be managed without technical support, almost every aspect can benefit from a technical view point. This may involve tools that the project team is unaware of, help developing an ideal process, or access to key systems. All of these decisions also will require some about of IT help, even if it’s just setting up an email alias or standing up a file share. Generally not having the tech teams involved early will result in either a mad dash at the end to get them up to speed, or a diminished project result.
“Just IT”
This boils down to mis/pre-conceptions about IT itself. After all, IT just pushes a button and the thing works. It can’t be THAT hard to setup a new email alias, so why include them at the kickoff meeting? This is only compounded as projects become more complex. (If you don’t understand the underlying concepts moving 2,000 workers around your HRIS seems like an easy thing, just a button, right?) . This apparent lack of appreciation for the complexities of modern information systems results in IT being left out of the loop. Several times I have been looped into projects with only a few days before go-live and asked to complete what should be 3 weeks of work in 3 days.
Including tech at the start of the project helps avoid these types of situations. On the one extreme is tech saying they’re not needed, but on the other is avoiding a massive complication. This may also require some amount of discretion depending on the topic (e.g. a super-secret merger or HR event may require more selectiveness), however, tech teams are used to handling highly sensitive data so it’s just another project to them. At the start finding the right person(s) on the technical side may be a bit of a challenge as the help desk expert may not know anything about the HRIS side of the house (and vice versa). One way around this is to include one individual from each tech team at least is consulted and asked if they might be needed. Another method would be to approach your tech leadership and ask them who the best individuals to include are since they’ll have a good idea of who’s best suited for the task.
Business + tech = win
Once tech is regularly involved you’ve given yourself a number of advantages. The least of which is IT becoming aware that something is going on. This doesn’t seem like much, but is a huge step in the right direction. Like any team they have restricted resources, so we’ve now given them a chance to put your ask into their planning cycle. This helps eliminate the possibility of not having the right resources available to do The Thing (or giving folks premature grey hair…).
Even better, it also allows IT to point out potential problems with your approach. While I have great faith in my business partners, tech is not their area of focus. Frequently this results in them sticking to habits / easily available things (google sheets, anyone?), resulting in tunnel vision. Maybe there’s an easier way to communicate with everyone, or maybe you’ve forgotten about some restriction. More diverse brains, earlier in the process, can only help.
If a technical resource cannot be included (maybe you don’t have one yet, or maybe they’re slammed), another approach is to find someone on your team who is more technically minded. Maybe this individual has worked in tech before, or works closely with the tech teams currently. While this person may not be a technical expert they should be able to at least point out areas where tech should be involved. The goal is to find a way to get a technical viewpoint on your project as early as possible.
All together now
Many, if not all, parts of a businesses project can benefit from including technical resources as early as possible in the process. At the very least you’ll avoid last minute scrambles, but more likely you’ll enhance the overall project in ways that are hard to see at the start. You’ll also build a better relationship with those teams, improving overall operations and helping improve future projects. Your tech teams will thank you as well, since they’ll feel like they’re part of the great team instead of being delegated to being “just IT”.
Remember : There's a person behind that ticket....
It can be REALLY hard to remember that there’s another live human behind the ticket you’re working on. Take the time to connect with them on a human level, not only will the ticket go more easily, but you’ll forge a great connection.
There’s a fascinating thing that frequently happens when someone puts in a help desk ticket. They stop being a person and start being just… a ticket.
While this is useful for doing things like tracking trends, or analyzing problems, it presents challenges on how the problem is solved. Abstracting the person from the problem sets ourselves up for situations where our agents treat the ticket as just that - a problem - and not something that impacts the life if another person.
The usefulness of tickets
While smaller offices or organizations can rely on the “Walk up to XYZ person and get help approach”, this quickly breaks down at scale. First, after some point not everyone knows the right person to go. This makes it a frustrating experience to find help since you first have to go through a treasure hunt. Second it’s really hard for organizations to have enough of the right person at the right place at the right time to really matter (how many IT help desk techs is the right number? What if the location only has 2 employees, should they have a third employee who just does IT work?).
Since it’s (unfortunately) not possible to scale 1:1 human connections with organizations, we have to rely on some type of system to help us. This system should allow us to track multiple requests at a time, provide specific (hopefully accurate) responses, and interact with our customers. Frequently the thing that does this is a ticket. This makes tickets incredibly useful things, as they allow us to track, codify and organize pieces of work that have to be completed.
Given the size of some environments this is especially important as thousands, if not hundreds of thousands (or more!) issues pop up every year. While some percentage of the population will figure out a way to get face-to-face service, the vast majority of folks will interact solely with whatever ticketing system is in place. While this certainly makes it easier for the group providing support (IT, HR, whatever), it results in some interesting behaviors that may not have cropped up if a 1:1 in-person interaction were taking placee instead.
Do you have a ticket?
Many times the first questions out of a support techs mouth when presented with a customer with a challenge is something along the lines of “Ticket number”. Hopefully it’s more polite than that, so let’s go with “Could you please let me know your ticket number?” as the default. Already we have a problem. Instead of acknowledging the person in front of them (and almost as important acknowledging the pain that person is experiencing) the tech has gone straight to the ticket. While this may be a result of some process the tech is trained on, it immediately divorces the person from the equation.
While this makes complete sense (I certainly agree work needs to be accounted for), it immediately pushes the conversation away from help a person and towards placating a system. Systems are intended to serve us, to make our lives easier, not to enslave us to process and procedure.
To help combat this I work on starting those conversations with something like “What may I assist you with?”. I make a conscious effort to use “assist” and not “help” since they help frame the conversation. “Assisting” someone makes it a more collaborative, “us vs. the problem” approach, while “help” makes it more of a “you clearly can’t do this yourself, give it to me”. While this difference may seem minor, it makes the customer feel like they are part of the solution, instead of part of the problem. This becomes important when I need them to do something for me (reboot their machine, send a screenshot etc.), or if the problem comes up again (they’re less likely to think I”m incapable and more likely to want o work on a solution).
PATS (Person Abstraction Ticketing Syndrome)
It’s a little easier to avoid this abstraction with in-person (even video) requests since you get immediate body-language feedback and can more easily build a connection with the customer. Things can get really hairy when interactions are solely through a ticket and there is no direct connection with the customer. In these instances both the agent and the customer can forget they are working with another live, breathing human. At best this shows up as a different tone in responses, at worst customers get shuffled around between different teams until they get fed up and escalate.
This breakdown occurs since tickets cannot capture enough information (let alone the information provided by body-language or spoken word). Frequently they don’t even come close to soliciting questions that pull out context, for example not asking WHY something is being requested. This relatively lack of information makes it very easy for the agent to treat the ticket as another piece of the computer - something to be dealt with using as little energy as possible.
The customer, unfortunately, is in the same boat as the agent; they’re not getting enough information either. Compounding this is the frustration they feel due to the underlying cause (e.g. their computers broken), and the frustration of having to navigate some ticketing system (No one’s ever told me it’s a joy to use a ticketing system). Now, on top of that frustration, they have received what is likely a curt response (or at worst something totally unrelated to their request) to their plea for help.
As work on the ticket continues this transforms into a nasty reinforcing loop. The agent becomes more and more annoyed at having to deal with that particular ticket, and the customer feels more and more frustrated at not getting what they need. This tends to result in agents resenting customers, and customers thinking agents are un-caring machines. Eventually one of a few things happens:
Miraculously the ticket gets resolved - both parties are relieved, but not happy
The ticket gets transferred - The agent realizes they cannot help the customer so they punt them to another team. This effectively restarts the process, but does nothing to reduce the customers frustration.
The customer gets fed up and escalates - This can take the form of an email to a manager/director/C-suite and is not a lot of fun.
Even the best-case scenario is not a good once as the steps taken to get there were painful for both sides. In order to avoid these less-than-ideal outcomes, we may need to take a few drastic steps…. Remember they’re human too, and Get out of the ticket.
Remember they’re human too
This is something I always (try to) keep in the back of my mind when I work on tickets. Whoever is on the other end of that digital paperwork is another living, breathing person who needs me to help them out. Depending on the day and the person this can be more or less challenging, but the ideal end result is to treat the ticket like I would someone in real life. I wouldn’t for example, not respond for 3 days to someone who is standing in front of me saying “hello” (hopefully they wouldn’t stand there that long!). Nor would I respond to a detailed plea for help by running away and telling someone else to deal with it (e.g. blindly reassigning the ticket).
While it’s true the rules and expectations for dealing with tickets may differ then those for in-person interactions, we still need to push ourselves to treat customers the same. Remembering that they are, in fact, human, and do, in fact, need our help, is a quick mental shortcut to improving their interaction. Very frequently this also helps improve the relationship with your customer - they feel like they’re being treated well, so they will be easier to work with. This helps solve challenges on both sides, the agent feeling like something’s being dumped on them without enough info, and the customer who’s feeling like they’re being treated like a machine.
Getting out of the ticket
There are tickets that, for whatever reason, blow up and escalate. Maybe it took too long to resolve, maybe the customer doesn’t feel like you’re responding fast enough, or maybe the customer cannot effectively describe their challenge in the ticket. The reason doesn’t matter, but this is the point in time where the agent has to get out of the ticket and setup some in-person connection (not that they could’t do this earlier, they should!, but they REALLY need to do it during an escalation). This could be walking to the customers desk, video chat, phone call etc. but the point is to make a more human (and real-time) connection.
Doing this solves a number of challenges. First it demonstrates the agents sincerity in resolving the issue. This alone can have a huge impact on the situation (especially if the ticket has been sitting, or going back and forth for a while). Second it removes the distance a ticket creates and allows for more immediate feedback. Now the agent doesn’t have to wait for a screenshot, they can see exactly what’s happening. Third it helps build a real connection between the agent and the customer. This is incredibly important to both the current challenge, but more importantly it builds a relationships between both sides.
This third benefit is the most important since it builds towards the future. Next time there’s a ticket the customer is more likely to provide more info and be a bit more understanding in delays. The agent is more likely to give the customer the benefit of the doubt and provide better support. Additionally both sides will tell other people about the interaction. The customer will impact how others perceive their help desk and vice-versa. This ripple effect is immensely powerful and helps stop the negative feedback that crops up with ticketing systems, and (even better) helps improve the relationship between tech and partner teams.
Only Human
At the end of the day we’re all human. We do the best we can and sometimes we make mistakes. Regardless of the situation we still need to treat each other as living, breathing entities and not as lines of text on a screen. Keeping this in mind helps elevate both the level of service provided, but also the relationship between agent and customer. The strength of this relationship is directly related to how our customer perceives us, impacting how they treat us and what they tell others about us.
Keeping the human aspect at the core of support not only helps the customer feel heard and respected, but improves our workplace and job satisfaction as well. After all, who wants to work at a place that treats its people like machines?
Data Shepherds
Data needs tending. This is becoming more true as the amount of data we have only increases. Given its importance, it’s critical that partner teams trust their tech teams to manage and use that underlying data correctly.
Much like sheep wandering the country-side data needs tending. What exactly this entails means a great many things, from ensuring database tables are setup correctly, to running errors checks against incoming data requests, to ensuring proper authentication methods are used. While each given environment may require different specifics, they will require someone to monitor and maintain it. This could be a Database Administrator, Functional Developer, or System Administrator. Regardless of this individuals role or title, they will need some level of access to the data, if only to ensure it’s actually there, and some data, especially things like Financial or PII, can make this a nerve-wrecking experience for partners.
And WHY do you need access to that?…
The business side can be understandably nervous when someone has access to their most sensitive information; after all it’s important stuff! What is sensitive may differ based on team, location or industry, but the fact remains that SOME data will fall into this bucket. On the other side is the tech partner who is responsible for maintaining those systems; the individual who needs access as part of their job. Between them lies friction, and responsibility of being a good data shepherd.
There are always times when a technical partner requires access to this sensitive information to perform some Amazing Thing. Naturally (and rightfully so!) the business will question WHY is access required to that information. Frequently my response follows some pattern of
“Without access to your data, we’ll be unable to accomplish that Amazing Thing you wanted.”
Of course the exact response differs depending on what the data is, but the basic reply is the same. I cannot accomplish the request without access to this data set or system for XYZ reasons. Most of the time (and after some further explanation into the why and how) I’ll get what I need to complete the ask. If pushed, however, I’ll tell them something like:
“Well, it’s possible for me to do this, but without access to the data I cannot validate my solution., which is bad for ABC reasons.”
This tends to put a stop to any further line of thought, as frequently me (or the team I am on), are the only individuals who can do The Thing. I’m not suggesting we don’t fully justify WHY, or even that we keep access indefinitely, just that calmly pointing out that The Thing isn’t possible without this information tends to be a very good way of convincing a partner to help provide access.
It’s just a set of numbers
One of the first times I ran into the challenge of access to sensitive information I was validating Social Security Numbers (SSN) in a HR system. Generally theses are considered to be rather important pieces of information, and so they should be both accurate and highly controlled. Before being granted access a more senior tech taught me a great lesson
“It’s just comparing one number to another, and our job is to ensure they match”
This was very impactful lesson for me and drove home that our job is to ensure the data is correct regardless of what that data is. It doesn’t matter if I’m confirming someone’s email address is valid, and this is especially true when dealing with highly confidential or sensitive information. Commonly this may involve confirming a termination action was correct, or updating compensation. It doesn’t matter that Jimmy makes $5,000,000, all it matters is that particular number is what it should be.
I also frequently let my partners know that once I’m done by access can (should) be revoked. I actually prefer it this way since it greatly reduces the possibility of a problem cropping up. Selfishly it also means there’s one less thing I have to deal with / worry about, which is always good.
At the end of the day, most data is important. It doesn’t matter if it’s SSN, payroll data, or publicly available info, it must be tended to appropriately. Fortunately tech partners generally aware of special requirements, but it’s never a bad idea to highlight areas that require more security or specialized handling. I always thank my business partners when they do - it helps them understand I am aware of the important, and helps reinforce our collective responsibility to be good shepherds.
On Entering Tickets
We’ve all had to put a ticket into something SOMEWHERE. Despite our collective practice, many tickets do not provide enough info for folks to get the help they need. Here are some tips.
Ticketing systems are everywhere, airlines, apartments, work. Everyone's reached out to one (sometimes not knowing it's a ticketing system!) at some time before, but despite the ubiquity of them many of us aren't the best at putting in good tickets.
Good tickets contain enough info for the person at the other end to understand what the problem is and determine a course of action. These tickets tend to include things like screenshots, error codes and descriptions of what was going on at the time. They not only provide the WHAT, but also the HOW and the WHY behind the ticket.
The bad
Before we look at what makes a good ticket, we need to understand what makes a less than good ticket. Consider the following (let's also assume the ticketing system knows who you are, what time it is, etc):
“Help! I can’t log into system ABC.”
This does tell us some information, that you cannot log into ABC, but the information provided is very limited. If I'm a very good tech I would first check to see if you have access to ABC, or if you're even supposed to be able to (its surprising how many times people try to log into systems they shouldn’t!). More likely, a tech will look at this, roll their eyes, and respond with something like:
“Ok, tell me what happens when you try to log in.”
While this response is typical, it doesn’t do much to get more information from the customer, and it doesn’t help establish positive rapport (not the scope of this discussion, but also very important!). Ideally the tech should do something more like :
“I understand you’re having trouble with ABC. I see you do have an active account in ABC. Could you please got to this link, try to log in with you username and password and send me a screenshot of your entire screen with what happens?”
I won't get too deep into how to properly answer tickets (a fascinating topic worthy of it's own discussion!), but this approach provides clear next steps for the customer. It also clarifies some assumptions, such as the user knowing where or how to log in, or them forgetting their credentials.
A Good Ticket
Short of just getting “Help!” (which does happen!) the example above is basically a worst case. A good ticket is one step up by providing more specifics, such as an error or screenshots. Thankfully more often than not customers fall into this bucket, mostly due to previous experience and/or training. It looks something like:
“When I try to log into ABC I get a ‘account not found’ error, help.”
This clearly states the problem, and provides some technical info to look into. It's better than the bad example since we get that error message, but even here more info would be really useful. For example a link to where they logged in, or telling us it worked yesterday.
Really Good Ticket
Rarely, oh so rarely, I see an exemplar. A ticket worthy of being printed off, framed, and hung on the wall as a shining beacon to direct people to. Something like :
“I tried logging into ABC at this link, but got a ‘account not found’ error (see attached). I could log in with my username last week, and don’t think anything’s changed. I need to get in to pay everyone. Help.”
This one gives us everything:
What - they can't get in, and am error plus screenshot
How - at a specific website, with info on it working before
Why - a business reason which helps determine priority
This information removes a lot of the guesswork for the tech. They should still double check, but now they know what to look for, and when to look (sometime in the past week). It’s also possible this info will trigger an immediate answer (e.g. system maintenance is ongoing and locking folks out), or otherwise clue-in the technician to something that may be impacting them.
While I concede our users won't do this all the time, we need to set the expectation on them to give us good tickets. Folks should be regularly reminded how to put in tickets, and that putting them in properly is beneficial for everyone. Not only does it make our techs lives easier, it decreases back and forth, shortens response time and makes everyone happier.
Afterthought of an afterthought
HRIS tends to be the forgotten cousin of IT - it’s frequently brought in at the last minute (if at all). Building better partnerships with HRIS helps both sides, as the business gets better results, and the tech team gets less grey hair.
Very frequently businesses need to make decisions about the business. These may be big or small decisions, but they all have one thing in common - tech/systems partners should be included in them sooner rather than later. This is doubly so for HR Information Systems (HRIS) since many highly sensitive things (like payroll) will be impacted, and very frequently the complexity of those systems isn’t fully appreciated by the business.
Oh, right.. we need that.
I frequently joke that IT is an afterthought. After all, no one starts a company to fix their own computers. Eventually, though, someone realizes that yes, you do need someone to manage your IT resources. Once this happens, things tend to get better for IT. The business fully (or at least mostly) realizes the need for IT resources, but this generally doesn’t flow over to HR. This results in HRIT becoming an afterthought of an afterthought - after all, we have HR Generalists / Coordinators / Business Partners to handle running HR, why do they need systems experts?
This is also compounded as HRIT and IT are only cost centers (would love to hear if anyone’s found a way to change that!). Since we don’t obviously increase profits it’s harder to justify why they exist. It’s also hard in some cases to prove their actions save money (how many dollars does a good knowledge base page save?). While it is possible to break down ticket cost etc. that also takes time and money, resulting in a nasty spiral of not wanting to do the work to prove it’s worthwhile since you don’t know it’s worthwhile.
Being a double afterthought results in problems ranging from processes being done manually that can/should be automated (manually emailing new hires vs. automating with free add-ons), to catastrophic problems resulting from the lack of understanding / planning (for example paying groups of terminated employees well after they’re gone). In my experience these problems are brought to the HRIS teams attention… but only AFTER the impact has been felt by the company.
The problem is this is the same as ignoring leaky pipes in a submarine, eventually the “savings” of not pumping up HRIS will result in a massive problem.
Leaky Pipes
Since HRIS is usually the last player to the party (or at least the last invited), we tend to only get looped in at the last possible second (“We need this live tomorrow” is a common request…). What kills me about this is many times I hear that planning for that initiative had been in the works for weeks, of not months, before hand. I very frequently find myself wondering how we can have so many smart and talented folks around, but constantly fail to include critical elements early enough in the process.
Some common things I hear about why HRIS isn’t included earlier, my thoughts, and possible solutions:
This project is highly confidential/legal/sensitive, so we have to limit the people involved
One of my favorite reasons (especially the confidential part). I completely understand the need to keep information contained, but every company I’ve ever worked with has had me sign some type of NDA. In addition, HRIS teams tend to deal with highly sensitive information as a matter of course (SSN, pay scales, home addresses, etc). It is expected that we are good data stewards, so your list of terminations is just like any other spreadsheet to us.
Solution - One of the simplest things to do is select one individual from the HRIS team (e.g. the manager) to get advanced warning that things are coming down the pike. They don’t have to get specific details, but a general outline of what is required is enough so they can think through possible fixes. Ideally this person understands both the system and the business ask well enough to make it generic so the team can plan.
We didn’t realize the impact on our systems
Any time I hear this one I scratch my head. I find it hard to believe that no one on the project team realized your plan to change compensation for 1,000 people wouldn’t, in some way, impact HRIS.
Solution - Involve your HRIS or IT teams in EVERY major change you consider. You wouldn’t leave Finance out of a discussion where you didn’t know with 100% certainty they’d be needed. At the very least include them in the “I” of your RACI charts (or whichever flavor your company prefers). This way your HRIT teams will at least be aware of whats going on and will speak up as needed.
We spoke to so-and-so and they didn’t think we needed to do anything
This generally results from someone on the project team (or their managers) making assumptions about how HRIS operates (similar to “This other place I worked at did it this way…”). The outcome tends to be dramatically skewed expectations from the project team that, at best, will alienate your HRIS teams (e.g. a change should . “only take two hours” but instead takes 4 days and 2 employees to fix).
Solution - This is all about proactive partnerships. Special project teams should regularly meet with HRIS teams to understand basics of the systems such as estimations on standard requests, downstream impacts, etc. Not only will this help alleviate #1 and #2, it will foster better collaboration and build trust.
Plugging the leaks
The best way to get over being an after thought is to build proactive relationships with HRIT and partner teams. This can take the form of a monthly lunch and learn where systems basics are shared, or specific meetings to go over features, or formalized partnerships where team members regularly sit down and go over challenges. At the very least this will help give partner teams a better understanding of just how complex the plumbing is.
I tend to prefer in-person sessions where I walk through specific processes, or demonstrate how specific features work. While I tend to have a plan in mind when we begin, the discussion frequently veers off into different areas based on comments or questions from my partners. Personally this is some of the most interesting discussions to be had about systems. Getting a systems expert and a business expert in the same room is bound to come up with some good topics.
To help avoid last-minute “gotchas” related to HRIS, we all need to remember that every aspect of what we do is complex; often more so than we think. Taking time to help the business understand our complexities, and appreciate the effort required to make “simple” changes, more than pays off. It not only helps strengthen relationships, but will pay dividends in future projects as partners are better equipped to help address challenges before they come up; hopefully bringing HRIS out from the shadows of being an afterthought.
"This other place I worked at did it this way…" ~ Some Executive
Tech teams need to be brought problems to solve, not solutions to implement. Frequently business partners only present their ideas for solutions, which, at best, will steal time from actual problem solving, and at worst cause problems down the road.
This is one of the phrases I dread hearing the most, mainly because it usually ends in “... so I’ve already told everyone we can do it this way” (or something scarily similar). This phrase definitely falls into the bucket of “partners telling us solutions” (which has it own dangers), however, for me this one is a little bit more insidious…
A Game of Telephone
Generally I don’t hear this phrase first hand. Instead, I’m (un)fortunate enough to hear it second, third or fourth hand. It tends to originate from someone higher-up in the org chart, generally a VP, Senior Director or the like. It also tends to originate from a place with good intentions. After all, this person and their team is faced with a big challenge, so why not use something they KNOW has worked before?
How it plays out (in Robs super-oversimplified world)
“Well, when I was at Telsa/Ford/GE/Kraft we solved this insanely complex thing by doing X, it was easy and took 5 minutes”
“Ok, cool, I’ll tell Rob to do it that way too”
Why it’s scary
This is scary since where ever we are now, we ARE NOT at the same place this worked for them in the past. We’ve also entirely skipped the part where we identify the problem. Even if the business is identical and we make the same product/service, the way our systems are setup will differ in some fashion. Generally we’re not in the exact same industry, making the differences even greater. Further, the individual who puts this idea forward likely does not understand the specifics of what was done, only the end product (it’s seldom a Director or higher I meet who truely cares to learn the technical specifics). So even if the solution worked exactly as remembered, they do not fully understand the pretzels their tech teams had to wrap themselves into in order to deliver.
How it should play out (in Robs super over-simplified world)
“Well, when I was at Telsa/Ford/GE/Kraft we solved this insanely complex thing by doing X, it was easy and took 5 minutes”
“Ok, cool, let me tell our Tech Experts about Way X, but we’ll also go over the problem and explore other solutions”
Getting from scary to supportive
Technical teams (whether it be IT, legal, communications, etc) are the experts in solving problems, so we get very concerned when instead we’re fed solutions. The best way to improve this relationship is, well, to improve the relationship. I personally spend a great deal of time working with my partner teams and sharing the basic concepts / patterns/ processes that my team uses. This helps demystify tech (that said a lot of it is still magic to me) for my partners, and, more importantly, helps build trust. This is needed for those times I have to tell them that what their VP said may have worked somewhere else, but it may not work here.
In the end it all boils down to the strength of relationships with partner teams. These scary phrases will continue to come up, but, they should become less and less scary as time goes on and more and more folks know to trust their tech.
On bringing solutions
I always appreciate when my partners think through challenges before coming to my team. It does get a bit dicey when they bring us solutions they think will be best…
One of the most common challenges I’ve run into is having a partner come to me with a solution to a problem they’ve run into. This might take the form of “Have Workday do XYZ”, or “Build me this type of report”, or “Use this tool to do X”. Part of me really appreciates my partners taking the time to figure out what they want to happen… but a much larger part of me has a blood pressure spike and a few more grey hairs pop up.
Why the grey hair?
I really do appreciate my partners taking a stab at figuring out what’s going on. I get the grey hair for a few reasons:
Generally partners don’t have the full picture - Partners usually are only aware of the aspects of systems they interact with (which is all we can expect or ask of them!). This means they frequently are unaware of other solutions, or of interactions with other systems.
Partners are usually not technical experts - Nor should they be! I frequently tell mine I’m not an HR expert and I’m glad they’re around to do that. That acknowledgment also means I don’t go tell them how to fix HR challenges though.
Their focus is only on their stuff - One of my favorite phrases is “This is my P0 (priority 0)”.(more on that in another post!). Everyone (me included!) has a personal list of what’s important, and nothing else comes close. This makes things problematic as partners get tunnel vision on just their own items.
When a partner brings me a solution they’re generally already stuck on one (or more!) of those items. This means I have to take time to talk them down (all that de-escalation training at the help desk REALLY comes in handy!) and explain why their solution may not be the best idea.
Why it’s challenging
While I find it great that my partners put thought into a solution before they come to me or my team, it tends to set us up for failure in a few ways:
They put energy into it - Once someone puts time/energy into something it’s MUCH harder to change their mind
They’re “stuck” on their idea - Everyone likes their own ideas, and it gets particularly challenging to try to change their thinking.
The clocks (usually) ticking - Since my partner’s already taken time to come up with an idea we now have less time to build one together. This can be particularly troublesome with highly sensitive asks.
These generally occur in some combination, which makes the initial talk mostly focused on talking my partner down or trying to find ways to reshape their thinking.
Just come back off the ledge…
This is where I find connections with my partners to be particularly important. When I first work with someone I don’t have any credibility (other than being the “IT” guy), so I have to build it on the fly. Once I have an established work relationship that process is a LOT quicker, allowing us to get to the source of the problem much more quickly.
I use a number of tools/tricks to help with this, but some of my favorite:
What are you trying to solve with this? - This question helps my partner focus on the problem and gives me an “in” to have them demonstrate it. This makes it easier to change their thinking about a solution.
Why do you want to do this? - Similar to the above it makes my partner explain how they got to their solution, which helps me figure out WHY they (think they) want it.
Who else have you spoke to about this? - This is a great question to help determine where their solution idea came from. This can then help me figure out how they came up with their idea.
Getting to a good endpoint
Usually this boils down to spending an hour with my partner to go backwards through their solution. This can be a painful process, but helps us uncover why they wanted that particular thing and, more importantly, better understand the underlying problem. There are some times when their solution ends up being the one we go with, but many times we land on a different approach (usually based on information my partner didn’t have, e.g. how a system operates).
The most important aspect of this approach is the time spent with my partner. This helps build a positive relationship with them, which will only help me out in the future. As the relationship progresses both my partners and I get better and presenting challenges, and developing solutions.