YOU are the expert now
Being asked to join a big project can be a bit scary. Not panicking (having faith in your team) and doing your homework (having faith in yourself) goes a long way to growing and staying successful.
One of the first big IT projects I ever worked on was updating and replacing an ERP system called IFS. At the start of the project I was just an IT help desk tech (the guy who replaces your monitor or installs a printer). I was asked if I wanted to become the IFS Project Management Module expert, to which I readily said “sure, that sounds fun” (not to mention more interesting than installing printers).
Problem was I didn’t know anything about IFS…. or about Project Management….
I’m the expert?…
I have a two-pronged approach to solving challenges like this. The first is to have faith in others. In this case my job would involve traveling to multiple sites and standing in front of a room of professional Project Managers as the IFS Project Management expert, despite knowing basically nothing about either. The enormity of this (and the rather large knowledge gaps!) required me to have faith in my manager (who clearly thought I could handle things), my team (who supported me immensely) and myself (who learned to step up)… and this helped me not panic.
The second prong I use is to have faith in my myself. We’re all aware of our own capabilities, as well as our own limitations (be honest with yourself on these!). Once I really understand the challenge, I can map out possible gaps and determine solutions to those… generally this requires learning more about various topics (in this case IFS fundamentals and project management concepts) and boils down to doing my homework.
Don’t Panic - aka Have Faith in Others
Trusting those around you is hard. It requires giving up some amount of control and allowing others to dictate some aspects of your life. In most situations, I have enough faith and trust in the people I work with to make the best possible decisions for me in situations like these. This is doubly so once I have a working relationship with them and understand more about how they work.
When asked to take on incredible challenging , generally unknown, requests, I always remind myself that I wouldn’t be asked to do it if someone didn’t think I was capable. In most cases the person asking has more experience in the area than I do, further giving me confidence that I can do the thing (otherwise why would they ask?).
Do Your Homework - aka Have Faith in Yourself
Having faith in others is great, but it’s not enough. In order to succeed at this big asks, you also have to have faith in yourself. This includes faith in your abilities, but also in your potential. Over the years I’ve come to enjoy trusting in that potential since it has allowed me to flex and grow in ways I would not have without that opportunity.
For me, this frequently takes the form of (literal) homework. I’ve found myself enrolled in community college courses, teaching data analytics courses (teaching is a great way to help reinforce and learn new skills), reading stacks of books, and getting lost in the guts of a new system (one of the best ways to learn them, but always be sure you have a sandbox!). Since I also had a job, all of that had to be done on my “free” time.
I am the expert
It takes time, but eventually you’ll begin to accept these opportunities as pathways to growth instead of something to fear. For me the cycle of insane ask, not freaking out, working the problem and growing has become somewhat of an addiction. Not only have I built technical skills, I’ve had the pleasure of working with some very smart people (and made some great friends).
If we’re not being pushed by ourselves or others, we’re not growing, so grab every opportunity you can and enjoy the ride.
"This other place I worked at did it this way…" ~ Some Executive
Tech teams need to be brought problems to solve, not solutions to implement. Frequently business partners only present their ideas for solutions, which, at best, will steal time from actual problem solving, and at worst cause problems down the road.
This is one of the phrases I dread hearing the most, mainly because it usually ends in “... so I’ve already told everyone we can do it this way” (or something scarily similar). This phrase definitely falls into the bucket of “partners telling us solutions” (which has it own dangers), however, for me this one is a little bit more insidious…
A Game of Telephone
Generally I don’t hear this phrase first hand. Instead, I’m (un)fortunate enough to hear it second, third or fourth hand. It tends to originate from someone higher-up in the org chart, generally a VP, Senior Director or the like. It also tends to originate from a place with good intentions. After all, this person and their team is faced with a big challenge, so why not use something they KNOW has worked before?
How it plays out (in Robs super-oversimplified world)
“Well, when I was at Telsa/Ford/GE/Kraft we solved this insanely complex thing by doing X, it was easy and took 5 minutes”
“Ok, cool, I’ll tell Rob to do it that way too”
Why it’s scary
This is scary since where ever we are now, we ARE NOT at the same place this worked for them in the past. We’ve also entirely skipped the part where we identify the problem. Even if the business is identical and we make the same product/service, the way our systems are setup will differ in some fashion. Generally we’re not in the exact same industry, making the differences even greater. Further, the individual who puts this idea forward likely does not understand the specifics of what was done, only the end product (it’s seldom a Director or higher I meet who truely cares to learn the technical specifics). So even if the solution worked exactly as remembered, they do not fully understand the pretzels their tech teams had to wrap themselves into in order to deliver.
How it should play out (in Robs super over-simplified world)
“Well, when I was at Telsa/Ford/GE/Kraft we solved this insanely complex thing by doing X, it was easy and took 5 minutes”
“Ok, cool, let me tell our Tech Experts about Way X, but we’ll also go over the problem and explore other solutions”
Getting from scary to supportive
Technical teams (whether it be IT, legal, communications, etc) are the experts in solving problems, so we get very concerned when instead we’re fed solutions. The best way to improve this relationship is, well, to improve the relationship. I personally spend a great deal of time working with my partner teams and sharing the basic concepts / patterns/ processes that my team uses. This helps demystify tech (that said a lot of it is still magic to me) for my partners, and, more importantly, helps build trust. This is needed for those times I have to tell them that what their VP said may have worked somewhere else, but it may not work here.
In the end it all boils down to the strength of relationships with partner teams. These scary phrases will continue to come up, but, they should become less and less scary as time goes on and more and more folks know to trust their tech.
Getting comfortable being uncomfortable
Just like that first workout can turn someone off to the gym, accepting those tough, uncomfortable, assignments can be hard. Instead of seeing it as a painful thing to endure, I’ve begun to see it as a positive reflection of growth
Jobs, especially those in tech, constantly throw new (and sometimes exciting!) things our way. These things, however, can range from the mundane and boring to the pulse-pounding hair-pulling problems that come out of nowhere. Regardless of the excitement is causes, I’ve found being constantly uncomfortable with what’s going on has helped me both stay involved and helped me grow.
Whats uncomfortable?
“Uncomfortable” in this case doesn’t refer to feeling out of place, or feeling afraid/insulted by my team. Uncomfortable instead refers to the feeling of “hmm, I’m not 100% sure I know what this is or how to solve it, but I’ll take a shot!”. Our lives are generally about finding comfort, the most comfortable chair, the most comfortable clothes, the most comfortable relationship. First feeling this at work easily makes most people recoil, since who wants to be uncomfortable?
Uncomfortable can pop up in different spots for different people, but I found it showing up frequently when:
I’m asked to take on something with a system or team I’m not familiar with
I’m given vague or incomplete information on an ask
I get pulled in to something last minute
These are all cases where I feel surprised, overwhelmed or frustrated.
Settle in, get comfy
There’s really only two options when that feeling comes up:
Embrace it and settle in
Reject it
Running is easy, really easy. This looks like pawning it off on a teammate, telling someone it’s not something you do, or simply not engaging with the request. Sometimes this response is appropriate, for example if you’re asked to something wildly outside your realm (think being asked to build dashboards when you’re an infrastructure engineer or front end work when you’ve never done that). How you do turn it down is important (and something I’ll get into more detail later!), but the other option is to embrace the discomfort.
Why get comfy?
Just like building muscle results in a bit of stiff or soreness, embracing the discomfort at work results in stronger and broader skills. Since that discomfort usually stems from being pushed a little bit further than you want to be pushed it also represents an opportunity to grow. Embracing that discomfort means embracing the chance to grow and to build new skills.
That said, it’s not always easy! Just like that first workout can turn someone off to the gym, accepting those tough, uncomfortable, assignments can be hard. Instead of seeing it as a painful thing to endure, I’ve begun to see it as a positive reflection of growth. Having that uncomfortable feeling now means I get to learn something new, and get to become stronger. So learn to get comfortable being uncomfortable. See out those things that will push you. It doesn’t matter if you blow it out of the water, or take your time working it through, you’ll get stronger.
On bringing solutions
I always appreciate when my partners think through challenges before coming to my team. It does get a bit dicey when they bring us solutions they think will be best…
One of the most common challenges I’ve run into is having a partner come to me with a solution to a problem they’ve run into. This might take the form of “Have Workday do XYZ”, or “Build me this type of report”, or “Use this tool to do X”. Part of me really appreciates my partners taking the time to figure out what they want to happen… but a much larger part of me has a blood pressure spike and a few more grey hairs pop up.
Why the grey hair?
I really do appreciate my partners taking a stab at figuring out what’s going on. I get the grey hair for a few reasons:
Generally partners don’t have the full picture - Partners usually are only aware of the aspects of systems they interact with (which is all we can expect or ask of them!). This means they frequently are unaware of other solutions, or of interactions with other systems.
Partners are usually not technical experts - Nor should they be! I frequently tell mine I’m not an HR expert and I’m glad they’re around to do that. That acknowledgment also means I don’t go tell them how to fix HR challenges though.
Their focus is only on their stuff - One of my favorite phrases is “This is my P0 (priority 0)”.(more on that in another post!). Everyone (me included!) has a personal list of what’s important, and nothing else comes close. This makes things problematic as partners get tunnel vision on just their own items.
When a partner brings me a solution they’re generally already stuck on one (or more!) of those items. This means I have to take time to talk them down (all that de-escalation training at the help desk REALLY comes in handy!) and explain why their solution may not be the best idea.
Why it’s challenging
While I find it great that my partners put thought into a solution before they come to me or my team, it tends to set us up for failure in a few ways:
They put energy into it - Once someone puts time/energy into something it’s MUCH harder to change their mind
They’re “stuck” on their idea - Everyone likes their own ideas, and it gets particularly challenging to try to change their thinking.
The clocks (usually) ticking - Since my partner’s already taken time to come up with an idea we now have less time to build one together. This can be particularly troublesome with highly sensitive asks.
These generally occur in some combination, which makes the initial talk mostly focused on talking my partner down or trying to find ways to reshape their thinking.
Just come back off the ledge…
This is where I find connections with my partners to be particularly important. When I first work with someone I don’t have any credibility (other than being the “IT” guy), so I have to build it on the fly. Once I have an established work relationship that process is a LOT quicker, allowing us to get to the source of the problem much more quickly.
I use a number of tools/tricks to help with this, but some of my favorite:
What are you trying to solve with this? - This question helps my partner focus on the problem and gives me an “in” to have them demonstrate it. This makes it easier to change their thinking about a solution.
Why do you want to do this? - Similar to the above it makes my partner explain how they got to their solution, which helps me figure out WHY they (think they) want it.
Who else have you spoke to about this? - This is a great question to help determine where their solution idea came from. This can then help me figure out how they came up with their idea.
Getting to a good endpoint
Usually this boils down to spending an hour with my partner to go backwards through their solution. This can be a painful process, but helps us uncover why they wanted that particular thing and, more importantly, better understand the underlying problem. There are some times when their solution ends up being the one we go with, but many times we land on a different approach (usually based on information my partner didn’t have, e.g. how a system operates).
The most important aspect of this approach is the time spent with my partner. This helps build a positive relationship with them, which will only help me out in the future. As the relationship progresses both my partners and I get better and presenting challenges, and developing solutions.
How Connections Form
Connections are incredibly important for work (and life!). This makes it important to know how they form, and how they differ.
We’ve all been there
Everyone, at some point in time, has been in that spot. For whatever reason we’re stuck doing something that pushes us and we need help. Generally this means we don’t know underlying concepts or ideas that are critical to success, or are unaware of how tools work. Some common examples include:
Being asked to perform data analysis
Managing a system or tech
Developing / maintaining a process
On the whole we are very intelligent and skilled at what we do. The problems crop up when we’re asked to do work outside our normal wheelhouse. It may be presented as a stretch goal, or an opportunity to grow, but frequently we are left in a bit of a lurch since our background and expertise is in other areas (imagine a software engineer being told to manage a help desk, or an HR specialist being told to develop analytics).
On the plus side, we are (generally) very smart and talented. On the down side we’ve got basically no idea what we’re doing. This is where connections between technical and non-technical teams is critical.
These connections form several ways, but in general I find they are either organic or prompted.
Organic Connections
Eventually we end up bumping into someone who knows more about what we’re trying to do. This might take the form of a content strategist commenting on posts, or a database engineer asking why queries are written the way the are. In some very lucky instances we can reach out for help proactively, but generally we have to get lucky….
How this connection forms is critical, as it dictates how the relationship, and end product, will unfold. Generally it goes one of three ways:
The expert reacts negatively - demanding to know why it was done this way, or why a specific process wasn’t followed
The expert reacts neutrally - either not showing much interest, or just fixing the problem, without connecting with the individual doing the work
The expert reacts positively - attempts to establish a relationship and help grow the individual with the work
Most commonly I see the neutral reaction occur. While this may be seen as a positive thing since it results in a good (or . acceptable) outcome, it doesn’t really serve anyone. It robs t he individual doing the work of the opportunity to improve by learning the proper way, and it robs the expert of the opportunity to educate their partners.
Fortunately I don’t see the first very often. I imagine this only really happens in highly controlled environments, or when someone is having a bad day.
Almost as uncommon though, is the third, which strikes me as very interesting since it is by far the most beneficial to everyone. Not only will the expert help solve a problem more quickly, they will also better understand their partners needs allowing them to head off future potential problems. The individual needing to do the work also gains a valuable contact, and likely learns a little bit more about how everything works.
Prompted Connections
While organic connects crop up when we basically randomly bump into an expert, prompted connections connect when someone helps us get an introduction. This may take the form of a manager knowing who to talk to, a coworker having a friend in another department, or a process requiring submission of plans/questions. I personally find these connections to be a bit weaker than organic ones, mainly due to the more artificial aspect of them (e.g. Organic connections tend to arise around a shared challenge, whereas prompted feel more like a job requirement), but they are still incredibly valuable ways of connecting partners.
Regardless of how connections form, they are absolutely critical to everyones success; even aa one-person company needs them to survive. I do my best to build new connections, and enrich existing ons, every change I get. I find them rewarding both in terms of learning new things, but also in terms of getting to know the people around me. They not only make my job a bit easier, but a but more enjoyable since I’m meeting new people, and picking up new skills.
"Generic" and "Specific" Basics
I’ve found there’s two types of basic skills - generic and specific. Understanding which one needs to be addressed helps folks better address underlying problems.
One of the great things about life these days is technology. It (mostly) makes are lives easier, especially when it comes to work. I cannot imagine having to keep track of employee data on paper, having to run payroll by hand, or generating reports manually.
The downside of tech is that it requires at least a baseline understanding of how it works in order to get any benefit. These basics may be more “generic” (applied across multiple systems or scenarios), for example knowing the magnifying glass allows you to search, to a more “specific” basic, such as knowing how your underlying data is sourced.
“Generic” Basics
“Generic” basics are things that can be applied across multiple systems or areas. Save icons fall into this bucket since they’re almost always a floppy disk (something that dates back as far as I can remember!), which is especially amusing since physical media of almost any type is quickly disappearing. The search icon is another example that appears almost everywhere.
Despite the prevalence of these items, unless you understand what they mean you’re in for a very frustrating time. I once watching a steelworker manually scrolling through a list of 5,000 files despite the search icon being displayed at the top of his screen. I stopped him after a few minutes and showed him what the magnifying glass did, the told him to call me if he ever looked around for files again (I’ve always wondered how much time is spent globally manually looking for things….).
Digital natives have a massive leg up with the generic basics since they grow up with it all (I’ve heard apocryphal stories of young children getting upset that the TV isn’t a touch screen). Since their training begins so young they’re able to easily translate those basics to work.
“Specific” Basics
While generic basics may apply across systems, concepts or ideas, specific basics are, well, specific. Some examples I run into include:
Workdays security architecture - Knowing how this works doesn’t really help you understand other systems security
Using a video game controller - I see this one a lot at home with my family. Knowing how to use a TV remote does’t help you turn on the Xbox to watch Netflix.
Perform data analysis - How data is collected, transformed, and stored has massive impacts on your analysis, but those changes differ based on the data source.
All of those examples are only really in the sphere they’re used in. Due to this Specific basics are generally only known by individuals in those areas.
Where Problems Crop Up
Things get dicey when someone :
Doesn’t know a generic basic
Incorrectly applies a Specific basic
Does’t know a Specific basic
The first tends to result from missing training. An employee is a physical trade skill (e.g. carpentry) may not be aware of the search icon, for example. This type is relatively straightforward to correct via training, but can be incredibly frustrating to that individual. It’s always a mark of a good
The second and third are where things get dicey. Not knowing Specific basics results in looking bad (example below) to catastrophic errors (inadvertently exposing social security numbers). Frequently I see these crop up when folks begin doing data analysis or presentation. Most recently I spotted this gem in a hospital:
97% isn’t a third of something!
In this specific instance the error wasn’t too catastrophic, but I always imagine what would happen if something like that was presented to the C-Suite.
Minimizing Errors
I’ve found the best way to help avoid both Generic and Specific errors is to work on connections with folks, and try to break down the “I only go to IT when something breaks” mentality. Having a solid (or developing) relationships makes it easier both for partners to ask questions, and for you to point out possible errors.
It’s also REALLY helped me to remember we all commit errors. Everyone has forgotten to save a file, or copy a formula, or how to correctly update something. Keeping our humility, and remembering we’re all in this together, will go a long way to keeping things running smoothly.
Trust. But Verify.
Trust what you’re seeing/being told…but always verify it with your own testing.
One of the favorite things I’ve learned working in IT is to “Trust. But Verify”. I find it especially helpful when I answer support tickets as users are frequently either mistaken about what they’re seeing (an ambiguous error message), or unable to provide all the information (e.g. they don’t realize they’re missing permissions). To me it means that I trust that the partner or customer I’m working with is giving me their best possible info, but that I still need to back it up and look into it myself. Pulling up the floorboards this way not only helps me determine the root cause of whatever’s happening, but also helps me learn about systems and processes in new ways.
Generally I don’t say “Trust, but verify” to the folks I’m working with (although I do use it in mentoring/coaching sessions to help folks get in the mindset of validating everything). Instead I have a number of variations I use, things like
“Prove it” - Generally more in teaching situations where someone tells me they have the answer / they’ve done something cool. I use this phrase to challenge the person I’m working with and see if they’ve really done what they think they’ve done. Also something I only really use with folks who know me and won’t be put off by the wording.
“Can you walk me through what’s happening?” - The more user-friendly version of “Prove it”. Everyone in IT know folks tend to report only small portions of what’s going on, this helps uncover the underlying pieces. It also helps my partners learn the process a bit better since they have to go through it a few times so I can understand it better.
In addition to answering support tickets, this phrase is also great when performing any kind of systems analysis. Frequently what I see isn’t what you get (the opposite of WYSIWYG). I’m finding this to be especially true as I navigate new systems (like Workday) that have underlying architecture or concepts I am unfamiliar with. Simply accepting what I see is a wonderful way to setup myself up for failure! In the same way I trust that my partners are telling me the best info they have, I have to trust that my current understanding is the best one I have at the time. I’m finding I cannot stop there though, I have to dig in deeper to verify what I think I see or know. This might take the form of reading up on documentation (everyone’s favorite past time!), or if I’m lucky asking a teammate who knows more than I do for help.
Every so often I give myself a reminder of this and forget to verify…. this usually results in a bit of rework as I have to go back in a fix things, but the silver lining is I both reinforce this lesson and learn the process a bit better. As a result I’ve found I constantly remind myself to not only trust my own work, but followup and verify that it’s the best I can do.
Lady Bugs - Always verify your data
When drawing conclusions from data it’s always important to look beneath the surface.
Recently NPR posted an article about a swarm of ladybugs showing up on radar system. I found this story both highly amusing (that must be a LOT of ladybugs!) and an interesting look at how we interpret and use data. The article mentions how the weather controllers saw the swarm show up and were rather confused since there weren’t any storms in the area that would make clouds. Then they took a step that many folks do not - they verified the data. Instead of just assuming that their equipment was showing them a freak storm, they called someone on the ground who could investigate and confirm what their equipment was showing them.
Frequently when we’re presented with a report/data/etc we take it at face value and assume it is reflecting reality. As that ladybug bloom shows us, that isn’t always the case. I regularly find myself stopping, stepping back, and seeing if I can prove to myself with the data what I am seeing. Does it take extra time? Yes. Does it help me avoid coming to wrong conclusions? Definitely.