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.

Setting Up Ad-Hoc Teams

Implementing a new system takes a ton of effort, planning and energy.  What happens AFTER implementation is equally important, although it frequently doesn’t receive nearly enough attention.  In this case I’ll take a look at how I provided post-implementation support and training for a group of admin assistants, taking them from brand-new users to local Subject Matter Experts (SME).

---

The Setup

After a large Enterprise Resource Planning (ERP) installation we moved into the support phase of the project.  This was a massive change in pace since the pressure to implement on a schedule entirely vanished. We no longer had executives breathing down our necks, and the gaggle of consultants who had been prodding us into action had (finally) left.

Instead we had the crushing grind of daily challenges presented by 3,000+ users of a new system - “I can’t log in”, “how do I add a purchase requisition?”, “Why can’t I find project X?”.  Since there was no way I could (or would ever want to!) handle all these requests, I started looking for better alternatives. Specifically, I began looking for a group of folks I could train up to be strong enough to handle the daily questions, thereby freeing up my time and also improving our support for our users.

---

Likely Suspects

The company I worked for had multiple locations spread throughout the Pacific Northwest.  These facilities ranged in size from 1,500+ employees, all the way down to 10-15 folks. What each location had in common, however, was they all had a dedicated Administrative Assistant.  This individual was responsible for handling general office tasks, including being the local expert with the ERP. “General tasks” might include data entry, helping other employees at that site with problems and being involved in testing or other updates.  Basically, these folks were the swiss-army knife of their office - they knew everyone at their site, knew how the business operated, and were very good at what they did.

Until the ERP system was updated, and they were a bit lost.

This is the challenge with any system update - things change, and users don’t like change.  They don’t like it when buttons change or move, and they REALLY don’t like it when they can’t do their job because they don’t know what to do.  These admins, however, were very well plugged into their local user base (they knew most folks by name if not personally), and, even better, the local users were used to going to them with questions.  This made the admins prime candidates.

---

Beginnings

Luckily I had already been introduced to all of the Administrative Assistant’s over the course of the original implementation.  This gave me a great leg-up since they already knew who I was and had some idea of what I did. This made getting the group together significantly easier as I did not have to sell the idea to both their managers AND the Assistants.  I still needed to connect with their managers (and mine) to align them on the idea, however, having previous contact made this process substantially easier than it can otherwise be.

Getting in touch with the managers was the first step.  After all, they’re in charge of these folks workload, and once sold on the idea they are a great resource to improve the process.  Managers can also shut everything down really quickly if you don’t include them (either for perfectly legit reasons like workload, or just because they don’t like you!).  This makes their involvement, and more importantly, buy in, critical to our success.

Once I had all the managers aligned on the purpose and need for this group, my next step was to connect all the admin assistants together.  Since I already knew them this was as simple as sending them all an email and jumping on a video-conference together. Most were already aware of the idea, so getting their buy-in was relatively easy.  This particular group was also motivated by the need to make their jobs easier, and interest in getting more training on the system.

---

Sidenotes 

What if you don’t know everyone? - Don’t worry, this part’s easy!  Just sit down, identify everyone in the group you’d like to include, and go say hello.  Ideally you can do this in person, but any method works. The main goal of first contact is just to put a face to name, don’t worry about getting them to sign on to anything yet.  You’ll also want to introduce yourself to their managers and begin acclimating them to your idea.

What if a manager pushes back? - This can be rather common… some managers are protective of their space (either due to legit reasons like workloads, or more political ones).  Do your best to back up your reasoning for needing their direct’s time (e.g. this will save X hours over Y days), and tie it into that individual and managers job (e.g. getting Suzie involved will reduce the accounting errors you’ll have to deal with).  If you’re still getting push back speak with your manager and see if they can help influence. Sometimes it just takes another voice to get someone over the line.

What if you have unenthusiastic targets (e.g. my Admins)? - Sometimes the folks you want to include in the group aren’t the best options.  They might be uninterested (“not my job” syndrome), unable due to workload (it’s possible you can change this through their manager), or they may not trust their skills (easier to fix via training and exposure).  Your challenge is to identify WHY they’re unenthusiastic and attack the root cause. Are they shying away because they don’t know the system? Train them. Are they afraid other work will suffer? Talk to their manager.  Do they think someone else would be better? They might be right… talk to that person. If all else fails, see if you can find someone else who would be a good fit.

---

Admins, Assemble!

Once I had my group identified and had manager buy in, the fun part started.  I first went about documenting as much of what we’d be looking at as possible (this ended up being over 300 pages of custom build pages, but more on this in another post).  Fortunately their jobs were fairly well defined, so I could make a laundry list of items they would be responsible for. Having clear documentation allowed me to easily spin up lesson plans to help round out their skills, and, more importantly, gave them a resource that wasn’t me to go to for help (a very critical step towards maintaining my own sanity).

I then setup a recurring video chat with the entire group on a weekly basis.  Originally this began as a 1 hour connection, but as they became more confident in the system we reduced it to half an hour.  The recurring meetings were mostly used to address challenges they ran into with the whole group. I would also hold ad hoc meetings as needed (e.g. in the case of a system failure, critical update, targeted coaching, etc.).  

While the meetings began more as a group lesson, they became more slanted towards team building as time went on.  Instead of helping them with the answer I would challenge the group to try and figure it out. I would also have admins teach each other when they ran into problems (generally after I helped them through it in a one on one).  This helped build their confidence in the system (e.g. don’t bug Rob, you can figure it out), but also their confidence in each other (I can’t figure it out… but I know Gina is good at this too so I’ll ask her first).

Everyone also had write access to the documentation, which they would update as they ran into differences or found errors.  We also went over those changes in our weekly meetings to ensure everyone was up to date, and would update documentation together when it came up.

---

The Endgame

Eventually the Admins became fluent both in the system and in how to address challenges.  They were comfortable both in their own skills, but also in relying on their team (and not just me!) when they needed help.  I did notice, however, that they would still come to me with questions they should know the answer to (or have documented). This was likely just inertia - they were trained to go to me for help so they kept doing it - but it wasn’t serving them any longer (and it was annoying me).  

To solve this, I setup a simple game.  Any time they came to me with a question we’d first check our documentation.  If the answer was in there, I’d get a point, and if it wasn’t in there, they’d get the point and we’d add the answer.  Points weren’t redeemable for prizes, but were intended to serve as a reminder that they had the power and knew what to do.  I also didn’t want them to be afraid of coming to me for help (especially on BIG problems), so I made it clear I’d always help them if they asked.

They almost immediately stopped coming to me with questions.

---

Lessons Learned - Setting up a Team

• Get Buy in - Ensure managers are on board.  Ensuring that your potential team’s actual managers are on board with your plan is critical.  Be sure you’ve got a well thought out idea, and can demonstrate how getting some of their time and energy will benefit both the team and the manager.

• Build Resources - Build documentation, get access setup etc.  At the end of the day what you’re really going for is a self-sustaining group to knock out some work.  To be successful the team will need documentation, references and training so they can build their confidence.  Taking the time to do this early will both help make the best product, but also set yourself up for success later.

• Constantly Connect - Regular meetings and interactions are key.  Not only do these touch points give you an opportunity to improve your relationship with the team, they also help build a sense of camaraderie.  This time helps the team learn to trust each other, and allows them to form connections that don’t require you to be involved.

