Knowing when to go "quick and dirty"

We’ve all been in situations where we know the “correct” or “best” way to do something, but not had the time/money/energy to go that route.  Instead, we look for something that will still get the job done, but may not be as clean…. The “quick and dirty” method.

While we generally want to avoid going quick and dirty (it is, after all, both quick… and dirty) there is an argument for it being useful.  Our standards and best practices certainly exist for a reason; experience (ours or others) tells us the best way to move forward.  There are, however, times when we are unable to follow best practice, or when following it would result in negative consequences.  These are the times when using a quick and dirty solution can be beneficial.

---

Making a decision to essentially ignore best practice and go this route shouldn’t be taken lightly.  You, and everyone you interact with, needs to understand the tradeoffs.  Generally there’s a higher risk of error and the end product may not be as robust as it would be had you followed the proper channels.  Getting buy in, or at least ensuring everyone knows what the tradeoffs are, is absolutely critical to this route.  You could go it solo, however, eventually others will notice that it wasn’t quite done “right” and will start asking questions.

Generally the quick and dirty approaches also necessitate additional testing or oversight to ensure something critical wasn’t missed.  This degree of oversight may not be required with the best practices route, but is here since you’re basically cutting corners (hopefully the right ones!).  You’ll need to ensure you’ve got extra bandwidth or support to help minimize the risk of problems showing up.

This approach can definitely help get things done… at least if you keep a close eye on things and know what you’re doing.  My best advice when choosing to go this route is to ensure everyone on the team is aware that you’re choosing it.  This has a few advantages, including getting more eyes watching out for issues and helping explain any odd side effects.

The biggest takeaway is to ensure you’re making the “quick and dirty” decision for the right reasons and that everyone is aware of your choice.  Ideally you’ll never need to use it, but if you do a bit of planning can help save the day.

"I had to give" someone feedback

Feedback is critical to learning.  Without understanding the impact our actions make we cannot course correct and become better.  One of the best sources of feedback is our team; the folks we work with.  Not only do they have an understanding of how we work, they understand something about the work itself. This gives them insight into how we can improve in specific areas, as opposed to generalities.

Understanding that feedback is important is one thing, but being able to accept it is something else entirely.  Many times the phrase “I had to give so-and-so feedback” is used when describing giving feedback.  This phrasing sets up a bit of an adversarial understanding.  They’re giving feedback because they “have to”, because something went wrong that needs to be fixed.

---

Phrasing

This phrasing instantly tells everyone that someone screwed up.  It tells the team that so-and-so made a mistake and the boss (or whomever) has to come down from on high to make sure it doesn’t happen again.  This phrasing also puts the boss into the mindset of “correcting a bad thing” instead of “helping someone improve”.  At this point it stops being positive feedback, and instead turns into something closer to a punishment.

The person receiving the feedback will also pick up on this difference.  Going into a meeting where you “have to be given” feedback primes you for being in a defensive / negative headspace.  It takes what should be a positive event - learning to become better - and shifts it into a negative event - being dressed down.  While this certainly isn’t guaranteed - after all everyone will accept and interpret feedback differently - it certainly doesn’t help.

Part of how feedback is delivered is built into the culture of the company - do folks expect regular, honest discussions on how they’re doing and where they can do better? - or do they expect to only be told when they screwed something up?  While this framework will certainly impact any feedback discussion there’s a lot a team, or even an individual, can do to frame feedback as a positive.

Use different words

As noted above “I have to give feedback” sounds negative, so just say something different.  

• “I liked XYZ you did, let’s talk about how you can get even better next time”.

• “I’ve got some ideas on how you can increase your impact”

The intention is to present the discussion as a positive, “lets help you do even better” talk vs a “you screwed up, don’t do it again” talk.  The words you use to transmit that intention are incredibly important… take time to think up a way to indicate you’ve found something they can do better, without sounding like a demerit.

Openly talk about feedback

Many times feedback is only provided during set times (generally around performance discussions).  This not only guarantees it’s stale (ever had a manager bring up something that happened 4 months ago? Or not bring up anything at all?), it also clearly ties it to performance.  This linkage is dangerous since it puts everyone in the mindset of “feedback had better be positive or I won’t get my bonus/increase/whatever”.

