Know what to cut

When I was in 5th grade I remember a classmate telling me how excited he was that the teacher was cutting everyone’s lowest quiz score. I got excited because my lowest score was…. low, but I was entirely confused that he was dropping his lowest score, a 92%. To me that was a great grade, so why would he want to not keep it?

Now despite my younger-selfs math-related challenges I find the approach of dropping the things that are holding us back very beneficial. Not only do we better understand what we are doing every day, but we can also hone our skills and improve our outcomes. I’m not suggesting we simply stop answering tickets, or stop doing chores, but I am suggesting that can find creative ways to get rid of the work that holds us back from becoming something greater.

---

What’s holding you back?

The first step is to figure out what, specifically, is keeping you stuck. This might be having to run a specific report, or manage a specific system, or deal with specific client group. I find it helpful to go through my calendar and emails and see what I would procrastinate on, or what I have a poor knee-jerk reaction to. That meeting on Tuesday mornings with auditors that I always dread? That one email from accounting I keep snoozing? Both great examples of things that maybe I could find a way to drop.

Just write down anything that falls into that bucket (I’m focusing mainly on work, but this can apply to anything), and, ideally, a quick reason WHY you’re putting it on The List. You don’t have to make The List all at once (I keep a rolling one going), so don’t feel like you need to cram in everything. The List may also change as time goes on. Maybe the guy in Accounting you don’t like working with leaves, or maybe you’re given the opportunity to improve the report that you hate running. Don’t think of this as being set-in-stone, but rather something that grows and changes with you.

Our example list:

Audit Report

Accounting Meeting

---

Now What?

Once your List is up and running make time to better understand what about each item makes you want to cut it. This could be a one word reminder, or a longer description of why it’s holding you back, but the intention is to better understand both why and how its holding you back. In my math example it would be “A 92 is my lowest score, and it’s lowering my overall grade”. For running a report it might be “The audit report can be run by anyone and it takes 3 hours every week”. Understanding your knee-jerk response to the item will help you better understand what you can do to get rid of it later.

Unless we get REALLY lucky it’s unlikely you’ll be able to get rid of everything on The List, so after you understand WHY it’s bugging you, stack rank everything. I find it helpful to quantify things a big with the following dimensions, both are on a subjective 1-5 scale of 1 being low and 5 being high.

• Frequency - How frequently does this thing come up? Is it a standing weekly meeting, or only once a year?

• Annoyance - How much does this item bug me? Will I complain about it to my spouse daily, or only gripe about it to myself once in a while?

This makes it a bit easier to more “objectively” (in quotes since the scales are entirely subjective) determine which item should be jettisoned before others. Once I’ve rated everything I just add the scores together and look for the highest number.

Our updated list:

Item	Frequency	Annoyance	Total
Audit Report	5	2	7
Accounting Mtg	3	5	8

---

And Then?….

Now comes the tricky part. We’ve done the work of figuring out what we want to get rid of, and in what order… now we have to actually get rid of it. Exactly how this happens depends a lot on your environment, what is available at the time and your company’s culture. Some of my favorites:

Shift the work to a more junior co-worker

“One man’s trash is another man’s treasure”. This can hold true for work as well. Many times a task that I find boring or mundane is something a more junior co-worker will jump on. Instead of being an onerous task I have to deal with, it morphs into a coaching opportunity that helps upskill my team. This is beneficial to me, since I both get rid of the task, beneficial to my teammate who gets exposure to something new, and beneficial to the greater team since skills are being improved overall.

Automate the task

While this doesn’t work in all cases (e.g. meetings), this is one of my favorites. Many tasks, especially those in a tech environment, can be automated away. In addition to getting rid of the work, I find this a fun technical exercise, almost like a mini-project. In the past I’ve done things like automating reports, auto-forwarded emails, written google scripts to automate badging into classes, and tapped into APIs to grab workday data. Any given solution will be unique (which is half the fun), but I really enjoy this approach since I both get to remove work from my plate, and explore new methods of automating stuff.

Delete the work

In some (usually rare) cases, the task can simply be deleted. I’ve found this to be true with some reports, especially ones that are more historic, as well as some access-related tasks (simply stop sending it or remove access and see what happens). You need to be careful with this particular approach, however, since the thing you delete might actually be needed. To help curb this instead of outright deleting something I tend to disable or hide it for a while. If no one notices after a month or two I’ll straight up remove it.

