On taking notes

I've found myself to be a compulsive note taker.  Every meeting I'm I. I'm constantly writing down the topics, what was said and follow ups.  If I'm being honest this started when I almost fell asleep in a VERY exciting meeting about the chart of accounts... Regardless of how it started though, it's been a very handy compulsion.

It keeps me engaged

This compulsion started as a way to keep me engaged in the discussion.  In order to write down what was going on I had to pay attention.  Paying attention meant I had opportunities to be involved in the discussion.

Over time this engagement helped me pick up a lot of new ideas and skills.  Simply by being involved in the meetings I learned more about the topics being discussed.  Over time, this has helped me understand complex deployments, foreign concepts and new areas of the business.  At the very least it demonstrated to my team that I was present and involved.

It provides instant value

Recording notes is an incredibly easy way to show you're creating value.  Suddenly you go from being just another person in the meeting, to the person in the meeting who actually knows what happened.  After joining a new team I constantly hear I'm providing value quickly.... Just by taking notes.  Honestly I find this a bit funny since all I'm doing is writing things down, but it's a real easy win.

It covers your (you get the idea)

Having a stockpile of notes is a great way to cover yourself if you need to.  Being able to go back and determine when a decision was made, or when a topic first came up is very powerful.  Personally I've used this many many times to remind folks of what we had discussed... And in a few places averted major escalations by proving a point.

Sometimes it's not a stakeholder I need cover from... by myself.  Sometimes (ok, many times) my memory feels like swiss cheese... I'm constantly going back to review what we went over, if only to ensure I make the best decision.  Having my stockpile of notes gives me an incredible resource to rely on to help me make better decisions.

Raising Issues Early

Raising issues early

Any given project will have any number of issues pop up.  It could be a resource will be on vacation, or a vendor is unavailable, or a dependency suddenly pops up.  These events can be disruptive, but in many cases they can be predicted or planned out in advance.  We can put together vacation calendars, ask vendors for their availability and investigate risk.  Knowing (or even expecting) they’re going to crop up and letting everyone know about them are two different things though.

Many times we do all the work to figure out an issue exists, and then don’t take the next (critical) step of sharing that with the greater team.  This misalignment causes numerous challenges, including (but certainly not limited to)

• Lack of resourcing - Not knowing an issue exists raises the risk that no one will be available to take care of it when it comes up.  

• Damaged relationships - Not letting all the stakeholders know about an issue, and then bringing it up later, can negatively impact your relationship with them.  You risk losing trust and making future work with them challenging.

• Stress - Even if you avoid other issues, more work, especially unplanned problems, only increases stress on the team.  This eats away at productivity and can amplify other problems (burnout, loss of trust, mistakes, etc).

The good news is it can be (relatively) straight forward to avoid these problems.  The (easy to say, hard to do) step is to be very proactive about raising any issues you are aware of.  The exact way this is done can differ based on your circumstances and group, but in general the following steps are very helpful.

1. Let your immediate team / manager know - The first thing to do is let your team and manager know what you’ve found and share as much info as you can.  This lets your team get aligned on how they want to handle the issue.

2. Gather info - Once your immediate team is aware gather as much info on the issue.  Things like expected impact, cost and possible solutions are all useful pieces of information to gather.

3. Plan communications - This can be done in tandem with gathering information, but you’ll want to think through how you’ll share what you’ve found with your stakeholders.  How you do this depends on your stakeholder group (e.g. a formal meeting with specific wording, quick slack call, etc), but thinking through how you’ll share this information is critical.

4. Communicate - Once your team is aligned on how you’ll communicate you’ll need to communicate based on your plan.  Depending on the severity of the issue this could range from a quick email to a formal meeting.  Knowing who to include is also important as sometimes not everyone must be included.

Followup - After your communication is completed follow up. Ensure everyone is getting relevant information on the issue, including status updates, tracking, and timelines. Doing this will help ensure everyone feels like they’re in the loop and help prevent additional stress or other pain.

Beginning Background Knowledge

I’ve found that many times I’m presented with a challenge that I don’t know the specific answer to.  It may be some complicated technical setup, or changing how a relationship operates, or some new technology.  These scenarios are a bit exciting and a bit scary since I go into them not knowing the answer.

