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.
Don't play telephone
Telephone is a great game to play as kids, but playing it at work presents a whole host of challenges. Cutting out the folks in the middle and finding the source of the request is critical, as is your followup.
Do you remember a game called “telephone”? You know, the one where a group stands in a circle and one person whispers a message into someones the next person’s ear, then they into the next until it gets back to the first person? The message changes… sometimes folks add in parts on purpose, and sometimes they just mis-understand what they were told. The end result, however, is the message changes in (hopefully funny!) way.
In the game, that’s the point! It’s fun to see what happens when multiple people are in the middle since you never really know what will come out the other side. When you’re at work, however, this communication drift causes a LOT of problems. This lesson will go over how to identify when you’re in a game of telephone and how to constructively resolve it.
There’s three things you want to do in these situations:
Get in direct contact with the person impacted
Let the reporter know you’re reaching out the impacted person
Educate both parties on what to do in the future
Step #1 - Connect
Getting in direct contact with the person impacted can be harder than it seems, as sometimes there is more than one person between you and them. Frequently I see 2, 3 or sometimes more people in the chain, all “helpfully” passing along a message to someone else. Unfortunately, as our game showed us, each node in communication introduces a chance for an error to be introduced, and the drift from the original message only increases each time it’s passed along. To help with this, the first question I ask myself when I get a new request, whether it’s an email, instant message or ticket, is “who is this REALLY coming from?”. For example, if one of my data analytics partners sends in a request to get a new team member setup with access, that new team member is really the person how needs help. In that case, I’d connect directly with them to understand their needs, versus the perceived needs that are being reported.
Frequently the folks in the middle also don’t fully understand the request; they are, after all, filtering it through their own experience and ideas. This can result in your understanding of what needs to be done being drastically different from what is needed. Identifying, and connecting directly with, the originator of the request helps mitigate this risk substantially.
Step #2 - Update
Once I think I’ve identified the person impacted, I’ll connect to them directly, and also let the reporter know what I”m up to. That second bit is critical; if they are unaware I’m helping they’ll keep coming after me. Some quick examples:
If it’s an email - I’ll move the reporter to CC or BCC and email the impacted person directly.
If it’s an instant message - I’ll either let the reporter know I’ll be in touch with the impacted person, or get both of them in a group message
If it’s in person - Similarly to an instant message I’ll let the reporter know what I’m up to, then connect with the impact person directly.
Step #3 - Educate
Keep in mind the reporter is just trying to help their colleague out, they’re not intentionally making things harder for you. This makes these situations great learning opportunities. As part of your communication, you can let the reporter know how these situations ideally should be handled. While the exact approach will differ by organization, I prefer for the person impact to be the one to report the issue. Sometimes this isn’t possible, maybe they’re on vacation or unavailable. That’s totally OK. In those situations someone else should report it, but clearly indicate they’re passing along a message and include the impacted person on the email, message or thread. This makes it significantly easier to follow up, and ensures everyone is aware of where they are.
Some examples of language I’ve used:
Example #1
“Hey Tim, thanks for letting me know Rebecca is having login issues. I’m going to connect with her directly. I appreciate you forwarding in her request, but please encourage folks to use our help desk (link here), it makes it a lot easier when they reach out directly”.
Example #2
“Hey Tim, Rebecca let me know you’re having problems running your TPS report. More than happy to help out, but it would be helpful if you report these directly in the future.”
Being better at technical communication
Communication is a challenging skill to learn that is only made more complex when attempting to communicate about technical topics. Making time to understand how to better technically communicate is a critical skill, especially as more and more folks end up in these fields.
I’m sure you can think of a discussion or email thread that you couldn’t really follow due to its content. Maybe it was with a software engineer describing their code, or a lawyer explaining the complexities of labor law. Regardless of the topic, parts flew over your head and you had to spend a good amount of effort going back to understand what happened. This confusion is a breakdown in communication; specifically technical communication.
Technical communication is just communication around specialized or technical topics. In addition to all the rules and guidelines around normal communication, it has the added complexity of needing to convey specialized knowledge. This is particularly challenging when the audience doesn’t share the same background concepts or ideas (such as when you’re trying to explain how your system works to someone who’s never used it). This is further compounded by the specific terms and acronyms that are used in different fields.
I see many individuals running into challenges when they either don’t know how to apply technical communication skills, they apply them at the time or in the wrong way. When this happens one, or both, parties, will miss important details of the message (at best) all the way up to damaging their relationship with that team. More frequently this results in poor communication that requires additional followup to clarify what is meant. I can think of many email threads that simply. Wouldn’t. End. because one or multiple individuals on it were not able to effectively translate their technical concepts.
In addition to needing to apply technical communication during synchronous communication - phone calls, zoom calls and the like - technical communication also needs to be applied to asynchronous communication - emails, documentation and bulletin boards. Asynchronous can be more challenging since the reader only has the text that’s in front of them and there’s no chance to clarify questions. In general the approach I take is to write my documentation so someone with NO background would be able to follow along. Assuming that my audience has no clue what I’m talking about helps me avoid assuming they’ll know background ideas and makes it a lot easier to include the right level of information.
Some other things that help with technical communication
Define acronyms immediately - The first time you use an acronym, either spell it out and put the acronym in parenthesis “Three Letter Acronym (TLA)”, or do the opposite “TLA (Three Letter Acronym)”. This gives the reader a good reference.
Identify and define specialized terms - Depending on the format this could take the form of a glossary, an appendix or just some lines at the top of an email. For example “Active Directory is a system we use to manage access and data about our users”.
Include Reference Material - Depending on the audience and format I also like to include links, attachments, photos etc. to help provide more context. This could be a general systems diagram so everyone knows how the systems interconnect, a vendors documentation, or anything else to help your audience understand what you’re talking about.
On Perseverance
Perseverance, or the ability to keep going, despite hitting brick walls repeatedly is a great skill to have. Having it means we can weather unexpected challenges more easily, and makes it easier to reach if they crop up.
Perseverance, the ability to keep going despite hardships, is a very important skill to learn, and something I recently had a chance to practice. On Friday I took what should have been a 4 hour exam… which lasted 5.5+ hours. Instead of starting this (stressful) exam that I’d spent 8 months preparing for immediately, I was greeted with a black screen and a spinning beach ball. Despite figuring out how to get help, I ended up waiting on hold for tech support. For 2.5 hours. Talking to chat bots. In circles. At several points I considered just calling it and rescheduling (something that would set me back another two months).
Instead, I took a moment to breathe and figure out my options… Everything basically amounted to waiting on hold for chat support… or phone support… or chat support again… and again and again. I figured if I could just get the RIGHT agent on the phone, I’d get in and could take my exam. It just took my not giving up. Eventually, 2 hours later I found that agent, and my exam started. 8 questions in it immediately broke. Again. This was another chance to give up. I’d already spent half my allotted time not answering questions, and who knows how much longer it would go on for. Instead I chose the perseverance route; apply my previous strategy of reaching out again. And again. And again.
This was not as easy as it sounds. Whatever chat system I was tied into would automatically send me a message “from the agent” every 3 minutes. It was something like “Thanks for your patience, I’m still looking into your issue”, that just repeated. After 40 minutes of non-responses I began asking if anyone was actually there, and they could type in literally ANYTHING other than the stock message to let me know. Eventually I hung up on that chat and opened another, and kept doing that until I found someone who could help me. The same thing happened to me on the phone; after 30+ minutes on hold an agent would pickup, tell me they’d fixed the issue, then hang up. I even asked one to stay on the line until I could confirm the issue was resolved, but they said they couldn’t.
Long story short I ended up passing that exam…. But not after getting a hands-on lesson in perseverance. In this case it expressed itself in not giving up, in not saying “I give” and quitting, in continuing to look for an answer despite every avenue being non-helpful. This is hard stuff… it would be SO much easier to just reschedule or do it later, but it wasn’t worth it to me. Not only would I have to go through all the anxiety of prep AGAIN, all the waiting AGAIN, I’d have wasted almost 3 hours of my life on hold.
Situations like this crop up all the time. We’re in meetings that we’re bored stupid in. We have to work on projects that just… never… die. Something fails and we lose several hours of work that we have to re do. The challenge is not to get stuck on how annoying/stupid/etc the situation is, but instead of focus on what’s important; being present, completing our work, solving the challenge.
Domain Expertise
Knowing the system is absolutely necessary to supporting it. Know the domain it exists in, however, vastly improves our ability to manipulate and design the best way to use that system. Take time to learn that domain, meet the experts in it and if you can, become one.
In the tech world we tend to focus on learning the tech. Those of us working on any given system or tool want to drill into how it operates, what features it has and when they should be used. This is true for NetSuite, or AWS, or InfoSec. And there’s nothing wrong with making technical skills a focus of our job; after all we ARE the systems folks!
Learning technical skills, however, shouldn’t (can’t!) be all we focus on. We also need to stretch ourselves to understand the domain our systems exists in. For SalesForce this would involve learning how sales teams operate. What does any given Sales rep need to do or know on a monthly/week/daily/hourly basis? Why do they (dis)like any particular aspect of SalesForce? What policies does the Sales team have to follow?
While certainly not directly related to the system, questions like this help inform WHY and HOW the system can be used. We don’t need to know as much as our customers about their process, but the more we know, the better we’ll be able to support them (personally I became a license health care broker to help accomplish this).
Gaining Domain Experience
There’s many ways to help expand our domain expertise. The simplest is simply through osmosis. As we work on any given system, we’ll naturally learn a bit about the domain it exists in. Working in NetSuite, for example, will expose us to charts of accounts. SalesForce will expose us to a closing process. Workday will expose us to hiring. This is a natural first step for many folks since it’s basically impossible to miss; you can’t learn the system without picking up SOMETHING. That said, this is only the beginning.
Getting to know your customers is another way to improve your domain knowledge. Get them involved in testing, or have them show you how they use any particular screen. Sit in on their team meetings and get a feel for how the team behaves. This first-hand experience has several advantages, including giving you more domain expertise, but also helps build connections and puts a face to everyone. Knowing Jimmy in sales is much more impactful than knowing some random user has problems.
Training like your customer-base takes this a step further. Go and get whatever certification or accreditation they need (like my example of becoming a certified benefits broker). This will not only extend your baseline knowledge of that particular area, it will help you see things the way they do. In the care of a credential or training you’re also rounding out your own experience and possible exposing you to new concepts. This has the added benefit of (generally) getting you some street-cred with your customers.
Going even deeper you could even BECOME your customer. I very rarely see folks taking this path since it is very intense and time consuming… but it does offer the most in-depth way to gain experience. For example a software engineer might choose to implement a live customer, or a Salesforce rep may take some inbound calls. While this does crank up the intensity a bit, it will really help show you what’s important, or annoying, or impactful for your customer base.
While there’s nothing wrong with not taking these steps, I find they help individuals make better informed decisions and allows them to develop better solutions to challenges. Flexing ourselves this way also has the side-effect of helping us build better relationships, and learn something new about our tool.
Broken Comb Skillsets
Broken Combs have expertise in a few areas, in addition to general skills. This makes them a great addition to any team since they can fill multiple gaps. This can, however, result in them getting spread too thin…
A broken comb skill set refers to the shape a comb with missing teeth makes - some vertical lines and a horizontal one (and certainly doesn’t suggest the individual is broken!). They’re essentially an extension of the “T” skill shape, multiple in-depth areas with a (potentially) broad general base. This type of skillset is very interesting to work with, as they have multiple areas of expertise. While this is not without its challenges, broken combs can be very flexible and bring immense value to a team.
The upside of a Broken Comb
Broken comb skill sets offer the advantage of multiple focus disciplines. Due to these areas they can potentially reduce the need to bring in additional team members, or negate the need to bring in outside help. By excelling in multiple areas they provide a lot of flexibility and are able to make a big impact on projects. This is especially true if their areas are related (your tax and finance systems, for example) as they are able to easily support thos areas and understand the interconnections between them.
In addition to their areas of depth they are also similar to how a “T”-shaped skillset with a broad skillset of more general skills. This general knowledge helps them bridge gaps between areas (even their own), and allows them to get a better handle on the big picture. The mix of focus areas and general skills can make for some very versatile individuals, capable of not only handling technical areas, but also “softer” skill sets.
The downside of a Broken Comb
While not a rule, despite a Broken Comb shaped skill sets offer deeper expertise in multiple areas, it’s likely their depth isn’t as great as an “I”, or even a “T”. This is simply due to not having as much time to dedicate to each one as those other types. This may result in overconfidence, or stretching too far in those areas. Have multiple focus areas can also detract from their overall impact as they may get pulled in too many directions to be truely impactful.
Similarly, the breadth of general skills may be limited as a lot of energy is put onto the areas of focus. This leaves less capacity to developing general skills, or to developing them deeply enough to be at least minimally effective. This can result in broken combs having narrower general skillset than their “T” shaped counterparts.
Managing a Broken Comb
Understanding what any given Broken Comb’s focus areas are is important to fully using their talents. Take time to understand where their interests lie, and what areas they choose to focus on. This will not only allow you to be utilize them on projects, but also help the continue to improve their focus areas. Knowing how wide (or narrow) their general skillsets are is also important. Their wide range of skills can make it seem like they can handle anything, but knowing where the edges are is critical.
Broken Combs can also fit in incredibly well between teams, especially if there are folks with I-shaped sklil sets on either side. A Broken Combs multiple focus areas allows them to (relatively) easily translate between groups as they share an understanding with each side. This can also open opportunities to expand someone else’s skillsets and the Broken Comb can relate to them, and the new skill.
If you’re a Broken Comb
Take time to understand where the edges of your focus and general areas are. Knowing your areas of depth allows you to further exploit and build those skills, and knowing your general areas will make it easy to see how things connect. It will also help you better communicate to your team what you can do… and help avoid situations where you’re expected to be an expert but really don’t know.
Having multiple focus areas (plus generalized skills to round you out) will make you very popular. Be careful that you don’t get pulled into too many different directions. Take an active approach in shaping what work you take on to best maximize your interest and impacts.