Data Analysts - Know Thy System

“Know Thyself” is certainly an important concept to being a human.  “Know Thy System” is an equally important concept to being a data analyst.

In addition to knowing data analytics concepts (not making misleading graphics, for example), a good data analyst also understands how data moves through the system(s) they analyze.  This knowledge goes beyond basics and extends into how specific metrics are collected, how users behave and how data is stored.  This background knowledge not only makes it easier for them to find the numbers they need, it allows them to draw better conclusions on that data.

Some examples I’ve run into include:

• Knowing when tickets are assigned - Many reports on ticketing systems relate to who’s been working on tickets.  Knowing when/how users are assigned tickets will impact the report.  For example, if someone triages a ticket THEN assigns it, we can expect tickets to remain unassigned throughout the triage process.

• When data is added to something  - Some data fields are populated when a record is created (Employee ID, for example).  Other data, however, may remain defaulted or even null.  These defaulted values will appear in reporting, and may throw off results.

• Where data comes from - End-user reports sometimes contain data from multiple sources/systems/etc.  While this makes for easier story telling it can make troubleshooting or updating things more complicated.  Being aware of how your reporting system pulls information reduces time to update things and makes it easier to explain how things were determined.

---

The problem with NOT knowing thy system

Understanding the UI and the users perspective isn’t enough to really know how the system operates. Many systems, for example, combine multiple metrics when displaying values such as Service Level Agreements (SLA), total compensation and others. Looking at the back end database tables can be incredibly confusing if you don’t realize that “SLA” really feeds 5 different dimensions.

As data analysts it is our job to know about these concepts. Failing to understand them will, at best, result in a LOT of wasted time as we dig through tables or configuration settings, and at worst, result in bad decisions being made about the data. Something as simple as not realizing your underlying data doesn’t include any data from January can be catastrophic; your customers will make business decisions on the lack of results from January… which aren’t real.

---

Helping others to Know Thy System

I’ve run into MANY situations where someone doesn’t have any background on the underlying systems and tries to make determinations on something.  At best, this results in confusion as folks come to you, the Data Analyst with more questions.  At worst, this results in conclusions being drawn from information that folks don’t truly understand.

In many cases we cannot expect our customers (folks reading our reports) to fully understand all the underlying concepts.  This isn’t to say there shouldn’t be SOME expectation that they understand things, just that we cannot expect them to know anything close to what we do.  To help bridge that gap, I’ve been following a few guidelines:

• Always put comments in reports - Many reporting systems have a comment or text field.  I’ve started always putting notes in there that relate to that specific report.  These include a brief description of what the report is intended to show, and any call outs to specifics that may not be 100% obvious (e.g. a specific field showing a null/none until a specific time period, etc).

• Proper Naming - Definitely another easy win - just name things more accurately.  I try to keep a specific convention that briefly describes the report.  This both makes it easier for me to organize, but also helps my customers find the right report more quickly.

• Basic Documentation - In addition to cranking out reports and dashboards, I’ve found providing basic documentation on where data comes from is incredibly helpful.  This doesn’t have to be (nor should it be!) a full data dictionary.  This wouldn’t only drown your customer in too much info.  Rather it’s a quick guide on what common metrics mean and how they’re pulled.  Think of this as proactive defense against common questions.

Attendance Automation

The Setup

I worked at a company that had a great L&D team setup.  They developed a lot of internal training on their Learning Management System (LMS), which was augmented by a large number of instructor led training (ILT). There was a wide range of training, from regulation mandated compliance, to new hire onboarding, to skills development.  Luckily we were well supported by an engaged group of trainers with backgrounds ranging from training consultants to formally trained teachers.

Tracking was mainly done through the LMS, and was easy enough since that system was setup to track things like log ins, who watched what, and what quiz scores we got.  A number of built in reports provided basic output we could share with the business.  The ILT, whoever, proved to be more of a challenge.  While we could get an idea of knowledge retention by sending out quizzes or follow ups, keeping track of who actually showed up was more of a challenge.  

