On taking notes
Taking notes, especially during meetings, is a VERY easy way to create value, and help save your future self from potential challenges.
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.
Frameworks
Having a framework for how things should be done is important… but equally important is ensuring your whole team shares that same framework. Nothing is worse than part of your team assuming things are done one way, when they’re really done another.
Frameworks
Projects are a funny thing. Everyone’s been on one at some point in their lives (even if it’s as “simple” as planning a trip), which means everyone kind of knows what to expect. This is good, because it means we all have some general idea of what the next steps are… but this is also not good because we all have our own assumptions / pre-conceived notions of what to do when.
Why This is good
All projects follow some version of ideation, planning, execution and completion. Exactly how that’s done differs, (for example Agile iterations over that execution and tinkers with planning while Waterfall sets it in stone), but all of that happens in one form or another. This makes it (relatively) easy(er) to translate our experience from one project to another, even if the exact topic or domain differs.
This is a good thing since we all have at least SOME shared experience. We’ve all had that moment of terror when we forget a detail and have to scramble to fix it. We’ve all had that moment of satisfaction when the project or milestone is done and we can check something big off the list. This makes joining a new project a little bit easier; we’ve seen how it’s done.
Why this is really not good
This familiarity, however, has a downside. It makes us complacent. It allows us to “safely” assume that one project will be anything like another, or that how one project is run will be how future projects are run. While this may lead to minor annoyances in smaller projects, it can lead to catastrophic problems for larger ones.
How to avoid the not good
There is a way to both capitalize on prior experience and avoid the pitfall of assumptions, and that solution is a framework. Frameworks give the team a shared understanding of what is expected. They take work to develop, teach and maintain, but the effort is worth it.
Building a framework is as simple as laying out steps to follow. Answering questions like 'how will we prioritize new work' or 'how will we run testing meetings' will help clear up confusion and avoid problems before the occur.
Just making a framework isn't enough though. We also need to gain buy in from the team, ensure they understand how to use it, and then actually use it. The payoff, though, is worth the effort.
No Update Updates
Sometimes we don’t have anything to report on how things are going… this, however, is (oddly) important to report! Letting folks know you’re still on it is just as important as having progress for them.
Communicating with stakeholders is important (citation needed). These updates frequently take the form of status updates, alerts, progress reports and more. All of these things are very important to share and ensure everyone has. That said, sometimes there simply isn’t an update share… maybe nothing major happened, or maybe stakeholders already know what’s going on. The exact reason doesn’t matter… what does matter is sending an update.
Sending an update like this sounds weird since there may not be any change or anything to update people about. Sending an update feels a bit ingenuous, or like a waste of time. In scenarios where updates are regular and expected, continuing to send one is important since it keeps up the schedule. These updates let stakeholders know you’re still there and keeps them engaged. It gives them that regular touchpoint they’re used to and reassures them you still care.
The trick is what to put in this update… after all, there may not be a big change going live, or any fun metrics to share. Frequently I’ll simply say something like “No specific progress was made this week, but we’re still tracking towards our plan”. Updates like this let the stakeholders know we’re on track, and allows them to spend their mental energy elsewhere. It also takes the important step of letting them know you’re still aware of their request. After all, nothing is worse than a stakeholder wondering if you still care about the work.
This trick is very useful on bigger updates, but I also frequently use it on tickets…. Especially when nothing’s changed. I might be waiting for someone else to take some action (e.g. a third party vendor or teammate), or I may just not have been able to get around to working on that ticket. Regardless of the background, this strategy helps the reporter know you’re still there and can prevent nasty escalations. Instead of them complaining to your manager that you’re not paying attention, they know you’re on it, even if nothing is going on.
The Importance of Triage
Triage is an important part of ticketing. Sure, it takes some time and effort, but it helps ensure basic information is available and the best resource is assigned to the task.
Every process has a point of entry, the point or place at which new work is considered and brought onboard. In the ticketing world, whether it’s for a benefits team, IT team or anyone else, this point of entry also represents a challenge; frequently requests come in that are missing information. As these move through the process they start to gum up the works as downstream folks may be missing critical information and have to go find it. At best this slows things down, at worst it results in a catastrophic failure.
This is where triage comes in. I think of this as a sub-process that runs as soon as new work enters the queue. Exactly what is performed here can vary, however, there are some standard questions that should be asked and actions that should be taken regardless of specifics.
Is the request clear?
Many times a request comes in and it’s hard to tell what it’s for. Maybe the name is poor, something like “New report request”. New report request for what?... for who?... when is it needed? Or maybe they’re asking for something sensitive but don’t provide any reason why. Regardless, we should always ask ourselves “Do I understand what this request is for?”. If I cannot answer “yes”, I follow up with the customer and ask for more information.
Is any information missing?
Similar to understanding the request, we need to ask if there’s enough information to take action. Asking for a change to report, for example, is useless without knowing what the change should be. Asking for access to a system without providing what type of access is similarly useless. Taking a moment to ask yourself if there is sufficient information to take action (or for the next person who gets the ticket to take action) is the next critical step. If you think any is missing, just reach out to the customer and ask for clarification.
Who should work on this?
Once we’ve got enough info on the request, we need to then determine who should work on it. Sometimes this is REALLY simple; there’s only one person to give the ticket to. Other times, this can be very complex if there’s multiple available agents to help out. In these circumstances figuring out who can/should work on the ticket can take a bit of thought since we have to take into mind things like workload and experience. In these scenarios I find it most helpful to have a list of who is trained/experienced in specific areas, and have access to everyone’s workload. These two pieces of info can make it easier to figure out who to assign the ticket to.
While triage does take time, it does streamline things quite a bit. By ensuring the ticket has sufficient information and is assigned to the most appropriate resource we set ourselves up for success. Even better, it helps build trust-based relationships with our customers by demonstrating we care about their needs.
Rolling out an intake process
Rolling out a new intake process can be tricky.. you need to ensure you’ve got buy in from the business and that everyone is aligned. Be sure to connect with their leadership, and invite them to collaborate to help make a strong process.
There's tons of ideas for work and projects floating around, and there's certainly no argument that there's tons of work to do, or that a lot of that is important and should get done. That said, this doesn’t mean that it ALL should be done. Frequently teams end up getting bombarded with different requests from multiple angles. Individuals will approach random team members and ask for some work, or executives will plan something out and assume it'll get done.
The challenge in the tech team is to figure out how to setup an intake process to streamline, filter and accept work. This process should include a way to evaluate the value of the work (e.g. what the business gets out of it), as well as the relative effort of the work (is it possible to accomplish with current resources). A good intake process results in several changes in how work is sourced, how it's accepted and how a team decides what to accept.
While there certainly is a lot to it, one of the biggest impacts I've seen is for the business side; they now have to follow a process instead of just flinging ideas at you. This makes getting buy-in from the business critical to any intake process. Not only are you changing things up for them, but you're adding process, which means things take longer. There's a few things I've found that help reduce this impact;
Start early
Once you've determined a basic I take process start socializing it with your business partners. This means letting them know what the plan is, and more importantly, how it helps them. Giving the team loads of time to get used to the change will help blunt the surprise when it goes online. You can start early be constantly bringing it up in meetings, reminding folks when it’s going to go online, and providing documentation on how it works.
Talk to the top
Like any process change, be sure you're getting buy-in from the leadership of your business partners. Ensuring the VP or Director is onboard will both get you an ally who will spread the word, but also give you a backstop. This makes it much harder for someone to not follow the process since their leadership is onboard. It also helps demonstrate you want to collaborate with the entire team instead of just pushing new processes onto specific individuals.
Be consistent
Once the process is in place ALWAYS use it. Nothing will undo it more quickly than one person or project getting to skip the line. This isn’t to say the process can’t or won’t be changed, just that it should be consistently applied across all requests / projects.
Collaborate
Once you've created your basic process, share it with the business. Explain to them why you started here, but ask them for their input. At the very least this gets more buy in, but it's also likely you'll get some good ideas from it. As the process matures, feedback from your business partners will also be a great source of ideas. After all, they’re the ones who have to deal with it on a regular basis.
Raising Issues Early
When we know something’s off it’s REALLY important we let folks know, and you can’t really loop them in soon enough..
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.
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.
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.
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.
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.
The Utility of Feedback
Feedback of some form is required for us to improve. Good feedback needs to be both timely and specific, otherwise some of that great utility is lost.
We rely constantly on feedback in our lives. Our bodies give us feedback on how it’s doing (hungry? Tired? Both useful pieces of feedback). When we play a game we’re reliant on feedback on how we’re doing. Social interactions with our friends and family give us feedback on how well (or poorly!) our jokes land. All of this feedback is good, it helps us take care of ourselves, get better at games and tell better jokes. Feedback at work, however, usually feels like a negative thing.
This to me is incredibly odd. Many of us spend the majority of our waking time at work, so I would expect work-related feedback to be treated at a premium. Frequently though, it’s seen as negative. I’ve written previously about “having” to give feedback and the negative connotation around that phrase, but it goes beyond just “having” to give it. Many of us are also reluctant to seek out, or even accept, feedback. Giving feedback is also something we shy away from, after all, it’s very hard to first identify something someone can improve on (or where they’re doing well) and then communicate that to them.
Regardless of our reluctance, however, feedback requires two things to be effective. It must be timely, and specific.
Timeliness
Imagine someone you trust comes up to you and says something like “hey, during that meeting four months ago you did a great job presenting X topic, it could be even better by also doing Y”. This is useful, since it’s specific… but it’s made less useful since it’s months later. You may not really remember that presentation or topic. You may have already improved that skill so this feedback isn’t as useful.
Ideally feedback is provided as soon as possible. I’m not saying interrupt a meeting, or call someone at 2am, but the sooner feedback is provided, the more useful it is to the recipient. Not only does it makes it easier for them to apply it, it’s also still fresh in their minds. They know the context, and they know how it can be applied. Waiting to give it robs the recipient of a lot of the utility.
Specific
Imagine someone you trust comes up to you and say something like “hey, I checked out that paper your wrote yesterday and noticed some grammar errors you made”. This is useful since it’s timely (they’ve told you close to the event), but it’s made less useful by not being specific. Sure they mentioned grammar errors… but WHAT errors? Are you mis-using commas? Not using conjunctions? Adding too many spaces after periods? Without the specific information this feedback is not very useful.
Making feedback specific helps the recipient by clearly showing what they’re doing that can be improved. Ideally specific examples can be pointed out and used to exemplify where improvements can be made. THis makes it considerably easier for the recipient since they clearly see what they’re doing that needs improvement. Being vague (regardless of the reason) robs the recipient of a LOT of the utility of feedback.
Wrap Up
Most people most of the time want to improve something, and feedback is one of the best tools to do that. Like any tool, however, it needs to be used properly. Being timely and specific gives the recipient the best chance of using the feedback effectively. Not only does it illustrate exactly what needs to be improved, but it’s provided close to the event itself making it much easier to translate into reality.
Right-sizing communication
We all get waaaay too many emails (citation needed). When sending emails, take a moment make it easier for the receiver by adding a tl;dr, or putting [Action Requested} in the header… trust me, they’ll thank you.
Waaaay back in 2015 folks received 121 emails per day. That’s about 1 email every four minutes. Sure, some of these are junk, or calendar invites, or cold calls from recruiting/sales reps/etc… but you still have to process them, even if only for a moment. There’s a lot of great tips out there on how to improve how to handle this deluge, but instead lets take a moment to contemplate how we can help NOT contribute to this insanity.
There’s a number of things we can do as email / communication senders that will help those poor, drowning recipients find our email and understand the message we’re sending in that torrent of other stuff. Applying these tricks does take a bit of time and thought to get right, but I find the small investment is more than worth it to help ensure my message is properly understood.
Include a too long; didn’t read (tl;dr)
The tl;dr goes back to early 2000’s, and was actually accepted as a word by Miriam Webster back in 2018 (How to geek has a pretty good breakdown). Basically you put a few bullet points synopsis of your message before the message itself (similar to a BLUF or exec briefing) so folks who are in a hurry can just read a few lines and be done. Under that, you write a long form version of your message.
I’ve used this trick for a number of years, and constantly have folks tell me how much they appreciate it (especially executives). This response makes sense… when you’re digging through 120+ emails a day, on top of your actual job, having something make it easier to determine what’s useful vs. what isn’t is incredibly useful.
A very brief example is below, but notice how the tl;dr says all the important stuff in only 2 lines. If someone wants more info, they can keep reading, but the tl;dr saves a LOT of time.
Tl;dr
Database will be offline from 2-2:15 for updates
Email help@example.com if you see any issues
Hello team,
Just a reminder that we will be taking the database offline tomorrow around 2 pm to perform maintenance on the indexing functions. We don’t expect this take more than 15 minutes, but please reach out to use at help@example.com if you notice anything out of sorts or have other questions.
[FYI] or [Action Requested] Subject Lines
Another trick I’ve started using is to add either [FYI] or [Action Requested] to the subject line of emails. For example:
“Database Update - 2 pm”Might be changes to
“[FYI] Database Update - 2pm”The [FYI] signals to everyone that this is just an information update, and that they don’t necessarily need to do anything. Similarly, adding “[Action Requested]” at the start clearly signals to the recipients that they need to do something. This trick helps the recipient more easily scan through their inbox for things that need their attention (or can safely be ignored).
CC Line = FYI Only
The last trick I’ll share is one that takes a bit more coordination amongst the team, but can also help folks figure out what they need to do. It takes effort because EVERYONE involved needs to remember that folks on the “CC” line of emails are there only to keep them informed. The folks on the “TO” line are there because they need to take action.
The big advantage here is it clearly calls out to everyone who needs to do something (e.g. the entire “TO” line), while also ensuring the folks who should be informed are (the “CC” line). This runs into trouble when someone forgets to put the appropriate folks on the appropriate line…. Things quickly get out of hand if you forget to add a critical person to the “TO” line and no one catches it.
All hands on deck
Sometimes something happens that needs the whole team to respond. When possible plan these out and ensure everyone’s there and involved.
Most of the time our work fits into the (insert your normal working hours here). This means we may or may not see the whole team we work with at any given time, and we can reasonably expect to be unavailable when we go home to do things like not work. There are, however, times when we need everyone to be available outside those hours. These situations tend to be big deployments, massive outages and other (thankfully!) non-standard events. While everyone knows they come up, they do frequently cause a lot of friction… after all, who wants to be dragged into the (virtual) office on a Sunday?
I’ve found a number of things help at least easy the pain of these events:
Plan it out in advance
When possible these events should be planned out in advance. This is easier to do on bigger projects where you can predict when major events (like a go-live) occur, but to some extent this can also be performed through risk planning. For example if you know a holiday is coming up and your system may be stressed, have more folks placed on call.
Planning it in advance helps everyone plan for it; now they can not take holiday and they can move other personal things out of the way. Planning it out also helps everyone see it’s an important part of the project/etc. And sets an expectation that its a required action vs. an optional event.
EVERYONE shows up
I usually serve as the project manager, so I’m rarely the one actually performing the go-live. This means my presence isn’t as critical as the developers, but I still make a point of being in the room as things unfold. This extends beyond my own personal sense of ownership of the project and into a sense of camaraderie. If everyone knows that everyone else will be there during crunch time, it’s more likely they’ll show up. Experiencing this stressful event together will help the team bond, and make it feel more like, well, a team.
Loosen protocol
Depending on the office culture this may or may not be a good tip, but loosening protocol (e.g. dress codes, eating at your desk, whatever) during these events helps to ease folks into it. It also helps deflate arguments about people being available as they can be more comfortable… or at the very least makes it more palatable (well at least I can wear my jeans).
Clearly define what needs doing
This goes with the “plan it in advance”, but you should (ideally) have a plan in place for what needs to happen during crunch time. This helps reinforce the “this is important” aspect of things, but also signals to your team that they aren’t going to be wasting their time. It also gives you a finish line to point at and keep driving towards.
Stay on Target
When someone brings up an off-topic topic meetings can get out of hand quickly. There’s a few strategies I use to help refocus things, but the single most important bit to remember is to acknowledge the statement.
I get a kick out of working on projects. You get to work with a talented group of people on a focused topic, learn new skills and (hopefully!) have some fun. You also tend to find a whole lot of OTHER things that should get done in the process, things that are really tempting to go work on. Things that should only take a moment, or are really important. Things that if you go and do will remove all focus on your project and make a mess of things. We call these things scope creep.
While scope creep certainly occurs, I find it most insidious during meetings. Typically we’ll be on track to deliver an update, or walk through some new functionality, when someone will come out of nowhere and ask about something unrelated to the project. Maybe it’s a known-bug in the code, or maybe it’s an enhancement that isn’t included in the scope. Or maybe it’s something entirely new. Regardless, the stakeholder is VERY keen on talking about it and wants it worked on… what do you do?
Since you’re in a live meeting, ignoring them entirely is basically impossible... after all, everyone just heard them bring it up. Others will also like jump in and add to the story, maybe it impacts more folks than the first stakeholder thought, or someone offers a “helpful” update on it that just lets things spiral more. I’ve found a number of different ways to address this situation, and while there’s always options the last is my preferred:
Shut them down - This can be an option if you need to immediately stop a discussion, but it has its risks. Shutting someone down risks damaging your relationship with them, and it may not actually get them to stop in the call… they may just end up continuing to bring up their topic, only now they’re aware you’re not interested in helping.
Let them continue - I tend to use this option… for a time. Redirecting or stopping the discussion too early can result in the individual being frustrated they aren’t being heard. Letting them go too long risks them taking over the meeting and feeling like they can just keep going.
Ask someone else to handle them - Depending on the scenario it may be best for someone not you to step in. This may be in cases where you don’t yet have a relationship with the stakeholder, or if this other person has a stronger/unique relationship they can use. The challenge here is having the right person available, and having them available to step in. This also prevents you from gaining the experience of working with the stakeholder and building a relationship - but may be more expedient.
Address their concern in the meeting - Being direct and addressing the concern in the meeting is useful in cases where it’s a super critical concern, directly related to the topic at hand or someone is incredibly escalated. This does raise the risk of the meeting getting taken over by this topic, and can result in that stakeholder feeling comfortable taking over other meetings.
Acknowledge their concern and defer it to another time - This is my preferred method of addressing out of scope topics that come up during a call. Acknowledging the concern is great because it communicates to the stakeholder that you understand there IS a concern. Bringing it up during the meeting also demonstrates you understand its (perceived) importance. The catch is to defer the issue to another time… taking time from the in-scope meeting to address this concern is counter productive, so moving it to some point in the future allows you to address the challenge and keep the current focus.
We’re human first
It’s very easy to forget that our coworkers are people too. Odd as it sounds, keeping in mind everyone is human first is incredibly important to building strong relationships.
Working in tech I’ve found it very easy to forget that the human element is still there. It’s REALLY easy to focus on how the systems interconnect, or which technology you’re using, or what error popped up… but it’s far more important to remember that everyone involved, the people using and complaining and working the tech, are human. That said, I imagine that many folks who work in tech don’t do it because they want to interact with folks, instead they do it because tech is amazing.
This split can make things…. Problematic. Think back to any interaction you’ve had with someone on a support team who’s been less than empathetic. Or hasn’t taken the time to get to know you… or cannot pronounce your name properly (or even cares). They may do a great job of fixing whatever problem you have, but the interaction still left a bad taste in your mouth.
Remembering that we’re all human also goes both ways. The customer asking for help should keep in mind that tech may have had to work overtime to fix a problem and really just wants to relax. That stakeholder who’s upset their deliverable will be a bit late needs to keep in mind that the project team is doing everything they can to help. That same help desk technician, however, needs to remember that the person calling in to get help for the same problem they’ve fixed 9123 times today still needs their help.
It can be incredibly hard to remember this basic rule, especially when things go sideways and the pressure is on. We’ll find ourselves falling back to demanding things, placing blame, and other behaviors that “feel good” because we’re able to vent, or we think we’re doing something that helps… when really it just signals we don’t see others as being people. Instead, this behavior signals we see others as not needing our empathy or compassion.
There’s a few tricks I’ve found that help keep the “we’re all human” aspects near the top:
Small Talk - While it seems like it’s just a time waster, small talk (how was your weekend, what’s up with those boxing gloves in your background, etc) help uncover small pieces of folks. This, in turn, helps make them less “This person is wasting my time” and more human.
Asking them for help - This is very useful if they don’t think you’re as human as you’d like. Asking them to help out with something, even something small, helps them see you as another person and not just a machine that pushes buttons.
Checking in - I’ll randomly reach out to folks I haven’t worked with in a while just to say hello, or to share an article I think they’ll like. This both helps keep our relationship going, but also shows them I’m interested in them beyond just the project we’re on. Some of my stronger relationships have come from this approach.
Dealing with crappy weeks
We all have crappy days/weeks/etc. The important thing is what we do with them.
We've all had a crummy day or week. You know those times when everything seems to go wrong and any bit of news is bad news? That week when a major deployment you’re managing hits a massive (or even small) snag? They hit all of us differently, from shrugging and moving on, to getting worked up emotionally, to taking it entirely personally. For most of us they’re not fun (especially if you feel like you’re responsible for the problem!), but there are ways to help get through them.
Separate the emotion
Emotions are great tools in many situations, but when we’re evaluating a problem they can get in the way. At the very least the emotions of "I screwed up", "I hate I have to XYZ" and others suck up mental bandwidth we should be applying to solving the issue. At worst they end up catching us in an endless cycle of "I'm terrible, I can't do anything".
The first step is to simply acknowledge that your emotions are getting the way. This is easier said than done, but feelings of anxiety are generally a good indication that emotion may be clouding things. Taking time to write down how you’re feeling can also help clear out, or at least minimize emotional responses. Having a friend or colleague at work you feel comfortable talking to is also incredibly helpful. They can both help you identify what the actual problem is and figure out good steps forward.
Keep moving and find the positive
During a crummy day/week finding small wins, or even making tiny amounts of progress, can help turn things around. Finding these wins gives you an anchor, something to point at and say “yeah, it’s not so bad”. These moments can also help improve your emotional state, helping to dig yourself out of that hole as well.
I find it easiest to review the current work I have and seeing what low-hanging fruit exists. There’s almost always something you can pick off in 15-30 minutes that will move the needle. Maybe it's something “too small” to do normally, or something that is a passion project. In this case it doesn’t really matter WHAT it is, just that it is something you can accomplish and feel good about.
Make a Connection
Talking through the crumminess can also be a big help. Ideally there’s someone at your workplace that you can speak with and just go over what happened. At the very least they can be a sounding board for you to just get everything out. More likely they can offer some insight into what’s going on, possible steps forward and the like.
Speaking to folks outside the office can also help, although they may not be able to offer the same insight as a colleague (if only because they don’t work with you). This, however, can be an advantage; they’re not also in the same situation and have a different perspective. At the very least you can unload a bit with someone you trust.
"Its broken"
Having a solid relationship in place before something goes wrong is incredibly important to helping folks navigate challenges.
Many times I’ve received a report that a specific system or integration is broken, only to go investigate and realize that nothing is actually wrong. Instead the root cause is a knowledge gap; the person reporting the problem doesn’t understand enough about how the system works so assumes it’s broken. This is a common challenge that takes up a lot of time, and fortunately one that can be mitigated quite easily.
Ensure new hires get basic training
As new team members join up they have a lot on their plate. They have a new team to meet, processes to learn and a job to do. Part of their onboarding, however, should include a basic outline of how the systems they use are intended to work. This basic knowledge will help reduce the risk they report something that turns out to be nothing.
Exposing new hires to systems will also begin building a partnership with them as early as possible. This will lay the groundwork for a positive relationship as they learn about you almost immediately. Having more touch points throughout a relationship will make it easier for them to reach out for help, and for you to help them.
Document everything (well, a lot)
Documentation is your protection against future questions and problems. You certainly don’t have to document everything, but taking time to write down and share out documentation on common challenges or basic information about your systems will help prevent users from reporting non-issues. Training users to go check documentation before they come to you will also help deflect tickets and up-skill your team. Frequently when someone comes to me for help the first thing I ask (assuming it’s not an emergency) is “What documentation did you check?”. This is both a (not so) subtle reminder that they should do that, but also clues me into what they’ve already tried.
Build solid partnerships
Getting to know, and understand, your end users is always a good idea. Strong partnerships make it easier for users to approach you with challenges or questions, and ensure they know who to go to for help. When an end user doesn’t have, or doesn’t feel like they have, a strong partnerships they’re much more likely to escalate issues or not report them. This can easily be mitigated by taking the time to get to know your end users.
While a large part of systems is working on tech, it is important to remember the importance of partnerships. The strength of these partnerships will help us get through challenging situations and can be a huge help in bridging knowledge gaps.
Knowing when to go "quick and dirty"
Sometimes there isn’t time or bandwidth or energy to do everything you “should” do. Knowing when, and how, to do something quick and dirty is critical to successfully pulling it off.
We’ve all been in situations where we know the “correct” or “best” way to do something, but not had the time/money/energy to go that route. Instead, we look for something that will still get the job done, but may not be as clean…. The “quick and dirty” method.
While we generally want to avoid going quick and dirty (it is, after all, both quick… and dirty) there is an argument for it being useful. Our standards and best practices certainly exist for a reason; experience (ours or others) tells us the best way to move forward. There are, however, times when we are unable to follow best practice, or when following it would result in negative consequences. These are the times when using a quick and dirty solution can be beneficial.
Making a decision to essentially ignore best practice and go this route shouldn’t be taken lightly. You, and everyone you interact with, needs to understand the tradeoffs. Generally there’s a higher risk of error and the end product may not be as robust as it would be had you followed the proper channels. Getting buy in, or at least ensuring everyone knows what the tradeoffs are, is absolutely critical to this route. You could go it solo, however, eventually others will notice that it wasn’t quite done “right” and will start asking questions.
Generally the quick and dirty approaches also necessitate additional testing or oversight to ensure something critical wasn’t missed. This degree of oversight may not be required with the best practices route, but is here since you’re basically cutting corners (hopefully the right ones!). You’ll need to ensure you’ve got extra bandwidth or support to help minimize the risk of problems showing up.
This approach can definitely help get things done… at least if you keep a close eye on things and know what you’re doing. My best advice when choosing to go this route is to ensure everyone on the team is aware that you’re choosing it. This has a few advantages, including getting more eyes watching out for issues and helping explain any odd side effects.
The biggest takeaway is to ensure you’re making the “quick and dirty” decision for the right reasons and that everyone is aware of your choice. Ideally you’ll never need to use it, but if you do a bit of planning can help save the day.
"I had to give" someone feedback
Feedback is can be hard to give or accept. It requires a culture that is open to providing and receiving it, and an open mind set that everyone can do better.
Feedback is critical to learning. Without understanding the impact our actions make we cannot course correct and become better. One of the best sources of feedback is our team; the folks we work with. Not only do they have an understanding of how we work, they understand something about the work itself. This gives them insight into how we can improve in specific areas, as opposed to generalities.
Understanding that feedback is important is one thing, but being able to accept it is something else entirely. Many times the phrase “I had to give so-and-so feedback” is used when describing giving feedback. This phrasing sets up a bit of an adversarial understanding. They’re giving feedback because they “have to”, because something went wrong that needs to be fixed.
Phrasing
This phrasing instantly tells everyone that someone screwed up. It tells the team that so-and-so made a mistake and the boss (or whomever) has to come down from on high to make sure it doesn’t happen again. This phrasing also puts the boss into the mindset of “correcting a bad thing” instead of “helping someone improve”. At this point it stops being positive feedback, and instead turns into something closer to a punishment.
The person receiving the feedback will also pick up on this difference. Going into a meeting where you “have to be given” feedback primes you for being in a defensive / negative headspace. It takes what should be a positive event - learning to become better - and shifts it into a negative event - being dressed down. While this certainly isn’t guaranteed - after all everyone will accept and interpret feedback differently - it certainly doesn’t help.
Part of how feedback is delivered is built into the culture of the company - do folks expect regular, honest discussions on how they’re doing and where they can do better? - or do they expect to only be told when they screwed something up? While this framework will certainly impact any feedback discussion there’s a lot a team, or even an individual, can do to frame feedback as a positive.
Use different words
As noted above “I have to give feedback” sounds negative, so just say something different.
“I liked XYZ you did, let’s talk about how you can get even better next time”.
“I’ve got some ideas on how you can increase your impact”
The intention is to present the discussion as a positive, “lets help you do even better” talk vs a “you screwed up, don’t do it again” talk. The words you use to transmit that intention are incredibly important… take time to think up a way to indicate you’ve found something they can do better, without sounding like a demerit.
Openly talk about feedback
Many times feedback is only provided during set times (generally around performance discussions). This not only guarantees it’s stale (ever had a manager bring up something that happened 4 months ago? Or not bring up anything at all?), it also clearly ties it to performance. This linkage is dangerous since it puts everyone in the mindset of “feedback had better be positive or I won’t get my bonus/increase/whatever”.
This also makes feedback a rarity, something that only happens at set points. This breaks any positive habits around feedback and instead sends you scrambling to look up what feedback is, how to write it and how to accept it. Knowing that it’s coming up, and that you and your team don’t regularly do it, just adds to the stress of it all.
Many of these challenges can be overcome by making feedback a regular, and open, thing on your team. The more the team experiences feedback, the more the team talks about the feedback and the more open it is will make it easier to give, and accept.
Beginning Background Knowledge
Understanding underlying concepts is critical to being successful. Not only will they help in whatever you’re up to now, but they can be applied across tools areas and people to make other ventures more successful as well.
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.
Speaking up when you find something
From time to time we’ll find something wrong in the systems we support. While dealing with it is important, spreading the word is also critical to success. Sure, it might be nothing, but it could also be a lot worse, and you’ll want folks ready to help.
If we’re really lucky on projects nothing will ever go wrong. Many of us, however, never get that lucky… Instead, we find ourselves looking at an issue or a challenge that blocks our project. Many times when this happens we shrug to ourselves and start trying to figure out a solution. This approach may result in us solving the challenge, however, it has a lot of problems.
Ideally when we find a problem we take a few steps before we start trying to solve it. These steps help ensure that we can solve the problem while minimize risk.
Let other folks know
As soon as we’re aware of a problem we should let other people know. While the exact folks we alert may differ based on the project we’re working on, our company culture and some other factors, we still need to reach out. I default to telling my immediate manager and anyone else working on the project, but other stakeholders may be included as well. This helps prevent them from being caught unawares, either by finding it on their own, or by having someone else tell them about it.
This also sets us up to get help in case we need it. While the problem may seem to be something we can handle at first blush, it’s always possible it will be something we can’t. While we can certainly ask for help after something has blown up, it’s easier to ask for help before things get too crazy.
Share information
Letting others know that something broke is the first step, but we also need to be proactively sharing what we’ve discovered. Initially this may be a short message along the lines of “I found XYZ error code in the system”, but as we go we need to keep sharing information. Providing regular updates has many of the same advantages as just letting others know; they won’t be surprised when someone else talks to them and they’ll be able to help.
This approach also lets us divvy up work, for example you can have other team members handle communicating with stakeholders while you handle the fix. Sharing information, especially with stakeholders, is also important to keep them calm. It’s highly likely that stakeholders don’t understand the technical ins and outs and just know “it doesn’t work”. Sending out regular updates helps maintain your relationship and makes them feel connected.
Keep Sharing Info
As you go through the process of fixing the challenge, keep sharing information. It’s really hard to provide TOO much info when something breaks. Continually updating throughout the life of the problem means no one is unaware of your progress, or if you need other resources for help.
Order Pushing
Non-technical partners need to be careful to partner with their tech teams… many times they end up just sending orders to their technical partners. This not only results in a weaker relationship, but many times results in a weaker end product.
I picked up a great bit of advice from a recruiter - “Recruiters aren’t order takers, they’re partners”. The intention behind this is you shouldn’t go to a recruiter and say “find me a lawyer” then walk away. Instead, you should sit down with your recruiter and talk with them about what you need. What problems are you trying to solve? Why are those problems, well, problems?
This discussion helps the recruiter figure out what you REALLY need… not what you *think* you need. The difference between the two can be finding a great candidate, and not finding anyone. By partnering with the recruiter, instead of just putting in an order for something, you raise your chance of actually solving that challenge.
The same paradigm exists with technical teams (and I would imagine with ANY relationship). Many times we’re just told to install some system or make some modification by a partner team. The thinking is that the technical partner is there to take care of the technical stuff… which is obviously to install that new system. This approach, however, drives us nuts.
Instead of just telling, or even politely asking, your technical partner for XYZ solution, it’s a much better idea to start a discussion with them. Let them know more about what pain you’re experiencing, what solutions you’ve identified, and then ask what the best path forward is. At the very least this will build your relationship with your technical partner; they’ll see you more as an active partner in the relationship and less of a burden. At best, this will enable your technical partners to find better solutions… in many cases solutions you didn’t even knew existed.
Changing from order pushing to partnering can be challenging, but, like many things, it gets easier with practice. The next time you have something you need from your technical partner, schedule a quick meeting with them. Let them know you’ve got a challenge you need their help on and provide some background before the meeting. This will likely intrigue them, especially if they’re used to being order takers, and give them a chance to understand what you need.
Instead of approaching the meeting in a “Here’s what I need” mindset, approach it in a “I need your help on X” mindset. This will shift your perspective a bit, but more importantly it will show your technical partners you’re seriously about partnering. Instead of phrasing things as a definitive - “we need X solution by Y date”, phrase it as a question “So we’ve heard X solution would be a good idea, what do you think?”. This opens the door for your technical partners to provide their ideas.
Most importantly this approach will demonstrate that you value your technical partners’ experience in their area. This goes a LONG way to building a positive relationship that will pay off in the future.
On Proactivity
When we discover a problem or error the first thing we should do is let others know. This not only gets more eyes on the problem, but helps avoid others being surprised and escalating the problem.
IT does a ton of work to support a company. We make sure billing systems accurately charge clients. We make sure our HR systems pay everyone properly, and we make sure our websites are up and accurate. All of these things are incredibly complex challenges that require a great deal of expertise and skills to manage successfully. Despite of all this work, however, IT is generally perceived as a reactive function; we just sit around waiting until someone reports a problem to us.
Certainly some part of our function is reactive… we do, after all, have a help desk and support portal to solicit tickets. There will always be some portion of our work that is reactive, we cannot, after all, be everywhere at once. There will always be SOME challenge that pops up in an area we don’t have eyes on. Just because a small percentage of our work necessitates reactivity, we shouldn’t accept only being reactive.. Indeed, there is a LOT to gain from doing the opposite, from being proactive.
Being proactive means a number of different things in tech. Most importantly it means letting others know that something is going on. Being in IT means we get an advanced view of how the systems are operating. We get dashboards, alerts and reports that most folks don’t get… and even if they DID get them they wouldn’t necessarily understand what they mean. This makes proactive communication the single most important thing we can do to increase out impact.
I take this lesson to heart and make alerting folks one of the first things I do when I find a problem. (The only step I would take before this would be to stop the immediate bleeding to help minimize the impact of the problem). This have a number of advantages:
Get ahead of the problem - Letting folks know about a problem before they find it helps prevent the wave of “OMG XYZ thing broke, help!” emails/calls/slacks/visits/telepathic messages that will come once folks realize there’s a problem. Your email just saved god knows how many tickets.
Builds partnerships - This is an important one! By showing your partners that you’re actively watching out for them you build trust.
Rallies the troops - Proactive alerts also let’s your team know that somethings happening. This gets more eyes on the problem, and helps solve the challenge more quickly. It can also help tap into other teams sooner since they’re now aware of the issue.
The good news about being proactive is it doesn’t take much effort… a few sentences describing what you discovered and that you’re looking into it goes a LONG way to avoiding an escalation.
Owning Mistakes
Mistakes… we’ve all got them, but not many of us own up to them. Calling ourselves out is scary, but helps us grow in many ways… it also helps us build stronger relationships and trust.
Mistakes… we all make them (citation needed), but not many of us are comfortable talking about them (or even sometimes acknowledging they happen). I find this lack of comfort to be a very interesting cultural outcome, since discouraging talking about mistakes means we’ll be making more. Even worse, it means the ones that do occur will end up hurting us more.
I recently had a great discussion with a colleague about how we can get more comfortable sharing mistakes (this is a fascinating topic that I’ll touch on in another post). In essence they were asking how we can go from a state of being fearful of owning mistakes and exposing ourselves to retribution to a state of feeling OK pointing out when I screw up. Their fear was centered around what would happen at our next performance review since we’d essentially be feeding our managers ammo on where we failed. While I completely understand this mindset (it’s one I imagine many of us have experienced… the manager who sees a mistake as something to hammer down on vs. an opportunity to improve), it’s one that I do not ascribe to for a few reasons.
Everyone makes mistakes
It’s a simple fact of our reality that everyone makes a mistake at some point (or several…). Trying to ignore this fact is essentially lying to ourselves… after all, we know that at SOME point we’ll make a mistake... and that our boss will make a mistake… and that everyone else will too. Since we know it’s going to happen, we don’t gain anything by hiding it. The best possible outcome in that scenario is no one finds out… worst case is someone does; in this case instead of asking how they can help fix it they’ll ask why you hid it.
You could also think of it this way - your manager knows at some point you’ll make a mistake. By exposing them, instead of letting your manager find them, you show that you can be trusted, that you recognize when you need help. This not only helps strengthen the relationship with your manager (see the third point), but also gets you in control of the conversation. Proactively bringing it up lets you frame the discussion as a “I made a mistake and want to avoid doing it again” instead of a “You really screwed up”.
Owning our mistakes gives us strength
Hear me out on this one.
The default assumption in many places is that individuals will not call out their own mistakes (despite everyone knowing mistakes are made). After all, it REALLY doesn’t feel good to stand up and say “I made a mistake”. Our ego (that voice inside that pumps us up/tells us how awesome we are/etc) is threatened by this, so we avoid that internal pain by not saying anything. This easy way out protects us in the short term, but can come back to bite us when the mistake is caught later.
Actively calling out our mistakes demonstrates to others that we’re aware of where we need help and where we can grow. It tells others that we’re human too, and that even us as the XYZ expert can stumble. By bringing your mistake into the open you not only make it easier to get help, you also make it easier for others to share their mistakes. This not only enables your growth by allowing others to help you improve, but strengthens the entire team by sharing those lessons.
Owning our mistakes builds relationships
One of the biggest advantages in admitting to our mistakes is the boost it gives our various relationships. As noted above, they also make mistakes, so knowing you’re comfortable sharing yours will make them feel better about working with you.
Being proactive and calling out when we’ve made a mistake lets our partners know we’re serious about helping them… after all, we could have just let is slide. Now this isn’t to say I just call up someone and say “Hey, I crashed the server, good luck”. Instead I’ll first figure out how to undo (or at least mitigate) the damage. This further helps my credibility as not only am I proactively alerting them to issues, I’m proactively fixing tem. This turns what could be a large escalation (imagine a situation where you don’t tell them about the mistake and they find out on their own) into a positive experience.
Not Easy
I’m not saying any of this is easy… indeed, it can be very challenging to stand up and say “hey, I screwed something up”. The benefits, however, outweigh that short-term discomfort. The good news, though, is that the more we practice this skill, the more we embrace being temporarily uncomfortable, the easier it gets.