T Shaped Skillsets
T shaped skillsets offer a single deep area of expertise, with a broad general base to support it. They can be great at helping bridge gaps, and filling in where others need support. Their depth, however, may not be as deep as someone with an I shaped skillset, and their general skills may not be strong enough in some situations.
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
“I” shaped skillsets are deep in on area of expertise, and light on others. This results in an individual very well versed in specific topics, but they may need support to fully maximize their impact.
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
We all build skill sets as we grow… but we can built them in different ways. Understanding the depth and breadth of our (and our teams) skills is important to our success.
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
Keeping an eye on details is important, but understanding how it all comes together, and how those details interact with everything else, is equally critical to success.
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
Keeping details in mind is incredibly important in life. Without them we can never really be sure what we’re doing… unfortunately many times though, we lose sight of this and suffer for it.
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.
Planning to (not) Fail
Planning is something we should be doing on a daily basis. Time taken to plan helps us focus our thoughts, helps avoid pitfalls, errors and mistakes later, and even makes us look good.
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.
Keep communicating until they tell you to stop
Communication is vital to our success, so don’t leave it to chance. When sending important messages, keep communicating until someone says “stop”.
Communication, like breathing, is one of things that humans must absolutely do in order to survive (citation needed). Since we’re born until we die we’re constantly communicating something, in some way. This means we’re effectively practicing this skills all the time… which only makes it more interesting that we’re all (generally) so bad at it.
90%
They (PMI in this case) tells me that 90% of project management is communication. I would further this, and say that 90% of our jobs, and general existence in reality, is communication. We tell our loved ones we miss them. Our children communicate that they’re hungry. Our co-workers communicate status updates. Even NOT communicating can be perceived as communicating (after all, ignoring someone tells them something…) (also, if you don’t notice someone is trying to communicate, you’re effectively communicating to them you’re oblivious).
On the plus side, we use this skill ALL the time. This would suggest that we should be getting better at it as we go. On the downside, we’re rarely consciously trying to improve this skill, meaning all that practice time is effectively wasted.
Shooting free-throws in basketball is a great analogy. Once approach would be to just continually shoot the ball again and again and again. Another approach would be to shoot the ball, then stop and honestly think about what you could do better (or not do at all). The first approach might get you more repetitions, however, the second will give you conscious improvement. Sure, it’s a bit of a pain to stop and critically examine yourself (not to mention ego-brusing at times), but the feedback gives you much better results.
Communication is no different. Many of us get TONS of reps in during the week… but many of us also fail to stop and think about how we can make those reps better (When was the last time you asked yourself if you’re communicating the right way?).
Repeat
One of the best pieces of advice I got on how to improve communication is to simply keep doing it until someone tells you to stop. Need help with a project? Keep bringing it up in different ways at different times until you get help. Need to let someone know when you’re available and you’d like to talk? Keep talking/texting/emailing until they get the point. This doesn’t mean send them an email every 10 seconds, but keep up the communication until you’re heard, and you know they heard you.
The good news is this skill is relatively easy to practice. The next time you need to communicate something you feel is important, pick at least 5 different times (and ideally different ways) of communicating that. One example of this:
Bring up your idea/need/etc. During a team meeting
Send a followup email immediately after the meeting.
Drop a slack message to folks the next day
Two days later send another followup email
The day after that bring it up in your meeting again
The point here is to ensure others received, and more importantly, understood, your message. By hitting them at different times in different ways you help ensure you cut through the noise (e.g. the 10000 other emails they have), and solicit any questions. And if all else fails, at the very least you have a great “paper” trail of your attempts.
Flexibility
Flexibility is an ever-more-important skillset. Bending yourself to a task lets you meet new folks, explore new areas, and even avoid things you don’t want to do.
In any given day I find myself coaching team members, managing projects, investigating bugs, being blindsided by new asks, and many many other things. Looking back, any given day represents a crazy mix of things, and juggling them all is certainly challenging. Despite the insanity of it all, I only really find problems when I try to control the flow things, or when I push back directly and reject doing something. Fortunately the best approach to this isn’t to just accept ALL work that comes my way, but rather to be flexible in what (and how) I accept.
Many roles these days are anything but specific. Job descriptions provide a rough outline of what a role is, but they can never fully capture what you’ll be doing if you get the job. Even if they’re fairly well written, they tend to include something like “duties as assigned”, which leaves a HUGE amount of room for other responsibilities to creep in. This craziness isn’t even touching the randomness that is smaller companies and/or startups!
Handling multiples
The wide range of randomness heading our way requires that our approach shifts from one of “I only do XYZ” to “I do a range of things”. The trick to finding a good balance within this range isn’t to remain rigid in how we accept things, but rather to be more flexible in what we accept, and more importantly, flexible in how we reject things. This may be further compounded by who is asking us to help out… for example if a VP is requesting help it can be a smidge harder to dodge that than someone else.
Being flexible in what work or responsibilities we accept has several benefits. Exposure to new areas/teams/ideas helps improve our overall skill sets. This can make our current jobs easier (by providing better context, resources, etc), and also opens doors that we may otherwise not have looked at (e.g. cultivating an interest in a new area of the company). Flexibility also improves our relationships, either by exposing us to people we wouldn’t otherwise work with, or by giving us time to deepen existing relationships.
Being flexible in how we reject work is equally (if not more!) important. There are times when you’ll decide you can’t/don’t want to take something on. When asked (or “asked”), straight up saying “no”, while direct, will likely be seen negatively (e.g. “you’re not a team player”), potentially damaging your reputation but also reducing the likelihood you’ll get help in the future. Instead you need to find a way to bend out of the way. Suggesting alternatives (“Did you consider asking so-and-so? They’re really good at this”) and pointing out better ways to do the thing (“Instead of manually doing this, did you consider automating it?”) are great approaches that avoid the need for YOU to do the thing, while still helping ensure it can get done.
Flexibility also means being open to changing how you operate. Especially now with many folks working from home we’ve had to change up how we work. Resisting the need for video conferencing is basically impossible, so instead of fighting these, flex, and use them. Sure, it requires some effort and creativity to find new ways to operate, but by making time to update team norms, meeting schedules, and other aspects of work you’ll avoid the discomfort of trying to fight the tide.
Make Time to Connect
Frequently back-and-forths are a signal that text communications are failing. When you notice this it’s best to change the medium - look for voice or video (or in person!) based communications to break the cycle.
Frequently I find myself either directly involved in, or watching, a chain of emails/texts/messages going in circles. One person asks a question, which is misunderstood or requires followup, which leads to more questions and goes around and around and around. It is incredibly easy to keep that chain going… after all, we know the other end is reading them, and we think we can get to agreement if we just. keep. emailing.
Unfortunately this is rarely the case… At best, this results in wasted time as it takes several cycles to get to mutual understanding. At worst, it results in damaged relationships. A much quicker (and simpler) approach is to break the cycle and connect - pick the phone (or jump on zoom) and take the 5 minutes to explain things in person.
Tangled
Communications technology is a weird thing. It allows us to instantly send messages, but weirdly this results in us being further apart instead of closer together. This could be due to the asynchronous nature of text communication (there’s no way to tell when the receiver will read it), in the static nature of the communication medium (sarcasm, for example is REALLY hard to pickup ion text), or in the assumption that other folks will “just get it”. Regardless, email or comment wars frequently crop up, with individuals endlessly sending messages hoping ONE of them will make sense to the other side.
We’ve all read a response from someone and wondering how the heck they didn’t understand our message. We took so much time carefully crafting our message, only for them to somehow miss the point. So we take more time to carefully craft a response… which is received in a similar manner on their end. This chain eventually becomes self-sustaining and will continue indefinitely unless someone breaks the cycle (the worst I’ve seen was a ticket with 150+ comments on it running in circles).
The problem with these cycles isn’t that the folks involved aren’t smart, or well intentioned, or anything about the person. It’s about the medium and some assumptions we make about it. Tools like email, slack and @ mentions are great for quickly sending a message around the world… unfortunately they also fail to capture a great deal of information. Tone is hard to encode in text… so is sarcasm, body language, and basically all of our body language. We tend to not see verbal communication run in as many circles because we get that additional information… we can see if someone is confused, or more easily pickup on frustration.
We also make assumptions about how we communicate and how others will interpret what we say. On our end we assume that our message is understandable. For ourselves this is (hopefully!) true, after all, we wrote it. For someone else, however, this may not be as correct. We all filter communication through our own experiences, and others rarely, if ever, have the same experiences we do. This ties directly into how someone else would interpret our message. Over time we get more familiar working with folks, but even WITH experience we can send a confusing message.
Finding Clarity
The trick, then, to breaking the circle of endless text communication is to step outside of it and use a different method. Getting back to a place where non-text information is shared (phone, video chat, etc.) will reduce or eliminate many of the problems pure-text conveys. By making communication more real-time we also provide immediate opportunities for the other parties to ask clarifying questions or point out challenges immediately. By both reducing the feedback loop, and providing a richer communications environment, we can make our connections much more impactful.
Short Bite - Get it done
One of the craziest things I’ve done to keep a project deadline was an overnight Seattle -> Portland roundtrip to upload a database… nothing like sleeping on the floor of your office while a script runs to get the blood pumping.
Backing up entire systems is a very data-intensive process. Not only does it involve moving a ton of data, it requires specific timing in terms of jobs, processes and systems to ensure it is done correctly. Even with dedicated data lines, this process can take hours, or sometimes days, which in general is OK. I, however, found myself in a situation where we had to get a copy of our database from Seattle to Portland by 8am the next day.. And it was already 4pm.
The Problem
We had two data centers that mirrored each other, one in Portland, and another in Seattle. This is a common setup for data centers since it allows for fault tolerance in case one goes offline, and can help provide faster speeds depending on which one you’re closer to. We had just completed a big update in Seattle data center, and needed that update to also be made in Portland. These updates were critical to the success of the project, and due to some (I’m sure very important) technical reasons both data centers had to be up to date. One option was to do this “over the wire”, that is copy/paste the information over the internet. This was the simplest method, however, also the most time-intensive. This was an incredibly large update, and despite having a dedicated line between our data centers estimates ranged from 12-48 hours to complete the update. Unfortunately this delay would break out deployment schedule.
The Solution
Someone pointed out that driving from Portland to Seattle only took about (a very boring) 3 hours, which was a LOT faster than going over the wire. We hatched a plan to copy the updates to a laptop, drive them down to Portland and perform the update overnight. (Despite advances in wifi and internet speeds using the “sneaker net”, or physically walking data from point A to point B is still the fastest way to move data).
Wanting to ensure others on the team could focus on their work (and also to maybe get some quality alone time), I volunteered to be the courier. After quickly downloading some new music I was handed a laptop and a list of commands to run when I got to the Portland datacenter. After a (very boring) 3 hour drive (Protip : bring more than 2 CDs), I plugged into the Portland datacenter and took a nap while the updates ran.
A few hours, and one massive update later, I drove back to Seattle.. Where I promptly crashed in my hotel room for a few hours.
The Takeaway
Ideally projects do not present situations where extreme solutions like driving all throughout the night are needed. Ideally.
When those situations are encountered, however, it’s always a good idea to get the team together to brainstorm. See what possible solutions you can come up with (no matter how insane they sound), and then pare them down to what’s possible given your requirements. In this case, we HAD to have the update live the next day, so that ruled out some options. It was also possible to safely use the sneaker net to make the update happen (e.g. I didn’t have to break all the speed limits).
Plus, sometimes you’ll get a great story out of it.
Setting Up Ad-Hoc Teams
Many hands make light work. They also make for great opportunities to setup ad-hoc teams to help support a new process.
Implementing a new system takes a ton of effort, planning and energy. What happens AFTER implementation is equally important, although it frequently doesn’t receive nearly enough attention. In this case I’ll take a look at how I provided post-implementation support and training for a group of admin assistants, taking them from brand-new users to local Subject Matter Experts (SME).
The Setup
After a large Enterprise Resource Planning (ERP) installation we moved into the support phase of the project. This was a massive change in pace since the pressure to implement on a schedule entirely vanished. We no longer had executives breathing down our necks, and the gaggle of consultants who had been prodding us into action had (finally) left.
Instead we had the crushing grind of daily challenges presented by 3,000+ users of a new system - “I can’t log in”, “how do I add a purchase requisition?”, “Why can’t I find project X?”. Since there was no way I could (or would ever want to!) handle all these requests, I started looking for better alternatives. Specifically, I began looking for a group of folks I could train up to be strong enough to handle the daily questions, thereby freeing up my time and also improving our support for our users.
Likely Suspects
The company I worked for had multiple locations spread throughout the Pacific Northwest. These facilities ranged in size from 1,500+ employees, all the way down to 10-15 folks. What each location had in common, however, was they all had a dedicated Administrative Assistant. This individual was responsible for handling general office tasks, including being the local expert with the ERP. “General tasks” might include data entry, helping other employees at that site with problems and being involved in testing or other updates. Basically, these folks were the swiss-army knife of their office - they knew everyone at their site, knew how the business operated, and were very good at what they did.
Until the ERP system was updated, and they were a bit lost.
This is the challenge with any system update - things change, and users don’t like change. They don’t like it when buttons change or move, and they REALLY don’t like it when they can’t do their job because they don’t know what to do. These admins, however, were very well plugged into their local user base (they knew most folks by name if not personally), and, even better, the local users were used to going to them with questions. This made the admins prime candidates.
Beginnings
Luckily I had already been introduced to all of the Administrative Assistant’s over the course of the original implementation. This gave me a great leg-up since they already knew who I was and had some idea of what I did. This made getting the group together significantly easier as I did not have to sell the idea to both their managers AND the Assistants. I still needed to connect with their managers (and mine) to align them on the idea, however, having previous contact made this process substantially easier than it can otherwise be.
Getting in touch with the managers was the first step. After all, they’re in charge of these folks workload, and once sold on the idea they are a great resource to improve the process. Managers can also shut everything down really quickly if you don’t include them (either for perfectly legit reasons like workload, or just because they don’t like you!). This makes their involvement, and more importantly, buy in, critical to our success.
Once I had all the managers aligned on the purpose and need for this group, my next step was to connect all the admin assistants together. Since I already knew them this was as simple as sending them all an email and jumping on a video-conference together. Most were already aware of the idea, so getting their buy-in was relatively easy. This particular group was also motivated by the need to make their jobs easier, and interest in getting more training on the system.
Sidenotes
What if you don’t know everyone? - Don’t worry, this part’s easy! Just sit down, identify everyone in the group you’d like to include, and go say hello. Ideally you can do this in person, but any method works. The main goal of first contact is just to put a face to name, don’t worry about getting them to sign on to anything yet. You’ll also want to introduce yourself to their managers and begin acclimating them to your idea.
What if a manager pushes back? - This can be rather common… some managers are protective of their space (either due to legit reasons like workloads, or more political ones). Do your best to back up your reasoning for needing their direct’s time (e.g. this will save X hours over Y days), and tie it into that individual and managers job (e.g. getting Suzie involved will reduce the accounting errors you’ll have to deal with). If you’re still getting push back speak with your manager and see if they can help influence. Sometimes it just takes another voice to get someone over the line.
What if you have unenthusiastic targets (e.g. my Admins)? - Sometimes the folks you want to include in the group aren’t the best options. They might be uninterested (“not my job” syndrome), unable due to workload (it’s possible you can change this through their manager), or they may not trust their skills (easier to fix via training and exposure). Your challenge is to identify WHY they’re unenthusiastic and attack the root cause. Are they shying away because they don’t know the system? Train them. Are they afraid other work will suffer? Talk to their manager. Do they think someone else would be better? They might be right… talk to that person. If all else fails, see if you can find someone else who would be a good fit.
Admins, Assemble!
Once I had my group identified and had manager buy in, the fun part started. I first went about documenting as much of what we’d be looking at as possible (this ended up being over 300 pages of custom build pages, but more on this in another post). Fortunately their jobs were fairly well defined, so I could make a laundry list of items they would be responsible for. Having clear documentation allowed me to easily spin up lesson plans to help round out their skills, and, more importantly, gave them a resource that wasn’t me to go to for help (a very critical step towards maintaining my own sanity).
I then setup a recurring video chat with the entire group on a weekly basis. Originally this began as a 1 hour connection, but as they became more confident in the system we reduced it to half an hour. The recurring meetings were mostly used to address challenges they ran into with the whole group. I would also hold ad hoc meetings as needed (e.g. in the case of a system failure, critical update, targeted coaching, etc.).
While the meetings began more as a group lesson, they became more slanted towards team building as time went on. Instead of helping them with the answer I would challenge the group to try and figure it out. I would also have admins teach each other when they ran into problems (generally after I helped them through it in a one on one). This helped build their confidence in the system (e.g. don’t bug Rob, you can figure it out), but also their confidence in each other (I can’t figure it out… but I know Gina is good at this too so I’ll ask her first).
Everyone also had write access to the documentation, which they would update as they ran into differences or found errors. We also went over those changes in our weekly meetings to ensure everyone was up to date, and would update documentation together when it came up.
The Endgame
Eventually the Admins became fluent both in the system and in how to address challenges. They were comfortable both in their own skills, but also in relying on their team (and not just me!) when they needed help. I did notice, however, that they would still come to me with questions they should know the answer to (or have documented). This was likely just inertia - they were trained to go to me for help so they kept doing it - but it wasn’t serving them any longer (and it was annoying me).
To solve this, I setup a simple game. Any time they came to me with a question we’d first check our documentation. If the answer was in there, I’d get a point, and if it wasn’t in there, they’d get the point and we’d add the answer. Points weren’t redeemable for prizes, but were intended to serve as a reminder that they had the power and knew what to do. I also didn’t want them to be afraid of coming to me for help (especially on BIG problems), so I made it clear I’d always help them if they asked.
They almost immediately stopped coming to me with questions.
Lessons Learned - Setting up a Team
Get Buy in - Ensure managers are on board. Ensuring that your potential team’s actual managers are on board with your plan is critical. Be sure you’ve got a well thought out idea, and can demonstrate how getting some of their time and energy will benefit both the team and the manager.
Build Resources - Build documentation, get access setup etc. At the end of the day what you’re really going for is a self-sustaining group to knock out some work. To be successful the team will need documentation, references and training so they can build their confidence. Taking the time to do this early will both help make the best product, but also set yourself up for success later.
Constantly Connect - Regular meetings and interactions are key. Not only do these touch points give you an opportunity to improve your relationship with the team, they also help build a sense of camaraderie. This time helps the team learn to trust each other, and allows them to form connections that don’t require you to be involved.
Encourage Collaboration - The main goal is to replicate yourself (to an extent, anyways). To really be successful at this you cannot be the only place someone can go for help. Encourage your team to ask each other for help, or have them each take the lead during a meeting and train everyone on something. Over time they’ll learn they can go to each other instead of bugging you.
Leading vs. Managing
Leading and managing are both skills we pickup along the way. Neither one is inherently better than the other, but both are very useful to have.
A very common question thrown around is “What is the difference between a leader and a manager?”. To me, it is very straight forwards - A Leader leads, and Manager manages. Leading or managing are not necessarily good or bad, but understanding the difference is important.
Leading
Another term for leading is “to guide”, although a much better one for me is “guide someone along the way”. In a literal sense this might mean showing someone how to get somewhere in town, although this is only scratching the surface. While physically guiding someone is a great thing, generally in our workplaces leading refers more towards guiding someone towards a goal. This goal could be improving a sales metric, implementing a new system, or welcoming a new team member. The specific instance isn’t important, instead it’s the vision and seeing a path to achieving it that is interesting. Leading is the ability to see an end result, and bring people along the path to get there. Therein lies one of it’s challenges - you have to get people to follow you to that destination. For me, figuring out how to convince others that my goal is worthwhile is part of the fun. Not only does it challenge my view points (and help improve my idea), it helps foster stronger connections with my teammates.
Here leading goes beyond pointing at some distant point and saying “go there” and extends into being part of the journey and solution. Just like giving someone directions to the post office isn’t leading them (you’d have to actually walk with them there) leaders don’t just sit back and give pointers. Leaders are part of the journey to the destination they envision. They share in the successes and challenges with those they lead, and help the group reach the destination together. Frequently it feels like many projects suffer due to a lack of leadership - someone seeing the way forward.
Managing
Another term for managing is “to exercise executive, administrative, and supervisory direction”. This implies that one is placed into this, and that one’s power to do those things is reliant on someone behind a bigger desk. It would, for example, be very hard to just decide to start managing a team or process at work without your boss (or someone else) making it official (although it would be an interesting exercise in confidence to just walk in and take something over like that).
Frequently we focus on the “supervisory” and “executive” parts of that definition, which makes sense; they’re the most apparent in most jobs. Line workers reports to their supervisors, CEO’s manage their companies. Titles frequently have “Manager” or “Team Lead” in them to indicate some amount of power over subordinates.
Managing doesn’t solely relate to managing people, however, which is where the “administrative” part comes in. Process managers are individuals who keep an eye on processes and are incredibly important. These individuals serve as the main point of contact for decisions about a system or process. While they may also manage others, it is not necessary. Executive assistants are another example; they manage their manager’s calendars, schedules and other tasks without directing others.
I’ve always been intrigued by this multiple meaning, and found it very interesting when an individual wants to be a “manager”. They’re very rarely referring to the administrative part, and almost always fixated on the “supervisory” part, likely because it is perceived as the only way to progress or improve in one’s career, something that is incorrect.
What’s the difference?
A leader is someone who steps up, points at a destination and goes (with or without followers). A manager is someone who occupies an official capacity and ensure whatever resources are available are being used properly (be they people, equipment, etc). It is entirely possible for an individual to be both a leader and a manager at the same time, or just manage, or just lead, or neither. None of these combinations is inherently better or worse than the other, just different. The higher up one goes in an organization, however, the more likely it is they’ll take on a blend of roles. A CEO, for example, must both manager and lead.
Many of us get it stuck in our head that unless we are officially ordained to do something, we can’t/shouldn’t do it. The thinking is that unless someone higher up (your boss, the CEO, whatever) decides to do something, it doesn’t need doing. This is entirely backwards. There can only be so many official managers/leaders at any given company. This means their sight is limited and guarantees they will miss something, or that they simply will not have time to get to everything. This opens space for leadership to occur at all levels, not just those “official” ones. This allows “non-official” leaders at all levels to step up and, well, lead.
At the end of it all
Both managing and leading also be practiced at any scale. There’s always small projects the need leadership (those little things that annoy you, but aren’t “important” enough to make official), and we all manage SOMETHING in our lives (finances, computer use, etc.). The largest difference I have seen is that leading can be done by anyone in almost any circumstance, whereas managing generally has some conditions that need to be in place (e.g. being made a manager). It’s important not to get stuck in a mental trap that the only way forward in your career is to be a manager or leader, and instead focus on the impact you can make.
Priority Zeros - Everyone’s got ‘em (sometimes several)
Finding a way to prioritize work is critical to success. The one approach that should NEVER be taken is to have the tech teams determining the priority… they’ll almost always get it “wrong” and end up agitating partner teams.
Priority Zeros. Everyone's got one, something dozens (which I always find amusing - how can there be multiple highest priority items?…). These items are the highest priority and most important item for any given group or individual. It's a great thing when a team can truly determine what these are as it allows them to direct work. It's a much less great thing when tech teams are given them without a structure in place the help manage them.
Collision alert!
Once you get to the point where you're regularly identifying P0s you’ll (hopefully!) start looking at how to accomplish them. This generally involves passing parts of the ask to other teams to do the work. Depending on the ask this can span large swaths of the company, or just a small targeted group. Given today’s information-rich environment, tech teams are almost always impacted by these asks. While it’s great that tech is thought of as being needed, a very serious challenge begins to emerge - What happens when tech gets a P0 from Finance and one from HR?
In an ideal world this balancing has already been taken into account where a designated person or group determines the actual priority (Finance then HR, or use some semi-objective ranking system, e.g. which one costs the most to implement). I won’t delve too deeply into what that process looks like, but this group should be ordained by the business to make, and defend, those decisions so the tech teams can focus on execution. This approach is great since it removes any pressure on tech to determine which should be done first and provides clear guidance on what order stuff should be completed in. It also helps ensure the business know’s what tech is up to, and when they are doing any given item (other very common challenges with prioritization).
More frequently, however, the decision is dropped on tech, and tech has to figure it out.
This is a terrible idea.
I dunno, that one first?
It's terrible because tech doesn't know which item is more important to the business. If we’re lucky we can sometimes make an educated guess, but this is very much a mystical art from the tech standpoint as is it very rarely objectively clear cut. For a vast oversimplification (many tech projects span months if not years), is it more important that an alert goes out from Legal or a finance report has a column added? Tech can guess (I’d hazard towards Legal on this one?), but at the end of the day it’s not your tech team’s job to determine priority of this type of work - it’s IT’s job to execute on the decision that is made and to ensure that it is executed properly.
In addition to potentially the “wrong'“ item being worked on, it’s terrible because no matter what order tech completes the items in it will be 'wrong’ to one customer or the other. If we go with the “Legal” option above its highly likely that Finance will come back at us more than a bit unhappy. Tech can try to justify why they chose a specific course of action, but at the very least this takes away from time better spent working on the item. Even if there is some justification Tech uses, it’s likely that Finance will disagree with the criteria (e.g. why are alerts weighted more than reports?). This ties back to having an ordained group or individual that all groups trust - it helps eliminate frustration down the road.
But we don’t have that…
There’s a variety of reasons why that ordained group or individual doesn’t exist yet. Maybe your company cannot afford to dedicate a single headcount to it (yes, this is a full time job). Maybe your company wants to, but has higher priorities (a bit ironic that). Regardless of the reason there are some steps you can take to help bridge the gap / mitigate the damage. This will require some amount of process / procedure, however, it will help protect your tech teams and avoid frustration from the business.
The intention of this individual is to provide a source of truth for the order of your tech teams work. This requires this person to be familiar with everyone on the tech and the business side, and have a working relationship. This person also needs to understand how the tech teams operate and what their capabilities are. A person like this may already exist on your team (or on the business side). This may be a finance expert who wants to learn more about tech, or a techie who wants to get a better feeling for how the business operates.
You’ll also need to get leadership buy-off on this stop-gap. Figure out who the decision makers are on the business and tech side and grab some time with them. Explain you want to dedicate X amount of someone’s time to helping prioritize and order tasks (with input from both teams). It shouldn’t be too hard to get buy in as they are likely feeling the pain of not having this role, but you can always point out the time/heartache savings by having an objective to-do list. You’ll also need to setup some kind of regular update/meeting with this group so they feel comfortable trusting your designated individual, but this is good since it will help keep you honest and get you feedback.
It is definitely an iterative process, but once trust is developed and the wheels start turning more easily marked improvements in efficiency and grey-hair will start to show up.
Same team!
It’s REALLY easy to fall into the trap of blaming the business or the tech team for a failing project or take out frustration on them. At the end of the day the most important bit to remember is everyone is on the same team. Tech teams don’t have anything to do without the business (except watch server lights flicker) and the business will have trouble improving without tech (there’s a limit to gSheets). The challenge is in bridging the gap, in helping the tech side understand the business’s priorities, and the business understand the tech teams capabilities. Providing a single point of truth for what should be worked on is a huge step in that direction, and one that you can start taking without breaking the bank.
When should Tech be involved?
Frequently technical resources are pull into projects at the last minute. This deprives the project team of a valuable viewpoint and raises blood pressure all around. Tech should be included as early as possible to best leverage their skills and avoid last minute scrambles.
Very commonly companies have to make important decision about what they should do. These decisions typically involve a number of different departments (legal, HR, finance etc), all of which provide an important and necessarily piece of input to the Decision. For some reason Tech seems to be frequently forgotten about during this step in planning.
Failing to plan….
Due to the expanding info-tech nature of work it is critical that technical considerations are taken into account during planning. This includes things like giving tech a seat at the table, including team members in planning meetings, and ensuring they’re included in updates. You wouldn’t, for example, not include Legal in a big decision, why is IT any different?
Planning is a very important thing (citation needed). Even the smaller projects or initiatives need time to be shaken out. Schedules need to be determined, resources need to be found (or borrowed… or stolen…) and communications need to be setup. There are a ton of moving parts that need to be managed, such as figuring out what teams are involved, and who is responsible for what. Many projects share some amount of requirements, for example having a unique email, that tend to be better understood by the project teams. Almost every project, however, can benefit from additional technical expertise, and this is where a breakdown frequently occurs.
While many pieces can be managed without technical support, almost every aspect can benefit from a technical view point. This may involve tools that the project team is unaware of, help developing an ideal process, or access to key systems. All of these decisions also will require some about of IT help, even if it’s just setting up an email alias or standing up a file share. Generally not having the tech teams involved early will result in either a mad dash at the end to get them up to speed, or a diminished project result.
“Just IT”
This boils down to mis/pre-conceptions about IT itself. After all, IT just pushes a button and the thing works. It can’t be THAT hard to setup a new email alias, so why include them at the kickoff meeting? This is only compounded as projects become more complex. (If you don’t understand the underlying concepts moving 2,000 workers around your HRIS seems like an easy thing, just a button, right?) . This apparent lack of appreciation for the complexities of modern information systems results in IT being left out of the loop. Several times I have been looped into projects with only a few days before go-live and asked to complete what should be 3 weeks of work in 3 days.
Including tech at the start of the project helps avoid these types of situations. On the one extreme is tech saying they’re not needed, but on the other is avoiding a massive complication. This may also require some amount of discretion depending on the topic (e.g. a super-secret merger or HR event may require more selectiveness), however, tech teams are used to handling highly sensitive data so it’s just another project to them. At the start finding the right person(s) on the technical side may be a bit of a challenge as the help desk expert may not know anything about the HRIS side of the house (and vice versa). One way around this is to include one individual from each tech team at least is consulted and asked if they might be needed. Another method would be to approach your tech leadership and ask them who the best individuals to include are since they’ll have a good idea of who’s best suited for the task.
Business + tech = win
Once tech is regularly involved you’ve given yourself a number of advantages. The least of which is IT becoming aware that something is going on. This doesn’t seem like much, but is a huge step in the right direction. Like any team they have restricted resources, so we’ve now given them a chance to put your ask into their planning cycle. This helps eliminate the possibility of not having the right resources available to do The Thing (or giving folks premature grey hair…).
Even better, it also allows IT to point out potential problems with your approach. While I have great faith in my business partners, tech is not their area of focus. Frequently this results in them sticking to habits / easily available things (google sheets, anyone?), resulting in tunnel vision. Maybe there’s an easier way to communicate with everyone, or maybe you’ve forgotten about some restriction. More diverse brains, earlier in the process, can only help.
If a technical resource cannot be included (maybe you don’t have one yet, or maybe they’re slammed), another approach is to find someone on your team who is more technically minded. Maybe this individual has worked in tech before, or works closely with the tech teams currently. While this person may not be a technical expert they should be able to at least point out areas where tech should be involved. The goal is to find a way to get a technical viewpoint on your project as early as possible.
All together now
Many, if not all, parts of a businesses project can benefit from including technical resources as early as possible in the process. At the very least you’ll avoid last minute scrambles, but more likely you’ll enhance the overall project in ways that are hard to see at the start. You’ll also build a better relationship with those teams, improving overall operations and helping improve future projects. Your tech teams will thank you as well, since they’ll feel like they’re part of the great team instead of being delegated to being “just IT”.
"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.
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.