This also makes feedback a rarity, something that only happens at set points.  This breaks any positive habits around feedback and instead sends you scrambling to look up what feedback is, how to write it and how to accept it.  Knowing that it’s coming up, and that you and your team don’t regularly do it, just adds to the stress of it all.

Many of these challenges can be overcome by making feedback a regular, and open, thing on your team.  The more the team experiences feedback, the more the team talks about the feedback and the more open it is will make it easier to give, and accept.

Beginning Background Knowledge

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

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

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

---

Find the common thread

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

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

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

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

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

Speaking up when you find something

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.

Owning Mistakes

Mistakes… we all make them (citation needed), but not many of us are comfortable talking about them (or even sometimes acknowledging they happen).  I find this lack of comfort to be a very interesting cultural outcome, since discouraging talking about mistakes means we’ll be making more.  Even worse, it means the ones that do occur will end up hurting us more.

I recently had a great discussion with a colleague about how we can get more comfortable sharing mistakes (this is a fascinating topic that I’ll touch on in another post).  In essence they were asking how we can go from a state of being fearful of owning mistakes and exposing ourselves to retribution to a state of feeling OK pointing out when I screw up.  Their fear was centered around what would happen at our next performance review since we’d essentially be feeding our managers ammo on where we failed.  While I completely understand this mindset (it’s one I imagine many of us have experienced… the manager who sees a mistake as something to hammer down on vs. an opportunity to improve), it’s one that I do not ascribe to for a few reasons.

---

Everyone makes mistakes

It’s a simple fact of our reality that everyone makes a mistake at some point (or several…).  Trying to ignore this fact is essentially lying to ourselves… after all, we know that at SOME point we’ll make a mistake... and that our boss will make a mistake… and that everyone else will too.  Since we know it’s going to happen, we don’t gain anything by hiding it.  The best possible outcome in that scenario is no one finds out… worst case is someone does; in this case instead of asking how they can help fix it they’ll ask why you hid it.

You could also think of it this way - your manager knows at some point you’ll make a mistake. By exposing them, instead of letting your manager find them, you show that you can be trusted, that you recognize when you need help.  This not only helps strengthen the relationship with your manager (see the third point), but also gets you in control of the conversation.  Proactively bringing it up lets you frame the discussion as a “I made a mistake and want to avoid doing it again” instead of a “You really screwed up”.

Owning our mistakes gives us strength

Hear me out on this one.

The default assumption in many places is that individuals will not call out their own mistakes (despite everyone knowing mistakes are made).  After all, it REALLY doesn’t feel good to stand up and say “I made a mistake”.  Our ego (that voice inside that pumps us up/tells us how awesome we are/etc) is threatened by this, so we avoid that internal pain by not saying anything.  This easy way out protects us in the short term, but can come back to bite us when the mistake is caught later.

Actively calling out our mistakes demonstrates to others that we’re aware of where we need help and where we can grow.  It tells others that we’re human too, and that even us as the XYZ expert can stumble.  By bringing your mistake into the open you not only make it easier to get help, you also make it easier for others to share their mistakes.  This not only enables your growth by allowing others to help you improve, but strengthens the entire team by sharing those lessons.

Owning our mistakes builds relationships

One of the biggest advantages in admitting to our mistakes is the boost it gives our various relationships.  As noted above, they also make mistakes, so knowing you’re comfortable sharing yours will make them feel better about working with you.

Being proactive and calling out when we’ve made a mistake lets our partners know we’re serious about helping them… after all, we could have just let is slide.  Now this isn’t to say I just call up someone and say “Hey, I crashed the server, good luck”.  Instead I’ll first figure out how to undo (or at least mitigate) the damage.  This further helps my credibility as not only am I proactively alerting them to issues, I’m proactively fixing tem.  This turns what could be a large escalation (imagine a situation where you don’t tell them about the mistake and they find out on their own) into a positive experience.

---

Not Easy

I’m not saying any of this is easy… indeed, it can be very challenging to stand up and say “hey, I screwed something up”.  The benefits, however, outweigh that short-term discomfort.  The good news, though, is that the more we practice this skill, the more we embrace being temporarily uncomfortable, the easier it gets.

Don't play telephone

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.

On Perseverance

