The importance of having a good stance

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

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

Devil in the details

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

Real world stability

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

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

Play a little, train a little, work a little every day

One of the better approaches to planning/spending my day came from my martial arts training.  “Train a little, work a little, play a little every day”.  This approach has helped me stay (a bit) more balanced, and has helped keep me from going overboard in any one area.

---

Work a little

In the same lens of improving ourselves physically (or my addition of upskilling), taking a little bit of time to “work” is also important.  Originally I took this to mean job-related work, taking time to write a few emails, tweaking a set of slides, or thinking through a strategy.  This helps keep moving things forward, but I’ve also found it helps relieve some mental pressure (especially over weekends!) as I get time to plan things out.  

In the same way we can combine “Train a little” with both physical and upskilling, we can do this with “Work a little”.  I frequently think through a work challenge while I”m on a run.  This double dipping gives me a bit more time to figure out what I should do, while also helping me improve in multiple areas.

---

Play a Little

This is an important one… take time every day to play.  I interpret this to mean do something you enjoy solely because you enjoy doing it.  This could mean playing a video game, reading a book, gardening, or anything else you enjoy.  The point of this isn’t to improve a skill, or get something done, it’s to allow yourself to relax.  Relaxing helps us let go of stress, and more importantly helps us unpack our emotions and thoughts.  

I find this unpacking makes it much easier to re-engage with work (or something stressful) than if I haven’t had that time to unpack.  It's similar to organizing your closet - at the end of it you realize there’s a lot more space than you thought, and you can actually find things.

Train a little

In the martial arts aspect this would mean making time to go run forms, or practice fighting, or teaching.  This could be a formal class, going to the park and training by yourself, or just taking 5 minutes to meditate during the day.  As I thought about this more I also realized it covered anything related to improving myself as a martial artist.. Going for a run, putting together a training schedule, updating my notebook, etc. all contribute towards training.

As I’ve spent more time in the workforce I’ve also come to understand this from an upskilling perspective.  In addition to the physical training aspect, I also include things like learning a new skill through a platform like Udemy (shameless plug!), reading a book that relates to business or talking to others about their approach to their career.  The point isn’t to pick a specific way to improve your skillset (whether it be physical, professional or otherwise), but that you take time every day to do SOMETHING to move the needle in those areas.

There are some ways to combine these, such as listening to podcasts while running, or having in-depth philosophical discussions while sparring (let me know how that one goes if you try it!).

---

All of this isn’t to say that you cannot have days that focus on just one or two of these areas.  Many of us frequently dive into work and take a lot of our time to wrangle with those challenges.  This can be a great use of time, especially when we’re in a flow state or achieve something satisfying.  The danger is we end up “stuck” in any one of these modes to our overall detriment.  By taking time to do each of these, train, work and play, we allow ourselves to trend more towards a balanced state. WE can even combine these, such as the listening to podcast while running example (improving work-related areas while also exercising).  The more balanced and stable we are, the better we will be able to react and address other things in our life.

Best intentions pave the road to massive headaches for other people

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

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

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

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

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

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

---

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

---

I’m “Helping”

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

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

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

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

---

Whoopsie

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

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

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

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

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

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

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

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

---

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

Laid Off? Invest in Your Self

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

---

Growth Takes Space

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

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

---

Uncertain Direction

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

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

• “Why me?….”

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

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

• “Who’s hiring?”

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

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

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

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

• “What do I WANT to do?”

• “How can I do that?”

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

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

Time to Breathe

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

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

---

Seeing the Clearing in the Trees

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

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

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

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

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