Three Doctors

There’s a parable I heard at some point that’s always stuck with me.  The more I’ve mulled it over, the more I see parallels to work (especially in my field, IT):

A parent had 3 children, all of whom became doctors.  

The youngest was a good doctor, and could cure a disease after it ravaged its patient.  Due to their skill their name was known throughout the country.

The middle child was a better doctor, and could cure disease at the sign of its first symptoms.  Due to their skill their name was known all over their county.

The eldest child was even better, and could cure disease before the patient even knew they were sick.  Due to their skill their name was known throughout their hometown.

---

I particularly enjoy the inverse relationship of skill to outcome and the correlation of reputation to severity.  Everyone would agree the eldest child is the best doctor - who wants to get sick?  Despite their immense skill, however, only the people in their home know who they are.  Everyone would agree the youngest child is the most well known doctor - we all know the names of folks who’ve put out massive fires.

Skill vs. Outcome

I heard at some point that a bored IT department is a good thing.  It means everything is working as intended, there are no outages and everyone is happy.  (Think about it, how often do you go hang out with the IT folks except when something breaks?...). (Go hand out with the IT folks more).  While it is possible IT is bored because they’re totally oblivious to problems, it’s also possible they’re incredibly good at planning and preventing problems from cropping up.

You can’t complain about a problem that never happens.  The “problem” with that approach, however, is no one knows that you’ve done anything.  There’s no visible action you’ve taken that helps folks… so they don’t know who you are.  IT can, however, take steps to change that.

Many IT departments publicly release metrics on things like system up time, number of tickets resolved, how long it takes to solve tickets etc.  These metrics help tell the story that may be invisible - how many issues are avoided.  Many groups also proactively reach out to partner teams to inform them of what they’re up to.  Systems updates aren’t as impressive as putting out fires, but they do keep the house from burning down.

Reputation and Severity

Everyone knows someone who is a “fire fighter”, that person who can come into a terrible situation and somehow fix it.  These folks are certainly necessary as bad things happen… but it’d be much better if those problems never happened or were avoided entirely.  Dr. Fauchi is a good example of this.  He is handling an immense task with incredible skill… but in another reality COVID would have been contained and we’d never have heard of him or learned of his skill.

Personally this correlation drives me nuts since it suggests all the preventative work we do is essentially unknown.  Even worse, folks may get rewarded for reacting to problems instead of preventing them from happening (that said, to the best of my knowledge it’s impossible to measure things that don’t happen).

---

While I have never found a single “best” solution to this challenge, I’ve found a few things that do work:

• Be proactive with messaging - Ensure your partner teams know what you’re up to (at least at a high level), and that they understand the value to them. Patching a server sounds REALLY boring, until you realize it prevent a massive data breach that just hit someone else.

• Help your team understand the importance of diligence - It feels good to be the firefighter… everyone knows who you are and how good you are (at least at putting out blazes). It can be hard to get folks to shift to prevention, but make the effort to help your team see the value. (Lower blood pressure, for one).

• Culture of sharing - Fires sometimes spring up when someone doesn’t feel comfortable raising a concern or admitting a mistake. I’ve found that calling out my own mistakes in our team communications has helped de-stigmatize this a lot (it also helps others avoid the same problem). Encourage others to do it as well, and soon folks won’t feel as bad if they do make a mistake.

Forward Movement

“When in doubt, go forward.”

---

Much of martial arts is about retraining your body.  We’re born with a huge number of instincts, reflexes and hard-coded behaviors to help us stay safe, which are great from an evolutionary perspective… but they’re not always the best approach.  For example, when we fall, we naturally extend our arms towards the ground, absorbing the impact on our palms and joints.  This is great for keeping our heads safe, but at the cost of our arms.  Retraining our body to fall differently, absorbing the impact along the side of our body, results in more safely hitting the ground.

Another example is sparring - our natural inclination is to move directly way from someone attacking us (The “Prometheus School of Running Away from Things”).  This knee-jerk response attempts to put distance between us and danger, but  we’re likely to trip, and will eventually just get run over as they continue forward.  To be successful in a fight, this instinct has to be reprogrammed to instead move in, towards the perceived danger.

Moving in

Ideally we’re able to avoid danger by avoiding it, but when needed this forward movement has a number of advantages.  Once you’re in a dangerous situation it’s usually better to be closer to the source.  This helps keep you out of a danger zone (e.g. it’s really hard to punch someone who’s only an inch away), and also allows you to take steps to neutralize the threat.  In the martial arts context this means closing the distance with your partner so you can protect yourself and attack them.

This physical concept can also be applied in non-phyiscal situations.  While the threats we experience at work at (hopefully) more metaphorical in nature, we can still benefit from moving towards then, rather than away.  Recognizing a teammate doesn’t fully understand what you’re asking them to do, for example, is a threat to your project.  They may not take the correct action, and result in a poorer outcome.  Once you’ve recognized this threat, instead of ignoring it and hoping it’ll take care of itself address it head on and have a discussion with that teammate.

---

This could also take the form of actively planning future projects now instead of waiting.  The threat in this case is missing deadlines or even entire portions of the project due to no planning.  Actively engaging and moving towards this threat will at the very least help you understand the potential outcomes.

Moving TOWARDS the danger is also not something that is expected… after all, we’re hardwired to run.  In a fight this gives you the advantage of surprising the attacker (e.g. they won’t expect you to get closer to them), which gives you an opening to strike back and escape.  At work directing the challenge directly and straight on results in quicker resolutions, and helps positively improve how others perceive you.