Perseverance, the ability to keep going despite hardships, is a very important skill to learn, and something I recently had a chance to practice.  On Friday I took what should have been a 4 hour exam… which lasted 5.5+ hours.  Instead of starting this (stressful) exam that I’d spent 8 months preparing for immediately, I was greeted with a black screen and a spinning beach ball.  Despite figuring out how to get help, I ended up waiting on hold for tech support.  For 2.5 hours.  Talking to chat bots. In circles.  At several points I considered just calling it and rescheduling (something that would set me back another two months).  

Instead, I took a moment to breathe and figure out my options… Everything basically amounted to waiting on hold for chat support… or phone support… or chat support again… and again and again.  I figured if I could just get the RIGHT agent on the phone, I’d get in and could take my exam.  It just took my not giving up.  Eventually, 2 hours later I found that agent, and my exam started.  8 questions in it immediately broke.  Again.  This was another chance to give up.  I’d already spent half my allotted time not answering questions, and who knows how much longer it would go on for.  Instead I chose the perseverance route; apply my previous strategy of reaching out again. And again. And again.

---

This was not as easy as it sounds. Whatever chat system I was tied into would automatically send me a message “from the agent” every 3 minutes. It was something like “Thanks for your patience, I’m still looking into your issue”, that just repeated. After 40 minutes of non-responses I began asking if anyone was actually there, and they could type in literally ANYTHING other than the stock message to let me know. Eventually I hung up on that chat and opened another, and kept doing that until I found someone who could help me. The same thing happened to me on the phone; after 30+ minutes on hold an agent would pickup, tell me they’d fixed the issue, then hang up. I even asked one to stay on the line until I could confirm the issue was resolved, but they said they couldn’t.

Long story short I ended up passing that exam…. But not after getting a hands-on lesson in perseverance.  In this case it expressed itself in not giving up, in not saying “I give” and quitting, in continuing to look for an answer despite every avenue being non-helpful.  This is hard stuff… it would be SO much easier to just reschedule or do it later, but it wasn’t worth it to me.  Not only would I have to go through all the anxiety of prep AGAIN, all the waiting AGAIN, I’d have wasted almost 3 hours of my life on hold.

Situations like this crop up all the time.  We’re in meetings that we’re bored stupid in.  We have to work on projects that just… never… die.  Something fails and we lose several hours of work that we have to re do.  The challenge is not to get stuck on how annoying/stupid/etc the situation is, but instead of focus on what’s important; being present, completing our work, solving the challenge.

Domain Expertise

In the tech world we tend to focus on learning the tech.  Those of us working on any given system or tool want to drill into how it operates, what features it has and when they should be used.  This is true for NetSuite, or AWS, or InfoSec.  And there’s nothing wrong with making technical skills a focus of our job; after all we ARE the systems folks!  

Learning technical skills, however, shouldn’t (can’t!) be all we focus on.  We also need to stretch ourselves to understand the domain our systems exists in.  For SalesForce this would involve learning how sales teams operate.  What does any given Sales rep need to do or know on a monthly/week/daily/hourly basis?  Why do they (dis)like any particular aspect of SalesForce?  What policies does the Sales team have to follow?

While certainly not directly related to the system, questions like this help inform WHY and HOW the system can be used.  We don’t need to know as much as our customers about their process, but the more we know, the better we’ll be able to support them (personally I became a license health care broker to help accomplish this).  

Gaining Domain Experience

There’s many ways to help expand our domain expertise.  The simplest is simply through osmosis.  As we work on any given system, we’ll naturally learn a bit about the domain it exists in.  Working in NetSuite, for example, will expose us to charts of accounts.  SalesForce will expose us to a closing process.  Workday will expose us to hiring.  This is a natural first step for many folks since it’s basically impossible to miss; you can’t learn the system without picking up SOMETHING.  That said, this is only the beginning.

Getting to know your customers is another way to improve your domain knowledge.  Get them involved in testing, or have them show you how they use any particular screen.  Sit in on their team meetings and get a feel for how the team behaves.  This first-hand experience has several advantages, including giving you more domain expertise, but also helps build connections and puts a face to everyone.  Knowing Jimmy in sales is much more impactful than knowing some random user has problems.

---