• Encourage Collaboration -  The main goal is to replicate yourself (to an extent, anyways).  To really be successful at this you cannot be the only place someone can go for help.  Encourage your team to ask each other for help, or have them each take the lead during a meeting and train everyone on something.  Over time they’ll learn they can go to each other instead of bugging you.

Case Study - Learning a New System

One of my first jobs had me in the role of a project management module expert for a new system we were installing.  This was a big step for me since it got me out of being an IT Helpdesk Tech and into business systems analysis (something I find a lot more interesting).  This project would impact how 2,000+ people did their jobs across 6 locations, but the challenge I had was that I didn’t know much about project management, or this new system….

---

The Setup

This turned out to be a great opportunity to learn both by experience and by training.  Since we were already using a version of this system we had environments available for me to play in, and, even better, we had other folks on my team who were familiar with the system and underlying concepts.  Having both of these isn’t always the case, so I got lucky (sometimes system implementations involve a team entirely new to the system, which makes for one rather steep learning curve) . It was still a lot of work to make time in the system and to get to know everyone, but it really helped improve my learning curve.

---

First Things First

The first thing I did was get access to a sandbox version of the new system so I could play around.  This helped me build up the basics, e.g. where buttons were, what they did, what our current setup looked like.  The other thing I did was get my hands on the manual (a digital copy anyways). This helped inform my wanderings by giving me some underlying context into what those buttons were intended for, as well as background on the architecture and setup of the system.

Manuals can be a great resource, but many systems are incredibly complex, resulting in incredibly large manuals.  My recommendation here would be to focus on specific areas to investigate (e.g. whatever area you’re responsible for) to build up familiarity with them.  Sometimes it is fun to randomly explore, but I find this can lead to areas that you may never use, or end up being more confusing than useful.

In short, hands on gave me the “how do I do X”, while the manual gave me the “what this does and how to do it”.  The last piece, the “why are we doing this?” came later.

---

Baby Steps

Going from zero experience in the system to something more than zero was a bit painful.  Not only did I not know what it COULD do, I didn’t even have the basics. So I put in time (to use a gaming term, I did a lot of grinding).  I tried adding simple things over and over. I read the same page of the manual multiple times and then tried doing those things to see if it really did that (a great way to check your own documentation!).  Eventually I got to a point where I felt like I could open the system without hurting myself, which was good. At this stage, however, I was almost effectively useless to the team. Sure, I knew there were some buttons, and what some screens looked like, but I couldn’t translate that into helping the business solve anything.

This was by far the most challenging aspect of it all.  Why did finance care how the GL is setup? Was it important that we used a specific numerical sequence for project numbers?  Which data field was used to identify the project owner? The questions were endless, and each time I found one answer, more questions popped up.

Not only was I very new with the system, I was almost entirely new with the business and with project management as well.  I needed help.

---

Help!

Luckily for me, my project team contained a representative from most areas of the business (Accounting, Accounts Receivable, Project Management, Purchasing, etc).  This made it fairly easy to find someone to help me understand the basics, and even better, they were on the same project, which made it incredibly easy to connect and get some of their time.  In addition to getting formal background on what everyone did (I have zero background with Finance, for example), I also got to see how they were planning on using the system. This helped me better understand how my area would interact with theirs (e.g. if a purchase order is placed on a project how does that impact inventory?  What about the general ledger? Hours worked?). These learnings helped me further round out my understanding of the system, and more importantly, the “why” behind how it operates.

I also got help from other employees who happened to use the system.  This was another bit of luck as not every implementation I work on has this setup (although you can generally get help from the system vendor).  These folks were able to provide me more background on historic use, which is honestly a bit of a double edged sword. Implementing (or re-implementing) a system is intended to improve operations, not simply continue with the status quo.  Understanding how something works is critical to improving it, however, you must be careful to not simply copy/paste that into the next iteration.

Connecting with other technical folks helped as well. For example, I originally believed reporting was a built-in module of our system.  After a lot of (poor) guess work, I found out it was mainly handled using MS SQL. Data was loaded into our data warehouse by (what I eventually learned) were CRON jobs, after which it could be used by our data analysts.  Being able to sit down and talk with our data engineer and analysts made this process both much shorter and more enjoyable.

---

Leveling Up

Having hands-on access to the system, formalized training (in the form of the manual) and access to experts on the underlying process was immensely helpful.  While each area was incredibly informative on their own, when combined they played off each other giving me more depth of insight than otherwise possible. For example, understanding that the project number for any given project was added to the general ledger code string shed a lot of light on why Finance was involved in the structure of project numbers (don’t worry if that doesn’t really make sense out of context!).

On the more technical side this combination of knowledge helped explain why our project managers were so adamant about knowing when data was available in their reports.  If, for example, we loaded data from the system to our data warehouse at 1am that morning, their reports that day would be a day old. Once I explained this to them they got much less concerned when the number in their report didn’t match the live number in the system.

---

Learning a New System - Lessons Learned

Despite the specifics being unique to the situation, there are a number of lessons that can be pulled out of this experience and generalized to others.  Indeed, I’ve repeated this general pattern many times so far (hands on, make friends, do your homework) since then.

• Get hands on - learn by doing.  Any time you have the opportunity to get hands-on with the thing you’re expected to learn, take it.  It doesn’t matter if it’s a new programming language, new vehicle or new system, the more time you have poking around and seeing what is where the better.

• Make friends - know your end users.  Get time (face to face if possible) with folks who already use the system, or who understand the underlying concepts that will impact it.  These folks will, at the very least, give you pointers on what to look into next. At best, they’ll be able to walk you through specific scenarios and help answer your questions.

• Do your homework - understand the business applications.  Underlying concepts or ideas are incredibly important to how systems, programs, processes etc. operate.  Take time to read up on your field to get a better grasp of these. While they may be very abstract or seem unimportant they almost always will have an impact on what you do.

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.

There’s always someone better...

One of the more egotistically painful lessons I’ve learned through the martial arts is that there is always someone better than you.  Someone better, faster, stronger, higher-jumping, etc. than you are. Even worse, even if all you did was focus on the training there are still folks out there who are better in those areas that you can possibly be.  I spent a good deal of time beating my head into this idea (fruitlessly) before finally accepting it.  Once I got over the hump of wanting to be the absolute best at something, I could finally focus on just doing MY best.

---

It’s the Same Everywhere

Our professional lives are no different - there’s always someone who knows the tech better, is paid more, has a “better” job etc. There’s always someone who puts in more effort, gets more blind luck, etc. And while there’s no Olympics of coding (or tech… or finance…), you can bet that if there were most of us wouldn’t come close. It can be incredibly hard not to obsess over those differences. This is a very slippery slope; once we start we end up spending more and more time thinking about those things. At best this ends up sapping energy and focus from things that are actually important - work projects, family, friends, your self, etc.

The worst part about this is the energy we spend obsessing over others results in less energy to spend on becoming better ourselves. The very “problem” we are concerned with ends up taking away from a solution to that problem. While there are a great many things we can focus on in people who are “better” than us, there’s also a great many things we can focus on to get past this mental trap.

---

Getting Over the Hump

The best way to move past this is to simply accept that there are others out there, somewhere, that are better. After all, it’s factually true, and you (hopefully) don’t dispute gravity, so why this? That said, this is hard… really hard. It requires giving up some portions of the self that can be really satisfying to entertain (who doesn’t love imagining what it’d be like to be the best at something?). It initially takes a LOT of mental energy to not allow those thoughts to surface (why is it NOT doing something can be harder than doing something?…).