Of course we cannot enjoy this strategy without first undoing what evolution has provided.  This is a long and uncomfortable process, but one that is wholly worth it.  Physically, we train this by standing in a corner and moving up towards someone as they punch/kick at us as we move towards and past them.  This is essentially exposure therapy, and helps your brain understand it’s not as dangerous as it seems.  Over time, you’ll get more comfortable moving in towards a threat, and eventually it will become a habit.

Comfortable being uncomfortable

Work offers similar situations.  Any time a perceived threat crops up, go to it directly.  Have someone you have challenges communicating with?  Don’t wait for them to approach you, grab some time and talk it out respectfully.  Notice an error in a system or insufficient documentation?  Don’t hope someone else will address it, proactively solve it.  The exact form this takes will vary based on the threat you find, but by practicing moving to the threat you’ll find you can resolve it significantly easier, and more quickly, than by running.

This approach definitely falls into the “get comfortable being uncomfortable” bucket.  Discomfort, I have found, is generally an indicator you have room to grow in some way, and this is no different.  The good news is that discomfort eventually disappears, and you’re just left with a good habit of forward movement, on that lets you deal with threats and exploit opportunities.

Like flipping a switch

We’ve felt the butterflies in our stomach, or the bottom drop out of our stomach as we’re given bad news, or felt a spike of terror when something unexpected / threatening happens to us.  Our bodies ability to change our energy level rapidly to match a situation is a great built-in mechanism… but this natural mechanism has at least one glaring weakness - by default we can’t consciously control it.

---

This is a problem, because there are times when our energy level needs to be higher, or lower, or a different cycle than it is naturally.  Having a difficult discussion with someone you love requires keeping your energy controlled and level so you can focus on the topic at hand.  Going to the gym for a sparring session requires selectively raising and lowering your energy.  Working on a project at work requires keeping your energy stable so you can keep your focus.

Disciplines like the martial arts, yoga, meditation, etc. help train us to first be aware of our energy, and eventually control it.  This control gives us the ability to more finely control when and how our energy is used.  Going into what should be an incredibly boring meeting about financial statements?  Knowing how to raise your energy will help keep you awake.  Only have 1 hour a week to train in the gym?  Consciously raising your energy, and keeping it there despite anything else that is going on, will help you get the most out of it.  Escaping a burning building?  Putting a leash on your energy will help you from making a mistake.

All about control

Learning that your energy can be controlled, and how you can control is it an important thing we all learn.  But HOW we do it is also important.  We can’t always, for example, take half an hour to “amp up” or get control.  Sometimes you need to be ready to go NOW.  This may be due to an extreme circumstance (the burning building from before), or just because something unexpected popped up (an employee comes in with a problem).

---

I’ve found this to be less of a “powering up” process, and more like switching a light switch.  The exact situation that is unfolding around me certainly impacts this (escaping from a burning building would have a much different impact than sparring, for example), but the mechanism is the same.  It’s the mental difference of “ok… so, I need to get ready for X.. deep breath.. Give me sometime” and “ok, go time”.

Flipping this switch is something we can learn through practice.  The trick is just to put yourself in situations where you need that switch “on” and get a feeling for flipping it.

The importance of having a good stance

Every movement in the martial arts is supported by some kind of stance.  Some of these have really cool names, like Dragon Takes Flight, while others… less so (like Squat). Regardless of the creativity and color behind the name, these all essentially boil down to how you’re standing.  Some are on one leg, while others look like you’re just… well, standing.  Regardless of the precise physical form it takes, however, every martial arts movement has one.  The stance provides a foundation for movement, and they mainly providing support for the rest of the body to do something (punch, kick, dodge an attack). In addition to setting you up for success, stances also help train the body to become stronger and more flexible, making the rest of training easier.

It doesn’t take years of martial arts training to see when someone is not using a stance.  Something just looks…. Off.  Or maybe someone stumbles and falls. Or maybe there’s a hesitation before the next movement. This is especially true when you put two practitioners next to each other with one in a proper stance and the other not.  Watching someone without a good stance attempt to perform various moves also highlights the importance of having a good stance.  This individual will be less stable, stumble more, and appear to be less powerful (because they are). You can see these things even without direct experience of what it should look like (being an instructor makes me incredibly thankful for the patience of MY instructors).

Devil in the details

Understanding the importance of proper stances is something that takes time, sweat and experience to fully understand. You can easily tell someone that having a good stance is important, but it’s something entirely different to realize that concept.  Despite multiple instructors drilling it into me, it still took me ages to fully realize WHY they kept yelling “hit your stance” and other adjustments as I trained. Here the devil is truly in the details as a small adjustment to knee placement, or minor hip movement can drastically change how the foundation supports the rest of your body.

Real world stability

The concept of having a solid stance is something that can be applied across many areas of our lives.  At work, failing to have an underlying process that tells us what to do will result in shaky execution.  If the foundation of what is being done (the stance) isn’t understood team members won’t know what we’re doing, and will make mistakes (such as not communicating effectively, failing to take specific actions, etc).  Personal finances are in a similar boat - if you have a solid foundation of disciplined saving/etc.  At best you’ll deliver sub-standard results… at worst you’ll collapse completely.

The good news is you don’t have to be a super expert to improve your foundations. In the same way you can see someone’s physical stance be stronger or weaker, you can also see when your foundation in other areas is off. Be on the lookout for poor communication, missing information or confusion. Many times these can be (realtively) easily improved, but at the very least you will get a better idea of where improvements need to be made.

Best intentions pave the road to massive headaches for other people