Training like your customer-base takes this a step further.  Go and get whatever certification or accreditation they need (like my example of becoming a certified benefits broker).  This will not only extend your baseline knowledge of that particular area, it will help you see things the way they do.  In the care of a credential or training you’re also rounding out your own experience and possible exposing you to new concepts.  This has the added benefit of (generally) getting you some street-cred with your customers.

Going even deeper you could even BECOME your customer.  I very rarely see folks taking this path since it is very intense and time consuming… but it does offer the most in-depth way to gain experience.  For example a software engineer might choose to implement a live customer, or a Salesforce rep may take some inbound calls.  While this does crank up the intensity a bit, it will really help show you what’s important, or annoying, or impactful for your customer base.

While there’s nothing wrong with not taking these steps, I find they help individuals make better informed decisions and allows them to develop better solutions to challenges.  Flexing ourselves this way also has the side-effect of helping us build better relationships, and learn something new about our tool.

Broken Comb Skillsets

A broken comb skill set refers to the shape a comb with missing teeth makes - some vertical lines and a horizontal one (and certainly doesn’t suggest the individual is broken!). They’re essentially an extension of the “T” skill shape, multiple in-depth areas with a (potentially) broad general base. This type of skillset is very interesting to work with, as they have multiple areas of expertise. While this is not without its challenges, broken combs can be very flexible and bring immense value to a team.

---

The upside of a Broken Comb

Broken comb skill sets offer the advantage of multiple focus disciplines.  Due to these areas they can potentially reduce the need to bring in additional team members, or negate the need to bring in outside help.  By excelling in multiple areas they provide a lot of flexibility and are able to make a big impact on projects.  This is especially true if their areas are related (your tax and finance systems, for example) as they are able to easily support thos areas and understand the interconnections between them.

In addition to their areas of depth they are also similar to how a “T”-shaped skillset with a broad skillset of more general skills.  This general knowledge helps them bridge gaps between areas (even their own), and allows them to get a better handle on the big picture.  The mix of focus areas and general skills can make for some very versatile individuals, capable of not only handling technical areas, but also “softer” skill sets.

The downside of a Broken Comb

While not a rule, despite a Broken Comb shaped skill sets offer deeper expertise in multiple areas, it’s likely their depth isn’t as great as an “I”, or even a “T”.  This is simply due to not having as much time to dedicate to each one as those other types.  This may result in overconfidence, or stretching too far in those areas.  Have multiple focus areas can also detract from their overall impact as they may get pulled in too many directions to be truely impactful.

Similarly, the breadth of general skills may be limited as a lot of energy is put onto the areas of focus.  This leaves less capacity to developing general skills, or to developing them deeply enough to be at least minimally effective.  This can result in broken combs having narrower general skillset than their “T” shaped counterparts. 

Managing a Broken Comb

Understanding what any given Broken Comb’s focus areas are is important to fully using their talents.  Take time to understand where their interests lie, and what areas they choose to focus on.  This will not only allow you to be utilize them on projects, but also help the continue to improve their focus areas.  Knowing how wide (or narrow) their general skillsets are is also important.  Their wide range of skills can make it seem like they can handle anything, but knowing where the edges are is critical.

Broken Combs can also fit in incredibly well between teams, especially if there are folks with I-shaped sklil sets on either side.  A Broken Combs multiple focus areas allows them to (relatively) easily translate between groups as they share an understanding with each side.  This can also open opportunities to expand someone else’s skillsets and the Broken Comb can relate to them, and the new skill.

If you’re a Broken Comb

Take time to understand where the edges of your focus and general areas are.  Knowing your areas of depth allows you to further exploit and build those skills, and knowing your general areas will make it easy to see how things connect.  It will also help you better communicate to your team what you can do… and help avoid situations where you’re expected to be an expert but really don’t know.

Having multiple focus areas (plus generalized skills to round you out) will make you very popular. Be careful that you don’t get pulled into too many different directions. Take an active approach in shaping what work you take on to best maximize your interest and impacts.

T Shaped Skillsets

If an “I” shaped skillset is very deep in one area and not much else, a “T” shape is a skillset that’s deep in one area (the vertical part of the T) with some general knowledge of others (the horizontal part of the T).  Generally these folks have a broader range of interests or responsibilities than someone who is “I” shaped, resulting in a broader skillset.  These individuals may also have been on the path to be an “I” shape and made the conscious (or not!) choice to broaden vs. deepen their skillset.

