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.
Ticketing system basics
Ticketing systems help us keep track of our work, and many have lots of bells and whistles. At it’s core, however, there’s only a few things that are REALLY needed.
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
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.
Getting into tech
Being in “tech” has a certain allure to many folks. If you’re interested in getting into “tech”, take time to first understand WHY you want to, then get out there and do your homework.
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
Being asked to join a big project can be a bit scary. Not panicking (having faith in your team) and doing your homework (having faith in yourself) goes a long way to growing and staying successful.
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
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.
Getting comfortable being uncomfortable
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
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:
Embrace it and settle in
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
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.
How Connections Form
Connections are incredibly important for work (and life!). This makes it important to know how they form, and how they differ.
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:
The expert reacts negatively - demanding to know why it was done this way, or why a specific process wasn’t followed
The expert reacts neutrally - either not showing much interest, or just fixing the problem, without connecting with the individual doing the work
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
I’ve found there’s two types of basic skills - generic and specific. Understanding which one needs to be addressed helps folks better address underlying problems.
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 :
Doesn’t know a generic basic
Incorrectly applies a Specific basic
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.
Trust what you’re seeing/being told…but always verify it with your own testing.
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
When drawing conclusions from data it’s always important to look beneath the surface.
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.