This is a challenging skill to build, but the effort is more than worth it. Learning to first identify, then stop, then completely avoid, going down the “I’m not the best” rabbit hole takes a lot of conscious effort. There are a few tricks I’ve learned to help:

• Acknowledge when those thoughts pop up - we cannot stop something if we don’t know it’s there. Simply realizing that you’re having these thoughts is a great first step in curbing them. This might take the form of writing it down, saying it out loud, or simply telling myself mentally that it happened. Over time you’ll end up training yourself to automatically do this and save yourself the trouble.

• Redirect the thought - Instead of thinking “Sally’s so much better than me”, I ask myself “Why can I learn from Sally to get better?”. This helps convert the potentially time wasting effort into something that I can use to improve. Depending on the situation I might even go talk to Sally and pick her brain a bit (I’ve met a LOT of great people this way).

• Get external validation - I find it way too easy to convince myself I’m not doing “well”. It helps to ask others how they think I’m doing. This will either give me positive feedback to help boost me up, or give me some (hopefully) constructive feedback on how to improve.

---

Just like in the martial arts, the fact there is someone better doesn’t mean that each individual can’t, or shouldn’t, do their best to be their best. While in some cases another’s success can come at the cost of our own (e.g. not getting the job opening), in most cases other’s success is, at “worst” neutral to us (e.g. we don’t get harmed in any way by it). Many times their success can actually help us (a teammate develops a better process that helps the whole team and gets promoted), so instead of focusing on “why aren’t I the best”, take time to focus on “how can I become the best me?”.

Certifications vs. Experience

There is a constant debate in the tech landscape (and in many others, I’m sure!) over training/certifications vs. experience.  Certifications, on the one hand, expose folks to a wide range of concepts and ideas, and give a bit of weight to someone as the certifying body says they know enough to be certified.  Experience, on the other hand, is an excellent (if sometimes painful) teacher that provides deep knowledge.

---

The Case For Certifications / Training

Certifications give other folks some indication that you have satisfied the certifying body that you know something. These certifying bodies tend to either be an equipment manufacturer (e.g. CISCO, Google, etc.) or an independent third party (e.g. CompTIA). I find that the harder, more specific skills tend to be manufacturer based (which makes sense since CISCO likely knows the most about their own hardware), while broader, softer skills tend to be third party (e.g. PMI handles project management). Many of these groups have been around for years, and are recognized as industry-standard, which gives the certificates they issues some extra weight.

This makes certifications a great tool to demonstrate your skill set to someone who either doesn’t know you (or your work), and provides a way to validate experience.  Going through the certification process also tends to involve some amount of training and studying, providing more tools and broadening your knowledge base. This, to me, is one of the best aspects since it helps round out knowledge. This both improves my skill set, but also gives me more common ground when working with others in my field.

---

The Case Against Certifications / Training

One of the weaknesses with certifications is the reliance on the certifying body.  You can, for example, buy a doctorate in your field for around $1,000 from an online university.  While you’re technically a doctor, it doesn’t mean you’ve put in the same effort as someone who went through, say, Stanford’s programs.  In a less extreme (and likely more common) case, you may end up earning a certification from a group that isn’t well known, well respected, or is so basic it doesn’t really prove anything (while I love by “Lucid Chart Expert” certification, it only took about 10 minutes to earn and covered bare basics).

A certification’s worth is entirely dependent on what the certifying body puts in the exam, and how others value the certification is dependent on what they think of that governing body.  A Cisco certification, for example, doesn’t mean you know everything about Cisco, just that you have passed the exam (many of which have low barriers to pass, like 60%). This reality makes many people wary of trusting certifications since they only prove that you’ve passed a test, not that you necessarily know the field.  Some groups mitigate this by including experiential requirements in the certification (e.g. the PMP issued by PMI required some number of project management hours verified by your manager). 

---

The Case For Experience

Experience is a great teacher.  I’ve learned a ton about programming simply by trying to solve problems on my own.  The frustration of running into dead ends and the joy of (eventually) overcoming the challenge is a great journey.  As a result, I’ve worked on many interesting problems and expanded my skill set in a number of directions that may not have appeared in official training or certification.  This gives me a deeper background in some areas that I can more easily apply to the next problem that pops up.

The great part is once others see what you can do, they’ll tell others.  Even better, they’ll think of you in the future and send work your way or help recommend you for other roles or projects.  Others having personal knowledge of your experience is an incredible asset that cannot be bought or learned in a test.

---

The Case Against Experience

The flip side is that unless someone knows you personally (or talks to someone who does), they have no idea what your experience actually is or what it is worth.  There’s no way for them to know if you can do what you claim without some kind of validation (e.g. a certification). This is why many companies have a coding challenge component to their hiring process - they need to know if you can walk to the walk.

Experience can also result in you missing key concepts or tools that someone who went through training would know about (a huge problem for me!).  This results in blind spots that may make things hard to figure out since you are missing key information. This is one of the challenges I’ve personally run into learning how to code, although it has led to some great “I could’ve just done THAT this whole time??” moments. At best this helps you learn how to find information (but takes a LONG time), at worst you are unable to continue.

---

My Approach

While I do really enjoy earning certifications (admittedly I enjoy the ego boost, but I also enjoy learning more about what I’m involved with), I do also recognize the value of raw experience.  Over the years I’ve tried to take pieces from both sides of the debate. I’ll use both personal exploration to build experience, and studying/certifications to build general knowledge. This is especially true when I’m given a new piece of tech to work with - I’ll take time to play around with it, while also digging into the general training. I’ve found this approach is great since these approaches compliment each other (the hands-on stuff gives context to the training, and the training guides the hands-on).

One area this has been very useful is in project management.  There are many different concepts/tools/ideas that may be applied, and it’s challenging to get those any way other than training.  Since it’s such a soft skill though, I cannot rely just on the textbooks, I have to get out there and experience it to see what else there is to it.  By having both the hands on experience, and the background concepts I’m able to be a much more effective project manger.

I also find both sides very useful for hard skills, particularly when I was learning Google Apps Scripting (GAS).  I had no background in programming, which meant basically a vertical learning curve. I did learn a lot about programming by experiencing it, but this was best described as smashing my head into the keyboard until it worked, I was missing out on some really basic concepts (data mapping blew my mind… until someone showed me that I was running several nested FOR loops).

---

Parting Thoughts

There’s arguments on both sides, but in the end it is up to each individual’s preference.  This may also be influenced by our working environment (e.g. some jobs may prefer or require specific certifications, many for good reason!  I wouldn’t want to go to a medical doctor that only learned by experience…) Some folks get by great on experience alone, others knock it out of the park with training.  It’s up to each of us to determine the best approach for ourselves, and then to apply ourselves to it.

Defects - What to do with them

Having determined our goal of zero defects, and determined what a defect is, the $10,000 question is what do you do with them.  After all, it’s one thing to identify what a problem is, it’s entirely another thing to solve for it.

---

The easiest approach

Every company will accumulate defects as time goes on (or at least I hope they do… if you know someone who’s proactively solved every possible problem please let me know!).  The type and quantity will differ, and may change over time, but at the end of the day there’s always a pile of things that need solving. The important thing is what is done with those defects.