I find “T” shapes to be good at putting together a broader picture, or investigating new areas (think a Business Systems Analyst, project manager, etc).  Their broad skillset allows them to more easily interface with other groups and understand new topics at a higher level, while their single deeper skill can have them either leading or assisting where an “I” shape would be.  These individuals can take the place of an “I” in some areas, but you need to be careful since the depth of the “T” tends to be shallower than that of an “I”.

---

The upside of a T

T-shaped skillsets result in an individual to have one area of in-depth focus.  It also results in them having at least a passing familiarity with other areas of the business, systems or processes.  This allows them to dig into one area of expertise, while also making it easier for them to flex into other areas or to draw from their other experiences.  This more rounded approach can result in more novel solutions to challenges, or help break out of challenges than an “I” shape may get stuck on.

“T” shapes also tend to be more open to exploring new areas or learning new skills.  This makes them useful in situations where different teams or groups have to come together as they can “talk the talk” of both sides.  In addition, the depth of the “T” can have them serving as the technical expert as well, eliminating the need to bring in more resources.  While each individual and situation will have it’s own requirements, having someone who is more flexible on the team can be a huge help.  This deeper expertise also makes it easier for them to work with “I” shaped individuals in a similar field; they’ll very likely share many concepts, skills and ideas.

The downside of a T

While a “T” shape does allow for some in-depth expertise, it is uncommon that it will be as in-depth as an “I” shaped skillset.  This is generally due to the “T” shape drawing energy away to build the general skillsets, however, may also relate to the interest an individual has in any one area.  Some folks simply aren’t interested enough to learn EVERYTHING about a particular area, so use the time that would be spent drilling deep to expand into other areas.  This can be detrimental as the “T” shaped skillset may not be able to handle the complexity of some scenarios, requiring more resources.

While “T” shapes have a breadth of skills, the depth of many of them may be lacking.  This could be due to a lack of need (e.g. “I know enough project management to get by”), lack of resources (“I never got formal training) or lack of interest (“I started learning XYZ but got bored”).  This may result in situations where a “T” quickly gets in over their head.

Managing a T

As noted “T” shapes offer a lot of advantages.  Not only do they have a single deep skillset, they have many other skills that can be applied.  This makes them great for throwing at problems that relate to the area of interest as they’ll be able to apply multiple tools or ways of thinking to the challenge.  This may also be hazardous since they may end up over their head.  Unless they’ve learned to raise a flag for help (or are closely watched) this can quickly lead to big problems.

The depth of a “T”’s area of focus may also not be as deep as you need for any particular task.  While they may seem to know enough, they can quickly get blind-sided by some obscure or specific thing that they don’t know how to handle.  While this can be mitigated by their broader skills (e.g. knowing how to ask for help, how to research the problem, etc.) it can lead to project delays or other challenges.  Until you’re at a stage where you can gauge their comfort, it may be beneficial to regularly check in to see what support they need.

You can support a “T” by learning if they want to deepen their focus, or expand their range.  Deepening their focus may involve getting them more specialized training, pairing them up with an “I” (or another “T”) who has the same focus, or letting them take on more challenging work in that area.  This will give them a deeper focus, but may also reduce their breadth.  Supporting their range could involve assigning them to work on projects related to their focus (e.g. if they’re a lawyer put them on something just outside their speciality), or embedding them on other teams to learn how they work.  This will increase their breadth, but may reduce the depth of their focus.

---

If you’re a T

Understanding where your focus is and how wide you want your breadth to get is important to being a successful “T”.  Knowing the limits of your focus is critical to knowing when to ask for help or call in support, and will also help you learn where you can expand (if you choose to).  Knowing how wide your skillset goes will help you avoid flinging yourself off the deep end.

You may also end up being the swiss army knife on your team - the one person who can be counted on to assist anywhere.  Clearly communicating those boundaries to your team will also help you avoid situations where you’re expected to perform but have no clue what’s happening.  While your interest and skills may be broad, they do have limits!  That said, these can be great opportunities to expand your general skills since they’ll be new.

"I" shaped skillsets