There’s almost nothing more dangerous than a well-intentioned individual who knows a little bit about how things work.  This can be the combination of many factors, such as seeing a particular solution somewhere else in the past, thinking they know what they’re doing / thinking it “can’t be that hard”, rushing, and just good old fashion dumb luck.  Unless other evidence exists I always treat these as honest mistakes.. That said, I’ve seen these crusaders end up:

• Emailing a group of 1200+ people accidentally - Instead of just collecting emails it also forwarded them to EVERYONE on the alias… 

• Telling a VP a 60+ hour job should only take 2 hours - Nothing like being told to deploy something in 2 hours that you know from experience is over a week of work.

• Crash a corporate network offline - Backing up a 60+gb harddisk over a cable modem is bad enough, but when it crashes an entire corporate network you know you’ve done REAL well.

(Fun fact - I was responsible for one of those….)

Personally I always encourage folks to learn more about tech and systems.  This, in general, makes for more informed users and can make things easier overall.  I’m constantly looking for ways to help people better engage with their tech, and to help foster that curiosity.  I’ve also seen this approach ignite interest in folks who want to learn more about tech and systems, to the point of them changing their career and interests. 

---

That said, a little bit of knowledge goes a long way towards wreaking havoc.  Once folks get just a little wind behind their sails they tend to forget they don’t know everything about a setup.  Many training videos, sessions and tutorials are tailored for a specific audience and use case… one your coworker(s) may be exceeding.  The sense of confidence felt when making or requesting a change masks a lack of knowledge over what is really going on… which can result in massive headaches for tech teams when they have to clean things up.

---

I’m “Helping”

To help curb this… “helping”... I’ve adjusted my approach to working with non-tech folks (While tech teams certainly commit these errors I’ve recently found it to be much more common in tech-adjacent groups).  In addition to giving them basic knowledge to do their job, I now also take the following steps:

• Point out hidden dangers - Thinking through what MIGHT go wrong is a great way to uncover potential risks.  I go through this before I setup training, and then use the output to better inform users.  For example, if there’s a field I think they might want to use, but isn’t included in the training, I’ll specifically call it out and what it’s for.  This helps avoid situations where they see it later and think “hey, that looks useful, let’s use that!”.

• High Level Documentation - While I cannot expect my users to understand ALL the ins-and-outs of a system, I can expect them to know high-level basics.  Knowing that Workday sends a termination file to XYZ teams is important info… and they should know that.  Knowing reports are accurate as of last night at midnight is important info… and they should know that.  I both call this out in training, and ensure there is documentation to back that up.  Training also covers where the documentation is, and how to find it… while this doesn’t guarantee we’ll avoid those challenges at least I know I’ve given it to them.

• Encourage them to come up with ideas… then talk to you - I have always encouraged my users to think up better ways to do stuff… now I’ve added a second step - talk to me (or someone!) about that idea BEFORE doing it.  I frame it along the lines of “You’re a super smart person, so help me find better ways to do things.  We need to keep in mind that there’s a LOT of other moving parts, so when you’ve come up with a new idea, let’s brainstorm on how to make it happen”.  This both stops them from acting blindly, and also helps build better partnerships and trust.

---

Whoopsie

Throughout all of this it is important to remember everyone makes mistakes.  I’ve watched experienced and trained engineers forget to deploy a change to production due to a poor file name.  I’ve personally deleted over 5,000 trouble tickets by changing a configuration file (thankfully we could roll it back!).  The important thing is learn and not do it again.  This requires a great amount of support from your team, as well a company culture of safety and acceptance.  This story of a man who lost $2 million is the perfect example - his company treats these as development experiences, opportunities to get better.

