how to manage I.T. when you’re not a technical person

by Alison Green on October 1, 2015

If you’re a non-technical person overseeing I.T. – one of the most critical parts of most organizations – how can you effectively manage an area so far outside your expertise?

Many COOs and VPs have had the unsettling realization that they’re now ultimately accountable for the performance of a team that in some cases might as well be speaking a different language. (We’re talking here, of course, about senior positions where the head of I.T. reports to you – not positions where you manage the I.T. team’s day-to-day work. If you’re in the latter, you need be be a technical person yourself, obvs.)

Before you start fearing that you’ll need to head back to school and take courses in systems analysis or application development, instead try these five key ways that non-techies can effectively oversee an I.T. team.

1. Hire strong people. Consider bringing in outside I.T. help when hiring key I.T. players, to help you create the job description, screen candidates, and participate in interviews. It’s crucial to get your hiring right here, since you’ll need to be able to trust this team to give you straight answers about how long something will take and what resources it will require, what resources they need, and what is and isn’t doable. You don’t want to be second-guessing those answers, so you need to hire people you’re going to trust and have confidence in.

2. Get aligned about big picture goals. You might not have much idea about how your I.T. team will achieve a particular goal, but you should know at a high level what goals need to be achieved. For example, you might agree that your I.T. team needs to deliver a fully-tested interactive mobile app up and running in time for your spring product launch with features X, Y, and Z, or ensure that technology runs smoothly enough that employees’ work is never more than minimally and rarely interrupted. Getting aligned about the outcomes you’re looking for is the important part; from there, they can figure out the best way to get there.

3. Ask good questions. Part of your role is to ensure that your tech folks are anticipating obstacles and challenges and have a plan for what they’ll do if things go wrong, that they’ve reality-checked their processes and plans, and that they’re taking things like organizational constraints into account. That means you need to ask good questions. For example: “What could go wrong and how will you plan for that?” “What milestones will you need to hit to make this delivery date?” “If this projects ends up not being a success, what do you think will have gone wrong?” “How do other companies handle the risk of X?”

4. Pay attention what you do see and understand. You might not understand all the technical details, but you probably know whether your organization is getting what it needs in the I.T. realm. Focus on those pieces. For example, if you’re the COO, you probably don’t need to understand exactly how your client contact database works, but you do need to know whether it’s giving your sales staff the functionality they need to do their jobs effectively. And you should certainly know things like whether your email and web connectivity are running smoothly.

5. Be honest about your limitations. Trying to bluff your way through technical conversation will hurt, not enhance, your credibility. You’ll gain far more trust by saying honestly, “I don’t understand this – can you explain it to me in layman’s terms?” or “Could you help me understand why X makes more sense than Y?” If you have the right people on your team and they see you adding value in other areas, they won’t hold this against you.

Originally published at Intuit Quickbase.

You may also like:
{ 31 comments }