Individuals with an “I” shape of skills have one focused their time on delving deep into a single skill.  This means they’ll know everything about a specific tool, concept or area, which tends to make them excellent resources for those topics.  This focus can, however, lead to other skills not being as strong as they could (or should) be.  For example, a technical resource who is incredibly knowledgable about yoru system, but cannot effectively communicate, or a lawyer who knows everything about their area but is incredibly abrasive in interpersonal interactions.

“I” shaped skillsets may not be very common in smaller environments, if only because the level of challenges that crop up on a regular basis don’t necessitate their skills.  Frequently this results in these individuals working as consultants or contractors so they can stay busy.

---

The upside of an I

Folks with I shaped skillsets are incredibly important to successfully completing large and complex projects.  This is mainly due to their in-depth understanding of the topic at hand, which tends to allow them to either foresee challenges before they crop up, or deal with them if they do.  While “T” shaped folks or “broken combs” may also possess some amount of skill in those areas, they rarely get to the depth that someone with an “I” shaped skillset can delve.

This means folks with an “I” shaped skill set are great to throw at large, complex problems that fit in their wheelhouse.  Their experience and background will give them a good idea of where to begin tackling the problem, and since they’ve done it all before they’ll know what steps need to be taken and when.  Their innate desire to learn about that topic will also result in them continuing to sharpen their skill set, either through formal training, experimentation or networking with others in their field.  This makes them a great resource for trying new things and getting the most out of their work.

The downside of an I

Given the immense amount of time and focus it takes to develop a single set of skills this deeply, “I” shaped skillsets tend to leave folks lacking in some areas.  When unrecognized this can lead to some severe challenges with projects, as this individual will keep chugging along their path without realizing other areas may need attention.  For example, understanding the need to communicate changes to a project’s scope is incredibly important, however, if I’m entirely focused on a technical buildout I may not share that information in time.

The extreme depth of skillset an “I” shape offers also can make it hard to find one.  This is less a challenge for that person, and more for someone seeking those skills.  This can lead to increased market demand, as well as scarcity (think back to how hard it can be to find an expert in some smaller fields).  The focus on one particular area may also blind this individual to learning about other areas, potentially leading to not fully understanding how their work interacts.

Managing an “I”

Managing an I

The best advice I can provide here is to learn to identify when someone has an “I” shaped skill set and where that skillset ends.  Theres a number of signs that will help indicate an “I” shaped skillset:

• Long history with one technology, concept, etc. - Individuals who have specialized over a number of years in one field may tend to be “I” shaped.

• Disinterest in other areas - Not expressing interest in other disciplines, ideas, etc. while focusing entirely on one is also a good indication.

Knowing where these edges are allows you to find ways to support them, whether it be through integrating them with a team of “T” or “broken combs” to help fill out the gaps, or someone skilled in managing “I” shapes.  You can also look for groups of “I” shapes and have them work together.  This can result in multiple folks with deep skill sets playing off each other and performing great work… you just need to be careful they all aren’t blind to each others areas.

Being direct, and repetitive, with communication can help avoid potential problems as well as folks in the “I” shaped bucket sometimes end up assuming others will fill in the gaps, or simply forget to take specific actions (e.g. communicating updates).  Consistently connecting with them (or putting them on a team that’s stronger in those areas) can help maximize their impact.  Helping ensure their schedules are cleared can also be helpful as it allows these folks to focus their time.

If you’re an “I”

Similar to someone managing an “I” the best thing you can do is to be aware of where your skill sets end.  Knowing this boundary will help you work with a team (since you can call out where someone else needs to step in), and where you can choose to improve.  Knowing the depth of your skill is also important, as many folks will turn to you for all the answers about a specific area.  While you may be a super-expert, there’s always *something* you don’t know… and know that edge is just as important and knowing everything else.

Asking for feedback on how to improve your overall performance is also a great (if not uncomfortable) idea.  There’s no expectation that you master other areas or take on more work, but there may be some simple and straight forward things you can do to help keep things running.

Skill Shapes

Everyone is different (citation needed).  This part of our reality impacts every aspect of our interaction with folks, but in this particular piece we’ll look at how it impacts our work.  There are many different ways to try and quantify or qualify our differences, from things like MBTI personality assessments, to background degrees, to more.  Here, we’ll focus on our skillsets, and how our understanding of others (And our own) can impact our work.