---

I was told there would be no math

While this exercise does take time, it is incredibly helpful, even if you can’t actually get rid of anything immediately. A better understanding of what you want to get rid of will help you start to find ways of improving. You’ll also get a list of things you can talk to your team or manager about, which may lead to some interesting solutions (maybe other folks have the same things on their List, or have creative ways of dealing with it). It helps me to remember that when I’m looking over what I do. At the very least I’ll get a better understanding of my work, at best I’ll be able to better focus on what is really important.

Remember : There's a person behind that ticket....

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:

1. Miraculously the ticket gets resolved - both parties are relieved, but not happy

2. 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.

3. 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

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.”

— Me

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.”

— Me

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”

— More Senior Tech

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.

Make it work

About half way to the store the other day one of my slippers (the right one) decided it had enough and tried to kill me (unsuccessfully).  Stranded, I was left with little option on how to finish my grocery run - I certainly didn’t want to walk half-bare-foot back home, get shoes, and go back… but I also didn’t want to walk half-bare-foot to the store and back.

Instead of losing my cool, I took a moment to assess what I had, examine options and weigh risks. Looking around I found a piece of twine, and figured I could jerry-rig a fix that would hold for one last store run. I took a few moments to tie it through the hole in my slipper, put it back on, and finished out my chores.

Very frequently I find myself in similar positions at work - something breaks (frequently at the last possible second on some Really Important Thing), and I’m asked to help fix things. When it does, I take the same approach as I did with my slipper:

• Step back and breath

• Look around

• Examine Options & weigh risks

• Execute

---

Step back and breathe

It’s really common for adrenaline to spike when something goes wrong. I tend to feel this as a quick pulse of energy and the jitters, and it can make it harder to make good decisions. Luckily almost nothing I do in tech (hopefully the vast majority of us in tech) has life-or-death consequences in the next few minutes (hopefully not ever!), so I can take the time breathe and calm down (or calm down my partner). This allows me to figure out what the problem actually is, and to help set me up for success in the next steps.

In the case of my poor slipper - This took the form of recovering my balance, kneeling down and taking a few breaths (and hope no one saw my inelegant stumbling).

In the case of a system - This takes the form of taken a few breaths and remembering the world isn’t ending (assuming you’re not a missile command officer). This includes helping your partners, who are likely feeling a lot of heat, take a breath and get perspective.

---

Look around

Once I calm down a bit, I look a round and see whats REALLY going on. Many times I get reports that XYZ system is entirely offline, or that ALL users are having a problem. Now why these things are certainly possible, it would require a large system failure (which are hopefully very unlikely!). Due to the less-than-likely nature of these problems I take the time to quickly investigate. I keep a list of everything I see, including items that are working properly, so I can make the best assessment possible.