The simplest approach is to collect them, which at its most minimal approach tends to be some kind of shared email inbox.  This is a very common approach for smaller groups, or groups bootstrapping the process with no previous experience or resources.  After all, it’s really easy to spin up a new email inbox and share out the alias with everyone.

This approach, however, gets out of hand incredibly quickly.  The inbox will either get flooded by all the incoming requests, or trying to keep track of everything becomes incredibly complicated and convoluted.  Having more than one agent (someone who responds to the emails) makes this even more challenging to keep track of (imagine 10 people monitoring a single inbox that gets 100’s of emails per day… how do you control who gets which email?  How about metrics tracking? Followups?).

---

The next step

Another more advanced, but still very common approach is to collect these requests in some form of a ticketing system.  Having a ticketing system adds some level of complexity to the process (it needs to be setup, administered, paid for, etc.), but this complexity provides a better foundation to provide support to customers.  Equally importantly it provides a framework to draw data and insights from (e.g. when tickets were created, who made them, what they’re about, etc). These data dimensions make the more advanced work much easier.

Requests can come into the system directly, or be piped in from an email alias, but regardless of entry point those requests are monitored by a support team.  This team is (hopefully) focused entirely on answering those requests. While it is possible to have part-time teams, breaking their focus onto other responsibilities will reduce both the number of requests responded to, and the quality of those responses.  You are also preventing yourself from learning more about patterns in your requests since any given agent won’t have complete exposure to everything. It is also incredibly important to support these agents with whatever training or knowledge base information is necessary to handle the majority of those challenges.  This is an ongoing goal, but something that must be started sooner rather than later.

A shared inbox or ticketing system is a necessary step, but it doesn’t do much, if anything, to prevent the defects from occurring in the first place (our actual goal).  While the challenges/pain the defects cause must be addressed, simply collecting them doesn’t help stop the next defect from occurring.

---

Reactive analysis

To actually help reduce the number of defects, someone (or a team of someones) is needed to and analyze the incoming defects.  Their goal is to better understand the defects that come in, and look for ways to help plug the leaks. What this team can learn from the defects is largely dependent on the quality of the incoming defects.  This is partially reliant on the collection method (e.g. email vs. a sophisticated ticketing solution), but is also impacted by the teams ability to understand what the defects are and routing them appropriately.

By critically examining known defects, this team can then make recommendations to the business on how to prevent future defects.  These recommendations may be the result of identifying patterns in defects (e.g. every tuesday we get a lot of tickets about entering time), or observations about improvements (e.g. update a button placement so users see it more easily).  Since every business and group is different, the recommendations will vary, but the end goal is to provide guidance on how to stop the defects from recurring. This team should be formally and informally connected to the business units they advise.

---

Proactive avoidance

Reactively examining defects can provide guidance for changes to stop future defects, it would be much better to prevent those defects from ever occurring.  To me, this goes beyond standard QA since some things cannot be easily QAed (for instance an onboarding program or policy).  This is where proactive assessments come in. Think of these as pen-tests for other areas of the business; a complex examination of existing systems or processes that attempts to uncover faults before your customers (or fellow employees) find them for you.

This is further complicated since the business is constantly changing.  It requires the totality of the process being examined any time a change is made to a process, a new policy is rolled out, or a new patch is released.  This is no small ask, and requires a team that is equipped to go in and try to break everything in any way they can imagine. Say a payroll system is updated to provide more employee self-service (a recommendation from your defect analysis team).  Your proactive team would need to think through a number of things, including:

1. What readily available documentation is available to employees?

   1. Can it be easily found?

2. Are managers aware of the change?

3. What formal communications are going out to employees to let them know?

4. What information is made available during onboarding and retraining?

5. What other information sources should be updated (bulletin boards, etc)?

6. What downstream systems might be impacted? (change management)

The specific questions would differ depending on the changes and environment.  This team may also opt to only focus on specific areas (e.g. payroll related items) to provide a more focused impact in higher-risk areas.

---

At the end of it all, it’s not a question of will there be defects, just when they will occur and where. While handling defects after they occur is necessary, groups need to better understand the weaknesses of their current processes and proactively plug them up. While it does take energy and time, it results in significantly happier customers.

Zero Defects - What is it?

Somewhere along the line I picked up the idea that any problem (a ticket in my world) represents a failure somewhere in the overall process. This isn’t intended to point blame, or make us think like we’re failing horrifically when we gaze upon or vast collection of tickets, but rather to help us frame every one as an opportunity to improve. This failure could be in training employees, training managers, a technical glitch, or how an interaction with HR is handled. Regardless of WHY it occurred, it is still a defect that needs to be examined, understood, and never repeated.

---

What is a defect?

In general, however, a defect is any adverse or unintended behavior in a system or process. This may be further refined based on who you’re talking to and/or what industry your in. For example it could be the QA team finding a flaw before the production run in completed, or could be a piece of code that generates an incorrect result. “Zero defect” also implies that the defect is reported, that someone out there in the “wild” (not your team or testing) has found the flaw and is bringing it to your attention. This could be represented by a help desk ticket (common), and email (also common), a sticky note on your desk (less common) or a brick through your window with a note tied to it (hopefully least common). Regardless of how the message is sent, you are now in possession of a bright, shiny new defect.

In my world a defect is anything that results in the customer (fellow employees) having to reach out to a support team for help (this includes the HR, tech and IT teams). This outreach could be a complaint about someone’s behavior, confusion over a policy, or help finding a payslip. Note that this does not include any time someone has figured out something on their own (e.g. restarting their computer fixed the problem), or being able to look it up somewhere (e.g. HR policy information). The focus is on the group of individuals who have some problem and then have to reach out to one of our support teams for help. This makes things a bit challenging to totally control since it’s entirely possible an employee reaches out to a co-worker, manager, etc. and gets an answer without needing to reach out to support. Personally I’m not sure if this is truly a defect since they were able to figure it out without reaching out, but it’s a bit of a grey area for me. Regardless, there’s no easy way to measure those, so I stick with whatever happens to get into our ticketing system.

---

Rating Defects

Ideally 100% of defects are examined, understood, and never happen again. Unfortunately we don’t live in this version of reality, so some yardstick is needed to understand and rank them. It’s important for the teams that look at defects to sit down and determine what dimensions they want to use to sort these (such as impact to the bottom line, type of system impacted etc.) and then to share those definitions with stakeholders to help improve trust and transparency. When in doubt I tend to start with two simple dimensions, complexity and urgency since they are relatively easy to understand and allow for quick sorting of defects.

Defects range from the simple (where do I find my payslip) to insanely complex or in-depth (employees in a specific area cannot not log into to one part of a certain system) An important note that “simple” does not mean it isn’t important to whomever raises it. “Simple” instead refers to the likely response/solution (e.g. “Click this link to access our payroll system”). Defects are never “simple” from the “Well, your thing doesn’t really matter” perspective (especially when related to HR issues), and always have a real-world consequence to someone. This is part of an overall tech mindset that’s a bit beyond this post, but definitely something I’ll dig into later.

In addition to falling somewhere on a complexity scale, they also fall into an urgency scale. This scale can range from “I need my medical insurance confirmed so I can get my cancer drugs” to “Just wondering what our policy on XYZ is” for HR matters to “Our payment processing system is offline and we’re losing millions every minute” to “the icon on some little-used internal page is broken”. Similarly to how “simple” doesn’t mean it’s not important to the reporter, the seemingly non-urgent items are still important. The icon on that site is the Priority Zero for someone and should not be dismissed simply because it’s “not urgent to me”.