One straightforward way to look at skill sets is to group them into “T”, “I” and “Broken Combs”.  These three classifications are useful to understand where an individual’s strengths lie, and how they can be best utilized to tackle any given challenge.  They can also be used to dig into past projects or events to better understand why things went the way they did.  I’ll start with a high-level of each of these, then dig into them more in the coming weeks.  Note that none of these is necessarily better or worse than any other - they’re just tools to help understand people a bit better (yourself included!).

Skill Shapes

I-shaped people

I (like the capital I or lowercase l) shaped people tend to have one deep skillset… and not much else.  These individuals are valuable where in-depth knowledge is needed for a particular area - specific programming languages or systems, business processes etc.  In my experience I-shaped people tend to be a bit more senior in their career or area, and likely ended up choosing to focus on a particular skillset because they find it interesting, or have a particular talent for it.  Note that this extreme specialization can make it challenging for them to adopt new concepts/ideas, which may lead to blind spots developing.

T-shaped people

T-shaped individuals are similar to I-shapes, in that they have one specific skill they’re much better at (the vertical line in the “T”), however, they also possess at least a passing familiarity with several other skills (the vertical line in the “T”).  This broader exposure of skills allows them to more easily flex between assignments, or to more easily interface with other groups as they may know some background concepts or parts of their systems.  Note that because they also possess a broader skillset, their in-depth knowledge may not be as deep as someone who is “I” shaped.

Broken Combs

Like T-shaped people, broken combs possess basic knowledge in a broad set of skills.  They differ from T-shaped people because they will possess at least 2 skills in more depth (this is where that name comes from… imagine breaking most of the teeth out of a comb).  This allows them to be subject matter experts in several areas, while still maintaining general knowledge of others.  Similar to a T-shape, however, their depth of knowledge in those areas may not be as great an I shaped person.

Each of these shapes offers its own insights, and I will be delving into each of these shapes over the next few weeks. Like many concepts these are not intended to limit or restrict an individual… instead they’re intended to be used to better understand how an individual or team will act (or to explain how it got to a specific situation).

On Forests

While it can be incredibly gratifying and satisfying to immerse oneself in details, keeping an eye on the bigger picture is also incredibly important to success. Not only does understanding how your contributions fit into the grand scale help you understand your work, it also helps you identify and correct potential problems. The challenge is remembering to look up every once in a while and seeing what the spread looks like.

Zooming out

One pitfall many folks fall into is assuming that your manager/director/leadership will be the ones to handle the big picture. They do, after all, sit behind a Bigger Desk. In many ways this is not a bad thought or approach; it’s literally their jobs to concern themselves with the big(ger) picture. This, however, doesn’t excuse those of us working on the details from also understanding, at least to a small degree, that larger picture as well. This expectation also goes both ways; those leaders are also expected to understanding, at least to some degree, how the details work.

---

Ensuring everyone involved is at  least aware of the greater picture has a number of benefits - 

• Seeing how your contribution fits in - Knowing that the really boring and tedious spreadsheet work you do will help drive down cost, or make someone else’s life better makes it MUCH easier to accept that work.  Not having this knowledge can result in you internalizing negative feelings around it.

• Avoiding potential problems - Knowing where a project should be headed ,or what it is intended to do, can help you sniff out potential problems before they show up.  This can take the form of helping you rule out specific approaches, altering leadership to specific things and more.

• Broaden skillsets - Most of our time is spent in our specific areas of focus (which is good, it’s why we’re there!).  Getting exposure, and awareness, to the greater picture helps us expand our skillsets, understandings and connections.  This, in turn, rounds us out and helps us be better at our specific area of focus.

---

Finding ways to keep an eye on the bigger picture can seem daunting… after all, most of the we’re just focused on our small area of the project.  There are some easy ways to see what else is going on at other levels:

• Just ask - The simplest way I’ve found to learn about the higher levels is just to ask.  Ask around your team and see what you can learn about your project.

• Get involved - Similar to asking, get involved with other aspects of your project. If you’re a sales specialist maybe get time with the operations team to see what they’re doing. If you’re on the tech side, talk to Finance. Something as simple as attending one of their status meetings, or asking them to show you their system can give you a great idea of how they operate.