I’ve found that in order to succeed with tasks like this background conceptual knowledge is critical.  Understanding the basics of how a system operates allows me to more easily understand new areas of it.  After all, it’s still got to follow some basic rules. (Similarly if we understand a little bit about how gravity operates that makes it much easier to understand how something will fall, even if we’ve never seen that specific object before).

This can also be applied to softer skills.  If we consider each individual we interact with as having their own underlying “rules” for how they prefer or need to communicate we can then apply those rules to future interactions.  As we meet and understand more people our toolkit expands and we can begin to apply these rules to folks we’ve never met before… and succeed.

---

Find the common thread

The biggest challenge to making this work is to understand those basic rules.  This requires work.  You have to memorize and internalize terminology, where buttons are, what process flows exist.  Personally I find a three pronged approach to getting my brain up to speed; get the manual and read up, get hands on with the thing itself, and talk to others who know it already.

While reading documentation and studying documents can be tedious and boring this is a great way to understand how something works, especially when that documentation comes from the vendor or an expert in the field.  Documentation is great since you can go through it on your own time.  It doesn’t require others to be available or access to any new system.  It does, however, require time and effort.  Since it was written sometime in the past documentation can also feel disconnected from reality.  Due to this disconnection I tend to combine it with hands on discovery.

It’s hard to beat hands on experience to help drive learning, especially when combined documentation.  Being able to tinker and see things in action is an excellent reinforcement to learning.  Having the manual next to you as well lets you lookup what you’re actually doing.  This approach, however, can be frustrating if you run into a situation where you can’t progress because you’re missing something important.  This is where having someone who knows the system is very useful.

Talking to others about that system or interaction is also important.  There’s two main ways this can go - they know more about the system than you do, or they know about the general concepts (or both!).  The first will let you improve specific skillsets and learn the mechanics of that particular system.  This is great, especially when you’re first starting out since it helps increase your rate of skill gain.  The second helps you understand how to apply general concepts to different areas, which is also very important (especially if your role expands or changes).

In general you can’t really have TOO much background knowledge in any given subject.  The more you have, the more likely it is you can apply some of it to a challenge and come out on top.  It does take work to accumulate this information, but the effort is more than worth it.

Bring Solutions

“Don’t bring your manager problems. Bring them solutions.”

We’ve all been in situations where we’ve found something that needs to be done/fixed/corrected/etc.  Our kneejerk response to finding these things is to point them out, to tell our manager/coworker/spouse that we found a problem.  This isn’t a bad thing... After all, we’re flagging a problem for others, and that’s the second step to getting it solved (number one being identifying there’s something wrong at all).  Indeed, many folks don’t even take the first step of identifying things that need fixing, which itself is a fascinating topic.

---

The weakness with this approach however, is it’s passive.  We’re telling everyone “Hey, I found something broken”, and nothing else.  There is certainly value in this, since now others are aware of the thing, however, you’re basically just making work for other people.  Now that it’s a known problem, your manager/team/parents/whoever, need to figure out what to do about it.  Suddenly someone else now has move work on their plate… work that you basically gave to them.

Bringing solutions

Instead of pointing at a thing and saying it’s broken, instead point out how you’re going to fix the problem.  For example, instead of “We scheduled the wrong flights for our vacation”, try something like “I noticed our flights were for the wrong dates, I’ve already emailed the airline to get them changed”.  Or how about instead of “All of these new hire records have the wrong hiring manager”, try “I’ve found that 54 new hires have the wrong hiring manager, here’s a list of their correct ones that I’d like to update”.

I always try to think through what I would like to get if the problem was brought to my attention and work backwards from there before I send out any communication.  Is there background info I should be including?  Are there statistics or other numbers that would be helpful (e.g. the total number of errors, people impacted, etc)?  Are there other folks that should be informed or brought into the discussion?  These questions help me shape what I pass along, and help shorten the time from “see thing broken” to “thing is fixed”.

What’s in it for you

This approach lets others know about the danger, and also demonstrates you’ve thought it through and have a fix in place.  You’re both saving them time by presenting a fix, and also demonstrating your initiative/skill/etc in fixing it.  By presenting both at once you’re also giving them an opportunity to weigh in… maybe they have a different fix in mind, or some new approach they could teach you. Regardless, you’ll end up in a more positive spot overall… either having solved the problem yourself, or gaining something valuable as a result.

No Extra

Extra, in some cases, is good.  Extra guac? Please.  Extra time to sleep in? Sure.  Unfortunately on a project, extra can be bad.  At best adding extra to things distorts our view of the request and makes it easy to lose sight of what is actually needed.  At worst it totally derails a project and diminishes its value to your customer.

