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.

Stay on Target

Meetings are (generally) useful things.  They allow groups of individuals to get together and figure out a solution to some challenge.  It could be a small thing, like what to get for lunch, or a big thing, like how to send someone to Mars.  Regardless of size, however, it’s incredibly important for them to stay on target.

Humans are, by nature, a bit chaotic.  Many things demand our attention, so it’s no wonder that meetings can wander all over the place as different folks bring up different topics.  This can quickly turn a potentially short productive meeting into a complete waste of time that leaves everyone wondering why they came.  I’ve found a two things that have helped me keep my team on track:

Share a clear agenda - This seems like a no brainer but I constantly find myself with invites to vaguely worded meetings without an agenda.  (As an aside I tend to decline these and ask for an agenda before I accept).  At best this leaves the invitee’s confused as to what is for and wondering why they should attend.  At worst, individuals will simply ignore the invite.  

The Fix : Take a few moments to add bullet points to your meeting invites.  Something as brief as the following can be enough to keep folks on track:

• Review project status from yesterday

• Update risk catalog

• Determine schedule for testing

Keep everyone focused - A (generally) positive thing about meetings is new ideas will come up.  Someone will remember some item, or bring up a related topic that could benefit the group.  The problem is these ideas distract from the purpose of that particular meeting.  Yes, those ideas are important and should be addressed - just not right now.  If unchecked this can easily drag a group down.

The Fix : Don’t be afraid to ask folks to continue a specific discussion later. This could take the form of a quick meeting after the current one, an instant message, an email, whatever, just get them to have the chat later. Clearly acknowledge their idea and it’s importance, but get back to the topic of the call.

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.

You work, I work

I’ve spent a lot of my career on various project teams.  I’ve been on large, multi-national deployments, handled startups getting their medical benefits for the first time, run projects entirely on my own and been part of much much larger teams.  While they were all very different, to me they all had one thing in common; the project team.

Teams were obviously composed of different people at different times and places, but all projects have some kind of team.  How that team functions is critical to the success of the project; a dysfunctioning team increases the risk of the project going poorly.  This isn’t to say a perfect team will always have a successful project, but a dysfunctional one will be at a much higher risk of failure.  

As the project manager (or really any non-SME / technical role) I tended to be close to the work, but not close enough to do a lot of it.  At times, I also have to be the one to decide if the team needs to work late or work over a weekend or a holiday.  Over time I’ve always followed a very important rule when I make those decisions ; if anyone on my team has to work extra hours, I will be right there with them.

Essentially this means that if any of my team is working a weekend (or over time) so am I.  At the very least I’m in the office with them (or online and on slack) to simply be around them.  This is incredibly important because it shifts the dynamic from “I’m telling you to give up spare time to work” to “we’re in this together to get it done”.  I’ve found this not only helps break down push-back to working extra, but it can help inspire others to volunteer to pitch in as well.

I also find this a great way to build space for myself to take on tasks I “don’t have time to do” otherwise.  This time is focused on the project my team is doing, but can be used to catch up on other aspects like improving documenting, reviewing lessons learned and updating plans.  For me, it all boils down to the team aspect of a project team.  We’re all in this together.

Let others do their jobs

I’ve had many transitions in my career; points in time where my job shifts a bit and I now get to do something new.  Doing something new also generally means no longer doing something old though, and this can be tough.  Tough, because you’re used to doing it.  Tough, because everyone knows YOU do it.  Tough, because you don’t think someone else can.

Letting go of those things is hard, but it’s also important to our own development, and maybe more importantly, for others to develop.  If we never let go of the things we used to do, the things that we’ve grown out of, we’re essentially cheating others out of the same opportunity we had to learn those skills.  If we step in and keep doing the same work we used to do, not only are we spending our time in an area that won’t help us grow, we deny others their chance to grow.

I’m not saying we don’t help someone who’s taken over an old role.  We certainly need to help set them up for success by giving them support, teaching them the ropes etc.  What we want to be careful of, however, is continuing to do that job even after we’ve moved on.  In addition to preventing them from learning, we also distract ourselves from our new role.  There’s only so much time, and any minute spent on the old role is one less spent on the new one.

I see this frequently happen when a new ticketing system and team comes online.  The group that used to do the work doesn’t want to let go.  They’re concerned the new system won’t track everything, or that the new team won’t be up to snuff.  There’s almost always SOME amount of disconnect as the new team comes online, but those aren’t just negative experiences.  They’re also opportunities for the new team to learn how to improve.  Making mistakes is one of the best ways to learn, and allowing others to make them is beneficial in the long term.

I’ve found that focusing on the new work, and checking in regularly with my replacement, is a great balance between the two.  This allows me to excel in my new area, but also keeps a communication channel open in case something is needed.  This helps build a strong relationship that makes the transfer more seamless, and easier, than if I stayed entirely involved.

Ownership

I’ve always felt some degree of ownership of the work I do… after all, it’s a direct reflection of who I am and what I do.  Ownership to me is very similar to accountability.  Both ownership and accountability involve being invested in something and helping drive it forward.  They both involve having to understand as much as possible about that thing as you can, and they both involve being bound to the outcome.  Where they differ, however, is in where they originate.

Accountability, I find, is generally external.  We're told by our boss/teacher/partner that we're accountable for the project/assignment/chore.  Accountability is something that someone else puts on us to complete a task. This isn’t a bad thing, as it helps us find our target and drive the project forward.  It provides excellent external guidance on what we should be doing, which helps us shape our approach.

