Heads up!

No one likes being surprised.  Ok, that’s not entirely true, instead I’ll say like no one likes getting handed big news in meetings.  I’ve seen many meetings devolve into reactive damage control when some big announcement is shared that rocks the boat.  Maybe it’s a project update that folks weren’t expecting, or maybe it’s some change in The Plan.  Regardless, this information is new to at least some of the individuals involved, and they don’t take it well.

This results in most of the meeting taken up by explanations, of how we got to where we’re at, of why we made that decision etc. The time that should have been spent planning on next steps is instead focused on explaining what happened, resulting in a loss of time and potentially some credibility.

I’ve started to take a different approach.  Instead of waiting for a meeting or gathering to pronounce something, instead I’ll give everyone a preview, a heads up, before the call.  I’ll break down some of the ways I do this below, but in general they all have one thing in common - they eliminate the surprise factor.

Group Email

Sending a preparatory email to the entire group (or sub sets) is one great way to prepare everyone.  Since email can be very asynchronous and is easily missed I tend to use this approach when the update will be less impactful.  Email does, however, offer the advantage of being rather information rich - it’s easy to include links, documents, etc. to help bolster your message

Individual instant messages

If the topic is a bit more contentious/sensitive/etc, or if the stakeholder has more influence I’ll reach out directly with an instant message.  GIven the prevalence of tools like Slack, this can be seen as a more personalized approach.  It is also, at least in my experience, less likely to be ignored until later (like Email) and tends to get a quicker response.

Pre-Meetings / Calls

If it’s a VERY sensitive topic or highly influential stakeholder I’ll reach out to them via call/virtual meeting for a face-to-face update.  This is the most time consuming and hardest to do with larger groups, but can help you get the message across in the most effective way.  It also demonstrates that you take this seriously which can help further blunt any impact.

Keeping up awareness

Projects tend to do a great job at the start by letting everyone know what's going on. Stakeholders are given demos, requirements are gathered and everyone is on the same page. Then things begin to drift. The project team may know what's going on, and updates may be sent out... But many are likely to lose track of what the project is for, and what the benefit is. Keeping all those moving pieces up to date and, and ensuring everyone is aware of the various changes can feel like an impossible task.

The folks working on the project are the most likely to know what's happening... After all, they're doing the world. That said, project teams can be big, and some individuals may not be as up to date as others. This is only amplified when multiple teams are involved as each one will have its own perspective on everything. When outside groups, like consultants, are brought in, this can only add to the challenge of keeping everyone updated.

The further any given person is from the project work, the less they'll likely follow up on it themselves. This raises a significant risk that stakeholders will forget what they're getting. At best this requires a realignment... At worst it kills a project.

There's a number of ways to counteract this knowledge drift:
Regular updates - emails and reports are the easiest, and should be sent out anyways. Ensuring they're easily understood is important, so asking for feedback is critical. Having the right audience is also important as different stakeholders will need different info. Your VP isn't as likely to care about minute bug details as your developers.

Recorded demos - recording updates and sharing with the team is one way to visually share updates. This doesn't have to be a long demo, just enough for folks to see what has been accomplished. One big advantage of this approach is being able to compare updates over time.

Live reviews - Agile's sprint reviews are a great tool to borrow for any project. These meetings are specifically to update stakeholders and to solicit feedback. These live calls also help build rapport between customers and the project team.

Metrics Storytelling

A large part of project management is collecting and sharing metrics on how things are going.  This could be the number of test cases completed, amount of code developed, or any other quantifiable aspect of a project.  Sometimes the numbers tell an obvious story - we completed everything, all the code is done… but sometimes the numbers tell a more subtle story.  To me this is much more interesting because instead of just sharing numbers, it requires me to dig in and find a story to tell about those numbers.

Sometimes the story isn’t “we were able to complete all our objectives this week”.  This message can be hard to pass along since it isn’t the best outcome; actually completing the work.  Instead, we have to dig in and see what other positives may be going on.  Here’s two additional things I look at for reporting:

Momentum

Depending on the task that has to be accomplished it can take some time for things to get started.  Test cases, for example, may have a delay between “started” and “completed”.  This can result in completion metrics being relatively low in the first parts of the testing cycle, with them eventually catching up as cases are closed.  

In these instances, I remind everyone to not only focus on the percent complete, but to take into account the “in progress” numbers as well.  Generally these will begin converting to “passed” and will result in success.

Error Resolution