Adding extra into our work does several things… some obvious, others much less so.  I find that instead of making things better or providing a better output, these additions detract from my deliverable.  Here’s several ways how:

Energy drain

Working on extra stuff that is “better” than our objective distracts us from what we should be doing.   We can tell ourselves we’re helping, or that we can make up the time, or that the actual request is easy to do, we’re just making it harder to complete our objective.  At best we end up putting less energy into our objective, which results in risk that we missed something important, or that the product isn’t as strong as it could be.

Diffused Focus

Working on extra necessarily pulls our focus away from what we should be doing.  Instead of critically examining our request for potential flaws, we’re day-dreaming about something unrelated.  This split focus allows us to make mistakes we otherwise would catch.  Even worse, this can result in less time to figure out the “extra” we thought was so valuable… so instead of delivering what was asked we deliver one thing that was asked that may or may not work, and another thing that wasn’t asked for of questionable use.

Missed Target

Working isn’t done in a vacuum, and we as individuals (and sometimes teams) can’t know everything.  When we make a choice to add extra to a request we’re gambling that we know what’s “best” or “right”.  While we might get lucky and deliver something that is, in fact, useful or valuable, what happens if we’re wrong?  Suddenly we have to explain why we wasted time NOT working on what someone wanted to build something that’s useless.

---

I find it fascinating how hard it is to only do what is asked, and nothing more.  It should be an incredibly easy thing to do, but the allure of making it “better” is very hard to resist.  As funny as is it to say, it takes discipline to stay inside the lines.  It is true there will be times when we can push on those lines, and sometimes help redraw them, we need to be very careful not to wander outside them.  Doing so distracts us from our objective, and instead of building us up, only tears us down.

Conceptually speaking...

Learning a new thing is always a process.  We begin by learning rote skills, the mechanical movements necessary to reproduce a specific result.  Then we progress to application of those mechanical skills, and eventually end up learning underlying concepts in whatever it is we are doing.  Take writing for example, we first learn how to physically hold a pen or to use a keyboard, then we learn how to make letters appear (so much tracing!), then onto making words appear, then sentences and finally paragraphs.  Once we have mastered those basic mechanical skills, we move on towards applying them to novel situations - writing new things.

---

This general progression appears everywhere.  In the martial arts we begin learning how to stand, or how to breathe, or how to focus where we’re looking.  These are then built into more complex moves, how to punch or kick, and then strung together into sequences of movements called forms.  Once we understand those basic building blocks we can compose any series of movements we like.

Professional skills are the same - we learn what the various buttons do on a machine we operate, then we learn how the machine works, and eventually we’re making widgets.  We learn how to perform basic tasks, we teach others those tasks, then we get to define what those tasks are.

Where I find it becoming interesting is after we’ve learned those mechanical skills and what we get to do next.  Must we ALWAYS have at least 3 sentences in a paragraph?

What happens if we don’t?

Must we ALWAYS turn to the left after a specific kick in a form?  What happens if we turn right… or don’t turn at all?

I find myself wondering what is beyond the rote mechanical skill.  It’s important to know the basic standard skills (they’re called standards for a reason - having a shared lexicon is incredibly important), but after you know them how important is it to follow them explicitly, and what happens if you don’t?

---

So far I’ve found it easiest to identify in martial arts movements.  It doesn’t REALLY matter if you right, then left, or left, then right.  The underlying concept behind the movement is to teach you how to move.  I’m seeing similar patterns in my work - learning how an Excel function works is great, but the concept of an “if” statement can be applied across every system we work in.  Zooming out a bit further, the concepts behind many soft skills generally don’t have a specific application, but rather require you to understand them conceptually.

This is certainly a reflection of where I happen to be at in my own growth.  Beginners, for example, should be given clear, repeatable directions to follow; before we can play with concepts, we have to understand the mechanics.  This also leads to some amusing situations when I’ve taught, and forgotten the “correct” way a movement goes.  Inevitably I’ll get the question “But Rob, don’t we turn right after that move?”.  After a few seconds of remembering the “correct” way I’ll respond with “Yes, but at the end of the day it doesn’t matter.  The intent is to teach you how to move, not how to turn right”. 