{ 31 comments… read them below }

    2. heatherskib*

      Definitely! Especially the one where she interviews at another firm and tells the interviewer that they need her because they can’t communicate to the I.T. people

    3. schnapps*

      :raises hand:

      “Hello, IT department. Did you turn it off and on?”

      My favourite episode is where they give her the Internet to take to her employee of the month speech. :)

      1. Not Katie the Fed*

        A good friend of mine got “the internet” in a kickstarter. It has blinky lights, and the suitcase, and, of course, it’s wireless!

  2. Sharon*

    What does IT mean? What DOESN’T it mean? :-)

    Alison’s points are all good. I feel compassion for nontechnical managers in this position. Having come from the IT trenches, I’ve seen managers really struggle with this. You can have really good people who can be trusted to do good jobs and keep you informed, and you can also have really bad people who snow management over with BS. I actually once replaced a guy who had management convinced that it was normal for the critical computer system to puke it’s guts out once or twice a week. When he went out sick long term and I took over, it was almost magical how things stopped crashing and the system became reliable. Unfortunately I can’t even figure out how to see through people like that, except to bring in some other experts with highly tuned BS detectors!

    1. Sharon*

      … AND I ruined the quote. Ugh. Here’s the real one:

      What does IT stand for? What DOESN’T it stand for?

  3. Wilton Businessman*

    I like how they had to put “Information Technology” in parentheses after IT. If you’re leading IT and you don’t know what it means, that’s probably your first step.

    Quite frankly, I think your last point is key to managing just about any group. I love to “play dumb” and have my leaders explain it so that anybody can understand it. If they can’t put it in simple terms, I know they don’t understand it.

  4. Merry and Bright*

    I was actually asked in the interview for my first office job what information technology was – not to see if I knew, but because the interviewer himself didn’t know – and this was an academic in a well known London science college.

  5. Brett*

    Most of these same idea apply to non-IS managers managing IS. Unfortunately, I have seen far more IS managers try to bluff their way through than IT managers. (I think possibly because IS ends up getting a lot of limited-technical managers who think they can handle IS while IT gets either technical managers or non-technical managers who are both more likely to know their limitations.)

    1. V2*

      At least in my experience, I haven’t found a distinction between IT and IS that’s universal, mostly they’re used interchangeably, and when they’re not, people disagree about the difference. The “academic definition” I’ve heard is that IT is a subset of IS (which also includes things like business processes, people, etc.) but I’ve never heard anyone actually make that distinction.

  6. IT Kat*

    #1 is probably the most important. I’ve been in IT from several different organizations, and by far the worst job was where the (non-IT) manager of the team… simply didn’t trust anyone in the department. He micromanaged and often lingered, wanting us to explain everything we were doing and why we were doing it – which can be good when we’re hashing out a plan for a large project, but not so good when you’re trying to get the email server back online and have to stop every 30 seconds to explain what you were doing.

    Hire good people, trust that they know what they’re doing, and by all means check in – but don’t insist on trying to learning every small aspect their jobs unless you’re planning on moving into the trenches.

    1. ITChick*

      This, so much. If you don’t understand what I’m talking about, it doesn’t mean I’m lying or trying to bullshit you. I had 2 managers who were not IT people and it was a constant battle to figure out new ways of explaining things that would justify what I originally said because they didn’t understand it (or really even try). They assumed that because we were using abbreviations and jargon that we were trying to mess with them.

    2. J-nonymous*

      Right – or save the deep dive for when it’s appropriate. For instance, if this is the third time this month you’re trying to get the email server back online then that’s a problem that needs to be addressed. But you’re right – leave the mission critical work alone and get things restored, then dive into what needs to be addressed.

    3. Kira*

      Agreed that the trust is key. When I came into my current job, our IT guy was starting to lose his boss’ trust. He had an explanation for everything, but her bs radar was going off. For example, why did the entire agency’s computer system crash for a week when one person opened a spam email? Why does everyone have to log off their computer for 30-60 minutes on Wednesdays? At that point, there was no trust.

  7. LQ*

    Documentation. I’d say it is extra important if you are a non-technical person that your technical IT people be really good at documentation. It doesn’t mean you have to understand all of it, but if they leave and you need a new person good documentation is going to be incredibly important here.

    1. Jen*

      I am a non-technically certified IT coordinator, and documentation is so key. When I asked my team to take over, they looked at me like I had 4 heads, but it has come in so handy making us more transparent to Partners and soothing worries that our technical employees are idiots. They are brilliant, but we lose a lot in translation.

    2. Dingle*

      My manager is technically clueless. She doesn’t understand why aging infrastructure needs to be replaced BEFORE it fails. When she doesn’t understand something, she wants me to write a report about it, which takes longer than just doing the work. When I do something really complex that takes time to do right, she gets on my case about why it isn’t finished yet, as if a quick and dirty solution will make the problem go away. If I solve a hard problem really well, she doesn’t notice at all. I have pretty much stopped trying as a result. Get good people, give them the resources they need, and let them do their thing.

  8. J-nonymous*

    #5 is so important. At a previous organization, we had someone over IT who downplayed his lack of technical background. Probably the worst way in which it manifested itself is that he frequently didn’t listen to people who had that experience who warned him his program/project schedules were fiercely aggressive.

    The second worst way in which it manifested was that he would often use technical terms completely incorrectly, but refuse to clarify what he meant (or acknowledge that these terms had very specific meanings, particularly within IT).

    I remember his asking me what we used for load balancing (I ran a SharePoint/web development team). So I explained how our web servers were load balanced. He said that wasn’t what he meant; how did we achieve *Load Balancing* (raising his voice on the last two words). So I answered again, but this time in lay terms.

    By the third time, he was visibly irritated with me (red face, fingers pressed down hard on his desk) that I just didn’t get what he was asking, so I said I’d look into it and get back to him. It occurred to me later that he was asking how I managed the capacity of the development team, which–not the same thing at all.

    Anyway, it wasn’t so much that he misused the term as that he refused to work with me (or any of his other reports) to get to any shared definition/understanding of what he was asking. He just expected us to know what he was talking about and got pretty angry (and treated us like we were stupid) if we didn’t.

    1. Vorthys*

      I have worked with that particular type a few times. It’s frustrating, but I’ve never figured out whether they think I’m being voluntarily obstructive just to insult them, or if they’re lashing out because they’re insecure and beleive asking questions of folks below them on the org chart would show weakness.

      Either way, it drives me batty.

      1. James M*

        It’s the good ol’ “everyone but me is <insert disparagement>” syndrome. For these people, the idea of their own competence/knowledge/understanding is one of their core beliefs and they cannot react rationally to anything that challenges that belief, even while that belief is contradicted by everyone around them. “I don’t know” is usually anathema to such people, so you can formulate a test (administered at your peril) to identify them.

      2. J-nonymous*

        Right. I tend to think the latter causes the former, but who knows.

        Also – I want to be clear – technical people can be really pedantic about using technical terms. So I’m not advocating that. I’m just saying if you’re in a leadership position *and* you don’t have deep experience in the area you’re leading, a little humility going into the discussions will go a long way.

        Plus people can feel better about working for a person who takes the time to come to a shared understanding.

        1. Vorthys*

          Oh yeah, I definitely agree that both parties must be flexible in that regard. Open communication and clarity is key, and everyone involved must work towards it. It’s not on a single person.

          If there’s hostility from one side , though, it takes away the chance for the other party to reach out to help bridge that gap in good faith.

  9. "Who's On First?"*

    Sometimes these articles seem a little like backseat driving lessons — my first impulse is always to ask, “Who thought it was a good idea to make the guy who has to have his emails printed out for him the head of our cloud computing division?”

    At it’s worst, it’s a good example of class-based hiring practices; “Of course this guy should be in a position of authority for a subject in which he has no ability whatsoever — did you see where he went to school? That’s a Hermes tie he’s wearing! He was at our synergy conference that we specifically held at a remote location only accessible through extensive international travel to filter out those too poor to attend; if that doesn’t convince you of his qualifications, I don’t know what will…”

Comments are closed.