Having these dimensions on defects help make it easier to prioritize both how they are resolved and how they are investigated. An ultra-critical, ultra-complex item will likely be immediately addressed, but an in depth investigation will take time, while a low-criticality, highly complex item will likely wait to be addressed. Exactly what dimensions are used to sort tickets can be up to any given team, but SOME yardstick should be used to help the followup work on determining how to avoid the defect in the future. All that said, regardless of the metrics being used, it is still a defect, which represents a failure.

Next up are responses to defects, something I’ll take a look at a bit down the line.

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.

Priority Zeros - Everyone’s got ‘em (sometimes several)

Priority Zeros. Everyone's got one, something dozens (which I always find amusing - how can there be multiple highest priority items?…). These items are the highest priority and most important item for any given group or individual. It's a great thing when a team can truly determine what these are as it allows them to direct work. It's a much less great thing when tech teams are given them without a structure in place the help manage them.

---

Collision alert!

Once you get to the point where you're regularly identifying P0s you’ll (hopefully!) start looking at how to accomplish them. This generally involves passing parts of the ask to other teams to do the work. Depending on the ask this can span large swaths of the company, or just a small targeted group. Given today’s information-rich environment, tech teams are almost always impacted by these asks. While it’s great that tech is thought of as being needed, a very serious challenge begins to emerge - What happens when tech gets a P0 from Finance and one from HR?

In an ideal world this balancing has already been taken into account where a designated person or group determines the actual priority (Finance then HR, or use some semi-objective ranking system, e.g. which one costs the most to implement). I won’t delve too deeply into what that process looks like, but this group should be ordained by the business to make, and defend, those decisions so the tech teams can focus on execution. This approach is great since it removes any pressure on tech to determine which should be done first and provides clear guidance on what order stuff should be completed in. It also helps ensure the business know’s what tech is up to, and when they are doing any given item (other very common challenges with prioritization).

More frequently, however, the decision is dropped on tech, and tech has to figure it out.

This is a terrible idea.

---

I dunno, that one first?

It's terrible because tech doesn't know which item is more important to the business. If we’re lucky we can sometimes make an educated guess, but this is very much a mystical art from the tech standpoint as is it very rarely objectively clear cut. For a vast oversimplification (many tech projects span months if not years), is it more important that an alert goes out from Legal or a finance report has a column added? Tech can guess (I’d hazard towards Legal on this one?), but at the end of the day it’s not your tech team’s job to determine priority of this type of work - it’s IT’s job to execute on the decision that is made and to ensure that it is executed properly.

In addition to potentially the “wrong'“ item being worked on, it’s terrible because no matter what order tech completes the items in it will be 'wrong’ to one customer or the other. If we go with the “Legal” option above its highly likely that Finance will come back at us more than a bit unhappy. Tech can try to justify why they chose a specific course of action, but at the very least this takes away from time better spent working on the item. Even if there is some justification Tech uses, it’s likely that Finance will disagree with the criteria (e.g. why are alerts weighted more than reports?). This ties back to having an ordained group or individual that all groups trust - it helps eliminate frustration down the road.

---

But we don’t have that…

There’s a variety of reasons why that ordained group or individual doesn’t exist yet. Maybe your company cannot afford to dedicate a single headcount to it (yes, this is a full time job). Maybe your company wants to, but has higher priorities (a bit ironic that). Regardless of the reason there are some steps you can take to help bridge the gap / mitigate the damage. This will require some amount of process / procedure, however, it will help protect your tech teams and avoid frustration from the business.

The intention of this individual is to provide a source of truth for the order of your tech teams work. This requires this person to be familiar with everyone on the tech and the business side, and have a working relationship. This person also needs to understand how the tech teams operate and what their capabilities are. A person like this may already exist on your team (or on the business side). This may be a finance expert who wants to learn more about tech, or a techie who wants to get a better feeling for how the business operates.

You’ll also need to get leadership buy-off on this stop-gap. Figure out who the decision makers are on the business and tech side and grab some time with them. Explain you want to dedicate X amount of someone’s time to helping prioritize and order tasks (with input from both teams). It shouldn’t be too hard to get buy in as they are likely feeling the pain of not having this role, but you can always point out the time/heartache savings by having an objective to-do list. You’ll also need to setup some kind of regular update/meeting with this group so they feel comfortable trusting your designated individual, but this is good since it will help keep you honest and get you feedback.

It is definitely an iterative process, but once trust is developed and the wheels start turning more easily marked improvements in efficiency and grey-hair will start to show up.

---

Same team!

It’s REALLY easy to fall into the trap of blaming the business or the tech team for a failing project or take out frustration on them. At the end of the day the most important bit to remember is everyone is on the same team. Tech teams don’t have anything to do without the business (except watch server lights flicker) and the business will have trouble improving without tech (there’s a limit to gSheets). The challenge is in bridging the gap, in helping the tech side understand the business’s priorities, and the business understand the tech teams capabilities. Providing a single point of truth for what should be worked on is a huge step in that direction, and one that you can start taking without breaking the bank.

When should Tech be involved?

Very commonly companies have to make important decision about what they should do. These decisions typically involve a number of different departments (legal, HR, finance etc), all of which provide an important and necessarily piece of input to the Decision. For some reason Tech seems to be frequently forgotten about during this step in planning.

---

Failing to plan….

Due to the expanding info-tech nature of work it is critical that technical considerations are taken into account during planning. This includes things like giving tech a seat at the table, including team members in planning meetings, and ensuring they’re included in updates. You wouldn’t, for example, not include Legal in a big decision, why is IT any different?

Planning is a very important thing (citation needed). Even the smaller projects or initiatives need time to be shaken out. Schedules need to be determined, resources need to be found (or borrowed… or stolen…) and communications need to be setup. There are a ton of moving parts that need to be managed, such as figuring out what teams are involved, and who is responsible for what. Many projects share some amount of requirements, for example having a unique email, that tend to be better understood by the project teams. Almost every project, however, can benefit from additional technical expertise, and this is where a breakdown frequently occurs.

While many pieces can be managed without technical support, almost every aspect can benefit from a technical view point. This may involve tools that the project team is unaware of, help developing an ideal process, or access to key systems. All of these decisions also will require some about of IT help, even if it’s just setting up an email alias or standing up a file share. Generally not having the tech teams involved early will result in either a mad dash at the end to get them up to speed, or a diminished project result.

---

“Just IT”

This boils down to mis/pre-conceptions about IT itself. After all, IT just pushes a button and the thing works. It can’t be THAT hard to setup a new email alias, so why include them at the kickoff meeting? This is only compounded as projects become more complex. (If you don’t understand the underlying concepts moving 2,000 workers around your HRIS seems like an easy thing, just a button, right?) . This apparent lack of appreciation for the complexities of modern information systems results in IT being left out of the loop. Several times I have been looped into projects with only a few days before go-live and asked to complete what should be 3 weeks of work in 3 days.