This approach to looking at the importance of underlying concepts, and not just the mechanical skill is one that shouldn’t be applied at all levels of learning.  Beginners especially need the mechanical approach as it reinforces learning and ensures they share a common baseline.  For example it’d be incredibly hard to talk about writing if everyone didn’t know what a period was, or if some of us used vowels differently.  Similarly it’d be challenging to train up new team members at work if everyone on the team taught them different ways to do the same task.

Once someone is comfortable with those basic thoughts, begin to shift the focus to what’s behind them.  Why we choose to take a certain action is more important than the action itself ... knowing the difference is even more important.

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.

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

Make it work

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

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

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

• Step back and breath

• Look around

• Examine Options & weigh risks

• Execute

---

Step back and breathe

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

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

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

---

Look around

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

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

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

In the case of systems

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

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

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

---

Examine Options & Weigh Risks

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

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

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

In the case of systems:

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

  • Do they have enough info to be truly helpful?

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

  • What problems can come up if it is used?

---

Execute

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

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

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

---

Making it happen

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

Ticketing system basics

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

---

Bare bones

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

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

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

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

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

---

Additionally useful fields

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

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

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

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

---

Pandoras box

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

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

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

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

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

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

"Generic" and "Specific" Basics

One of the great things about life these days is technology. It (mostly) makes are lives easier, especially when it comes to work. I cannot imagine having to keep track of employee data on paper, having to run payroll by hand, or generating reports manually.

The downside of tech is that it requires at least a baseline understanding of how it works in order to get any benefit. These basics may be more “generic” (applied across multiple systems or scenarios), for example knowing the magnifying glass allows you to search, to a more “specific” basic, such as knowing how your underlying data is sourced.

---

“Generic” Basics

“Generic” basics are things that can be applied across multiple systems or areas. Save icons fall into this bucket since they’re almost always a floppy disk (something that dates back as far as I can remember!), which is especially amusing since physical media of almost any type is quickly disappearing. The search icon is another example that appears almost everywhere.

Despite the prevalence of these items, unless you understand what they mean you’re in for a very frustrating time. I once watching a steelworker manually scrolling through a list of 5,000 files despite the search icon being displayed at the top of his screen. I stopped him after a few minutes and showed him what the magnifying glass did, the told him to call me if he ever looked around for files again (I’ve always wondered how much time is spent globally manually looking for things….).

Digital natives have a massive leg up with the generic basics since they grow up with it all (I’ve heard apocryphal stories of young children getting upset that the TV isn’t a touch screen). Since their training begins so young they’re able to easily translate those basics to work.

---

“Specific” Basics

While generic basics may apply across systems, concepts or ideas, specific basics are, well, specific. Some examples I run into include:

• Workdays security architecture - Knowing how this works doesn’t really help you understand other systems security

• Using a video game controller - I see this one a lot at home with my family. Knowing how to use a TV remote does’t help you turn on the Xbox to watch Netflix.

• Perform data analysis - How data is collected, transformed, and stored has massive impacts on your analysis, but those changes differ based on the data source.

All of those examples are only really in the sphere they’re used in. Due to this Specific basics are generally only known by individuals in those areas.

---

Where Problems Crop Up

Things get dicey when someone :

1. Doesn’t know a generic basic

2. Incorrectly applies a Specific basic

3. Does’t know a Specific basic

The first tends to result from missing training. An employee is a physical trade skill (e.g. carpentry) may not be aware of the search icon, for example. This type is relatively straightforward to correct via training, but can be incredibly frustrating to that individual. It’s always a mark of a good

The second and third are where things get dicey. Not knowing Specific basics results in looking bad (example below) to catastrophic errors (inadvertently exposing social security numbers). Frequently I see these crop up when folks begin doing data analysis or presentation. Most recently I spotted this gem in a hospital:

97% isn’t a third of something!

In this specific instance the error wasn’t too catastrophic, but I always imagine what would happen if something like that was presented to the C-Suite.

---

Minimizing Errors

I’ve found the best way to help avoid both Generic and Specific errors is to work on connections with folks, and try to break down the “I only go to IT when something breaks” mentality. Having a solid (or developing) relationships makes it easier both for partners to ask questions, and for you to point out possible errors.

It’s also REALLY helped me to remember we all commit errors. Everyone has forgotten to save a file, or copy a formula, or how to correctly update something. Keeping our humility, and remembering we’re all in this together, will go a long way to keeping things running smoothly.