The question related to how to structure an IT consultancy to garner more than "repairman" work. A consultancy in Canada is interested in developing their business, and somehow it got out there. Valeria posed the specific questions:
...what are your thoughts on marketing IT services? Do you have a preferred provider? Why do you like them? What would make you value a company in this space? We all get the value of rescue when a disaster occurs, what about on the day to day operations?My answer included some of the material below, but I've also expanded on it.
Personal interaction, it's the only way. Couple that with competent and honest services and you're likely to gain that wonderful thing: trust.
I value the tech who admits to screwing up (as long as screwing up isn't a habit!) more than the one who, bravado and dust trailing in his wake, rushes from one job to the other. I used to phrase it "I hate 'heroes'" That is, I didn't want people who could fix something when it was broken: I preferred people who noticed problems, and took steps before the server went down.
I've worked to get "heroes" out of my group; I hated them for a reason: they have a need for the accolades, the "oh my, doesn't he know a lot" sort of crap they always get. I like a quiet life, no phone going off at 2AM, calling me into an office I left a few miserly hours earlier. It didn't help that my boss was one of those "political" types; never mind the effort: if you were a golden boy you were in. If you weren't, well, let's just say I considered the people who used "my" network more than I considered the opinion of that Waste of Space On The Org Chart. It really was a thing for me: I hated it when the network went down; I took it personally. I considered the network a living thing, and it was out to best me, unless I bested it. And I did.
Yes, I needed techs who could respond at 2AM, not quibble with me about the importance of a server or whatever. (The tech would always look at the technical importance; my job was to look at the political importance.) But at the time, what I really needed was a group to keep the network running, and another group to plot the future of the network. My job would be reduced to (for me) the very frustrating level of "facilitator". Oh God! How I hated that word. (And despised the role).
IT is a tricky business: customers expect phone-company reliability, but are willing to pay on the scale of their own phone bill. They don't think about the millions of other customers, all contributing to the maintenance fees of a phone system. Valeria makes mention of the dial-tone analogy; it's a good analogy, and useful in the presentations.
Arguing that a million dollar investment will return reliability gains only works when you also emphasize that the maintenance needs to be kept up. (I've had to do that. It wasn't the easiest "sell" I've ever done...) That's where setting expectations correctly comes in. My boss positioned the new server infrastructure as a silver bullet. I, who had to role out of bed at 3AM when something went south, again, differed. I didn't say it was a cure for the common cold, but it would help alleviate the symptoms. (I got my million dollars.)
That was as an in-house IT provider. I can only imagine how that might work out in the wild. Sure, the dollars are probably lower, but the pain of handing them over for dubious or not-clearly-explained gain is likely to be worse. So the IT firm needs to build trust. And they need to articulate the investment in terms of gain. Not so much "we'll be there when the system goes down", but "we'll work with you, and your budget, to ensure that you have an IT infrastructure that doesn't go down."
And demonstrate good work: neat cabling, clearly documented systems and so on. Any company I would hire would have to ensure I wasn't dependent upon them. That would be a quick way of being shown the door: I want you look out for my interests, not yours. Yes, I know, it's a consulting firm. They have their interests to watch, as well. But they can be honest about them, and a compromise can be reached. But don't mess with my infrastructure: I've threatened companies with lawsuits (even arrest, in one case!) because of such nonsense.
A word about the cabling, and server infrastructure. It has to be neat. Military-like neatness. It inspires confidence, and it helps troubleshooting. It costs more, and it's worth it: it reduces faults due to cables failing; they'll always find a reason to fail, but why provide an excuse? And why give your customer a reason to question your competence?
Now for the meat of it all. An IT group is a team, although it tends to have some mythos of the lone genius, solving any and all problems. The basic thing wrong with that is the lone genius has also figured out that you're dependent upon him, and he's not exactly strategic. Strategy: the statement that provides you with a clear goal of where you're going. Forget all that "mission statement" stuff; they're nice platitudes but useless as an operational item. Besides, they tend to be so convoluted you need a dictionary simply to explain them. Make any IT strategy short, sweet and relevant. You'd be amazed at how many times that last point is neglected. Maybe you wouldn't; I was.
To avoid the problem of perception - that you're a strategic partner, not just a repair shop - you have to clearly separate the functions. The same salespeople, but not necessarily the same technicians. It's really difficult, no matter how much the IT tech or engineer protests, to be strategic when you're busy fixing stuff. It's easy to perceive the need for changes when it's 2AM and the server is still refusing to work. But that's different from looking at the IT infrastructure and saying "How do I avoid problems?" (I never call them "challenges"; such PC nonsense makes the whole thing an exercise in linguistics and not engineering.)
So that's sort of how I'd approach the issue. I've worked with a number of IT providers, and the ones that got my attention, and dollars, treated my technicians better than they did me: they took them for lunch, paid for a few rounds after work or after a difficult problem was resolved. The sales people asked after their kids, and so on. (Hearts and minds, it's a tried and true tactic.)
(I changed that one because the original didn't "read" correctly.)
There is a fine line between bribery and ethical "treats". The K Street Gang managed to get it wrong; make sure you don't. Unethical behavior is rampant in the IT business, and always has been. If it's not a certain storage company sliding so close to the libel line that I'm looking up lawyers, it's other salespeople promising vast rewards if I only pick them. (They were usually lucky I didn't report them to the FBI. Seriously.) But enough of that!
Building a career path for your techs, and taking care of the customer, is a tricky path to travel on. But first, you need to separate out the roles: the tech who's a wonder at fixing stuff is not necessarily the greatest choice for figuring out the implementation of a strategy. Figuring out the IT strategy is a job for the managers; keep the techs informed, though. And listen to them: a good tech is like a sergeant in the army; he can keep the manager from making a major mistake.
Make sure that the repair shop guys have a chance at the strategy stuff. If you don't, I'll guarantee that you'll spend a lot of money hiring good repair shop guys. But don't hand them critical projects when they could be better utilized fixing a downed server somewhere. One job will suffer. If you figure they're young, they can handle the pressure: you'll find out that they're using your company as a stepping stone to better employment. Don't be a sweatshop.
(If you do make your techs think they're in one, I'll also guarantee that they'll have a quiet word with "important" people and you're not so likely to gain that contract when its up for renewal. A happy tech is a good thing. Make that your mantra.)
The strategic role of an operational IT group is critical. If your company is starting to get "big", make sure you know who you're going to put in charge of figuring out how to implement managements plans. If it's the network boss, make sure his "keep the servers running" ops team is headed by someone competent. And who's not out to backstab him; it's a little better for the company. (No, I didn't follow my own advice on that one. Either bit.)
The strategy guys look at your systems, the email, the database infrastructure, the network, the login systems, everything but the software infrastructure, and figures out how to make it cheaper, more reliable and so on. As an IT manager you make the decisions on what those goals are; you work with the strategy group to figure out that stuff. They figure out how to connect to clients, vendors and so on. You can consult in that role, and I'm sure its got a lot of paychecks. I'm not the person to tell you how to sell that function, though.
Many companies simply put the email on that server, and the files over there, and oh, we ran out of space, so we'll add a box here, and so on. This is what I call "a mess". It's impossible to maintain properly; many IT consulting companies like this sort of thing for exactly those reasons. (How many books have you read that state that little factoid? Same number I have, probably: none.) A good IT strategy figures out where the login server will be; does it have a fail over? Where's the email server? Spam protection? What's your storage strategy? If its like many others, you don't have one. Virtualize the storage? Wozzat? SAN? Oy vey, I need an aspirin. Strategy is figuring that stuff out. If you're in the information business, you're in the storage business. You need to know how you're going to store your data, how you're going to protect it. And how you're going to migrate it.
Things like that are where the strategy and ops groups get together; it's where the ops guys get a chance to prove they understand strategy. And where the expensive consultants get to prove they really don't have a clue about ops. (I've been there. I've seen this too many times. If you object: that's what comments are for.)
Just about every book I've ever read on IT strategy has concentrated on the glamorous, high-dollar work of websites or databases. Often it's how to integrate the latest buzzword into your infrastructure (clue: hire expensive consultants. Who have read the same book, but one day before you did.) I've rarely (never) read a book that describes how to figure out an operational IT strategy. No, I'm not about to. It's been too many years, and too many bad memories. Besides, I'm renovating my house and working on my own open-source projects.
Figuring this stuff out is difficult. Don't let anyone kid you about that. It's not as glamorous as putting together a website, but without - no website. It's certainly not as glamorous as the bells and whistles of a corporate, high-profile application that promises the world and fails to understand where the tea kettle is. In the ops world you're a plumber, an electrician, a mailman and a person who enables the rest of it: and that's something to be proud of.
Okay, that was a bit more rambling and personal than I maybe should have written. So many people expect these santized to-do lists, and get upset when presented with the paranoia of someone who's been there way too long. Sorry. I promised I'd write. Nevertheless, in this little bit you have a few hours of
(I recall one interview; the guy - a senior IT manager at a really major Wall St corporation - wanted me to recite details of the mail packet header, the ethernet packet structure and other stuff like RFC details. Great: he had the details memorized, I look them up in a book. He wasn't impressed, and wondered how he could fulfill his strategic role while he was paying so much attention to the minutia. I was offered the job, but turned it down.)
A defining moment for me was about half way through my time as a Network Manager. A sales tech asked me how long I'd been a Network Manager. "3 years", I replied. He looked stunned. It took him a moment to recover, "Most don't last 18 months", he muttered.