It can certainly be hard to do this, especially if your partner teams are screaming that everything is broken and the company’s going under (it’s not). You should always ask for as much information as they can provide (e.g. screenshots, what error message, how many reports, etc), but if they do come at you in a panic, help them take a breath (step #1). Having a calm business partner will effectively give you two (or more) sets of eyes, making it easier to isolate the real challenge.

In the case of my slipper - I dug through my backpack and looked around on the ground for anything that might help.

In the case of systems

• Can you open the website that is “entirely down”?

• Can you find any examples that contradict the reports? e.g. if ALL paychecks are wrong, can you find any that are?

• Can you replicate the problem? if not, can you connect directly with who experienced it?

---

Examine Options & Weigh Risks

Taking the time to look around and really see what’s going on helps set up some options. You’ll get a good feel for what resources there are, who’s around, and (if you’re lucky) that cause of whatever happened. These options may be good, or they may be terrible, but the important thing is to sit down and list them out. Even better, if you have some team members around enlist their help. Their differing experience and outlook can help find solutions you cannot currently see.

While you’re listing out possible solutions, also take time to consider the risks to those options. Yes, a manual adjustment may fix things, but what down stream impacts are there? Sure, having a partner team in Japan do something while you’re asleep might help, but will they have enough context/info to execute? This process may also help uncover other options, or help other ideas shake out of your overall process.

In the case of my slipper - I dug through my backpack for anything that could help (sadly no extra shoes), and looked around on the ground for string or something similar. Another option would be to call an Uber.

In the case of systems:

• Are there other teams / individuals who can help shoulder the load temporarily?

  • Do they have enough info to be truly helpful?

• Is there a manual workaround that can be used until the problem is fixed?

  • What problems can come up if it is used?

---

Execute

Once you’ve determined what options are available it’s time to act. Depending on the situation execution can result in a lot of fast movement, or single simple change. For me this is the most nerve-wrecking part, but since you’ve already taken the time to determine your options and risks just stick to the plan! That said, remember that no plan survives contact with the enemy, so you may need to quickly adjust or modify pieces of it. This can require rapid iterations of the plan, so ensure your partners know what’s going on and make it happen.

In the case of my slipper - I tied the twine through the hole in my slipper and made two loops. It was awkward, and I had to stop every so often to adjust, but it worked!

In the case of systems - Every situation is different, but this can take the form of building reports to monitor progress, double checking UATs, and (always!) over-communicating how things are going with stakeholders.

---

Making it happen

These short-cycle situations are always nerve-wrecking. Someone is usually very animated and likely putting pressure on you to get things done. Even though it takes a bit longer, this approach will not only help get better results, it will show your partners you know what to do. Over time this helps build trust, and will make everyone’s lives a little bit better.

On Entering Tickets

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.”

— User

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.”

— Technician

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?”

— Better Technician

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.”

— User

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.”

— Really Helpful User

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.

Ticketing system basics

Tech teams of all stripes rely on tickets to track their work.  Tickets may be put in to ask for updates ask for new work or report problems.  They may be put into a formalized ticketing system like JIRA, recorded in email (please God, don't do this!), or even written on a board (seriously there's free tools to help!).  Regardless of method of collection, system used or content, what a ticket contains is incredibly important to it being treated properly.

---

Bare bones

At the very least tickets need to contain some basic information.  This includes things like:

• Reporter - the individual who provided the ticket is critical in providing additional info, clarifying questions and confirming it has been completed.  Many systems record this automatically. While possible, anonymous tickets should be avoided unless absolutely necessary and clearly justified (e.g. anonymous complaints)

• Assignee - having a single (yes, SINGLE) owner of a ticket helps ensure clearer communication,  accountability and follow up. While this person can change, tickets should always be clearly connected to someone. Depending on the type of ticket this might be a project, manager, development resource or help desk technician.

• Description of request - this generally comes from the reporter and details what the ask is.  Frequently this is lacking in information (I can't log in), requiring triage of some form to get more info (can't log into which thing? What did you try?).  Because of this it is incredibly important for the reporter to be very clear and accurate in their request.

While there are certainly other data points that are useful (time entered, labels, tags, priority, etc) if you can nail those three things 100% of the time things should go (fairly)  well. The more complex the system is the more fields you'll tend to see as well (e.g. which team owns this? Can it link to a knowledge base of some kind?).

---

Additionally useful fields

The above are critical and should be mandatory for everything, but there is a lot more interesting things to be learned.  Once you've captured basic information it's very helpful to know more about that info (metadata). Some of my favorites include:

• Time entered - this timestamps can be used for a lot, including stack ranking (oldest first), handling expectations (we only got your ticket last night, chill out) and developing SLAs (especially when combined with Time Closed).

• Time closed - another timestamps telling you when the ticket was closed.  Very useful for fending off repeat requests (we already answered this last week), building SLAs (every ticket solved in 24 hours) and determining Mean Handle Time (MHT).

• Tags - Also known as Labels, these things allow you to sort tickets by them.  Generally requires a human to attach (e.g. reports put a 'bug's tag on tickets about bugs), but allows you to slice metrics by them (e.g. what's your MHT for bugs vs questions).

---

Pandoras box

One of the downsides of collecting this data on your tickets is folks will begin expecting more from you.  For example, expect to start reporting out on how many tickets come in, which areas report them, average response times, etc.  You will also likely be held accountable to some agreement around resolution times or MHT.

While the 'downside' can be a bit annoying since you'll now need someone to actually gather the metrics and report, it gives you a lot of power.  Once you get a baseline you'll be able to do some interesting things:

• Targeted help - you might find certain groups or areas report a large number of problems. Once you know this, create specific training just for them to help reduce their numbers (make a game out of it).

• Prioritization defense - once you know some tickets take more time than others, or have a bigger impact than others, you can more easily prioritize work.  Even better, you can show your partners WHY you're doing that, which will reduce pressure on you to justify yourself.

• Team support - frequently tech teams get overwhelmed or blindsided by waves of tickets.  Knowing what tends to come in, and when, gives you the ability to plan ahead and get your team more training, or clear their calendar if needed.

Having this information is not nearly as important as having the discipline to actively manage it.  Reports, after all, are useless if they're not maintained or read! Keeping only a few basic metrics, however, is easy enough to do (especially with today's tools), and provide a lot of advantages.  Even if you've already got a solution in place, take some time to reevaluate it, you never know what improvements you can make or what you'll learn.

Afterthought of an afterthought

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:

1. This project is highly confidential/legal/sensitive, so we have to limit the people involved

   1. 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.

   2. 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.

2. We didn’t realize the impact on our systems

   1. 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.

   2. 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.

3. We spoke to so-and-so and they didn’t think we needed to do anything

   1. 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).

   2. 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.