Including tech at the start of the project helps avoid these types of situations. On the one extreme is tech saying they’re not needed, but on the other is avoiding a massive complication. This may also require some amount of discretion depending on the topic (e.g. a super-secret merger or HR event may require more selectiveness), however, tech teams are used to handling highly sensitive data so it’s just another project to them. At the start finding the right person(s) on the technical side may be a bit of a challenge as the help desk expert may not know anything about the HRIS side of the house (and vice versa). One way around this is to include one individual from each tech team at least is consulted and asked if they might be needed. Another method would be to approach your tech leadership and ask them who the best individuals to include are since they’ll have a good idea of who’s best suited for the task.

---

Business + tech = win

Once tech is regularly involved you’ve given yourself a number of advantages. The least of which is IT becoming aware that something is going on. This doesn’t seem like much, but is a huge step in the right direction. Like any team they have restricted resources, so we’ve now given them a chance to put your ask into their planning cycle. This helps eliminate the possibility of not having the right resources available to do The Thing (or giving folks premature grey hair…).

Even better, it also allows IT to point out potential problems with your approach. While I have great faith in my business partners, tech is not their area of focus. Frequently this results in them sticking to habits / easily available things (google sheets, anyone?), resulting in tunnel vision. Maybe there’s an easier way to communicate with everyone, or maybe you’ve forgotten about some restriction. More diverse brains, earlier in the process, can only help.

If a technical resource cannot be included (maybe you don’t have one yet, or maybe they’re slammed), another approach is to find someone on your team who is more technically minded. Maybe this individual has worked in tech before, or works closely with the tech teams currently. While this person may not be a technical expert they should be able to at least point out areas where tech should be involved. The goal is to find a way to get a technical viewpoint on your project as early as possible.

---

All together now

Many, if not all, parts of a businesses project can benefit from including technical resources as early as possible in the process. At the very least you’ll avoid last minute scrambles, but more likely you’ll enhance the overall project in ways that are hard to see at the start. You’ll also build a better relationship with those teams, improving overall operations and helping improve future projects. Your tech teams will thank you as well, since they’ll feel like they’re part of the great team instead of being delegated to being “just IT”.

Know what to cut

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

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

---

What’s holding you back?

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

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

Our example list:

Audit Report

Accounting Meeting

---

Now What?

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

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

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

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

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

Our updated list:

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

---

And Then?….

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

Shift the work to a more junior co-worker

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

Automate the task

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

Delete the work

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

---

I was told there would be no math

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

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

There’s a fascinating thing that frequently happens when someone puts in a help desk ticket. They stop being a person and start being just… a ticket.

While this is useful for doing things like tracking trends, or analyzing problems, it presents challenges on how the problem is solved. Abstracting the person from the problem sets ourselves up for situations where our agents treat the ticket as just that - a problem - and not something that impacts the life if another person.

---

The usefulness of tickets

While smaller offices or organizations can rely on the “Walk up to XYZ person and get help approach”, this quickly breaks down at scale. First, after some point not everyone knows the right person to go. This makes it a frustrating experience to find help since you first have to go through a treasure hunt. Second it’s really hard for organizations to have enough of the right person at the right place at the right time to really matter (how many IT help desk techs is the right number? What if the location only has 2 employees, should they have a third employee who just does IT work?).

Since it’s (unfortunately) not possible to scale 1:1 human connections with organizations, we have to rely on some type of system to help us. This system should allow us to track multiple requests at a time, provide specific (hopefully accurate) responses, and interact with our customers. Frequently the thing that does this is a ticket. This makes tickets incredibly useful things, as they allow us to track, codify and organize pieces of work that have to be completed.

Given the size of some environments this is especially important as thousands, if not hundreds of thousands (or more!) issues pop up every year. While some percentage of the population will figure out a way to get face-to-face service, the vast majority of folks will interact solely with whatever ticketing system is in place. While this certainly makes it easier for the group providing support (IT, HR, whatever), it results in some interesting behaviors that may not have cropped up if a 1:1 in-person interaction were taking placee instead.

---

Do you have a ticket?

Many times the first questions out of a support techs mouth when presented with a customer with a challenge is something along the lines of “Ticket number”. Hopefully it’s more polite than that, so let’s go with “Could you please let me know your ticket number?” as the default. Already we have a problem. Instead of acknowledging the person in front of them (and almost as important acknowledging the pain that person is experiencing) the tech has gone straight to the ticket. While this may be a result of some process the tech is trained on, it immediately divorces the person from the equation.

While this makes complete sense (I certainly agree work needs to be accounted for), it immediately pushes the conversation away from help a person and towards placating a system. Systems are intended to serve us, to make our lives easier, not to enslave us to process and procedure.

To help combat this I work on starting those conversations with something like “What may I assist you with?”. I make a conscious effort to use “assist” and not “help” since they help frame the conversation. “Assisting” someone makes it a more collaborative, “us vs. the problem” approach, while “help” makes it more of a “you clearly can’t do this yourself, give it to me”. While this difference may seem minor, it makes the customer feel like they are part of the solution, instead of part of the problem. This becomes important when I need them to do something for me (reboot their machine, send a screenshot etc.), or if the problem comes up again (they’re less likely to think I”m incapable and more likely to want o work on a solution).

---

PATS (Person Abstraction Ticketing Syndrome)

It’s a little easier to avoid this abstraction with in-person (even video) requests since you get immediate body-language feedback and can more easily build a connection with the customer. Things can get really hairy when interactions are solely through a ticket and there is no direct connection with the customer. In these instances both the agent and the customer can forget they are working with another live, breathing human. At best this shows up as a different tone in responses, at worst customers get shuffled around between different teams until they get fed up and escalate.

This breakdown occurs since tickets cannot capture enough information (let alone the information provided by body-language or spoken word). Frequently they don’t even come close to soliciting questions that pull out context, for example not asking WHY something is being requested. This relatively lack of information makes it very easy for the agent to treat the ticket as another piece of the computer - something to be dealt with using as little energy as possible.

The customer, unfortunately, is in the same boat as the agent; they’re not getting enough information either. Compounding this is the frustration they feel due to the underlying cause (e.g. their computers broken), and the frustration of having to navigate some ticketing system (No one’s ever told me it’s a joy to use a ticketing system). Now, on top of that frustration, they have received what is likely a curt response (or at worst something totally unrelated to their request) to their plea for help.

As work on the ticket continues this transforms into a nasty reinforcing loop. The agent becomes more and more annoyed at having to deal with that particular ticket, and the customer feels more and more frustrated at not getting what they need. This tends to result in agents resenting customers, and customers thinking agents are un-caring machines. Eventually one of a few things happens:

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

2. The ticket gets transferred - The agent realizes they cannot help the customer so they punt them to another team. This effectively restarts the process, but does nothing to reduce the customers frustration.

3. The customer gets fed up and escalates - This can take the form of an email to a manager/director/C-suite and is not a lot of fun.

Even the best-case scenario is not a good once as the steps taken to get there were painful for both sides. In order to avoid these less-than-ideal outcomes, we may need to take a few drastic steps…. Remember they’re human too, and Get out of the ticket.

---

Remember they’re human too

This is something I always (try to) keep in the back of my mind when I work on tickets. Whoever is on the other end of that digital paperwork is another living, breathing person who needs me to help them out. Depending on the day and the person this can be more or less challenging, but the ideal end result is to treat the ticket like I would someone in real life. I wouldn’t for example, not respond for 3 days to someone who is standing in front of me saying “hello” (hopefully they wouldn’t stand there that long!). Nor would I respond to a detailed plea for help by running away and telling someone else to deal with it (e.g. blindly reassigning the ticket).