It can be incredibly challenging to not react poorly when uncovering these errors.  (Why the *()@#$*&^ did you do that??!??!), and it is certainly a learned skill in responding appropriately.  I’ve started taking specific steps to help both keep myself in check, but also limit damage and maximize learning:

1. Breathe - The damage has likely already been done, so taking a moment to breathe and assess won’t hurt much.

2. Quick Assessment - Determine a preliminary root cause and prevent further damage.  This might mean rolling back some code, (un)plugging some hardware or making a quick phone call.

3. Alert Partners - Generally happens the same time as #2, but let any downstream partner teams know of the error.  THis will allow them to help out with damage control and minimize surprises.

4. Deep Assessment - Dig into what happened and why.  Understand as deeply as possible how the change negatively impacted things and what should have been done differently to prevent that from happening.

5. Deploy Adjusted Fix - Based on the assessment deploy the updated changes.

6. Share - Clearly document and share out a detailed assessment of what happened and how it will be prevented next time.

---

The individual who caused the ruckus should be involved in every step of undoing it.  This will help build their confidence by improving their skill sets and give others more confidence in their ability going forward.  The final step, “Share” is also critically important (and frequently missed) to ensure this doesn’t happen again.  Saving this knowledge also helps ensure that other team members do not commit the same error (something that is sadly too common).

Laid Off? Invest in Your Self

I can now claim the dubious honor of being caught up in two different layoffs at two different startups (one more for the hat trick!). Both times I have been part of a much larger group that was laid off due to dramatic reorganizations that impacted the entire company, and while they were certainly traumatic to some extent, I have viewed both as an uncommon opportunity, as space in which to improve my Self.

---

Growth Takes Space

I’ve found that when I’m working at any particular job it can be hard to think of next steps.  The mental weight of having that job makes it harder to envision a better / brighter / whatever path.  This “old growth” makes it harder to see what a next step could be, or to see what I would like to improve.  After all, I already have a job, so why would I look for something else that might be a better fit for me?

Having now been laid off twice in my career I’ve found it has a similar effect on my mental state; a (relatively) brief period of trauma followed by more room to expand with new ideas and directions.  I also feel this on a much smaller scale when I get to work on a new project or have a new position… space is created by giving up something old, which allows something new to grow in its place.  The challenge I have is to guide that growth so it serves me, instead of just growing organically.

---

Uncertain Direction

One of the challenges with getting laid off is it strips away some of our direction.  We no longer have a job to report to, no longer have teammates to whiteboard solutions with, no longer have systems to monitor or memes to send out.  This opens up a wide range of possibilities, but also introduces some uncertainty into what we should do.

This raises questions which lead to more questions which lead to more stress:

• “Why me?….”

• “What did I do wrong to end up here?”

• “How will I make rent in X months?”

• “Who’s hiring?”

• “What will happen to the plant I left at the office?”

While concern is warranted, worry is not a good strategy (it’s right up there with hope).  Instead of focusing on that concern, I’ve begun to view this uncertainty as a freedom (although usually not without a period of freaking out a bit…).  This is really a nice clearing to sit in comfortably for a little while, a space to help me ask slightly different questions:

• “What should I keep doing wherever I end up?”

• “What should I stop doing when I get there?”

• “What do I WANT to do?”

• “How can I do that?”

This shift in mental direction makes it easier for me to be on the lookout for opportunities that I will find of value and provide some personal growth (this blog for example).  By shifting the internal discussion from “this is only terrible” to “hmm, this is a great opportunity” I find it much easier to find new paths forward, paths that maybe I wouldn’t have seen earlier.

I’m not saying this is necessarily easy, especially as other circumstances can add further pressure (having a partner who is also out of work, children to care for, etc).  We certainly need to keep the totality of our lives in mind, but taking the time given to me by getting laid off and investing it in myself has given great results.

Time to Breathe

The space provided by being laid off generally results in some period of not-working-time.  Not-working-time is uncommon in our adult lives… we may take a week or two vacation, but rarely will get more than two weeks in a row where we’re not required to show up from 9-5 (or 8-6… or 7-7…etc).  After the initial shock wears off, this time can be spent to just…breathe.  Take stock of what you’ve got going on, cultivate your self and enjoy the time you’re not slaved to a clock to finish a project or answer tickets or follow up on some report.

Some folks take this time to travel in ways they couldn’t before (Tahiti for a month?), others use it to get into a hobby they’ve always wanted to (cross-stitch anyone?).  I’ve personally used it to meditate and better understand my self (honestly one of the most challenging, demanding, and rewarding exercises I’ve ever done).  The point isn’t to do a specific thing, but instead to not just focus 1,000% on finding the next job.  Instead use this time to step back, take a breath, and think about how we can create the life we want vs. accepting the one given to us.

---

Seeing the Clearing in the Trees

Getting laid off is an incredibly stressful event, and it can be incredibly challenging to find the bright spot in losing your job.  While it’s true this is work, and may take a lot of mental energy, it is an incredibly rewarding way to spend this time between jobs.  Some ways I’ve found to help see the space and appreciate it:

• Question yourself - Ask questions to yourself about what you want to learn or do differently with your career and life instead of just how to keep it moving along the same path.

• Chat it up - Talk to friends and family about what they know about you… what they think you’d enjoy doing, or what you’ve enjoyed in the past.  Their perspective is incredibly valuable and can give you great insight into your blind spots.  Talk to (now former) coworkers about what you did well and pursue that.

• Just chill - Take time to indulge a bit more in things you enjoy.  Take a painting class, go somewhere you’ve always wanted to but “couldn’t”, workout.  This rare bit of time if yours to shape into whatever you want.

Tech Takes Empathy - Sheer Terror

There has only been one time in my life (and hopefully the last!) where I have looked into a man’s eyes and seen pure, abject terror.  This didn’t happen in (to me, anyway) a life or death situation, or a horror film, or even after eating bad shellfish. It happened when he was told he could no longer use paper forms and had to use a computer.

---

The Setup

Working in the IT department of a shipyard was a lot of fun.  Not only did I get to work on and with computers (including some great experience bringing a corporate network down with a single file transfer…), I also got to see the physical thing our company made - ships.  To build them, however, you need a lot of very technically skilled individuals. This includes welders, carpenters, foremen and women, and supply managers. Building ships is really complicated (citation needed), but this was all managed with pen and paper… up until the time IT decided we needed a better system.

My role on the team was to support employees when they ran into problems with our system.  This could be anything from login problems to system errors to training. Many of our users were not computer savvy, so I spent a good deal of time going over basics (for reference many could only peck-type) and developing easy to follow documentation so they could continue to do their job.  Most folks didn’t need to use a computer, or only used it sparingly, so things were mostly OK. Our supply managers, however, were another story.

Historically, when a part or item was needed, you had to fill out a paper form (called a Purchase Requisition, or PR) and give it to their supply manager, who would then update a logbook, and if it fit specific criteria (e.g. under a certain dollar amount, or out of a specific list of things), give you the item.  If it didn’t meet criteria, the supply manager would go talk to whoever controlled the item to see if you could get it.

In the New Work of Tomorrow, however, this all had to be done on a computer.  Instead of filling out a paper form, the Supply Manager suddenly was expected to type the order into a computer, and the PR system would then follow whatever rules were in place for that item.  On a higher level this was great, since management could see in near-real time what was being asked for and by whom. On a highly localized scale, this was the End of Days.

---

Sheer Terror

Frank was a supply manager who had been working at the shipyard for 20+ years, and he knew his job inside, outside and backwards.  Even better, everyone knew he knew his job, and he was good at it. Then everything changed when the computers came. Frank knew how to type, which was great since it removed one hurdle entirely… the problem was Frank didn’t understand how this computer would impact his job.  If people could put a PR into the computer, was his job still needed? Even if it was still needed, what would he do all day, just watch the screen?

This was the moment I saw true terror in another man’s eyes.  In the moment Frank wasn’t able to process how great it would be overall, he was afraid his job would disappear.

---

Queue Empathy

This is one of the great tensions technological advances have to offer.  On the one hand, technology allows us to gather lots of data and be more effective at finding patterns and handling information.  On another hand, technology can be incredibly threatening to individuals who feel they may be replaced. We’ve all heard the news stories about this, but until Frank I had never experienced it first hand and it was a powerful experience.

Many of us in tech are in it for the cool stuff it can do.  Analyze millions or rows of data to find specific patterns? Magic.  Build a robot that can navigate novel environments? Witchcraft. What we need to remember, however, is there is also a very human component to it.  Tech does not exist by itself, it impacts people in many ways. As techies we need to keep this forefront in our minds as we roll out new magic and interact with folks who maybe don’t quite understand it all yet.

---

Back to Frank

In Frank’s case I made a deal with him.  I had to take all his paper requisition forms away, but in return, I’d sit with him until he felt more comfortable with the system.  In addition, I gave him my (work) cell number and told him to call me any time he had a question, or, more importantly, was getting stressed by the computer.

This did result in more hours spent than I had thought, however, I got a lot out of it.  While Frank didn’t entirely lose his anxiety, he did get a LOT more comfortable using a computer which made it easier to help him learn new skills.  I also learned a ton about the supply process from him, which made it significantly easier for me to design better processes in the system (e.g. changing screen setups, routings, etc.).  Even better, while Frank wasn’t exactly an evangelist for the system, he told his coworkers it wasn’t as bad as they had thought and there was help (e.g. me) if they needed it.

---

Lessons Learned

• Remember there’s people involved - While tech provides us some really cool tools, all of these tools eventually will impact a real live person.  This impact may be felt as part of their job changing (as in Franks case), or in different ways, but regardless something is changing.

• Take time to know users - It’s VERY easy in tech to become distanced from our users.  After all, they’re just the people that break our meticulously built system, right?  Taking some time to meet them offers a number of advantages though. Not only will you help put a face to these folks, you’ll pick up more about what they need from the system which will make your job easier.

• Be open - Those same users you’ve met will give you ideas on how to improve things, which is great!  Don’t shut down their ideas or problems just because they’re “not in tech”. Like any field, getting more perspective and a wide range of people involved only helps build a better end-product.

Performance Reviews!

It’s that wonderful time of year when employees the world over receive their performance reviews and the collective blood pressure/stress levels spike.  Performance reviews always feel like a stressful situation, for both managers (who have to find ways to constructively point out areas of improvement) and employees (who have to find ways to accept feedback in a healthy way).  I find it very helpful to keep one thing in mind - people wouldn’t give us feedback if they didn’t care about us.

---

Asking for Help

I know I’ve agonized over every step of the feedback process, from selecting peers to provide it, to writing my own, to reading my own.  It can be very hard to get into the mindset of “I want you to help me improve” because it requires us to become vulnerable. Not only are we asking for help (something in itself that can be a challenge), we’re asking for someone else to hold up a mirror and show us the flaws that we don’t see.  

Despite the pain, this tends to be the quickest way to figure out where you can improve.  If you’re looking for a promotion, you’ll certainly need to do this, but at the very least you should be interested in making your life (and your coworkers lives) easier by plugging the holes and amplifying your strengths. The point of feedback is to improve yourself. Unfortunately many of us confuse it with getting a promotion/raise/etc, which corrupts the goal and dilutes the result.

My approach is to pick somewhere from 5-10 folks to provide a review.  I know some percentage won’t get back to me, so having 5-10 helps ensure at least a few will (this doesn’t include my manager or direct reports, who are generally automatically included).  If I can’t think of folks I go over any projects I’ve worked on over the year (also helpful with writing your own feedback!), specifically for longer or more challenging ones and select folks from those.  I also do my best not to cherry pick only folks I know will give me a “good” review… the intention is, after all, to improve.

---

Writing Your Own Feedback

This to me is always a challenge.  It requires both cheer-leading yourself but also being objective.  You need to keep enough self-awareness to point out where you can improve, while also showcasing your accomplishments.  It also requires actually remembering what you’ve been up to.

I start with just listing out things I’ve done over the year (or however long it’s been since the last review) and grouping them into themes (led X# projects to completion, etc.).  I may call out one or two big wins, but this is mainly to help me shape the rest of the my self-review. Once I’ve got a good view of what went on I see if there are any patterns (positive or negative) to look into.  These patterns make it much easier to start, and also provide a focus as I think through what I’m going to write down.

The critical self-feedback is always a bit more challenging, but I perform the same basic process - examine my work for any patterns I want to change, and dig into those.  This may result in bigger themes (e.g. improve my ability to think strategically) to specific skill sets to improve (training in project management).

---

Writing Others Feedback

This one is always a toss up for me.  Not a toss up in terms of “will I do it?”, but in terms of what feedback I’ll give them.  The general intention I follow is to call out things they do well and should keep doing, and point out areas they may either be unaware of, or areas I feel they can be stronger.

Blind spots can be tricky to point out since I don’t want them to feel attacked.  For example, “You never provide a meeting agenda and I hate that” isn’t really a positive way to point out an area to improve.  Something more along the lines of “You schedule a lot of meetings, I think you’d be more impact by including an agenda”.

Point out areas to amplify is a bit easier, since you can build on something they already do.  For example “You’re off to a great start writing project summaries. They’ll be even better if you include an appendix”.  This not only shows them a behavior you want them to continue to do, but offers some way to make it even better.

---

Positives and Needs Improvement (Work in Progress, Weaknesses, Opportunities, etc …)

One of the major features of a performance review is to include examples of your strengths and weaknesses.  This is always a fun exercise of first remembering what you’ve done over the past 6-12 months, and second critically thinking about areas you can improve (which tends to run directly into my ego at full speed).

I find it easier to think in terms of stories when talking about strengths.  Saying you’re a good communicator is one thing, but providing a narrative that gives context and details makes it both easier to write and share.  Conversely I find it easier to stick with discreet statements on opportunities, and then add a bit about how I will improve it. This helps demonstrate that I both understand where I need to improve, and have thought through some fixes (at the very least).

Strength example - My communication skills helped defuse a very tense escalation with a client resulting from a system error.

Weakness example - My communication skills need work.  To improve these I will sign up for XYZ class and double check every email before sending.

The goal here is to exercise self-awareness so you can self-correct. Feedback from others twice a year is good, continuous (honest) feedback from yourself is even better.

---

Dealing with feedback

Opening yourself up to feedback can be a very scary (and challenging) thing, and getting it can be even more challenging.  I tend to read my feedback several times before I even try to understand it. This mainly stems from reading the “opportunities” section (e.g. where you can improve).  My ego frequently kicks in and gets defensive about the comments and immediately begins formulating responses.

Not very helpful.

It’s not helpful because this individual is:

• Someone I’ve asked to help me by giving feedback - While not true for 100% of folks (e.g. some places may assign reviewers, and typically your manager and direct reports always give feedback), in most cases you’ve ASKED for their input.  Unless that feedback is wildly out of line you’re both wasting their time and second-guessing yourself.

• Has a unique perspective on me - This is both frustrating and helpful.  Frustrating because you know you don’t do XYZ thing all the time… helpful because it is how at least one person views you (imagine all the folks you didn’t ask who have the same viewpoint….).

In order to actually learn from that type of feedback I desensitize myself to it.  I’ll read it a few times, then walk away. Then come back and repeat. Once the twitching has stopped (for the most part anyway), I’ll then see if I agree with what they said.  Frequently I can find other examples of their feedback, which makes it easier for me to digest it.

I would almost prefer the feedback where my ego kicks in and immediately starts screaming challenges to the feedback that doesn’t tell me anything interesting.  In the first case I have to learn to take a critical look at myself and examine potential flaws (even if I’m blind to them). In the second case, I get comments like this :

“I cannot think of anything else he can improve on”

Possible reasons for this response:

• This is my fault - I may have picked a non-optimal reviewer (e.g. someone who didn’t work with me enough to get a good picture), or I failed to outline what I was looking for in the feedback (e.g. prompting).

• This is their fault - It is also possible this individual simply didn’t put energy into this to think through our interactions.  Basically they’re cheating me out of improvements because they’re lazy.  

• I really am perfect. - (unlikely)

---

Summary

Feedback is a skill, and like any skill it gets better with practice.  Don’t wait for the end of the year, half or quarter to solicit feedback from folks.  The more constant, honest feedback you get the faster you’ll be able to improve.

Leading vs. Managing

A very common question thrown around is “What is the difference between a leader and a manager?”.  To me, it is very straight forwards - A Leader leads, and Manager manages. Leading or managing are not necessarily good or bad, but understanding the difference is important.

---

Leading

Another term for leading is “to guide”, although a much better one for me is “guide someone along the way”.  In a literal sense this might mean showing someone how to get somewhere in town, although this is only scratching the surface. While physically guiding someone is a great thing, generally in our workplaces leading refers more towards guiding someone towards a goal. This goal could be improving a sales metric, implementing a new system, or welcoming a new team member. The specific instance isn’t important, instead it’s the vision and seeing a path to achieving it that is interesting. Leading is the ability to see an end result, and bring people along the path to get there. Therein lies one of it’s challenges - you have to get people to follow you to that destination. For me, figuring out how to convince others that my goal is worthwhile is part of the fun. Not only does it challenge my view points (and help improve my idea), it helps foster stronger connections with my teammates.

Here leading goes beyond pointing at some distant point and saying “go there” and extends into being part of the journey and solution. Just like giving someone directions to the post office isn’t leading them (you’d have to actually walk with them there) leaders don’t just sit back and give pointers. Leaders are part of the journey to the destination they envision. They share in the successes and challenges with those they lead, and help the group reach the destination together. Frequently it feels like many projects suffer due to a lack of leadership - someone seeing the way forward.

---

Managing

Another term for managing is “to exercise executive, administrative, and supervisory direction”.  This implies that one is placed into this, and that one’s power to do those things is reliant on someone behind a bigger desk.  It would, for example, be very hard to just decide to start managing a team or process at work without your boss (or someone else) making it official (although it would be an interesting exercise in confidence to just walk in and take something over like that).

Frequently we focus on the “supervisory” and “executive” parts of that definition, which makes sense; they’re the most apparent in most jobs. Line workers reports to their supervisors, CEO’s manage their companies. Titles frequently have “Manager” or “Team Lead” in them to indicate some amount of power over subordinates.

Managing doesn’t solely relate to managing people, however, which is where the “administrative” part comes in.  Process managers are individuals who keep an eye on processes and are incredibly important.  These individuals serve as the main point of contact for decisions about a system or process. While they may also manage others, it is not necessary. Executive assistants are another example; they manage their manager’s calendars, schedules and other tasks without directing others.

I’ve always been intrigued by this multiple meaning, and found it very interesting when an individual wants to be a “manager”. They’re very rarely referring to the administrative part, and almost always fixated on the “supervisory” part, likely because it is perceived as the only way to progress or improve in one’s career, something that is incorrect.

---

What’s the difference?

A leader is someone who steps up, points at a destination and goes (with or without followers).  A manager is someone who occupies an official capacity and ensure whatever resources are available are being used properly (be they people, equipment, etc).  It is entirely possible for an individual to be both a leader and a manager at the same time, or just manage, or just lead, or neither. None of these combinations is inherently better or worse than the other, just different. The higher up one goes in an organization, however, the more likely it is they’ll take on a blend of roles. A CEO, for example, must both manager and lead.

Many of us get it stuck in our head that unless we are officially ordained to do something, we can’t/shouldn’t do it. The thinking is that unless someone higher up (your boss, the CEO, whatever) decides to do something, it doesn’t need doing.  This is entirely backwards.  There can only be so many official managers/leaders at any given company.  This means their sight is limited and guarantees they will miss something, or that they simply will not have time to get to everything.  This opens space for leadership to occur at all levels, not just those “official” ones. This allows “non-official” leaders at all levels to step up and, well, lead.

---

At the end of it all

Both managing and leading also be practiced at any scale. There’s always small projects the need leadership (those little things that annoy you, but aren’t “important” enough to make official), and we all manage SOMETHING in our lives (finances, computer use, etc.). The largest difference I have seen is that leading can be done by anyone in almost any circumstance, whereas managing generally has some conditions that need to be in place (e.g. being made a manager). It’s important not to get stuck in a mental trap that the only way forward in your career is to be a manager or leader, and instead focus on the impact you can make.

Tilting at work

Tilting is a term I picked up from playing video games. Imagine you’ve got a team of people playing superheroes and you just lost a game. You make some mistake that loses the game, and then you’re stuck in your head thinking how terribly you are… and then another mistake. And another… and then you’re yelling at your teammates. This is tilting, and it shows up in more places than just video games.

---

Anatomy of a Tilt

I always thought “tilting” was a great term to describe someone on negative run of output. It tends to also go a bit deeper than just venting (but venting can be part of it) and becomes a downward spiral of negativity directed either at oneself (internal tilting) or others (external tilting). I found a great definition from a user named “Kryptine” over on the Blizzard forums (and outcome given the video game context):

As their post suggests tilting may be initiated by something YOU do (for example - in the video game context falling off a cliff and having to start over), or your inability to succeed due to the actions of others (your team member doesn’t pass the ball so you miss a critical play). Regardless of how it begins, the end result is the same - a single spark sets off a downward spiral of negativity resulting in a substantially worse outcome (smashing your computer with a hammer in Kryptine’s case).

All tilts begin with some trigger which kicks off the mental decay. At work this could be missing a deadline, getting poor feedback, etc, but there’s always one specific point that causes it to start. Once it begins, it becomes self-reinforcing, kicking yourself over missing a deadline causes you to get overly critical with a teammate, which causes friction which makes your mood worse. They all also (thankfully) end at some point… generally when you realize things are going from worse to terrible and you just walk away for a bit.

---

Internal Tilting

Most of the time we think of tilting as something we watch other people do, or we do to others (we’ve all had SOME experience doing this). I find that my own self-talk can fall into this category too. Generally this feels like it comes out of nowhere…. “Dummy, you screwed that up the same way last time”, “Well that was incredibly stupid of me”. These tend to be knee-jerk responses to something happening, and I find unlike someone on my team tilting (more on that below), it crops up with some regularity. I’m not sure if this is me being too critical of my own work, or just a runaway internal monolog, but sometimes it is very disruptive.

I’ve found a few ways to help mitigate it’s impact:

• Keep an “I Rock” folder - A stockpile of positive or supportive messages from colleagues / friends is a great way to help those negative voices calm down / go away.

• Ask a colleague for their thoughts - Frequently I find getting an external opinion about my negative thought helps smooth things out. Most of the time I’m either misreading a situation, or or blowing something out of proportion.

• Imagine a stop sign - I’ve been using this one more frequently to stop a runaway train of thought. Just imagine a stop sign (or anything, really) popping up and stopping whatever thought is floating around. You might have to do it several times, but its been reasonably successful for me.

The aftermath of an internal tilt is always a bit challenging… you basically just need to be gentle with yourself and let it go. Take a moment to think about what happened, see if you can identify WHY it happened so you avoid it next time and move on with your day.

---

External Tilting

This is much easier to observe, since you can see / hear someone doing it. This tends to take the shape of a team member being hypercritical, or focusing only on the errors committed. A major difference between this an internal tilting is external tilting can impact multiple people. Imagine you’re in a meeting and someone goes off on you, or in chat, or any other environment that multiple people are in together. Not only will the target of the tilt feel the impact, the rest of your team will as well. An odd advantage of this is that the rest of your team can help to curb or correct the tilt, so the approaches to correcting it look a bit different.

• Point out positive things - This is a bit situation dependent, but when someone is on a negative tear pointing out a win can help get them back on track (or at least nudge them that way).

• Let them vent - Depending on the context, sometimes just letting them vent for a while can burn the tilt out. This can be dangerous since it may put them (or others) into a worse tail-spin, so I tend to reserve this for one on one connections.

• Walk away - This can take the form of you or them walking away for a bit. Simply excuse yourself, get up and leave. Take some time to do anything else to allow yourself (of them) to reset and recenter.

If I’m the one tilting in a meeting II will do my best to call myself out and apologize (usually after the fact). Frequently I will ask my team for help in figuring out what happened and why so we can all avoid it next time. If someone else was tilting, I’ll see if I can identify why and see if I can help avoid that going forward (not always possible, but certainly worth the effort).

---

Tilt Detection and Avoidance

It’s one thing to recognize a tilt in progress and try to disarm it, it’s something else entirely to avoid it completely. Internally I am ruthless with negative thoughts. As soon as I detect one, especially if it’s in reaction to something (like an email that ticks me off) I mentally step back and evaluate what’s going on. Is it possible I’m mis-reading the email? Who can help me fix whatever problem has popped up? Simply taking a few minutes to breath and look at my options helps keep me from spiraling.

External tilts can be a bit harder to manage since we don’t get that same internal feedback, so frequently we can only watch as someone goes off the deep end. The strategy with these is in preparation and knowing your team. Most of us can probably guess what our teammates triggers might be. This makes it relatively easy to determine if/when someone will tilt; just be on the lookout for those triggers. Easier said than done, since it requires you having enough info to make that determination, but it’s certainly possible. When I think someone is beginning to tilt I usually reach out right away with an offer to help. Sometimes it’s accepted, sometimes it isn’t, but simply reaching out can help nudge someone away from the end.

---

Keep it positive

At the end of it all the best way to avoid, or recover from, a tilt is to keep things positive. Focus on the parts of the project/day/whatever that are going well, and help others see that as well. While it can feel a bit like you’re faking it (and you very well might be!), it can nudge everyone towards a less stressful outcome.

I Rock

One of the first things I do any time I start a new job is make a folder called “I Rock”.  As time goes on I add anything to that folder that makes me remember that I do, in fact, rock.  This might be something as simple as a thank-you from a business partner, to a screenshot of someone’s positive feedback, to a list of the projects I’ve successfully launched.  The intention is to give me a solid library of positive things that I can look at any time I’m feeling less than 100%, but it’s got a great upside during performance reviews as well.

---

Remembering what you do well

Humans are, unfortunately, a bit hardwired to remember mistakes, or things that maybe didn’t go as well as we hope (take a second to think of something you didn’t do well back in, say, middle school…. now try it with something you did well. Which was easier?).  This makes complete sense, since we need to remember something that might hurt us (don’t go over there, the tiger will eat you). Unfortunately, this ability generally ends up in us only remembering the negative experiences (like that one email I sent without proofing).  While yes, it is useful to remember the things NOT to do, it is even more important to remember all the things that go well.  While these memories are always great to think about, these snippets of positivity are a great counter to those times when we screw up.  They allow us to blunt the impact of the error, or even erase the emotional negativity entirely.

We’ve all been stuck in those downward spirals of “I screwed that up real bad”. Personally, I find it challenging to break out of these since everything feels like failure. I also find these states make it easier to keep screwing up (or at least I perceive it that way) since everything is already tinted poorly. Having a life-line of stored positive things is a great way to help pull myself out of those holes, or at least stop me from sinking deeper.

In Practice

Personally I take a two pronged approach to building up my stockpile. I create a folder on my desktop or in gDrive and I make an email label.  I’m sure there are other ways to keep track of these - printing off hard copies into a binder, setting up an auto-reminder every week with a random sample of a positive message, etc. I’ve found that these two options play into my laziness.

I use the label the most frequently since most of my work happens to be in email. Finding positive messages is as simple as clicking on “I Rock”.  It’s incredibly easy to add something I want to remember, and it makes for instant gratification when I search for it.  It is also really nice seeing EVERYTHING that pops up.  I get to both see the individual emails, but also the total, which has a huge impact on how I’m feeling.

I use the folder for screenshots or downloads of positivity. This might be a Slack message from someone thanking me for sometimes, or a bit of feedback from a performance management system I don’t want to lose.  I save everything with a short name and the date (“Thanks from integrations - 10 1 2019”) so I can figure out what It’s for, and I make sure the sender’s name is included in the screen cap so I remember who sent it. I tend to use whatever built-in screen-cap solution is available on my computer (again, laziness wins).

I do get the occasional laugh when I’m in meetings and someone spies my folder or label. This tends to kickoff a great discussion about what it is and why I have it (I’m surprised more folks don’t have a similar bucket to capture their awesomeness).  I get chuckle too, since it is a bit odd to keep these snippets, but I’ve caught a few of my coworkers adopting this approach.

---

Performance Bump

While I mainly use these tools to help boost my mental-health they can help when performance reviews come around. Many places I’ve worked have had some kind of performance management system that is intended to capture feedback/kudos/etc as time goes on. Despite this, I find that many places do not have a culture that provides prompt feedback (or frequently any feedback at all).  While the intention behind these tools is to collect or send real-time feedback, they are seldomly used in practice.  This makes it especially frustrating when called out for doing something incorrectly (or, depending on the situation, “incorrectly”), while never getting called out for doing positive things.  It does take some effort to keep a personal list of the good feedback, I’ve found that in addition immensely useful when looking for a pick-me up it can help when being reviewed.

---

You Rock

We all do great things on a regular basis, the challenge is recognizing them and remembering them later. These things don’t have to be big, they can be small wins, a quick thank you from a teammate, or something you feel you did well. The point to keep these artifacts of success readily at hand to help keep driving you upwards and onwards.

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.

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.

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.