Despite the best setup possible, errors also pop up in testing.  While these do represent more work and need to be dealt with, they do represent another source of positive metrics that can be shared.  While initially reporting on the number of new errors can be stressful (after all it’s MORE work), reporting on how quickly the team triages and resolves them is a positive.

I see it as a positive in two ways, first the team is actively improving the process by IDing errors, and two, the team is fixing them (hopefully quickly!).  Both of these can be presented as a value add vs. a distraction.

Both momentum and error resolution rates provide a lot of great stories.  The secret is just to keep your eyes on and be able to point out positive aspects that help keep things moving.

On taking notes

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

It keeps me engaged

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

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

It provides instant value

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

It covers your (you get the idea)

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

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

No Update Updates

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

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.

Raising Issues Early

Raising issues early

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

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

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

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

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

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

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

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

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

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

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

The Utility of Feedback

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.

We’re human first

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.

"Its broken"

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.

"I had to give" someone feedback

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.

Speaking up when you find something

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

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

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.

Don't play telephone

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:

1. Get in direct contact with the person impacted

2. Let the reporter know you’re reaching out the impacted person 

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

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.

Planning to (not) Fail

Failing to plan

is planning to fail

It’s a rather straightforward idea, and I’d bet most of us have heard that quote at some time, but it seems like many of us don’t really understand it, or at least we don’t put as much energy into it as we should.  Planning is one of those things where you can do TOO much of it; indeed, many daily tasks don’t really need much, if any.  That said, anything bigger, or more complex, definitely benefits from more planning.  To help keep things simple, I try to break planning into three areas… from smaller to bigger - my week, projects and my career.

---

For your week

Before the week begins (generally on a Sunday) I take time to review what’s coming up.  This involves going over my calendar, project tracking system (e.g. Asana, JIRA, sticky notes, etc), emails, etc. to see what’s coming up.  I spend a bit of time reviewing my recurring meetings (one on ones, team meetings, etc) just to ensure I’m up to date on the agenda and plan, but I particularly go through my non-recurring meetings.  These can sneak in over time, so I’ve found it’s very important to dig into them.  Where possible I rearrange things to make better sense of my time, for example I cluster 30 minute meetings to give me more blocks of time to work, or I bow out of things I”m not needed for.  This helps me better focus my time during the week, and lets me identify areas that need particular help.

For a project

Individual projects also get their own planning attention.  This can range from scheduling out meetings with vendors, to thinking through how to handle various stakeholders, to mapping when deliverables are needed.  While it can be annoying and a bit time consuming, the energy spent on continually improving project plans has consistently paid off in terms of better outcomes, less stress and avoiding mistakes.

I make a point to put project planning onto my calendar on a weekly basis as an event.  This ensures I’ve got the time blocked off, and also lets others know I value and prioritize this work.  I also send out weekly project updates (depending on the project these can be as short as a one-line update or as long as a page).  Writing these not only keeps everyone up to date (assuming they read them!), but also forces me to look at my portfolio and really understand what’s going on.  Time time helps support my overall project planning as I’m constantly examining what’s going on

If you don’t know where you are going, you’ll end up someplace else.” ~Yogi Berra

For a career

Planning where we are going in our career is one of the longest things we can plan for.  These types of plans generally span years, if not decades, and can seem very daunting to put together.  I try to break them down into very distant, fuzzier plans, and slowly bring up the clarify and focus as I get closer to today.  I tend to not get any closer than 1 year from now, as project or weekly planning can handle that time frame, but understanding the bigger picture is critical to the rest.  How can I decide which project to go after if I don’t know where I want to be in a year or five?  Having that knowledge gives you a lens to focus your efforts, something that helps sort through everything and provide guidance on what you should do to attain your goals.

Bring Solutions

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

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

---

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

Bringing solutions

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

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

What’s in it for you

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

You Gotta Ask

“Better to be thought a fool for a moment than to remain ignorant for your lifetime”

I’m not 100% sure where I first heard that quote, but it has helped me immensely both in my personal and professional lives.  We’ve all had those situations where we’re not 100% sure what someone said, or what they mean… or even if they’re talking to US.  We’ve all also had that lingering thought of “well, I don’t want to sound stupid….”, so instead of asking a question, we keep our mouths shut.  And we’re lesser for it.

---