Generally paper attendance was taken, which works…. To an extent.  This was compounded as we had multiple locations that had to report back, forcing us to rely on folks outside the team to scan and email us attendance sheets.  Cheating was also a concern, as you could write down anyone else’s name and then claim they were there.  Given the highly regulated area we were in, this could result in significant consequences if we were caught.

---

The Eureka Moment

While thinking over this problem I had a “no-duh” moment that led to an eventual solution - every employee has a security badge, why can’t we just use those to log into class?  I knew our security system could record badges when someone opened a door, including who it was, when it happened and which door.  I didn’t see any reason we couldn’t do this for in-person trainings, now I just had to figure out how it could be done.

I knew other companies had dedicated training rooms (lucky), which would have made this easy.  All we would have do was get folks to badge into that training room and they knew who was there.  While we did have a number of rooms large enough to hold dozens of people (frequently needed for mandatory training), we were not lucky enough to have dedicated training spaces.  This was further compounded by having multiple locations.

My general idea was to have some kind of website setup that folks could swipe their badge into and record their attendance.  This would remove the need for paper (messy and easy to make a mistake), as well as the risk someone would write in someone else’s name (one individual did try to badge in their entire team at once, which we quickly shut down).  The only challenge was I didn’t have was the hardware to scan the badge or the software to process the information.

---

The Challenges

There were three challenges to overcome, two technical and one cultural.  On the technical front I had to figure out how to allow someone to badge into a class, and then how handle and process their scan-in.  The first required a hardware approach (some kind of badge reader), and the second a software approach (some system to take that persons scan-in and put it somewhere).  On the cultural front we had to get buy-in from leaders to socialize this amazing new product, and from individuals to properly use it (e.g. not send one person to scan in their entire team).

The Hardware

The Security team owned our badging system, so I started my quest there.  Their first recommendation was to have the Learning team pay to put a badge reader on EVERY conference room.  Now this would solve our challenge, since it would collect badging information when someone badged in… and it would also cost a LOT of money that we didn’t have (our budget was basically $0).  This approach would also only tell us that someone badged in at a certain time, not information about WHY.  For example, without additional work we wouldn’t know what class they were attending, or who was teaching it, both data points we were interested in.

Their next suggestion was to use a USB badge reader.  This sounded like a great idea, but unfortunately they didn’t know exactly which one we should get.  After a few failed Amazon purchases we reached out to the contractor who setup our system originally.  Without nerding out TOO much, the badges were made by a company called HID and go by the “Prox Card” brand name.  These cards can be programmed with any one of 137 billion unique codes, which is great if you have 137 billion employees, and slightly more of a challenge if you’re looking to read them.  We eventually figured out there are multiple ways to encode the card, for example, you can include a building number, as well as a unique ID for an employee, in the code.  The card readers have to be setup to read the number properly, if not, they’ll grab the information incorrectly (something I ran into during my initial testing).

In this sample card number the first three digits (110) could mean building #110, while the last 5 (72956) could be the unique ID for that individual.  

11072956

Unfortunately the USB card readers don’t know this out of the box… resulting in them reading the entire number as the employee’s ID.  The cards do have the number printed on the outside, so I was able to verify the number the reader was picking up was the correct one.  This, however, did not help me figure out what the numbers actually meant.

Fortunately our contractor was able to help us untangle this and gave us a configuration file that we could write to the card readers.  This ensured they properly read our badges, and meant we could quickly update new card readers ourselves.  We ordered a few readers for each location, and made sure the local L&D folks knew where they were (they aren’t cheap!). This took care of how to get an employees badge ID off their badge.

The Softer Side

Oddly writing the software for this turned out be easier than wrangling the badge readers.  I discovered that Google Suite (gMail, Slides, Sheets, etc.) has a scripting language called Google Apps Script (GAS), which is based off of JavaScript.  Not only was there more documentation available online, but there are massive communities online to reach out to for help (unlike our badge readers, which required a consultant to come in and help out).

