Considering An Operations Person For An Open IT Position? Don’t Do It
Written by Todd L. MichaudTodd Michaud runs Power Thinking Media, which helps retailers and restaurants tackle the convergence of social, mobile and retail technologies. He spent nine years delivering technology solutions to more than 10,000 retail locations as VP of IT for Focus and Director of Retail Technology for Dunkin’ Brands.
Operations often complains that the IT team is too disconnected from the business to perform at the highest levels. Business leaders clamor for IT staff who can talk about retail operations and back-office management, not just about information security and system availability. Every so often, an opportunity arises to fill an open IT role with someone from Operations who has “technical aptitude.”
In an effort to keep the peace, a lot of IT leaders make the mistake of accepting a transfer from the Operations team rather than hiring an outside IT resource. Although it sounds almost “romantic” in design, in my experience, it almost never works out.
Sure, it would be great to have an IT person on staff who understands the intricacies of Cost Of Goods Sold (COGS) and Sales Per Labor Hour. It would be great to have someone on the team who could provide leadership on the impact a technology solution has on retail operations or back-office management, right out of the gate. Those are great goals, but you need to focus on getting your IT people deeply engrained within your business and not on trying to teach an Operations person how to operate within an IT framework.
Here is why the Operations-to-IT conversion doesn’t work out:
- Operations and IT are dramatically different. Although it may seem obvious, someone who has spent most of his or her career in a restaurant or retail outlet typically doesn’t like the process-ridden, political, desk-chained role of an IT person. It’s like going from working outdoors to working inside. Most Operations people I have known who have attempted this transition behave like a wild animal put in the zoo. At first, they are happy for the simplicity and the routine. But soon they either sit at their desk staring into space or start to get defiant and angry.
- Operations and IT fix problems differently. I once had a colleague use the analogy that a farmer who fixed his broken tractor in the field may feel like he is getting more done, but that the farmer who took the tractor back to the barn to make the repairs would always achieve greater results. Operations people, by design, are great at putting out fires (fixing the tractor in the field). That is a lot of what they do. IT people, on the other hand, are good at doing root-cause analysis to determine what actions can be put in place so the problem doesn’t happen again. Software development lifecycle and change control might as well be foreign languages to Operations people (as it should be). If you’ve always fixed your tractor in the field, heading to the barn when there is a problem seems like a bad idea. With Operations, “taking action” is what leads to success; with IT, “following process” is the way to win. See why there is a disconnect?
- There is a bigger impact to not understanding IT than there is for not understanding Operations. I’ve seen multiple examples where an Operations person (in the role of an IT person) made a change to the system that negatively impacted every store in the chain. The person was trying to address a problem in one location and accidentally made the change at all locations, causing hundreds of locations to lose money. When you are not technically trained but given a position with a lot of access to make changes, you can get yourself into a lot of trouble.
- There is not a cultural fit within the IT community. Let’s say that you can dodge the bullets outlined above and have an Operations person successfully make the switch into an IT position. The next challenge is abandonment. What happens when the Operations peers move on to other roles or companies and the Operations/IT person is left alone with IT? That person can easily, and often, become ostracized from the rest of the IT group, because he or she is not technical enough to take on additional work. IT is often understaffed and has to ask everyone to pitch in to help. It makes it difficult when one team member can’t help out in times of need because he or she doesn’t have the basic skills. It also makes that person difficult to promote, because he or she doesn’t have the experience to take on other IT roles and quickly loses touch with pervious Operations skills the longer he or she stays in IT.
- Being a strong user does not mean someone is qualified to be an administrator. I love to drive my car, but I am not a qualified mechanic. I am a tequila connoisseur, but that doesn’t mean I could take over a distillery. You get the point. For some reason, business leaders believe that power-users would make good administrators, and that rarely is the case. Maybe if it were an ex-pat (from IT) who left the herd along time ago, I would consider it. But, otherwise, having technical abilities at a user level is not nearly enough qualification to run the system.</li
The most successful way to manage the relationship between the Operations team and the IT department is through true Business Analyst roles. This is where an IT organization hires people who are dedicated to managing the relationship with their functional counterparts. Smaller IT shops have a hard time dedicating resources to this type of role when there are so many IT projects that don’t have enough resources to get things done. But a Business Analyst role was really designed to solve this problem (and why it exists in many larger organizations). A person in this role is truly meant to be the bridge between both sides, understanding the needs of the business while having the background to explain the options with technology.
What do you think? If you disagree (or even, heaven forbid, agree), please comment below or send me a private message. Or check out the Twitter discussion on @todd_michaud.
May 12th, 2012 at 9:57 am
This post touched a personal pain point I am going through right now. Very insightful, and worthy of a book.
I have an ops mentality but have worked directly or indirectly in IT for over 30 years. I think, naturally, young people and/or go-getter personality types are, by nature, “operations” types. However, as responsibility, experience, and maturity increases, people who may even be naturally “ops-oriented” can and should make the transition to an “IT” mentality like that you describe above.
My boss is, by background, an “operations” person who never had a strong technical background or interest. Very smart, and capable when focused, but not that turned on by learning the intricacies of “how stuff works.” In other words, despite over 20 years in the “IT” industry, still fixing tractors in the field.
As a person who, by training, natural interest, and experience, has transitioned from “ops” to IT, especially given my responsibilities for preventing the failure of deployed IT systems, I continually butt heads with my “ops” boss. It has negatively impacted my health, my demeanor, my sense of satisfaction with my career field. This insightful post provided a glimpse of understanding into why, in a small org with no “IT” mentalities, I was increasingly ostracized for recommending caution, greater examination of risks, and “go slow” approaches to deploying systems on the Internet that had not been sufficiently tested (i.e., not at all with regard to security).
PCI DSS, although at first seen as an unnecessary burden even by myself, has forced the “ops” people in charge at too many organizations deploying web-based tools and services into the light of day. Sadly, I think far too many decision-makers, both business and “IT”, lean towards “ops” rather than reasonable approaches to risks and rewards. Those that can and have read and recommended fixes to get in compliance with PCI DSS likely find themselves ridiculed, demeaned, and ostracized as the self-congratulatory “ops” people charge forward with “innovation” and highly visible new services.
Thanks for writing this article. Helped put a logical framework for seeing the dynamics that I, and probably many others, are caught in the middle of.
May 16th, 2012 at 11:14 am
Chris,
Thanks for taking the time to write out this comment. I think that the more that both sides understand where the other is coming from, the better off everyone will be. I find that taking the time to ask someone “why” (is something being done that way, is that decision made, is this project important) can at least provide a good starting point.
Best of luck!