While it’s true the rules and expectations for dealing with tickets may differ then those for in-person interactions, we still need to push ourselves to treat customers the same. Remembering that they are, in fact, human, and do, in fact, need our help, is a quick mental shortcut to improving their interaction. Very frequently this also helps improve the relationship with your customer - they feel like they’re being treated well, so they will be easier to work with. This helps solve challenges on both sides, the agent feeling like something’s being dumped on them without enough info, and the customer who’s feeling like they’re being treated like a machine.

---

Getting out of the ticket

There are tickets that, for whatever reason, blow up and escalate. Maybe it took too long to resolve, maybe the customer doesn’t feel like you’re responding fast enough, or maybe the customer cannot effectively describe their challenge in the ticket. The reason doesn’t matter, but this is the point in time where the agent has to get out of the ticket and setup some in-person connection (not that they could’t do this earlier, they should!, but they REALLY need to do it during an escalation). This could be walking to the customers desk, video chat, phone call etc. but the point is to make a more human (and real-time) connection.

Doing this solves a number of challenges. First it demonstrates the agents sincerity in resolving the issue. This alone can have a huge impact on the situation (especially if the ticket has been sitting, or going back and forth for a while). Second it removes the distance a ticket creates and allows for more immediate feedback. Now the agent doesn’t have to wait for a screenshot, they can see exactly what’s happening. Third it helps build a real connection between the agent and the customer. This is incredibly important to both the current challenge, but more importantly it builds a relationships between both sides.

This third benefit is the most important since it builds towards the future. Next time there’s a ticket the customer is more likely to provide more info and be a bit more understanding in delays. The agent is more likely to give the customer the benefit of the doubt and provide better support. Additionally both sides will tell other people about the interaction. The customer will impact how others perceive their help desk and vice-versa. This ripple effect is immensely powerful and helps stop the negative feedback that crops up with ticketing systems, and (even better) helps improve the relationship between tech and partner teams.

---

Only Human

At the end of the day we’re all human. We do the best we can and sometimes we make mistakes. Regardless of the situation we still need to treat each other as living, breathing entities and not as lines of text on a screen. Keeping this in mind helps elevate both the level of service provided, but also the relationship between agent and customer. The strength of this relationship is directly related to how our customer perceives us, impacting how they treat us and what they tell others about us.

Keeping the human aspect at the core of support not only helps the customer feel heard and respected, but improves our workplace and job satisfaction as well. After all, who wants to work at a place that treats its people like machines?

Data Shepherds

Much like sheep wandering the country-side data needs tending. What exactly this entails means a great many things, from ensuring database tables are setup correctly, to running errors checks against incoming data requests, to ensuring proper authentication methods are used. While each given environment may require different specifics, they will require someone to monitor and maintain it. This could be a Database Administrator, Functional Developer, or System Administrator. Regardless of this individuals role or title, they will need some level of access to the data, if only to ensure it’s actually there, and some data, especially things like Financial or PII, can make this a nerve-wrecking experience for partners.

---

And WHY do you need access to that?…

The business side can be understandably nervous when someone has access to their most sensitive information; after all it’s important stuff! What is sensitive may differ based on team, location or industry, but the fact remains that SOME data will fall into this bucket. On the other side is the tech partner who is responsible for maintaining those systems; the individual who needs access as part of their job. Between them lies friction, and responsibility of being a good data shepherd.

There are always times when a technical partner requires access to this sensitive information to perform some Amazing Thing. Naturally (and rightfully so!) the business will question WHY is access required to that information. Frequently my response follows some pattern of

“Without access to your data, we’ll be unable to accomplish that Amazing Thing you wanted.”

— Me

Of course the exact response differs depending on what the data is, but the basic reply is the same. I cannot accomplish the request without access to this data set or system for XYZ reasons. Most of the time (and after some further explanation into the why and how) I’ll get what I need to complete the ask. If pushed, however, I’ll tell them something like:

“Well, it’s possible for me to do this, but without access to the data I cannot validate my solution., which is bad for ABC reasons.”

— Me

This tends to put a stop to any further line of thought, as frequently me (or the team I am on), are the only individuals who can do The Thing. I’m not suggesting we don’t fully justify WHY, or even that we keep access indefinitely, just that calmly pointing out that The Thing isn’t possible without this information tends to be a very good way of convincing a partner to help provide access.

---

It’s just a set of numbers

One of the first times I ran into the challenge of access to sensitive information I was validating Social Security Numbers (SSN) in a HR system. Generally theses are considered to be rather important pieces of information, and so they should be both accurate and highly controlled. Before being granted access a more senior tech taught me a great lesson

“It’s just comparing one number to another, and our job is to ensure they match”

— More Senior Tech

This was very impactful lesson for me and drove home that our job is to ensure the data is correct regardless of what that data is. It doesn’t matter if I’m confirming someone’s email address is valid, and this is especially true when dealing with highly confidential or sensitive information. Commonly this may involve confirming a termination action was correct, or updating compensation. It doesn’t matter that Jimmy makes $5,000,000, all it matters is that particular number is what it should be.

I also frequently let my partners know that once I’m done by access can (should) be revoked. I actually prefer it this way since it greatly reduces the possibility of a problem cropping up. Selfishly it also means there’s one less thing I have to deal with / worry about, which is always good.

---

At the end of the day, most data is important. It doesn’t matter if it’s SSN, payroll data, or publicly available info, it must be tended to appropriately. Fortunately tech partners generally aware of special requirements, but it’s never a bad idea to highlight areas that require more security or specialized handling. I always thank my business partners when they do - it helps them understand I am aware of the important, and helps reinforce our collective responsibility to be good shepherds.

Make it work

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

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

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

• Step back and breath

• Look around

• Examine Options & weigh risks

• Execute

---

Step back and breathe

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

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

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

---

Look around

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

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

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

In the case of systems

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

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

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

---

Examine Options & Weigh Risks

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

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

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

In the case of systems:

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

  • Do they have enough info to be truly helpful?

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

  • What problems can come up if it is used?

---

Execute

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

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

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

---

Making it happen

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

On Entering Tickets

Ticketing systems are everywhere, airlines, apartments, work.  Everyone's reached out to one (sometimes not knowing it's a ticketing system!) at some time before, but despite the ubiquity of them many of us aren't the best at putting in good tickets.

Good tickets contain enough info for the person at the other end to understand what the problem is and determine a course of action.  These tickets tend to include things like screenshots, error codes and descriptions of what was going on at the time. They not only provide the WHAT, but also the HOW and the WHY behind the ticket.

---

The bad

Before we look at what makes a good ticket, we need to understand what makes a less than good ticket.  Consider the following (let's also assume the ticketing system knows who you are, what time it is, etc):

“Help! I can’t log into system ABC.”

— User

This does tell us some information, that you cannot log into ABC, but the information provided is very limited.  If I'm a very good tech I would first check to see if you have access to ABC, or if you're even supposed to be able to (its surprising how many times people try to log into systems they shouldn’t!). More likely, a tech will look at this, roll their eyes, and respond with something like:

“Ok, tell me what happens when you try to log in.”

— Technician

While this response is typical, it doesn’t do much to get more information from the customer, and it doesn’t help establish positive rapport (not the scope of this discussion, but also very important!). Ideally the tech should do something more like :

“I understand you’re having trouble with ABC. I see you do have an active account in ABC. Could you please got to this link, try to log in with you username and password and send me a screenshot of your entire screen with what happens?”

— Better Technician

I won't get too deep into how to properly answer tickets (a fascinating topic worthy of it's own discussion!), but this approach provides clear next steps for the customer.  It also clarifies some assumptions, such as the user knowing where or how to log in, or them forgetting their credentials.