Our ego’s are incredibly annoying things.  While they do have some positive qualities (helping us acknowledge when we succeed, being a CLEAR signal for failures, etc), here I’m more interested in their negative qualities as it relates to the quote above.  Specifically, our fear that our ego will be hurt if we ask a “stupid” question.  There’s many thoughts on “stupid” questions (see if you can figure out which one I ascribe to based on the quotes), ranging from “there’s not stupid questions, only stupid people” to “there’s no such thing”.  Regardless of one’s philosophical approach to them, however, we still fear asking one, because it can change how others perceive us.

Speak up

This perception is heavily influenced by the culture of the group we’re with (e.g. teams with higher psychological safety will likely perceive less threat by asking questions), but that inner fear can still exist.  Knowing how to overcome that fear is an essential skill, that not only helps you get better at asking questions, but can avoid some amazingly terrible situations.  In each of these examples (and by no means is that a complete list!), taking a few moments to speak up can avoid a world of hurt.

For example:Not getting clarification on what someone needs from you… then delivering the wrong thing.

• Not asking for follow up information on a potential risk… and then having to deal with that risk.

• Not asking how to take your medication and taking the wrong dose.

---

In addition to help avoid potential downsides, speaking up and asking for clarifications also helps improve how others perceive you.  Asking questions about the topic at hand tells others you’re paying attention to what’s going on.  (While I’d like to think everyone always pays attention in meetings, somehow I don’t think that’s the case).  By extension, this signals you’re interested in the topic, which is always a good thing to show.  

Asking questions also helps others understand your level of comfort and experience with the topic.  I’m not suggesting that asking questions will make others think you’re inexperienced and a fool, but rather the questions you ask will help them know where you best fit into the solution.

Personal Growth

Questions will also help you expand personally.  Not only will you learn something new (or avoid potential problems), you’ll get valuable practice asking questions.  This sounds silly, but the more you ask clarifying questions, the more comfortable you’ll get with asking questions.   This in turn, will give you more access to knowledge, and help you improve overall.  So ask away, you can never chase away too much ignorance.

Keep communicating until they tell you to stop

Communication, like breathing, is one of things that humans must absolutely do in order to survive (citation needed).  Since we’re born until we die we’re constantly communicating something, in some way.  This means we’re effectively practicing this skills all the time… which only makes it more interesting that we’re all (generally) so bad at it.

90%

They (PMI in this case) tells me that 90% of project management is communication.  I would further this, and say that 90% of our jobs, and general existence in reality, is communication.  We tell our loved ones we miss them.  Our children communicate that they’re hungry.  Our co-workers communicate status updates.  Even NOT communicating can be perceived as communicating (after all, ignoring someone tells them something…) (also, if you don’t notice someone is trying to communicate, you’re effectively communicating to them you’re oblivious).

On the plus side, we use this skill ALL the time.  This would suggest that we should be getting better at it as we go.  On the downside, we’re rarely consciously trying to improve this skill, meaning all that practice time is effectively wasted.

---

Shooting free-throws in basketball is a great analogy.  Once approach would be to just continually shoot the ball again and again and again.  Another approach would be to shoot the ball, then stop and honestly think about what you could do better (or not do at all).  The first approach might get you more repetitions, however, the second will give you conscious improvement.  Sure, it’s a bit of a pain to stop and critically examine yourself (not to mention ego-brusing at times), but the feedback gives you much better results.

Communication is no different.  Many of us get TONS of reps in during the week… but many of us also fail to stop and think about how we can make those reps better (When was the last time you asked yourself if you’re communicating the right way?).

Repeat

One of the best pieces of advice I got on how to improve communication is to simply keep doing it until someone tells you to stop.  Need help with a project?  Keep bringing it up in different ways at different times until you get help.  Need to let someone know when you’re available and you’d like to talk?  Keep talking/texting/emailing until they get the point.  This doesn’t mean send them an email every 10 seconds, but keep up the communication until you’re heard, and you know they heard you.

The good news is this skill is relatively easy to practice.  The next time you need to communicate something you feel is important, pick at least 5 different times (and ideally different ways) of communicating that.  One example of this:

1. Bring up your idea/need/etc. During a team meeting

2. Send a followup email immediately after the meeting.

3. Drop a slack message to folks the next day

4. Two days later send another followup email

5. The day after that bring it up in your meeting again

---

The point here is to ensure others received, and more importantly, understood, your message.  By hitting them at different times in different ways you help ensure you cut through the noise (e.g. the 10000 other emails they have), and solicit any questions.  And if all else fails, at the very least you have a great “paper” trail of your attempts.