Annnd a bit further

While learning about the greater forest does take some time and energy, the return is more than worth it. Not only will you get to expand your own skillsets and knowledge, you’ll also help keep the project moving in the right direction. So go ahead, take a moment to stop looking at the trees and see the forest.

On trees

Details are important, it’s where the devil is (citation needed). Details are what allow a plan to come into focus and and idea to have impact. Without them we cannot fully shape what we’re working on, and can never really be sure we’re done with our task. Despite this, we frequently fail to fully understand the details on what we do. We embark on tasks without taking the time to fully examine the minutia that defines our work. Instead, we focus on the higher-level portions - concepts, ideas - that rely on the detailed work to really stand out.

On one hand I can completely understand the desire to avoid really getting into the details… it’s tedious.  It can be boring.  It takes time… and there’s SO much of it.  Even what seems to be a “simple” project contains a ton of details when you zoom in.  Asking questions like “who do we talk to about X”, or “what specific steps are needed to complete this task” makes those “simple” projects seem more complex… after all, we started with just installing a new piece of software, why does that have more than one step?

While it is true getting into details can make projects seem to stretch out, the time is more than worth it for a number of reasons.

• Understanding the whole picture - Taking time to understand the details helps flesh out the entire picture you’re looking at.  It’s similar to looking at a painting and noticing something new… suddenly you understand a new perspective on what the artist wanted to capture.

• Avoiding pitfalls - Knowing the trap is there is the first step to avoid it, and investing energy in the detail work will help uncover potential problems that may have otherwise remain hidden.  While identifying and planning for these challenges adds more time to your calendar, it will pay off by avoiding the need to fix those problems later.

• Improving your skills - Getting into the details also helps you expand your skillset.  You’ll find things you didn’t know were there, or connections suddenly become obvious.  Like any skill, over time you’ll also get better at defining the detailed work, which will reduce the amount of time it takes to reap the benefits of this exercise.

On the other hand, however, I find it baffling when folks consciously avoid the details.  I’m not suggesting that everyone involved in a project needs to be at the most granular level (indeed, executives need to exist at a high level and tend not to have time for detail work), but the project as a whole needs to be aware of details.  Even something as simple and double checking settings on an email account should not be taken for granted (unless you want the whole company to see what’s in there…).  

You can always take 15 minutes to kick around your projects details with your team.  Ask them what’s missing from the plan, and then go find that devil.

On Negative Examples

To preface this piece - negative examples are about finding attributes, outcomes, etc. that you choose to avoid, not necessarily things that have failed.

Frequently we look around a good example of what we want to do.  We find some project, or team, or event that was insanely successful and point at it as a model to follow.  This is a great approach since we can learn from that things success, and then build on it.  It is, however, also important to find negative examples - things that didn’t go the way you want, or things you don’t want to do - to learn from.  These both teach you what can go wrong, but also help provide a better definition to the shape of what you want.

Filling in the edges

Just like how negative space in artwork can define interesting shapes (or even the artwork itself), negative examples at work help us define our outcome.  They allow us to look at another project/outcome/team/whatever and make more informed decisions on how we want to operate.  As noted above, this doesn’t necessarily mean those projects/outcomes/teams are not effective or working properly… just that you choose a different route.  Some examples:

• Methodologies - Agile project management makes a lot of sense…. In certain circumstances.  Many projects, however, will not benefit to the same degree, and some may even suffer.  Watching another project struggle with the wrong methodology can serve as an example for your work, and what to avoid.

• Team structure - How teams are setup differs widely, both between and within organizations.  Looking at other orgs will help you determine the shape of yours.  Maybe the People team has a great structure that’s super successful for them, but for some reason wouldn’t work in Engineering.  Noting that difference, and being able to point out why it wouldn’t be good for your team, will help avoid

• Documentation - While there are some more standardized ways to document material, at some point it comes down to specifically how a team operates, and choices they make in cataloging information.  Understanding why another group’s decisions wouldn’t be the best for your needs will help you better shape what would be best for you.

---

When finding negative examples it is important to keep any judgement of good/bad or any blame out of your assessment.  The intention is to help identify what the best solution for your particular need, not to pass judgement on how someone else operates (which may be best for them).

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.