GAS allows you to perform virtually anything a human can do via a script.  Need a Form to update a spreadsheet, perform some calculations, then email someone and wait for a response?  GAS can do that.  Need a button you can push to reformat an entire Slides presentation?  GAS has you covered.  Need a Sheet to open a webpage and collect badging information?  GAS serves up HTML and CSS.

Unfortunately while I had some basic coding classes back in the day, I knew nothing of coding (well, I knew it was a thing, in the same way I know quantum mechanics is a thing).  Fortunately I had two advantages - a manager who wholly supported this project and the firm belief that I wasn’t trying to do anything groundbreaking.  Having my manager’s support was essential as it legitimized any time or energy I put towards this project.  Since this was a prioritized project, this also allowed me to push back against other demands on my time and gave my some great backup in the form of my manager getting folks off my back.

Understanding that this project didn’t present truly novel problems to humanity helped me keep my focus and feel from being overwhelmed.  At the end of the day all I was doing was taking a number, looking up a name and displaying something on a website.  Sure, the number came from an ID card, but everything about this was what I called a “solved problem”; everything I was trying to do had already been solved by someone, somewhere.  This understanding gave me a great “out” any time I got stuck - just look it up online.

The challenge with looking things up is knowing what to actually type into Google/your library/whatever to find what you want.  Since my background isn’t computer programming my biggest challenge was not having the correct words to describe problems.  This resulted in a lot of wasted time at the beginning, but helped expose me to a wide range of ideas as I tripped over things and generally beat me head against the keyboard until something worked.

Culture Wars

Getting buy in to use the tool was the easiest part. No one likes doing paper attendance (citation needed), and this is doubly true at tech companies. After all, if we’re surrounded by really smart people who can code new apps and discover new solutions, why are we stuck using technology invented in the first century?

The cultural challenge we ran into was enforcing some simple rules, like “You can only badge in yourself”. This came around after several teams sent one person “ahead of everyone else” to badge in the entire team. We avoided most of these challenges by getting managers and directors buy-in to help enforce behavior. We also told our front-line trainers to push back on anyone trying to break the rules, and, more importantly, they we had their backs if anyone complained.

---

Deployment

Eventually I got to a place where I had a working prototype which I felt comfortable showing my team.  Getting feedback was an important part of this tools life, mainly because I wouldn’t be the one using it on a daily basis, but also because my background wasn’t in running corporate training.  I got several great suggestions, such as having the tool accept an email address in case folks didn’t have a badge, or also recording the instructor and name of the course that someone badged into.  These reviews did take time, but at the end of the day they made a much stronger tool.

We had a large (400+ employee) compliance training coming up and saw it as a great opportunity to field test the tool.  We decided not to say anything to the trainees or their managers, and instead just setup a table with a computer, badge reader and someone to check folks in.  Everyone up until now had been conditioned to sign in on paper, something they really didn’t like since it was one, slow, and two, annoying.  We weren’t sure what the response to the tool would be, but figured it couldn’t be worse than signing in on paper.

We were amazed at the response.

Several folks who badged in wanted to get their hands on the tool for other events their team ran.  Several Directors immediately wanted to know how they could blend this information with other learning systems to see how their teams are performing (e.g. if Sally shows up to training, do her sales numbers improve?).  Many of them asked where we had bought the tool from, and were quite surprised when they learned it was home grown.

Overall, the tool was a hit.  We got some great feedback on how to improve it, and after a few modifications and testing, we deployed it to all our locations to track attendance.  Not only did we entirely remove the annoyance and inaccuracy of paper based records, we drastically improved our reporting capabilities and built great relationships with internal teams.

---

Lessons Learned

• Find pain points - Everyone has something that bugs them about how they do their job.  A screen loads slowly.  They have to get 15 approvals to go to lunch.  Bob in accounting refuses to sign off on something with a $.01 difference.  When folks are first exposed to these pain points, they tend to either complain a little bit and then stop, or just assume that’s part of reality and accept it.  Over time, we learn to deal with them and they don’t seem so bad… but they are.  Take the time to talk to your coworkers about what could go better, and then go do it.