---

A Good Ticket

Short of just getting “Help!” (which does happen!) the example above is basically a worst case.  A good ticket is one step up by providing more specifics, such as an error or screenshots. Thankfully more often than not customers fall into this bucket, mostly due to previous experience and/or training. It looks something like:

“When I try to log into ABC I get a ‘account not found’ error, help.”

— User

This clearly states the problem, and provides some technical info to look into.  It's better than the bad example since we get that error message, but even here more info would be really useful. For example a link to where they logged in, or telling us it worked yesterday.

---

Really Good Ticket

Rarely, oh so rarely, I see an exemplar.  A ticket worthy of being printed off, framed, and hung on the wall as a shining beacon to direct people to.  Something like :

“I tried logging into ABC at this link, but got a ‘account not found’ error (see attached).  I could log in with my username last week, and don’t think anything’s changed. I need to get in to pay everyone. Help.”

— Really Helpful User

This one gives us everything:

• What - they can't get in, and am error plus screenshot

• How - at a specific website, with info on it working before

• Why - a business reason which helps determine priority

This information removes a lot of the guesswork for the tech.  They should still double check, but now they know what to look for, and when to look (sometime in the past week).  It’s also possible this info will trigger an immediate answer (e.g. system maintenance is ongoing and locking folks out), or otherwise clue-in the technician to something that may be impacting them.

---

While I concede our users won't  do this all the time, we need to set the expectation on them to give us good tickets.  Folks should be regularly reminded how to put in tickets, and that putting them in properly is beneficial for everyone. Not only does it make our techs lives easier, it decreases back and forth, shortens response time and makes everyone happier.

Ticketing system basics

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

---

Bare bones

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

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

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

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

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

---

Additionally useful fields

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

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

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

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

---

Pandoras box

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

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

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

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

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

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

Afterthought of an afterthought

Very frequently businesses need to make decisions about the business. These may be big or small decisions, but they all have one thing in common - tech/systems partners should be included in them sooner rather than later. This is doubly so for HR Information Systems (HRIS) since many highly sensitive things (like payroll) will be impacted, and very frequently the complexity of those systems isn’t fully appreciated by the business.

---

Oh, right.. we need that.

I frequently joke that IT is an afterthought. After all, no one starts a company to fix their own computers. Eventually, though, someone realizes that yes, you do need someone to manage your IT resources. Once this happens, things tend to get better for IT. The business fully (or at least mostly) realizes the need for IT resources, but this generally doesn’t flow over to HR. This results in HRIT becoming an afterthought of an afterthought - after all, we have HR Generalists / Coordinators / Business Partners to handle running HR, why do they need systems experts?

This is also compounded as HRIT and IT are only cost centers (would love to hear if anyone’s found a way to change that!). Since we don’t obviously increase profits it’s harder to justify why they exist. It’s also hard in some cases to prove their actions save money (how many dollars does a good knowledge base page save?). While it is possible to break down ticket cost etc. that also takes time and money, resulting in a nasty spiral of not wanting to do the work to prove it’s worthwhile since you don’t know it’s worthwhile.

Being a double afterthought results in problems ranging from processes being done manually that can/should be automated (manually emailing new hires vs. automating with free add-ons), to catastrophic problems resulting from the lack of understanding / planning (for example paying groups of terminated employees well after they’re gone). In my experience these problems are brought to the HRIS teams attention… but only AFTER the impact has been felt by the company.

The problem is this is the same as ignoring leaky pipes in a submarine, eventually the “savings” of not pumping up HRIS will result in a massive problem.

---

Leaky Pipes

Since HRIS is usually the last player to the party (or at least the last invited), we tend to only get looped in at the last possible second (“We need this live tomorrow” is a common request…). What kills me about this is many times I hear that planning for that initiative had been in the works for weeks, of not months, before hand. I very frequently find myself wondering how we can have so many smart and talented folks around, but constantly fail to include critical elements early enough in the process.

Some common things I hear about why HRIS isn’t included earlier, my thoughts, and possible solutions:

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

   1. One of my favorite reasons (especially the confidential part). I completely understand the need to keep information contained, but every company I’ve ever worked with has had me sign some type of NDA. In addition, HRIS teams tend to deal with highly sensitive information as a matter of course (SSN, pay scales, home addresses, etc). It is expected that we are good data stewards, so your list of terminations is just like any other spreadsheet to us.

   2. Solution - One of the simplest things to do is select one individual from the HRIS team (e.g. the manager) to get advanced warning that things are coming down the pike. They don’t have to get specific details, but a general outline of what is required is enough so they can think through possible fixes. Ideally this person understands both the system and the business ask well enough to make it generic so the team can plan.

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

   1. Any time I hear this one I scratch my head. I find it hard to believe that no one on the project team realized your plan to change compensation for 1,000 people wouldn’t, in some way, impact HRIS.

   2. Solution - Involve your HRIS or IT teams in EVERY major change you consider. You wouldn’t leave Finance out of a discussion where you didn’t know with 100% certainty they’d be needed. At the very least include them in the “I” of your RACI charts (or whichever flavor your company prefers). This way your HRIT teams will at least be aware of whats going on and will speak up as needed.

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

   1. This generally results from someone on the project team (or their managers) making assumptions about how HRIS operates (similar to “This other place I worked at did it this way…”). The outcome tends to be dramatically skewed expectations from the project team that, at best, will alienate your HRIS teams (e.g. a change should . “only take two hours” but instead takes 4 days and 2 employees to fix).

   2. Solution - This is all about proactive partnerships. Special project teams should regularly meet with HRIS teams to understand basics of the systems such as estimations on standard requests, downstream impacts, etc. Not only will this help alleviate #1 and #2, it will foster better collaboration and build trust.

---

Plugging the leaks

The best way to get over being an after thought is to build proactive relationships with HRIT and partner teams. This can take the form of a monthly lunch and learn where systems basics are shared, or specific meetings to go over features, or formalized partnerships where team members regularly sit down and go over challenges. At the very least this will help give partner teams a better understanding of just how complex the plumbing is.

I tend to prefer in-person sessions where I walk through specific processes, or demonstrate how specific features work. While I tend to have a plan in mind when we begin, the discussion frequently veers off into different areas based on comments or questions from my partners. Personally this is some of the most interesting discussions to be had about systems. Getting a systems expert and a business expert in the same room is bound to come up with some good topics.

To help avoid last-minute “gotchas” related to HRIS, we all need to remember that every aspect of what we do is complex; often more so than we think. Taking time to help the business understand our complexities, and appreciate the effort required to make “simple” changes, more than pays off. It not only helps strengthen relationships, but will pay dividends in future projects as partners are better equipped to help address challenges before they come up; hopefully bringing HRIS out from the shadows of being an afterthought.

Getting into tech

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

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

---

What do you mean by tech?

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

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

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

---

Technical Project Management

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

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

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

Quality Testing

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

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

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

Sales engineering

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

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

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

Data Analyst

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

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

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

---

Taking the plunge

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

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

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

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