Getting into tech

Many people I speak to who aren’t “in tech” express a desire to be “in tech”. There seems to be a certain glamour surrounding being 'in tech', that being able to say you're 'in tech’ is a Good Thing. I always get a kick out of this since being 'in tech' can mean many thing (also the reason I use the quotes for 'in tech’). Do you want to become a product manager? A programmer? Network Engineer? There’s a huge range of opportunities “in tech”, the trick (after determining you want to make a switch) is to pick which branch you want to look into.

Once you do though, be open to a change of pace/leveling/etc. Depending on your background you may essentially be starting from scratch, so make sure you’re OK with a more junior position than you have now (not saying it’s guaranteed, just be prepared!). Once you’re OK with all that there’s a whole lot more work to do!

---

What do you mean by tech?

When we think of tech most of us tend to think of a programmer locked in her basement making the Next Big Thing. While I feel this stereotype is damaging to programmers (sometimes they’re locked in their bedrooms), it certainly isn’t the only kind of technical role a company requires. Indeed, the types of technical roles available will vary based on industry. Laboratory technicians are likely not needed at a financial firm, and programmers are less likely to be found in factories.

Have an honest discussion with yourself about what you mean when you say you want to get into a technical role. Reach out to folks you know on LinkedIn who you are in a similar field to see what they think, and grab time with trusted friends/mentors/role models to talk through your thoughts. This will help you better target a good role, and, more importantly, better understand where your thoughts are coming from.

To go with the stereotype, if you’re thinking of becoming a Software Engineer (coder), it is a very available skill (throw a digital rock online and you’ll hit a dozen code academies). It still, however, takes time, discipline and a lot of elbow-grease to pick up (especially at any level that will result in a job at a big company). That said, there are many other technical roles available (by no means an exhaustive list!):

---

Technical Project Management

This role blends technical knowledge with project management. Technical Project Managers (TPMs) are essentially project managers for tech. Unlike a “non technical' Project Manager (PM), TPMs tend to require a deeper understanding of the systems or concepts they have manage. For example, a TPM implementing a new SQL database would highly benefit from understanding basic SQL commands, server requirements etc. They also serve as translators between the technical teams and the business partner they’re working with.

Good For - People with project management experience, individuals who want to be around tech without necessarily being IN tech.

Less good for - Wanting to get hands-on with tech. TPMs tend to work tightly with tech teams, but are not generally doing the technical work directly.

Quality Testing

Quality Testers (also called Quality Assurance) are responsible for ensuring products don’t get released with bugs or defects. Frequently this involves developing and executing test plans (which can be incredibly tedious!) that run through every combination of actions or inputs. While they work with software engineering teams they generally do not need the same depth of expertise in coding. They can, however, work on/write testing scripts to help automate the more boring parts of the role.

Good for - Folks who want to get hands-on with tech and do not have an in-depth background

Less good for - Folks who cannot handle monotony. Imagine having to look at the same website for a week and clicking each link repeatedly.

Sales engineering

Sales Engineers work with (you guessed it) sales teams to help sell products. Generally they’re brought in to help demonstrate specific use-cases, features or to find new ways to demonstrate how a product works. Not necessarily a role you’ll find at a smaller company, but larger ones (e..g Salesforce) will certainly have these folks around. Most of the time they know what they’re walking into on a call, but depending on how things go they may have to apply some quick-thinking trouble shooting if an unexpected question comes up.

Good for - Someone with sales experience and interested in working with multiple client groups

Less good for - Someone who doesn’t like sales, or someone or who wants to work with the same customer (internal or otherwise) over longer periods of time.

Data Analyst

Data analysts analyze data (shock!). Contrary to popularly held beliefs there is a huge amount of knowledge needed to be a good Analyst (not just how to use Excel). Fortunately the skills are readily available online and at schools. I personally find this discipline fascinating since it allows us to put order to data and help others draw conclusions from that. Data Analysts almost always need to learn some type of coding language in order to pull and manipulate data (e.g. SQL).

Good for - Someone good at finding and explaining patterns, or good at translating raw data into actionable insights.

Less good for - Folks who don’t like numbers, or folks who don’t like presenting insights to groups.

---

Taking the plunge

Once you’ve got a rough idea of what flavor of tech you’re interested in go learn more about it. See if your company has someone who has that role (or a similar one). Ask your friends if they know anyone who’d be willing to chat about it. Take the time to come up with some questions to ask everyone you speak with. This will not only make the best use of your time, but help you get a better handle on WHY you want to get into tech.

While you’re lining up folk to talk to take a look at job postings for the types of jobs you’re interested in. This will help give you a good feel of what types of things company’s look for. For me this really helped line up supplemental training/education (the whole experience vs. training question is out there, but more knowledge never hurts!).

One other thing you can do is look into volunteer opportunities. Many NPOs and community organizations are looking for help and have some interesting projects. At the very least these will help you better understand what you’re getting into and help focus your thinking. Also, they tend to not require 100% of your time, allowing you to stay at your “real” job while you feel things out.

Above all keep a good eye on WHY you want change, and while it may not happen overnight, eventually you’ll find a spot that makes the best sense for you.

YOU are the expert now

One of the first big IT projects I ever worked on was updating and replacing an ERP system called IFS. At the start of the project I was just an IT help desk tech (the guy who replaces your monitor or installs a printer). I was asked if I wanted to become the IFS Project Management Module expert, to which I readily said “sure, that sounds fun” (not to mention more interesting than installing printers).

Problem was I didn’t know anything about IFS…. or about Project Management….

---

I’m the expert?…

I have a two-pronged approach to solving challenges like this. The first is to have faith in others. In this case my job would involve traveling to multiple sites and standing in front of a room of professional Project Managers as the IFS Project Management expert, despite knowing basically nothing about either. The enormity of this (and the rather large knowledge gaps!) required me to have faith in my manager (who clearly thought I could handle things), my team (who supported me immensely) and myself (who learned to step up)… and this helped me not panic.

The second prong I use is to have faith in my myself. We’re all aware of our own capabilities, as well as our own limitations (be honest with yourself on these!). Once I really understand the challenge, I can map out possible gaps and determine solutions to those… generally this requires learning more about various topics (in this case IFS fundamentals and project management concepts) and boils down to doing my homework.

---

Don’t Panic - aka Have Faith in Others

Trusting those around you is hard. It requires giving up some amount of control and allowing others to dictate some aspects of your life. In most situations, I have enough faith and trust in the people I work with to make the best possible decisions for me in situations like these. This is doubly so once I have a working relationship with them and understand more about how they work.

When asked to take on incredible challenging , generally unknown, requests, I always remind myself that I wouldn’t be asked to do it if someone didn’t think I was capable. In most cases the person asking has more experience in the area than I do, further giving me confidence that I can do the thing (otherwise why would they ask?).

---

Do Your Homework - aka Have Faith in Yourself

Having faith in others is great, but it’s not enough. In order to succeed at this big asks, you also have to have faith in yourself. This includes faith in your abilities, but also in your potential. Over the years I’ve come to enjoy trusting in that potential since it has allowed me to flex and grow in ways I would not have without that opportunity.

For me, this frequently takes the form of (literal) homework. I’ve found myself enrolled in community college courses, teaching data analytics courses (teaching is a great way to help reinforce and learn new skills), reading stacks of books, and getting lost in the guts of a new system (one of the best ways to learn them, but always be sure you have a sandbox!). Since I also had a job, all of that had to be done on my “free” time.

---

I am the expert

It takes time, but eventually you’ll begin to accept these opportunities as pathways to growth instead of something to fear. For me the cycle of insane ask, not freaking out, working the problem and growing has become somewhat of an addiction. Not only have I built technical skills, I’ve had the pleasure of working with some very smart people (and made some great friends).

If we’re not being pushed by ourselves or others, we’re not growing, so grab every opportunity you can and enjoy the ride.

"This other place I worked at did it this way…" ~ Some Executive

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”

— My Imaginary Executive Type

“Ok, cool, I’ll  tell Rob to do it that way too”

— My Imaginary Teammember Type

---

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”

— My Imaginary Executive Type

“Ok, cool, let me tell our Tech Experts about Way X, but we’ll also go over the problem and explore other solutions”

— My Imaginary Teamember Type

---

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.

Getting comfortable being uncomfortable

Jobs, especially those in tech, constantly throw new (and sometimes exciting!) things our way. These things, however, can range from the mundane and boring to the pulse-pounding hair-pulling problems that come out of nowhere. Regardless of the excitement is causes, I’ve found being constantly uncomfortable with what’s going on has helped me both stay involved and helped me grow.

---

Whats uncomfortable?

“Uncomfortable” in this case doesn’t refer to feeling out of place, or feeling afraid/insulted by my team. Uncomfortable instead refers to the feeling of “hmm, I’m not 100% sure I know what this is or how to solve it, but I’ll take a shot!”. Our lives are generally about finding comfort, the most comfortable chair, the most comfortable clothes, the most comfortable relationship. First feeling this at work easily makes most people recoil, since who wants to be uncomfortable?

Uncomfortable can pop up in different spots for different people, but I found it showing up frequently when:

• I’m asked to take on something with a system or team I’m not familiar with

• I’m given vague or incomplete information on an ask

• I get pulled in to something last minute

These are all cases where I feel surprised, overwhelmed or frustrated.

---

Settle in, get comfy

There’s really only two options when that feeling comes up:

1. Embrace it and settle in

2. Reject it

Running is easy, really easy. This looks like pawning it off on a teammate, telling someone it’s not something you do, or simply not engaging with the request. Sometimes this response is appropriate, for example if you’re asked to something wildly outside your realm (think being asked to build dashboards when you’re an infrastructure engineer or front end work when you’ve never done that). How you do turn it down is important (and something I’ll get into more detail later!), but the other option is to embrace the discomfort.

---

Why get comfy?

Just like building muscle results in a bit of stiff or soreness, embracing the discomfort at work results in stronger and broader skills. Since that discomfort usually stems from being pushed a little bit further than you want to be pushed it also represents an opportunity to grow. Embracing that discomfort means embracing the chance to grow and to build new skills.

That said, it’s not always easy! Just like that first workout can turn someone off to the gym, accepting those tough, uncomfortable, assignments can be hard. Instead of seeing it as a painful thing to endure, I’ve begun to see it as a positive reflection of growth. Having that uncomfortable feeling now means I get to learn something new, and get to become stronger. So learn to get comfortable being uncomfortable. See out those things that will push you. It doesn’t matter if you blow it out of the water, or take your time working it through, you’ll get stronger.

On bringing solutions

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:

1. 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.

2. 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.

3. 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.

How Connections Form

We’ve all been there

Everyone, at some point in time, has been in that spot. For whatever reason we’re stuck doing something that pushes us and we need help. Generally this means we don’t know underlying concepts or ideas that are critical to success, or are unaware of how tools work. Some common examples include:

• Being asked to perform data analysis

• Managing a system or tech

• Developing / maintaining a process

On the whole we are very intelligent and skilled at what we do. The problems crop up when we’re asked to do work outside our normal wheelhouse. It may be presented as a stretch goal, or an opportunity to grow, but frequently we are left in a bit of a lurch since our background and expertise is in other areas (imagine a software engineer being told to manage a help desk, or an HR specialist being told to develop analytics).

On the plus side, we are (generally) very smart and talented. On the down side we’ve got basically no idea what we’re doing. This is where connections between technical and non-technical teams is critical.

These connections form several ways, but in general I find they are either organic or prompted.

---

Organic Connections

Eventually we end up bumping into someone who knows more about what we’re trying to do. This might take the form of a content strategist commenting on posts, or a database engineer asking why queries are written the way the are. In some very lucky instances we can reach out for help proactively, but generally we have to get lucky….

How this connection forms is critical, as it dictates how the relationship, and end product, will unfold. Generally it goes one of three ways:

1. The expert reacts negatively - demanding to know why it was done this way, or why a specific process wasn’t followed

2. The expert reacts neutrally - either not showing much interest, or just fixing the problem, without connecting with the individual doing the work

3. The expert reacts positively - attempts to establish a relationship and help grow the individual with the work

Most commonly I see the neutral reaction occur. While this may be seen as a positive thing since it results in a good (or . acceptable) outcome, it doesn’t really serve anyone. It robs t he individual doing the work of the opportunity to improve by learning the proper way, and it robs the expert of the opportunity to educate their partners.

Fortunately I don’t see the first very often. I imagine this only really happens in highly controlled environments, or when someone is having a bad day.

Almost as uncommon though, is the third, which strikes me as very interesting since it is by far the most beneficial to everyone. Not only will the expert help solve a problem more quickly, they will also better understand their partners needs allowing them to head off future potential problems. The individual needing to do the work also gains a valuable contact, and likely learns a little bit more about how everything works.

---

Prompted Connections

While organic connects crop up when we basically randomly bump into an expert, prompted connections connect when someone helps us get an introduction. This may take the form of a manager knowing who to talk to, a coworker having a friend in another department, or a process requiring submission of plans/questions. I personally find these connections to be a bit weaker than organic ones, mainly due to the more artificial aspect of them (e.g. Organic connections tend to arise around a shared challenge, whereas prompted feel more like a job requirement), but they are still incredibly valuable ways of connecting partners.

Regardless of how connections form, they are absolutely critical to everyones success; even aa one-person company needs them to survive. I do my best to build new connections, and enrich existing ons, every change I get. I find them rewarding both in terms of learning new things, but also in terms of getting to know the people around me. They not only make my job a bit easier, but a but more enjoyable since I’m meeting new people, and picking up new skills.

"Generic" and "Specific" Basics

One of the great things about life these days is technology. It (mostly) makes are lives easier, especially when it comes to work. I cannot imagine having to keep track of employee data on paper, having to run payroll by hand, or generating reports manually.

The downside of tech is that it requires at least a baseline understanding of how it works in order to get any benefit. These basics may be more “generic” (applied across multiple systems or scenarios), for example knowing the magnifying glass allows you to search, to a more “specific” basic, such as knowing how your underlying data is sourced.

---

“Generic” Basics

“Generic” basics are things that can be applied across multiple systems or areas. Save icons fall into this bucket since they’re almost always a floppy disk (something that dates back as far as I can remember!), which is especially amusing since physical media of almost any type is quickly disappearing. The search icon is another example that appears almost everywhere.

Despite the prevalence of these items, unless you understand what they mean you’re in for a very frustrating time. I once watching a steelworker manually scrolling through a list of 5,000 files despite the search icon being displayed at the top of his screen. I stopped him after a few minutes and showed him what the magnifying glass did, the told him to call me if he ever looked around for files again (I’ve always wondered how much time is spent globally manually looking for things….).

Digital natives have a massive leg up with the generic basics since they grow up with it all (I’ve heard apocryphal stories of young children getting upset that the TV isn’t a touch screen). Since their training begins so young they’re able to easily translate those basics to work.

---

“Specific” Basics

While generic basics may apply across systems, concepts or ideas, specific basics are, well, specific. Some examples I run into include:

• Workdays security architecture - Knowing how this works doesn’t really help you understand other systems security

• Using a video game controller - I see this one a lot at home with my family. Knowing how to use a TV remote does’t help you turn on the Xbox to watch Netflix.

• Perform data analysis - How data is collected, transformed, and stored has massive impacts on your analysis, but those changes differ based on the data source.

All of those examples are only really in the sphere they’re used in. Due to this Specific basics are generally only known by individuals in those areas.

---

Where Problems Crop Up

Things get dicey when someone :

1. Doesn’t know a generic basic

2. Incorrectly applies a Specific basic

3. Does’t know a Specific basic

The first tends to result from missing training. An employee is a physical trade skill (e.g. carpentry) may not be aware of the search icon, for example. This type is relatively straightforward to correct via training, but can be incredibly frustrating to that individual. It’s always a mark of a good

The second and third are where things get dicey. Not knowing Specific basics results in looking bad (example below) to catastrophic errors (inadvertently exposing social security numbers). Frequently I see these crop up when folks begin doing data analysis or presentation. Most recently I spotted this gem in a hospital:

97% isn’t a third of something!

In this specific instance the error wasn’t too catastrophic, but I always imagine what would happen if something like that was presented to the C-Suite.

---

Minimizing Errors

I’ve found the best way to help avoid both Generic and Specific errors is to work on connections with folks, and try to break down the “I only go to IT when something breaks” mentality. Having a solid (or developing) relationships makes it easier both for partners to ask questions, and for you to point out possible errors.

It’s also REALLY helped me to remember we all commit errors. Everyone has forgotten to save a file, or copy a formula, or how to correctly update something. Keeping our humility, and remembering we’re all in this together, will go a long way to keeping things running smoothly.

Trust. But Verify.

One of the favorite things I’ve learned working in IT is to “Trust. But Verify”. I find it especially helpful when I answer support tickets as users are frequently either mistaken about what they’re seeing (an ambiguous error message), or unable to provide all the information (e.g. they don’t realize they’re missing permissions). To me it means that I trust that the partner or customer I’m working with is giving me their best possible info, but that I still need to back it up and look into it myself. Pulling up the floorboards this way not only helps me determine the root cause of whatever’s happening, but also helps me learn about systems and processes in new ways.

Generally I don’t say “Trust, but verify” to the folks I’m working with (although I do use it in mentoring/coaching sessions to help folks get in the mindset of validating everything). Instead I have a number of variations I use, things like

• “Prove it” - Generally more in teaching situations where someone tells me they have the answer / they’ve done something cool. I use this phrase to challenge the person I’m working with and see if they’ve really done what they think they’ve done. Also something I only really use with folks who know me and won’t be put off by the wording.

• “Can you walk me through what’s happening?” - The more user-friendly version of “Prove it”. Everyone in IT know folks tend to report only small portions of what’s going on, this helps uncover the underlying pieces. It also helps my partners learn the process a bit better since they have to go through it a few times so I can understand it better.

In addition to answering support tickets, this phrase is also great when performing any kind of systems analysis. Frequently what I see isn’t what you get (the opposite of WYSIWYG). I’m finding this to be especially true as I navigate new systems (like Workday) that have underlying architecture or concepts I am unfamiliar with. Simply accepting what I see is a wonderful way to setup myself up for failure! In the same way I trust that my partners are telling me the best info they have, I have to trust that my current understanding is the best one I have at the time. I’m finding I cannot stop there though, I have to dig in deeper to verify what I think I see or know. This might take the form of reading up on documentation (everyone’s favorite past time!), or if I’m lucky asking a teammate who knows more than I do for help.

Every so often I give myself a reminder of this and forget to verify…. this usually results in a bit of rework as I have to go back in a fix things, but the silver lining is I both reinforce this lesson and learn the process a bit better. As a result I’ve found I constantly remind myself to not only trust my own work, but followup and verify that it’s the best I can do.

Lady Bugs - Always verify your data

Recently NPR posted an article about a swarm of ladybugs showing up on radar system.  I found this story both highly amusing (that must be a LOT of ladybugs!) and an interesting look at how we interpret and use data.  The article mentions how the weather controllers saw the swarm show up and were rather confused since there weren’t any storms in the area that would make clouds.  Then they took a step that many folks do not - they verified the data.  Instead of just assuming that their equipment was showing them a freak storm, they called someone on the ground who could investigate and confirm what their equipment was showing them.  

Frequently when we’re presented with a report/data/etc we take it at face value and assume it is reflecting reality.  As that ladybug bloom shows us, that isn’t always the case. I regularly find myself stopping, stepping back, and seeing if I can prove to myself with the data what I am seeing.  Does it take extra time? Yes. Does it help me avoid coming to wrong conclusions? Definitely.