• Get buy in - Once you’ve IDed some pain points, talk with your team/manager and get their feedback and buy in to tackle one or two.  Notice it’s one or two, not ALL of them… you really want to sell the lowest hanging fruit, something you can knock out of the park with a bit of work.  Getting buy in makes it much easier to get help from others, and makes your goal much more legitimate to others.

• Jump in - Once you’ve got buy in, jump in!  The solution may not be a straight line… but those are boring anyways.  Going into it I wouldn’t have been able to tell you I’d end up learning how to write JavaScript, but also learned how our ID badges work.  Take the time to understand the challenge, and give yourself space to explore the options.

Short Bite - Get it done

Backing up entire systems is a very data-intensive process.  Not only does it involve moving a ton of data, it requires specific timing in terms of jobs, processes and systems to ensure it is done correctly.  Even with dedicated data lines, this process can take hours, or sometimes days, which in general is OK. I, however, found myself in a situation where we had to get a copy of our database from Seattle to Portland by 8am the next day.. And it was already 4pm.

---

The Problem

We had two data centers that mirrored each other, one in Portland, and another in Seattle. This is a common setup for data centers since it allows for fault tolerance in case one goes offline, and can help provide faster speeds depending on which one you’re closer to.  We had just completed a big update in Seattle data center, and needed that update to also be made in Portland. These updates were critical to the success of the project, and due to some (I’m sure very important) technical reasons both data centers had to be up to date.  One option was to do this “over the wire”, that is copy/paste the information over the internet. This was the simplest method, however, also the most time-intensive.  This was an incredibly large update, and despite having a dedicated line between our data centers estimates ranged from 12-48 hours to complete the update. Unfortunately this delay would break out deployment schedule.

---

The Solution

Someone pointed out that driving from Portland to Seattle only took about (a very boring) 3 hours, which was a LOT faster than going over the wire.  We hatched a plan to copy the updates to a laptop, drive them down to Portland and perform the update overnight. (Despite advances in wifi and internet speeds using the “sneaker net”, or physically walking data from point A to point B is still the fastest way to move data).

Wanting to ensure others on the team could focus on their work (and also to maybe get some quality alone time), I volunteered to be the courier.  After quickly downloading some new music I was handed a laptop and a list of commands to run when I got to the Portland datacenter.  After a (very boring) 3 hour drive (Protip : bring more than 2 CDs), I plugged into the Portland datacenter and took a nap while the updates ran.

A few hours, and one massive update later, I drove back to Seattle.. Where I promptly crashed in my hotel room for a few hours.

---

The Takeaway

Ideally projects do not present situations where extreme solutions like driving all throughout the night are needed.  Ideally.

When those situations are encountered, however, it’s always a good idea to get the team together to brainstorm.  See what possible solutions you can come up with (no matter how insane they sound), and then pare them down to what’s possible given your requirements.  In this case, we HAD to have the update live the next day, so that ruled out some options. It was also possible to safely use the sneaker net to make the update happen (e.g. I didn’t have to break all the speed limits).

Plus, sometimes you’ll get a great story out of it.

Tech Takes Empathy - Sheer Terror

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

---

The Setup

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

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

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

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

---

Sheer Terror

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

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

---

Queue Empathy

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

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

---

Back to Frank

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

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

---

Lessons Learned

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

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

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

Performance Reviews!

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

---

Asking for Help

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

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

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

---

Writing Your Own Feedback

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

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

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

---

Writing Others Feedback

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

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

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

---

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

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

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

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

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

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

---

Dealing with feedback

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

Not very helpful.

It’s not helpful because this individual is:

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

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

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

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

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

Possible reasons for this response:

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

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

• I really am perfect. - (unlikely)

---

Summary

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

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.