Confession number one: That quote was pre-populated into the blog template. I have no idea whatsoever about whom to attribute that quote to (neither does the internet, it seems, because there’s no evidence that Oscar Wilde ACTUALLY said that), but it’s relevant to the motivation behind starting this blog. I’m aiming to chronicle my path through the twisted world of IT… read that again, my path. However, weirdly enough I’ve been to enough training courses, trade shows, and conferences and networked with enough professionals in my field to know that while the players change, the game remains largely the same. The experiences are shared, the frustration common, and the stories… uncannily similar.
Hiding behind big, popular words like “DevOps” and “Agile” and “Process” are people who largely struggle (in my experience) with the same sorts of challenges across every vertical in this profession. That’s the good and bad of IT, really, because generally speaking, it isn’t industry specific. My path has taken me from services, to public education, legal, manufacturing, aerospace, higher education, and more… and everywhere I go, I’m still IT.
In that same vein, however, there’s always this chasm between the business units and IT. This feeling that the business and IT don’t see eye to eye. I’d bet that’s the reason behind the high turnover in my profession, but I digress. Here’s where you get the IT-isms such as “adding value back into the business”, but it’s more than that. It’s learning to live in an IT driven world, even when the businesses don’t see it that way.
Maybe you’re like me. You grew up being tabbed as the person who, if it plugged into the wall, you were responsible for fixing. You got calls from your grandmother about how to change the input on her TV. Your boss calls you from another country because his personal email won’t load on his (personal) iPad (true story), and your places of employment all recognize the desperate need for (IT) change, but want it to look, act, and feel exactly the same.
Or maybe you’re not! Maybe you see IT as the great mystery – you don’t understand what we do! Or why, for that matter! I always joke that I’m like Chandler Bing (from Friends)… nobody (even in my family) knows what it is I do.
This blog is for you. I’ll share tips, tricks, and stories about how I got to where I am, and hopefully in a somewhat humorous way, give thoughts about how to make IT normal in an IT world. Hopefully you realize that you’re not alone, that the players change, but the game remains largely the same. Then, we can walk this path together, not as the “IT guy” (or gal), but as a normal person, who just happens to be proficient in IT. If I can provide you just a little perspective on an otherwise ambiguous career path, then I see that as an absolute win!
So these are my confessions, written down so that you all can relate. Or not…. But I’m willing to bet that my experiences in this wonderful profession are more shared than not.
I had a recent conversation with a VP, and despite my protestations and disagreements, he said (rather matter-of-factly), “If it has X’s and O’s [sic], you own it”. I knew the conversation wasn’t a collaborative one, so correcting him by telling him it was “1’s and 0’s” wasn’t going to be productive, and probably be a detriment to a conversation where I was clearly being assigned something that I didn’t think IT should be assigned.
Truth is, I still disagree – because I don’t think IT should “own” much of anything, to be honest. Actually, by his logic, if IT actually “owned” all things 1’s and 0’s that would pretty much constitute most of everything… don’t you think? In the digital age, not much is done by way of analog anymore… Does IT have the authority to be the gatekeeper for all things?
I worked in an environment once where the manager (my boss at the time) took that stance, that IT was the gatekeeper to all digital assets… What it resulted in was a culture that viewed IT as an impediment to their ability to work. Furthermore, when something would go wrong, regardless of whether it was actually an “IT” issue or not, the organization would have carte blanche to blame IT, because such was the culture… “IT didn’t give me [X], so I can’t do [Y]”. You wouldn’t believe the level of ridiculousness when it came to the perception of IT in that environment. The thought process behind the level of IT interference was so bad, I remember during a company luncheon (I believe the In-N-Out truck was there to celebrate safety), the C.O.O. (who was… advanced… in his age) argued with the us, the IT team for 45 minutes because he insisted that my manager had developed some sort of software that told him that he had typed his password in incorrectly at login every time. He insisted that the second time he tried to login, he was permitted, but that first time always told him it was incorrect – he was convinced that the IT Manager was purposely creating a lag to slow down production.
Culture is a difficult thing to fix… long after that manager departed the company, lasting sentiment about how much IT affected how the organization did business hovered for a long time. It wasn’t until I was able to provide actual metrics regarding requests, response times, effectiveness, and data for rebuttal that perception began to shift, slightly. Even still though, three years later when I departed the company, there was guilt by association.
I don’t fault the IT manager, though. He built the environment from the ground up, and so speaking from experience, when you feel you “own” all the “1’s and 0’s” there’s a tendency to protect your customers (the users IT supports) from themselves. We used to joke that his favorite phrase when being asked for something was, “What is the business case?”
So how much should IT, “own” if anything at all? That’s a tricky question. IT’s influence is no doubt felt throughout the entire organization, from printers to scanners to computers, to software, development, automation… in the “digital” age – everything is done with something that uses “1’s and 0’s” to do its job. With that said, should IT own “everything?”
I would always answer no. The answer I give is this: IT should not be relied upon to do day to day operational tasks. I’ll give an example –
One of the locations I worked at, somehow, some way, became reliant upon IT to run MRP everyday. Without going into heavy manufacturing theory, MRP basically allows the business units, daily (at this place) to know what items they required to make their job loads, how many of said items, and when they were going to be needed, based on the schedule. The idea is that if everything is scheduled, you can operate at peak efficiency, because you have the exact amount of raw material available to you to manufacture your product, without any waste, and more is delivered to you for your next job… I digress.
The MRP module was a module within our ERP system, and somehow, many years before I had started there, it was given to a developer in my department to run. When she went out of town on vacation or was sick or anything else, it was very likely that MRP didn’t run, meaning that production would have no visibility as to what materials were needed that day, or when… and things would be ground to a halt.
IT should never be the lynchpin to which a process occurs everyday. Yes, it’s 1’s and 0’s, yes, it runs in a software environment, but the process should be OWNED by the department that uses it (in this case, Materials Mgmt).
So what does IT own?
In this case, infrastructure, and the software and systems that these business processes run on are owned by IT… but the processes themselves should not be. In the case of my first example, where the VP was talking to me about what I “own”, this particular VP was trying to make the case that IT “Owned” and was responsible for the development of the website. I’m not a web developer, and know enough to be dangerous. I can manage the vendors, however… but that’s not what they want. The disconnect came when I said I lacked the credentials to make decisions based on the marketing aspects on the site, like content and functionality – but could advise as to the platform and technical requirements.
Needless to say, I’m now in charge of the website content, form, and function. Yay me. (Can I put that on the resume?)
I’m being slightly sarcastic about the entire thing, but the truth of the matter is, why do you want your IT guy deciding on what goes on the website? Just because it displays on a screen doesn’t mean the IT guy has dominion over it. You take your car to a mechanic, but you don’t ask them where you should drive on vacation… that’s on you. He’s just there to support your desire to do so.
It’s this scope creep that gets companies in trouble, that expands IT costs in a way that becomes uncontrollable. In a world of specialized jobs, why does the IT guy a generalist for all things that require electricity and network? (As I write this, I’m developing a financial report that’s doing business analysis on price changes of our products, based on targeted gross profit margin…. So there’s that)
IT needs to supplement the business processes that the BUSINESS owns. The disappointing thing is that the buck is usually passed to IT when there isn’t a specialized talent there to handle the task. It plugs in! Give it to IT!
At the end of the day, in order to bridge the gap between organizations and their IT, and the chasm of understanding between the two, it’s clear that IT will have to wear multiple hats, and I’m well aware of the risks, as they were, in doing so. But IT has to be upfront and relinquish control as well, be honest with the business about what they can, and cannot do… and what they should, and shouldn’t own.
IT Executives tend to wear out their welcome after a little while. I’ve explored this before, but the premise is that with a new IT exec, there tend to be massive changes that accompany the arrival of the person. A new system, an implementation, organization, practices, etc… but as time moves on you get a regression toward the mean — or more simply put (in the article) “extreme performance tends to get less extreme the next time” Why is this? SImply put – you run out of projects to do, and eventually you go into maintenance mode. Right or not, the organization judges IT Executives (Directors) on a “What have you done for me lately” style – and so when the changes become less extreme, the (wrong) thought process is that the IT Executive is doing less, and so therefore the organization begins the process of replacing that executive, which starts the whole process over again. The new person will bring with them a stash of projects and ideas that the company will implement out of excitement, and then eventually that person will wear out as well.
I don’t have any real stats to prove this, but I had a previous IT Director that I reported to once tell me that the lifespan of an IT Director is 3-5 years. I believe it.
Thus – companies are always on this cycle of looking for new IT executives, depending on where on the “bell curve” the current IT executive is in their lifespan.
In my career I’ve changed jobs a few times for one reason or another. Better opportunities, better pay, closer to home, increase in title, etc. As I reflect on my career journey to this point, I notice that there have been some similarities as to how IT executives, and even standard IT technical people are recruited, but I’m not sure that’s the best way to do it…. And it has to do with the right fit.
Recruiters are usually given a technical “checklist” of attributes that an organization is looking for in a potential new person. If you’re looking for someone who makes a widget, you usually start by listing a request for someone who has that particular “widget-making” experience. The recruiter very often has no idea what it takes to make said widget, only that the candidate has to meet the “widget-making” requirement on the checklist before the candidate would even be admitted to a hiring manager.
In the IT world, I find that this backfires quite often. I had a recruiter once tell me, “it sounds like you really know your stuff, but this client is looking for someone with RDP experience, and you don’t have that on your resume.” After assuring the recruiter that I was quite proficient in RDP, he then asked that I revamp my resume to mention it a few times so that the hiring manager can see it. So I did… uneasily, but I did.
This began a snowball effect in my mind about how to go about looking for a job. Does one make a specific resume that hits specific listed points so that you can get through the door? I suppose that’s the way to play the game, but I can’t help but think that organizations are short-changing themselves out of perfectly viable and perhaps better candidates by insisting they have arbitrary attributes that some job description has listed, versus gauging a technical candidate on their intangibles? Is too much importance put on specific acumen as opposed to how a particular person reacts, handles, or adapts to a situation? Can a weighted system where a technical baseline is pitted against a candidates intangibles make for a better choice in candidate?
I had a job interview for an organization once where the “wrong” answer on a technical question cost me the ability to procure the job. I had gotten along swimmingly in my initial video interview with the panel, and all looked very good for a second interview. The premise of this particular job was that this IT Executive was to bring management of IT resources in-house. Things looked good. It was for an exciting, well funded company, and the benefits were great. There was no current executive, but the firm had been using a consultancy to manage their IT needs.
Therein lay the problem. During the second interview, the firm asked the consultant to ask technical questions. Besides the fact that it was a conflict of interest (why would the consultant sign off on a candidate that would potentially lower the consultant’s footprint in the organization), I couldn’t remember an oddly specific question about a feature of Microsoft Exchange. I answered the question, with the caveat that I’d have to look it up (trying to prove that I have the resources necessary to adapt and find the answers that I didn’t know off the top of my head) but it was too late. The nail was in the coffin, and they didn’t hire me, despite the recruiter telling me that I was their first choice.
Conversely, I worked for another organization that had me interview with a technical person, but then with a non-technical person for “mission fit.” I thought this was a pretty smart approach. There were no “gotchas” in the technical interview, only an establishing of a baseline to prove that I could handle the level of technology that I’d be managing at that organization, and then I was passed on to another executive to determine if I was a “mission fit” (also referred to as “cultural fit”) to the organization.
The interview went well, and at the end when I was asked if I had any questions, I inquired about the “mission/cultural fit” interview as I hadn’t been part of that to that point in my career. The person I interviewed with told me, “the tangible, we can teach, but we want to make sure you have the intangible.”
Somewhat recently, I had met with another organization who was looking for an IT executive. After a couple minutes, I could tell that they didn’t really know what they were looking for. There was someone in that role before, they had left, and for 8 months the role was vacant. They quizzed me incessantly about their particular ERP, the different applications they used, everything from their hardware purchases to data consolidation to worldwide collaboration between different ROBOs (remote office branch offices). I flew through everything, not hiccuping once, answering all their questions. I explained that someone to keep up the status-quo wasn’t exactly what the organization needed, and explained my spiel about bridging the gap between the organization and IT, aligning the business priorities with IT, and helping drive top-line revenue. Same story, the recruiter told me I was far and away their first choice.
I didn’t get the position. “The other person was a better fit,” the recruiter told me.
Now, giving that organization the benefit of the doubt, maybe the other candidate did blow them away. Maybe they were charismatic, knowledgeable, and motivated. More likely, they probably fit within their budget better, but it doesn’t change my point. There’s a vicious cycle where a request for an IT executive is put out by an organization that really isn’t sure what they need, but rather, are choosing an IT executive based on a checklist that someone, somewhere put together. A few years later frustration grows (due to regression towards the mean), the IT department is looked at as a cost center that needs to be reduced (instead of helping drive top-line growth), and the IT executive is replaced, with the company looking again for someone with (likely) the same checklist for “skills” that will get the next person through the door. Wash, rinse, repeat.
This is why it’s so important for IT leaders, executives, and directors to change the conversation. To help organizations understand that the intangible is much more important than the tangible. It doesn’t matter how proficient your candidate is in your particular ERP system, if they can’t align themselves with the overall direction of the organization and adapt to help the organization grow. “We all wear different hats” is a common phrase (especially where I work). Organizations need to look for the person who can change hats quickly and wear lots of them, not the person who has a specific set of hats.
When you’re looking for “the right fit”, you need to be looking for someone who can buy in and further the goals of the company. Someone who is hungry and eager to prove their worth through their intangible skills is much more valuable than that person who has worked with all the technologies you’ve put on your candidate checklist.
I didn’t really go anywhere, to be sure, but I was sort of on hiatus from this blog. Part being “too busy fighting alligators to drain the swamp” and partly a case of writer’s block, I’ve taken the last six weeks (mostly unintentionally) away from writing.
My writer’s block notwithstanding, the former reason (being too busy fighting alligators to drain the swamp) tends to be a common reasoning as to why people in this profession get stuck. IT, if not carefully cultivated, cared for, and organized can devolve into a constant and vicious cycle of firefighting. Get to work, figure out what’s “wrong” today – and then get to fixing it. Then go home, wash, rinse, repeat.
On one hand, I’m always grateful for technical issues. Being that I chose to be in a technical field, the mere existence of these issues ensures my gainful employment. Having a wife and three kids and a mortgage, gainful employment means even more. But it’s a double-edged sword, for several reasons. Of which I’ll detail:
The “What have you done for me lately” conundrum.
It’s been my experience that troubleshooting, technical resolution, crisis remediation, and generalized “firefighting” aren’t usually considered when senior leaders (especially “Non-IT” executives) review the job performance of an IT executive. It’s a little more applicable when an IT director reviews the job function of the IT service members, but even then it can be flawed. I used to (way back when) be a system administrator for a city municipal government, and every week the IT manager would print out and display on a bulletin board the ticket metrics of the IT team.
The colored bars of the graph would indicate how many tickets were opened that week, how many were assigned to a specific technician, and how many tickets that technician closed. It became this competition, as members of the team would compare how many tickets each person closed that week. It’s been a while, but I want to say that the IT director even had incentives for the person who resolved the most amount of tickets.
Thing is – ticket counts are a horrible metric. Plug in a keyboard? Ticket. Reset a password? Ticket. Reimage 80 machines? Ticket. Some tickets could take seconds to resolve, while some could take days, months, etc. There were no guidelines as to what did and didn’t constitute a ticket, what constituted a project, etc.
As time went on, members of the service team would make everything a ticket. Move a few boxes of computers. Ticket. All that mattered was the count – that’s how senior leadership was judging.
Sidebar – years later when I had moved into the managed service space, the problem as to what is a “ticket” versus what isn’t reared its ugly head again. The company I was with sold managed service contracts to their clients, but what was covered under those agreements was ambiguous, at best. Even I, who worked for the company, didn’t always understand it. A client would want something done, but it would constitute a project and thus be subject to a different price structure and not covered under the contract. Needless to say, that company lost a lot of business.
All to say, tickets are never weighted the same, so they make for a bad metric.
I digress.
As an IT Director, or any other part of the IT leadership team the onus isn’t placed on remediation, for whatever reason. It’s just sort of expected that it’s part of the job, but it doesn’t really count as your accomplishments for the period. When asked what I’m up to, exeuctive leadership wants to know progress on tasks and projects that take the company forward, save the company money, or improve something that needed to be improved. Even though remediation is paramount, it isn’t looked upon favorably. You’re supposed to be taking us into the future, not keeping alive where we’ve been.
What have you done for me lately?
The “Perception is reality” problem:
Despite all the trendy talk at every conference or gathering of like-minded individuals about the mobile workforce and the ability to do work from anywhere, the truth of the matter is that many executives can only gauge the work by what they see. Meaning, if they don’t see you, the automatic assumption is that you aren’t working.
Most IT people in my position can probably relate to this. IT isn’t a 9-5 job – especially at this level. Computers don’t sleep, the systems that run on these computers don’t magically go home at 5pm and come back in the morning, so despite what your hours are, IT is 24/7/365. This is a particularly difficult point for my wife, though she’s learned to accept it better in recent years. I’ve been contacted for (seemingly) stupid reasons in the middle of the night, or on vacation, or during a movie, show, event, church service, or what have you, more times than I can probably count.
So the conundrum here is that there’s an expectation that as an IT Executive, you’ll be ready at a moment’s notice to execute on some major issue, but subsequently are judged on the number of hours you’re in the office. Recently I witnessed what can only be described as “a competition between rivals to determine superiority, predominance, or leadership” between two VPs at an organization. One arrives at the office prior to 6am, and leaves near 6pm, and the other arrives near 10am, but doesn’t leave the office until nearly 10pm. The first was criticizing the second for the amount of time he had to wait for the second to come in, while the second was saying things like, “You may get here early, but I close this place up by myself every day.” I, for one, couldn’t imagine what it is that they had to do in the office that required 12 hour days, every day, despite their 4 hour gap between arrivals.
Later the VP that my department reports up to made a comment about my (the IT director) schedule and how the leadership was “old school”. It wasn’t worth the chest-beating, so I just said nothing and nodded, but the truth of the matter is, is that if I, as the IT director, had to spend 12 hours in the office daily, then something was seriously wrong, and I would NOT be doing my job.
Just because you don’t see me doesn’t mean I’m not working.
This is especially frustrating, because the expectation (even if not stated) is that time be spent in the office. But also the expectation is that IT will be available any time someone else is working (whether it be a Sunday evening, 2:00am, or any other “inconvenient time”) But like the earlier example about ticket counts as a bad metric, amount of time spent in the office is a bad KPI as well. I can guarantee that I am several times more effective, efficient, and productive working remotely outside the office than I am sitting at my desk. Why? For the entire reason of this post, because when you’re in the office you tend to do more “fighting alligators” than “draining the swamp.”
But… many times, unfortunately, perception is reality. Even if it’s wrong.
Truth be told, IT more than anything else has become more about “that laptop life”, and organizations need to realize that chaining your IT department to their desks is less effective than letting them work remotely.
The IT organization I ran for 4 years a few years back called them “drive bys”, but I’m sure every IT department experiences something of the same phenomenon. As members of the organization see the IT team (any one of them) walking around, they’re quickly reminded of an issue, no matter how great or small, that they forgot to report through proper channels, and so they grab the IT person to tell them about it.
I had a former IT manager tell me he took his lunch in his car every day because if he took his lunch in the employee lunchroom, he’d be inundated with questions revolving the system, a ticket status, a technical problem someone was having, or some sort of glitch. I quickly realized all the IT team members did the same thing, or attempted to take refuge offsite, for the same reason.
The notion that perception is reality can be beneficial to IT in some cases – for instance, I always told my employees that when they walked to address a user’s issue, that they walk with speed and urgency, because lackadaisical walking gave the perception that the IT employee was not doing anything. However, using time spent in the office to make a judgement about the effectiveness of an IT executive is not a good perception. Like Obi-Wan says – “Your eyes can deceive you, don’t trust them”
The Law of Diminishing Returns
Issue remediation can buy you some short-term capital, at the cost of long-term investment. While some senior leadership can excuse a period of review filled with remediation, repeated periods of work where all that was done is issue management and remediation eventually works against the IT executive, and IT team in general.
Eventually, the organization will look at the constant problems and make the correlation that the IT executive (and by proxy, the rest of the IT team) isn’t cutting it, because the company’s problems persist and don’t seem to be getting better.
I don’t have any statistics to back this fact, but this is why IT executives tend to only be in place a few years. Like a coach or GM of a sports team, without consistent forward progress, the underlying thought is that the IT executive has lost their effectiveness, and “new blood” is brought in. Occupational hazard.
—
I think that’s why, at the end of the day, I decided to start this blog. I made the comment the other day at my work that everyone speaks English but nobody is speaking the same language. (I think I stole that from a “Calvin and Hobbes” comic strip) The same can be true for organizations and IT. I keep calling it the “chasm” between these two entities (that really should be the same), but it’s the same no matter where I go. I want to serve to bridge that gap, to help organizations understand the world of IT, and help IT relate more relevantly to the organization. Right now, I’m doing it through this blog – who knows what form this mission will take going forward.
I do know one thing, in order to keep my dream of making the “IT vs. Organization” situation a better, more productive, more seamless relationship, I need to stop being so busy fighting the alligators and start draining the swamp.
You can’t do everything. You can plan, plan contingencies, have a backup, a backup for your backup, documentation up the wall… but something is going to go wrong.
This has been my experience over the last few weeks/months. As noted before, I was brought in to my current position about a year ago to “wear the cape” and be superman for the organization. I needed a job, so I relished the opportunity. “This is a target rich environment,” the CEO said to me on my final interview, where he kept me for nearly three hours giving me a tour of the enterprise. “Plenty to do here,” the CFO (who has since left the company) said. They were right, of course. But the truth of the matter is, is that they didn’t know what they didn’t know.
Ultimately, that’s the fundamental difference between the business and IT. That’s what I’ve been trying to disseminate and define, through networking and this blog, to anyone who will listen. The organization doesn’t know what they don’t know, and they anticipate that IT (and in my case, the IT Director) will cover that gap. But we (in IT) are just like the people in the organization, just with a different core proficiency. There’s a blurring of the lines that occurs, because the IT organization’s function isn’t ever explicitly defined. Scope creep begins quite quickly, and as the organization begins to understand that every operation that occurs (especially in these times), depends on the backbone of an IT infrastructure (at least), IT begins to permeate every aspect of the organization. Operations, Finance, Reporting, Marketing, Administration, HR… IT has a hand in them all…
Furthermore, organizations tend to see IT costs as a burden on the bottom line of the organization, and the expectation of the IT leadership is that we will find ways to save costs by consolidation, cutting, or otherwise. So how do we simultaneously get leaner and prepare for Murphy? How do we cut costs yet advance the company, technology-wise?
I wrote about this mainly in my last post – and this is nothing if not an expansion of that topic. Whatever can go wrong, will go wrong. This is especially true in IT. This is why we have jobs. This is why we are compensated. This is why Gartner reports consistent upwards growth of IT spending.
However, I’d wager that much of this spending is reactionary, and not precautionary… at least that’s been my experience in the enterprises that I’ve been a part of in my career. Capital (IT) expenditures are (in my experience) a direct result of a system-wide failure that forces an enterprise to make an investment (or change), and not a direct result of planning for the future. I’d also wager that those companies that invest in their IT preemptively are better prepared for when (not if) Murphy strikes.
Case-in-point, I’ve been running an ERP upgrade (we’re 5 iterations behind the latest version, so this “upgrade” is more of a re-implementation) over the last 3 months. Despite the organization’s mandate that it be completed in 30 days, due to lack of resources we’ve pushed it to 90. I’ve created the project plans, testing schedule, coordinated with the resources doing the testing, and sat in on the pilot group’s work. From hardware failures, to unknown compatibility issues, to other fires to put out, an ERP implementation is not without its challenges.
So you document, you plan, you make backups, you convert, you pivot, and you report. You try to foresee every possible thing that could go wrong, and you plan for it.
Until you don’t.
I had spent weeks working with a pilot group in the new system, having them spend hours of their day testing and running transactions through the new ERP to verify that they were able to function and that everything functioned properly. Day after day another user would meet with me, and spend their time working on the system to make sure there would not be a problem come go live. For three months (almost) we did this practice, and I documented, planned, tested, and retested, all the while maintaining my regular duties in managing and providing direction for the IT organization.
In retrospect, however, there was a (pretty big) gap I didn’t count on. This is a learning opportunity – so pay attention.
I’ve come to realize that end-users are typically worker-bees. They aren’t paid enough to think critically of a system, and approach their tasks almost robotically in the sense of the work instructions. Where I was testing functionality with end users, I failed in the analysis. I took for granted that if an end user (and their supervisor) signs off that something is functioning, that it was, without analyzing that cross functionality between tasks worked properly. In a cleanroom environment, person A’s task might function properly, and person B’s task might function properly, but Person B doesn’t know how to analyze Person A’s work and see how it affects them.
Ultimately, I trusted… and there was my biggest failure. This is why IT folks are cynics.
After a myriad of delays, I finally got signoff from executive leadership and we were turning up the new system and going live. We went live on a Sunday, because our Australia office runs a day ahead of us, and everything seemed smooth. I celebrated, and was confident in a virtual ticker-tape parade in the office.
In fairness – the Monday after go-live started that way…. I was hailed as a hero as everyone lauded the speed, consistency, and efficiency of the new system. They didn’t know what they didn’t know. I threw my hands up in celebration, and the VP of Ops was giving me a pat on the back for how great things had gone.
Then Murphy showed up. In the form of our Planning Manager. She came to work around 8am (I had been there since 5:40am, to account for our operations in other parts of the country) and within an hour of work, she discovered a critical problem.
Here’s the thing, and the thing I keep having to learn. Worker Bees don’t know WHY there is a problem, they just know they aren’t able to complete their task. They don’t know what they don’t know.
To spare the technical details, a portion of an add-on that we utilize for our ERP was purchased in the last year by another vendor from the original developer, and they didn’t know that the piece of the add-on wasn’t compatible with the 2019 version of our ERP, and released it anyway. Since only our planning manager utilizes this portion of the add-on, we didn’t know it was a problem until she came in and began trying to release work orders. The ERP didn’t recognize any of the locations where the material was being held, and so while she could release work orders, the workers on the floor would have no way of knowing where what material was being held where. It was a mess.
A quick meeting with the VP of Ops (who had previously patted me on the back) and the consultant ended up with a decision to revert to our previous environment, essentially flushing 17 hours of operations down the drain (no way to recover anything done in the new system)…. And as Director of IT, I had the responsibility to let everyone, enterprise-wide, know that not only was the go-live a massive failure and that we had to go back, I had to let them know that everything that everyone had done in the last 17 hours, every product made, every transaction, invoice, sales order… everything… would have to be redone.
Persona Non Grata.
Seconds after hearing of this catastrophic failure, my boss (the VP of Finance) called my personal cell… he wasn’t in the office yet and apparently someone had called him to tell him that “all hell was breaking loose”.
Snitches end up in ditches, I thought.
Needless to say, he was not happy, and I got an earful for the next couple days.
Thing is, is that this function was tested… in a clean environment. The planning manager signed off on this function. Why, oh why, then, in production, did it fail? Because I tested everything individually, but not collectively. In checklist style, I had every department go through their functions and signed off, and then like a conveyor belt, brought the next department to test, never testing how work would go THROUGH the system.
The fault can lie with several people. The end user didn’t recognize the potential problem during testing. I didn’t catch the discrepancy in inventory after the work order completion. The vendor released a piece of software that was incompatible (and they didn’t know it)… but it doesn’t matter. While all those smaller issues will be addressed, the responsibility of a failed implementation (and 17 hours of lost production) lies on my shoulders.
If you don’t fail, however, you don’t learn.
To make a longer story even shorter, we pivoted. Shifted gears when Murphy took out one of them. I’m in the midst of deploying a stable release, setting aggressive testing, and a go live date of two weeks from now. All is not lost – much of the leg work done in the three months leading up to the (failed) go-live is still useful and will be used.
My armor is blemished, but I’m still standing. My leash is shorter, eyes are closer on what I’m doing, but I’m still standing. I could be writing this from a Starbucks as I search for the next fork in my career path, and while that may still come, for now I’m still pushing forward, learning from my mistakes.
Because if there’s anything I’ve learned to this point – just like the organization, IT also doesn’t know what it doesn’t know. My failure was in the assumption that others did know what they knew.
“Anything that can go wrong, will go wrong.” – Murphy’s law.
It’s been a couple weeks. The work has caught up to me, as it often does. Unplanned work is usually just that, unplanned work, and so it gets in the way of planned work – which derails everything in its path. These confessions are planned work – and so thus had been put on hold.
Most people are familiar with the adage, “Murphy’s Law” – which states that “Anything that can go wrong, will go wrong.” There are lots of articles about it, and you can read what Wikipedia has on it, here.
You’ll get varying opinions on Mr. Murphy and his law, depending on who you speak to. I think most people in the executive/leadership space use it as motivation as to why one must be prepared… because if you’re prepared, there’s nothing for Murphy to make go wrong, because you’re prepared to handle it.
Interestingly, the wikipedia article referenced above has this line:
“According to Richard Dawkins, so-called laws like Murphy’s law and Sod’s law are nonsense because they require inanimate objects to have desires of their own, or else to react according to one’s own desires. Dawkins points out that a certain class of events may occur all the time, but are only noticed when they become a nuisance. He gives as an example aircraft noise interfering with filming. Aircraft are in the sky all the time, but are only taken note of when they cause a problem. This is a form of confirmation bias whereby the investigator seeks out evidence to confirm his already formed ideas, but does not look for evidence that contradicts them”
Dawkins is right, and I don’t believe that inanimate objects have desires of their own. I also agree with the leadership teachings that you can avoid Murphy’s law by being prepared. That being said, how does that relate to IT? How can you adequately be prepared for anything, when the organization is usually focused on REDUCING IT costs, and planning in preparedness increases cost?
I once told one of my newest employers that I wasn’t going to make any changes, do anything out of the ordinary, or make any recommendations until I had done at least a 30 day assessment of the environment in which I found myself.
The company I had landed in had never brought IT in-house, and had found their IT costs ballooning utilizing external consultants. The company had been purchased by private equity a few years prior, and as most PE firms are, they were mostly concerned with EBITA. As the PE firm revamped the organization, brought in upper echelon talent, they began to look more closely at their expenditures, and IT was no small expenditure. The decision was made to bring IT in-house, to 1) lower costs, and 2) determine the state that the organization was in. There was no SME in house to be able to decipher whether or not the organization was realizing the value provided by the consultant or not. I digress.
Upon my arrival very little direction was given. Lower costs. Just lower them. There wasn’t even a true “IT” budget… more of an IT bucket in which all IT-related spending came from. I had my work cut out for me.
A trusted mentor recommended a book called, “The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter” by Michael Watkins. (Available HERE) and one of the things the book suggests is a 30 day assessment. Being in IT, having zero documentation, and not having anyone on staff to give me the lay of the land, as it were, a 30 day assessment (if not more) was just what the doctor ordered.
What I found was pretty shocking. Infrastructure was mostly, if not all EOSL (End of service life). There were (and still are) single points of failure in multiple places, and core infrastructure had reached its limit in terms of pure bandwidth. Frustration was high as the middle of the day rolled around and most people grinded to a halt as the core infrastructure struggled to keep up. Applications were fragmented, and operationally, end users had begun creating their own work-arounds to circumvent the system’s shortcomings.
My assessment was pretty clear – it all had to go – all of it. You can imagine the organization’s surprised faces when I told them the condition of their system. The board was even less pleased, becoming concerned mainly about the state of backups, and how this would affect the PE firm’s ability to sell the company. But most of all – I was supposed to CUT costs, not bring more to the table!
”A strong wind can take down our system” – is what I said. They took it as hyperbole.
I was being serious.
So the question remains – how does one prepare for Murphy, if you aren’t given the resources to prepare? Proposals are all rejected, and the only approvals were for cost cutting?
Something has to break.
It isn’t pretty.
You purchase insurance not because you intend on getting into a car accident, but because the cost of you getting into one without insurance far outweighs the cost of insurance. (Plus it’s mandatory, but that doesn’t work for the purposes of my illustration)
Organizations have to realize that the cost of stretching the dollar and not having any sort of contingency planning in IT far outweighs the cost of the resources to prevent an outage. I used to work for a company that (reportedly) lost $40,000 an hour when the system is down. All it took was the system to go down for a couple hours (or 36 hours, once) for executive management to invest in IT so that it doesn’t happen again.
But now we’re in a conundrum. As an IT professional, you’re tasked with the health of the system, no matter what the situation you inherited is like. You can’t ever advocate for something to break… because it’s your head when it does.I had an executive tell me once, “This is why you’re well compensated, you have battle pay because we know that the system is less than ideal”
I am not that well compensated, comparatively speaking.
As if somehow my level of compensation (it’s not THAT well compensated) determined the propensity of the system to go down or not. In a lot of ways, you get what you pay for… but paying someone more or less doesn’t change whether or not a system is in good or bad shape.
Fast forward – the organization I work for experienced an outage – one that stopped production for nearly a full day a couple weeks back. Thankfully I had purchased a last-ditch contingency, but the damage was done. A full day of working to get the organization back up and running, and executive management comes back with these types of questions…
And I quote:
“Was something [sic] that was to be done after- hours? In my experience, this is what is usually done to make sure all issues are taken care of and business efficiencies are not compromised.”
And
“I need to be told what is going on on a real time basis when the environment goes down so that we can explain it. I don’t like coming to you with a lot of questions because I don’t know what is going on”
Murphy had struck. And all I could do was sit there and say, “but I told you!”
In this blog I keep coming back to having to do a better job of bridging that gap between IT and the organization. Man is it difficult – I’ll tell you. Just based on the fact that when a system outage happens and the first response from executive management is (paraphrasing), “what were you doing when this happened?” “Could what you were doing have been done after hours?”
I posted this on LinkedIn a little while ago – Correlation does not imply causation.
All to say – is that sometimes something has to break before the company realizes that an investment has to be made in that area. It doesn’t preempt Murphy, but if it pushes the company towards making investments so that when things go wrong, they’re more prepared… then who am I to complain?
That is – unless they fire the IT guy. : |
So you balance, you hedge. You keep the system running as best as possible, while creating as much documentation as possible to prove that your environment is a shift away from coming down. You do your best to CYA, and hope that when things go down, they don’t come hunting for you.
It’d be so much easier if the organization would just listen – Investing in the immediate provides much more savings in the future.
—
A couple weeks back I got a call from an HR person looking for a reference for an old employee of mine. I, of course, gave a great reference and he got the job. (Why would you put someone on your reference list that wouldn’t give you a good review?) He sent a text thread to myself and some of our old teammates (we’ve all gone our separate ways now) informing us that he’s leaving the old stomping grounds, making him one of the last to leave.
We all left under not the most auspicious of circumstances, but in retrospect you don’t realize how good things are until they’re done. My teammates and I from that job still converse pretty regularly, and we all remark how when things were good, they were really good, and we all were enjoying some of the most satisfying, most productive times of our lives. It’s amazing how a great environment makes you want to work.
Was watching a (stupid, but entertaining) movie with my wife over the last couple nights. As we’ve gotten older and have had our children, we’ve gotten to the point where it’s near impossible to sit through an entire movie at night. So movies now span the length of two or three evenings, depending on how exhausted we are.
So we’re watching this movie and it’s rolling along, stupid humor (it is a comedy/action/fun movie) and the climax of the movie approaches. Stop me if you’ve heard this one before… the protagonists need to acquire evidence to find out just how the antagonists are carrying out their nefarious plans, or to discover where the bad stuff is, or to find out the twist as to who exactly is behind the problem, or…. Well… you know. Who do they turn to? The plucky tech guy. In this movie it was a “he”, but they generally are cut from the same mold. Not overly handsome or well built, socially awkward, many times overweight, and an absolute wimp that can’t handle the action part, but can “clickety-clack” on a keyboard clicking random keys and some random scrolling text later, the evil master plan is revealed.
One of the lines that this “tech guy” said in this movie was, “I’ve never seen this type of interface before!” (Cause you know, if there’s a screen with a gui, somehow the tech guy is an expert in it) Also hacking, and things. Getting through a secure firewall is as easy as a bunch of keystrokes and some witty quip about security, camera pans to the more attractive but dumber lead, and voila! We’re IN!
I can’t help but wonder how this portrayal of “tech” people came about. It’s hardly a new phenomenon, as movies in the 80’s had the same formula, if not necessarily the same sort of typecasting. I don’t have empirical data to back it up, but my observation of the typecasting of the tech person is a bit more recent. For all its posturing about achieving your dreams and not letting people stand in your way, Hollywood movies tend to put people in boxes. The chubby, socially awkward guy is the brilliant but-not-hot tech person. He can’t jump off the building, but man he can hack your firewalls. And start up your system. And spoof your cameras. And open your security doors, launch the missles, abort the launches, shut off the lights, turn on the lights… everything is a click and keystroke away!
Perfect example, albeit this guy was evil and greedy.
Whether conscious or not, this type of typecasting has an implicit bias in the real world. There is this misconception about what it is a “tech guy” does. Some of it I believe has to do with what people’s perceptions from the movies are. The other part of it is that “tech people” have sort of embraced the “guy in the chair” look. Stereotypes, wrong or right, are based in some sort of reality.
Regardless, from an ability perspective, if the role of the IT person isn’t clearly defined the organization tends to believe they can do either everything, or nothing at all. It’s usually one of those, and not in between. “Ugh, he couldn’t [insert task here], IT doesn’t do anything”… or the opposite. If it plugs into the wall, IT does it. (A while back I had a CEO send me to a golf course/meeting location to setup a sound system and projector. Add sound engineer to my resume thank you very much.)
Yesterday there was an article in the Wall Street Journal called, “America’s Got Talent, Just Not Enough in IT” (You can read it HERE)
Basically, the summary of the article is that companies are having a difficult time filling the tech roles that they have open… and to recruit for these roles companies are offering high incentives (the article referenced one instance where a candidate was offered a $250,000 signing bonus to fill a role….) SIDE NOTE: WHERE ARE THESE COMPANIES! I WILL GLADLY FILL THAT ROLE FOR THAT SIGNING BONUS – CALL ME… THE IT CONFESSIONS GUY.
Here are some excerpts if it’s TL;DR:
Gartner estimates that most large U.S. companies are competing to fill many of the same technology roles, including computer and information research scientists, systems managers, analysts, engineers and software architects. “Nearly a third of the most critical roles, like tech talent, are left unfilled after five months, costing millions in lost productivity on the table for each company every year,” Mr. Atkinson said.
And
Demand for these workers is growing as companies world-wide seek an edge over competitors by using technology such as cloud computing, data analytics and artificial intelligence. Global spending on these and other enterprise IT tools is expected to reach $3.79 trillion this year, up 1.1% from 2018, Gartner said.
In the first half of 2019, tech job postings in the U.S. rose 32% from a year earlier, according to federal employment data analyzed by IT trade group CompTIA. In the past three months, U.S. employers had about 918,000 unfilled IT jobs, CompTIA said.
Interesting, to say the least. I can’t help but wonder about this particular article. Are organizations having difficulty filling these roles because they aren’t really sure what the roles are that they are supposed to be filling? HR managers, not being well-versed in the IT world, are looking to check boxes on a requirements sheet. (“RDP? They say that they have RDP experience, check!”) But even those requirements, I have to call into question. How often does an organization know the areas of immense need and how to fill them? Who is coming up with the needs? “Oh we need a developer” What is that person developing?
I made the comment a few weeks back that everything in IT went from generalist, to super specialized, back to the generalist space (due to cloud computing and converged systems)… and if it’s happening so fast that IT folk haven’t caught up, how do organizations know what it is they’re asking for? Furthermore, what I’ve found to be true is that once a person is hired, the expectations are drastically different than what was advertised. This is particularly damaging when organizations bring in talent for a specific project. How many organizations who make a commitment to invest in technology (IT) have the patience to see it through? In my relatively short career, I’ve seen organizations pull the trigger and change out people before the job is complete… effectively ruining chances that the project completes on time, on schedule, and on budget – and many times turning all the investment to that point into sunk costs.
How do we level-set the expectations? You wouldn’t expect the corporate controller to generate a sales invoice, so why expect the IT guy to setup the sound system? Just because it plugs into the wall doesn’t necessarily mean it’s within the purview of the IT department. Or is it? Organizations need to level-set their expectations as well. I referred a friend of mine to an open position I knew of a while back, and after going through a couple rounds of interviews, he didn’t get the job. I knew the recruiter (she was a friend of mine) and asked why, and she said that the hiring manager felt that my friend (the one I referred) didn’t have the correct skillset for the position. In talking to my friend the candidate, he revealed to me that the hiring manager was adamant that he wanted someone who would do the job of (what my friend identified as) 5 different IT roles… and even though the compensation was decent, there was no way that he (or anyone else, in his estimation) would be successful in that. Months later, they pulled the position and last I heard never filled it.
So this never-ending cycle between make-believe and real life is blurred in the IT realm. It’s a chicken and egg scenario. What came first? An IT guy (or gal) who could seemingly do everything? Or some blockbuster flick that set the stereotype that IT folk generally sunk into?
I posed the question on LinkedIn the other day and for my 16 twitter followers (side note: I have GOT to get more followers)… “What is valuable (IT) information to bring to a monthly MOR (Management by Objectives and Results) meeting? What kind of metrics/KPIs do you think the senior management wants to see?”
That was my sort of “LinkedIn” version of wondering aloud what sort of metrics executive management wants to see.
Let me explain
Anytime I can throw a “Princess Bride” reference in, I’m going to.
My current place of employment is owned by private equity. So every month there is a (monthly) internal, and external MOR meeting (Management by Objectives and Results). The internal one is with the CEO and Leadership, the VPs and Directors of their respective departments. The meeting itself is a good 2 to 3 hours (depending on the month) long. Each department is expected to contribute a few slides to a PowerPoint deck that sum up objectives and results for their department. After the internal MOR, the top end leadership (CEO, VPs) take the deck, make whatever changes, and deliver a similar deck to the Board of Directors for the PE company. Usually the operational stuff is considered superfluous, and the BOD is really only interested in the financials… sales, forecast info, EBITA, etc…. Their primary focus is how profitable the company is, because when they decide to sell the company, that’s the marker. “We’re flipping a house” is a common phrase said around here.
The presentation deck for the internal MOR is usually 130 or so slides long, with the last 15 or so slides being appendix slides. The IT department slides (my slides) come in around slide 100. The final department prior to the appendix slides showing all the financial datasets, etc.
So, a recap. 15 to 20 people have been sitting in a small-ish office for nearly 3 hours, and it’s my turn to present. When I was first briefed on this particular exercise, I was told to prepare 4 or 5 slides. That was pretty much it… no real direction on what they wanted to see, because I honestly don’t know that they knew what they wanted to see. Everyone is a little stir crazy due to being cooped up in the office listening to data going on and on and on… and then there’s IT, a department people don’t really understand to begin with. What DO you do?
Therein lies my problem. Get too technical, and people don’t understand and tune out. Nobody wants to know the issues you had in switching the routing from the old firewall to the new firewall, or the details in the open case with Cisco because one of the switches wasn’t passing traffic, or how this old version of one of the ERP modules isn’t compatible with the new version of the ERP, and so you’re in negotiation with the vendor to provide an updated file. It’s the teacher from Charlie Brown.
The other way isn’t great either. Don’t give any real info, and people start asking, “What about my issue from…. _______?” and, better yet, people start reporting IT issues to me that I wasn’t aware of (which invariably precedes the question, “Why didn’t you know about this” Cause it wasn’t reported.) Then I’m talking about a purchasing clerk’s computer and when it’s up for refresh, or why the credit card processor was slow at 11am, or why the new sales guy doesn’t need 64gb of RAM.
I gave less information once, and one of the bosses called me into his office afterwards and told me I missed my opportunity to “showcase my wins”. “Wins” are subjective. What is it he considered wins?
Worse yet are the PowerPoint slides – best “data” I can give is ticket counts… opened, closed, categories… etc. Not a great metric, because if you didn’t know… a ticket can constitute 15 minutes or 15 hours, depending on what it is. Some tickets are closed immediately after opening them, and some stay open for weeks with a variety of variables, priority, type, resources needed… etc.
But… it’s the best I have to offer right now. There are multitudes of tools (for $$$) out there that can deliver automated reports on system health, bandwidth usage, top talkers, and potential trouble spots… but… “We’re flipping a house”. Granite countertops, but galvanized piping.
So I strive to stay on that narrow road. Ticket counts shows the stakeholders that IT is busy, but they don’t really show what IT is doing. Don’t give too much attention so I don’t put everyone to sleep, but give enough so that people feel that IT is doing something.
But, at the end of the day – I don’t have an answer. If someone out there has found a winning formula, a KPI that energizes the organization and gets executive management engaged into IT direction, then please forward that my way. Until then, I’ll keep throwing stuff on the screen showing that IT is doing something, even if they don’t understand WHAT it is.
Coincidentally, it’s my son’s birthday too. He was born 31 years exactly after me. Everyone says that one day we’re going to find that super cool. I’m sure as we get older and enjoy the same things, that will be the case. Right now, he’s more about how many treats he can have… me, I’m sorta about that too, but more because I’m trying to figure out what will fit in my macros, not how many I can have without getting in trouble. I joke – it’s great. He’s into LEGOs and Star Wars and video games… and lets be honest, I’m into those things too.
I had a medical thing this week, so I was out of work for a few days. I wish I could tell you that things marched right along without me, but that isn’t the case. I’m not surprised, though. IT doesn’t sleep.. Not in the organizational sense. If computers, servers, services, websites, security all would shut down at 5pm when the business shut down, and then was able to be turned on each morning, that’d make my life easier… but systems don’t take a break. I guess that means the IT department doesn’t take a break either.
I can never tell if my absence (or IT’s absence) from the organization results in a, “oh my gosh where is he we need him” response, or a “oh my gosh this is so annoying he’s never around when we need him” response. Probably a little of both. As expected, in my first day back to work, the work was piled deep and wide. It’s a tenuous relationship, the one IT has with the business… I guess that’s the entire point of this writing journey, to explore and help define that relationship.
I admit I’m not good at the interpersonal stuff that comes along with working in an office. I don’t do watercooler talk, don’t really do idle chit-chat, and due to being burned (severely) by friendships that crossed the work/personal divide, I keep my coworkers as just that, coworkers. That being said, I’m told if you want things to be different, you have to try different things…. So today I’m shooting the breeze with people I know. Joking about people breaking their stuff, joking (sorta) about being jealous that they miss their old IT guy (a consultant), giving people grief that their current ask is in danger of lowering in the queue if they give me grief – office banter. It’s difficult, because my personality is one that I want to get in, do my work, and get out. I don’t want to wax poetic for 48 minutes about comic-con or your fantasy football picks, at least not at work. But (there’s always a but)… I’ve learned my lesson (harshly) several times about how important it is to the people we (IT) service to be personal and friendly with them. IT is a service industry, after all. Users want to feel comfortable, so relating to them on some level helps the IT/organization relationship. It actually improves it, because there’s such a stigma surrounding what it is we do, working on the relationship first makes you appear… dare I say it… human.
I actually have those “Ctrl Alt Del” cups
It’s this humanizing of the “IT” guy (IT Director, in my case, thank you very much) that surprisingly allows for a lot of leeway from the business. That friendliness paves the way for understanding, patience, and even statements like, “I know you’re just so busy, I don’t want to bother you with…” which is a far cry from, “It’s broken, you need to fix it”
So why is it so difficult to find that balance? That crossroads between professionalism and interpersonal relationships? I’m not the first IT guy to be labeled as anti-social… I’ve already given multiple examples of how in popular culture the IT guy is tagged as a condescending know-it-all who enjoys making people feel stupid. Someone who has little patience for people who don’t have their technical knowledge, and makes sure that they tell people they have no time for their crap.
I wish I could tell you. Maybe it’s part of the gig. Maybe it’s a deeply rooted psychological trait that is attributed to IT people. Maybe we are inundated with so much, we feel we have no time for the relational. Whatever the case may be, IT people are much to blame why there is such a chasm between the business and IT… and that aint it, chief.
I had lots of anxiety driving into work today, because after being out for 4 days I dreaded the amount of work that was about to be heaved my way. My shields were up and I geared up for a fight. I dreaded amount of people lining up at my cubicle to explain to me their issue (one user used their cell phone to video how slow their processes were running on their machine, as if I didn’t believe them)… but I can tell you, the Proverb is true. A gentle answer turns away wrath, but a harsh word stirs up anger. It’s amazing what a smile, some small talk, some laughs, and a little bit of self-deprecation does. It goes a long way towards disarming your would-be work assailants and putting them in a position where not only do they give you understanding, but they become advocates on your behalf.
I write this primarily for me… but on the off chance that there’s another IT dude or dudette out there googling “IT confessions” because you’re frustrated with your environment and you want to see who else out there can relate to your predicament. You’re overworked and underpaid, under appreciated and under resourced… I don’t have the answers… but I do know that we’re all in the same boat. One thing I need to remember myself is the same advice I give here.. Be nice. Or rather – listen to Abraham Lincoln:
Abraham Lincoln: Fourscore and… 7 minutes ago, we, your forefathers, were brought forth upon a most excellent adventure, conceived by our new friends: Bill and Ted. These two great gentlemen are dedicated to a proposition, which was true in my time, just as it’s true today. Be excellent to each other… and… PARTY ON, DUDES!
Confession: I try to write on Wednesdays, but I didn’t yesterday. Truth be told, my professional life lately has been a lot like the photo above… no way that dude is going to catch all of those. I also can’t tell, but they look like billiard balls, which means that if any hit him on the way down, they’re going to hurt. What an apt pic. (I stole it from here)
I have my MBA, not because I was a glutton for punishment and wanted more schooling, but I believe (and had been told) that it was the gold star for positions I want (and continue to want) to attain in my career… and throughout my academic schooling (and my professional schooling, ie, the things I learn on the job every day) you hear the terms “strategic” and “tactical”.
Strategy defines your long-term goals and how you’re planning to achieve them. In other words, your strategy gives you the path you need toward achieving your organization’s mission.
Tactics are much more concrete and are often oriented toward smaller steps and a shorter time frame along the way. They involve best practices, specific plans, resources, etc. They’re also called “initiatives.” (https://www.clearpointstrategy.com/strategy-vs-tactics/)
I was able to locate that explanation (and countless others) in a 5 second search… So there’s plenty of the “business school” explanations out there. Strangely enough, however, while there’s lots of info out there about being strategic versus tactical, there isn’t much (if anything… still searching) about being both strategic AND tactical.
I don’t want to be so egotistical to think that the only sector that has to be both strategic and tactical simultaneously is IT, but I’m hard pressed to think of another function that has the same burden. You see, if you do your research, everything is about “drawing the line between strategic and tactical” or “the importance of being strategic vs. tactical”. It’s always “or”, never “and”.
This is one of my chief disappointments with academics. I worked for an academic institution for a while, and I observed a large disconnect between what academics taught things should be like, and what things were actually like. In George Bernard Shaw’s Maxims for Revolutionists, there is a quote that has become a social idiom, “He who can does; he who cannot, teaches.” It was a nice throwaway witticism that has become a way to denigrate teachers. I don’t think the quote is exceptionally fair, because I’ve had lots of brilliant-minded people who had “done”, but couldn’t teach for beans. However, Shaw isn’t wrong, either, because I’ve also had and met many academics who know how something is done by the book, but can’t put it into practice. I digress.
I posted on my LinkedIn a while back that it feels like the IT space is becoming more generalized again. When I started in this career, it was largely a generalist space. The IT guy did your audio/visual, your printers, your computers, your troubleshooting, your website, security, servers, networking, development, wrote code, and programmed your phones. Then it got super specialized… you had a security officer, dedicated helpdesk techs, a network admin, a storage admin, printer guy, web development guy, programmers, coders, telecom admins, etc… the IT department blew up in size. Now, perhaps with the adoption of the cloud (it’s just someone else’s computer), it’s getting more generalized again. You have less staff that can handle more as platforms are consolidated, data centers are virtualized and offloaded, and tools become single-panes of glass for management.
I love this photo
But, it seems like while the expectation from IT is that less will be able to handle more, the business still expects results as if there are specialized assets in the field.
So the question remains (and the entire point of this post)… how is one supposed to be Strategic AND Tactical? Expanding that conundrum… with little to no assets and no bandwidth, how are we to be Strategic and Tactical and Operational and Executional simultaneously? It’s very difficult, and I find myself navigating the latter two categories more often than not, perusing the Operational and Executional aspects of my day-to-day than in the former (Strategic and Tactical). I’ve heard it described so many ways, firefighting, being too busy fighting alligators to drain the swamp, etc… but it’s all true.
This week I got chastised for neglecting my duties to bestrategic and tactical, and I had let management reports, project plans, updates, and status reports slide to not-great levels. At first my response was a defensive one, thinking, “How on earth am I supposed to do all of this by myself?” My wife (and primary support) keeps telling me, “You can only do what you can do”, and I’ve tried very hard to take that to heart. It isn’t a platitude, but an accurate representation of the situation. If I’m to change the culture about IT, and IT folks in general, I need to start by level-setting expectations and creating boundaries. How can you be simultaneously strategic, tactical, operational, and executional? By doing them all in very small doses. I’m beginning to experiment with removing a majority of the billiard balls that I’m juggling. Last post I talked about denying the call (you can read it HERE), and surprisingly, it didn’t come back to haunt me. So I’m implementing changes, making moves. Here are three things that I’m trying to do daily:
List. List. List. I come into work and I list out a few tasks that I need to accomplish that day. Make sure that there are tasks that encompass all the categories talked about above. A strategic task, a tactical task, operational tasks, and executional tasks.
Transparency: In listing the “tasks” – I publish it so that people can see what it is I’m doing. Much of the disconnect comes from the business not understanding what I do, so there’s apprehension that I’m not accomplishing what it is I’m supposed to be accomplishing. Publishing the tasks where people can see them usually has gets the response of, “Oh…” when people look at it.
Saying “No.” This is arguably the most difficult part, because it goes against everything I’m supposed to be doing, but it’s okay to say “No” to people. People adapt and can find their own solutions to things, which ends up being okay, at least in the interim.
Being more organized and making sure I prioritize something from all of the buckets (strategic, tactical, operational, and executional) daily is checking the boxes. Is it sustainable? Probably not… there will be days where the fires are too great and I can’t do anything else. But the idea is, if I can spend more time on the first couple buckets, there will be less of the last two to have to deal with. Maybe then the fires can go from a 5-alarm forest fire to some dude who put too much lighter fluid on their barbeque. Or a candle I can blow out. One can dream.
Random Musings:
If there’s a picture to sum up what my experience has been lately, this is it. This was left (unopened, shrink-wrapped, new-in-box) on my desk this week. I really need to do a better job of explaining and showing the organization what it is I do for it. Meanwhile, I’ll be looking for something to do with all these 3.5” floppy disks.
My wonderful wife has started an amazon business – so if you’re in the market for what she has to sell, check it out! Her new brand (Mop Knot Hair) is taking off! See that link for more details!
Peter Gibbons: Let me ask you something. When you come in on Monday, and you’re not feelin’ real well, does anyone ever say to you, ‘Sounds like someone has a case of the Mondays’?
Lawrence: No. No, man. S***, no, man. I believe you’d get your ass kicked sayin’ something like that, man.
It was around my first week on the job, I think. The CEO was at a conference, or show, or something out of the office, and he called the main line looking for me. He couldn’t get emails on his phone, or something to that effect. Come to find out he had left his phone on airplane mode from being on the plane ride, and when he turned off airplane mode, voilà… emails started flowing. I had saved the day without actually doing anything but answering the phone… then came the trap.
CEO: “Hey… your office phone doesn’t have a direct dial number”
Me: “No, we don’t have any direct dial numbers left, and they’re mostly reserved for the sales department”
CEO: “Oh, well we really should be able to get ahold of you directly, instead of calling reception”
Me: “Well – I have my extension forwarded to my cell, so if you call my extension, it’ll ring my cell…”
CEO: “Let me get your cell number so if I continue to have problems on this trip, I can give you a call or text…”
Me: “Oh… okay… it’s…… _____”
That was it. That did me in. Somehow, from that moment, it became open season on my cell phone. Fast forward to present time, and I’m getting texts from the Warehouse manager at 7pm because he can’t find his docking station. I’m getting texts on Sunday when I’m on a date with my wife because someone can’t figure out how to log into the Remote Desktop server. I get texts at lunch when they can’t find me at my desk, calls when I’m in the employee lunchroom, bathroom, or anywhere but visible to everyone.
Then came this last Monday – one of THOSE Mondays. Nothing worked. A couple members of the sales team had ignored the Microsoft warnings that their mailbox was almost full, and they let it fill up, so they weren’t receiving mail, which means they couldn’t get purchase orders. Our credit card processor went down, and computers in our remote warehouse had lost their trust in the domain and so therefore weren’t authenticating users at login. People couldn’t scan, printers wouldn’t print, programs were hung up, reports didn’t go out… basically, if it could be broken, it broke. And my cellphone did not stop ringing.
By the end of the day, I had mitigated most of the issues (the credit card processor wasn’t anything to do with me, our internal systems, or anything we could do…. But the business looked at IT to fix it anyway) and one of the executives walked over to my desk.
EXEC: “I haven’t talked to you today”
OFFICE MANAGER (who is my cube neighbor): “He’s been very busy”
Me: “If it could break today, it broke”
EXEC: “Oh yeah, well… it looks like you had a case of the Mondays… but here’s what I need from you….”
I was living in a scene from “Office Space”
It made me think.. At what point in this career is IT too accessible? I realize that systems don’t go home at 5pm and back into the office in the morning, so there was always a degree of after-hours and non-traditional time to be put in for this vocation. It is something I’ve accepted, understood, and was fully aware of when I began this career. Furthermore, as my purview began to expand beyond local operations into national or global IT operations, I knew that I was never going to be really “off the clock” in a sense… that somehow I would always have a degree of knowing what was going on… but what is contact worthy, and what isn’t? When is it appropriate to “ghost” your company? IS it appropriate to ever “ghost” your company? If you see your CEO, or VP, or someone who is high up on the chain calling your cell (no matter the circumstances in which they got your cell phone)… can you decline the call? Do you feel obligated to answer?
I’ll be honest. I do. I have this almost pathological need to answer and prove myself. But, I’m not so sure it’s the right attitude to have…. Because to this point in my career, my perceived “always” availability has been a bit like the children’s book, “If you give a Mouse a Cookie”
“If you give a mouse a cookie, he’s going to ask for a glass of milk”
If I answer the phone, text, or email at 8pm on Sunday, then the expectation is that if you reach out to me, anytime, anywhere, I’ll come through…. And it isn’t an altruistic notion. It’s an expectation.
I had this conversation with a superior recently (when being asked about my office hours). I said something to the effect of, “The system requires a lot of after-hours and weekend maintenance, and the operations in different time zones require support that I have to give/provide during off hours. So I’m more effective if I’m not sitting in the office 8 hours per day… ”
The response? “We all work from home”
I felt like that gif where the guy is surprised and his eyebrows go up.
This one:
Either I’ve grossly understated what I do, or the business has no idea what IT’s role is, or both.
Probably both.
So where’s the balance? When am I “off” work? When is it okay to “ghost” my employer… if ever? I have a wife and three kids (all under 6)… and family life is the most important thing. Yet, somehow I feel like if I neglect the employment that provides for that family life, then I’ll be failing at family life… does that make sense? I don’t know how accurate that thought is, but it’s my paranoia.
Thus is the issue with “invisible IT”… where I know that I do much behind the scenes to keep things running, it isn’t inherently felt by the company. So the (incorrect) assumption is that I’m not doing anything… hence my desire to answer when someone calls, starting the cycle all over again. I need to do a better job of explaining to the business what it is I’m doing… but I don’t want them to have this expectation that I will ALWAYS be on…
I’ll tell you this, however… yesterday I had to leave the office early for a personal matter. About an hour and a half later my phone rang, twice. First the office manager, then a VP. For the first time seemingly EVER in my career… I slid the button on my phone to “decline”
The office manager followed up with a text about a vendor trying to contact, and I didn’t get anything from the VP. So far, today, I haven’t been told anything… so I wonder, is it okay to decline the call? I sit here with baited breath.
Further bulletins as events warrant… If you see me walking on the street with a banker’s box, pick me up.
Confessions of an IT Director 