Being external, however, has its downside.  External drive is harder to sustain as it requires someone else to push us along.  Generally this can kickstart internal motivation, but sometimes it doesn’t, and suddenly it requires two people to do the task.  External forces can also push us in a direct we maybe don’t like.  Perhaps it’s a project or task we just don’t want to do.  This makes it harder to get motivated and follow through with completing the task.

Ownership, I find, is generally internal.  We tell ourselves we're responsible for that thing,  and it is up to us to beg/borrow/steal to make it happen.  Personally I find that once I understand what is needed I tend to assume ownership of projects and the like quite easily.  I take a look at what is being asked of me and I make myself responsible for the outcome.  If it doesn't happen it's not because of some external force (something being unavailable, someone missing etc, it's because I didn't get the resource I needed, or I didn't ask for help.

The plus side of ownership is the feeling of having a stake in the game.  I’m part of that thing, so I’ll do whatever I can to make it happen.  The downside of ownership is it can be hard to feel.  Sometimes I just don’t feel like I’m an owner.  Personally, I find it the most frustrating when others on my team have different levels of ownership; some are all in, some part way and others couldn’t be bothered.

I find the best way to help others invest in ownership is to speak to my own experience with it.  Letting my team know that I stay up late working on the project, or showing them how I go the extra mile(s) to get something done helps spark that feeling in them.  From there, it’s just a matter of encouraging them to continue to invest in their ownership.

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.

Frameworks

Frameworks

Projects are a funny thing.  Everyone’s been on one at some point in their lives (even if it’s as “simple” as planning a trip), which means everyone kind of knows what to expect.  This is good, because it means we all have some general idea of what the next steps are… but this is also not good because we all have our own assumptions / pre-conceived notions of what to do when.

Why This is good

All projects follow some version of ideation, planning, execution and completion.  Exactly how that’s done differs, (for example Agile iterations over that execution and tinkers with planning while Waterfall sets it in stone), but all of that happens in one form or another.  This makes it (relatively) easy(er) to translate our experience from one project to another, even if the exact topic or domain differs.

This is a good thing since we all have at least SOME shared experience.  We’ve all had that moment of terror when we forget a detail and have to scramble to fix it.  We’ve all had that moment of satisfaction when the project or milestone is done and we can check something big off the list.  This makes joining a new project a little bit easier; we’ve seen how it’s done.

Why this is really not good

This familiarity, however, has a downside.  It makes us complacent.  It allows us to “safely” assume that one project will be anything like another, or that how one project is run will be how future projects are run.  While this may lead to minor annoyances in smaller projects, it can lead to catastrophic problems for larger ones.

How to avoid the not good

There is a way to both capitalize on prior experience and avoid the pitfall of assumptions, and that solution is a framework.  Frameworks give the team a shared understanding of what is expected.  They take work to develop, teach and maintain, but the effort is worth it.

Building a framework is as simple as laying out steps to follow.  Answering questions like 'how will we prioritize new work' or 'how will we run testing meetings' will help clear up confusion and avoid problems before the occur.

Just making a framework isn't enough though.  We also need to gain buy in from the team, ensure they understand how to use it, and then actually use it.  The payoff, though, is worth the effort.

No Update Updates

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.

Rolling out an intake process

There's tons of ideas for work and projects floating around, and there's certainly no argument that there's tons of work to do, or that a lot of that is important and should get done. That said, this doesn’t mean that it ALL should be done.  Frequently teams end up getting bombarded with different requests from multiple angles.  Individuals will approach random team members and ask for some work, or executives will plan something out and assume it'll get done. 

The challenge in the tech team is to figure out how to setup an intake process to streamline, filter and accept work. This process should include a way to evaluate the value of the work (e.g. what the business gets out of it), as well as the relative effort of the work (is it possible to accomplish with current resources).  A good intake process results in several changes in how work is sourced, how it's accepted and how a team decides what to accept.  

While there certainly is a lot to it, one of the biggest impacts I've seen is for the business side; they now have to follow a process instead of just flinging ideas at you. This makes getting buy-in from the business critical to any intake process.  Not only are you changing things up for them, but you're adding process, which means things take longer.  There's a few things I've found that help reduce this impact;

Start early

Once you've determined a basic I take process start socializing it with your business partners.  This means letting them know what the plan is, and more importantly, how it helps them.   Giving the team loads of time to get used to the change will help blunt the surprise when it goes online. You can start early be constantly bringing it up in meetings, reminding folks when it’s going to go online, and providing documentation on how it works.

Talk to the top

Like any process change, be sure you're getting buy-in from the leadership of your business partners.  Ensuring the VP or Director is onboard will both get you an ally who will spread the word, but also give you a backstop.  This makes it much harder for someone to not follow the process since their leadership is onboard.  It also helps demonstrate you want to collaborate with the entire team instead of just pushing new processes onto specific individuals.

Be consistent

Once the process is in place ALWAYS use it.  Nothing will undo it more quickly than one person or project getting to skip the line.  This isn’t to say the process can’t or won’t be changed, just that it should be consistently applied across all requests / projects.  

Collaborate

Once you've created your basic process, share it with the business.  Explain to them why you started here, but ask them for their input.  At the very least this gets more buy in, but it's also likely you'll get some good ideas from it.  As the process matures, feedback from your business partners will also be a great source of ideas.  After all, they’re the ones who have to deal with it on a regular basis.

Raising Issues Early

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.

Right-sizing communication

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

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

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

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'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"

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.