how to manage work that you can’t do yourself

by Alison Green on November 29, 2011

Help! You know little about computers, and you’re suddenly in charge of overseeing the I.T. department. Or you can barely balance your checkbook and now your firm’s finance team is under you. If you’re charged with managing an area of work outside your main expertise, you could feel in over your head – or you could use these four tips to do it effectively.

1. Get aligned about the end product for big, important goals. For instance, you might agree with your IT team that “We need an interactive Web site up and running in time for our big spring product launch, which means launched, tested, and ready to use by March.” This keeps you focused on the end product, and then you can ask questions about the process: “How will we know whether this is on track? Are there milestones you could set to hit along the way?”

2. Manage by asking good questions rather than suggesting answers. Even without knowing the nitty-gritty of the work well, you can pose basic, useful questions like, “How do you know that X is true?” or “What will you do if Y happens?” or “What do other businesses do about X?”

3. Connect the employee to her “customers.” Your staffer may be doing work that few others understand but where many know whether or not they’re getting what they need. Often you might find yourself in the middle between other departments that tell you they want something, and an “expert” whom you manage. Your job is to bring the two sides together. Make sure your employee is talking to these “customers” and agreeing with them on what they’ll have by when. And make sure that there’s an ongoing channel for communication and feedback, including periodic surveys or other means that let you and your staffer see how these internal customers feel.

4. Judge by what you do know. Often you won’t have a clear idea whether 90% of what the person does is good because you don’t really understand the subject matter. You will, though, understand 10% of it (even if it’s just something like, “Did this person explain what she was doing in a way customers could understand?” or – with IT – whether or not your e-mail and networking are running smoothly). Extrapolate from what you can understand, and assume the 90% you don’t get is similar. If the small pieces you get seem great, it’s reasonable to assure that the rest probably is too – and if the piece you get seems off, it’s likely that the rest may be as well.

You may also like:
{ 17 comments }

{ 17 comments… read them below }

  1. nyxalinth*

    I think that it’s helpful, but not necessary. The only time I have personally seen this go awry is in a call center I worked in Florida. Our manager had never worked in a call center before: not on the phones, not as a lead or supervisor, nothing. So he was very clueless about the running of call centers. This had a very bad effect one day, when we had calls in queue and he refused to allow breaks or lunches until it was cleared. Long story short, I didn’t get lunch until 5 hours after it was scheduled, and several complaints to the labor board were made by my co-workers.

  2. Christopher Allen-Poole*

    There is a major difference between experience in the field and experience in the topics and the tasks. Experience in the field is paramount and the lack thereof is nie unforgivable — you don’t want the CTO to be someone who has not used a computer in a decade.

    Without going into detail, I will simply state that it is *impossible* for a CTO to stay up to date on all aspects of his industry, even those related to his company.

    1. Jamie*

      This is true. There are sacrifices to in-depth expertise for a broader skill set. One isn’t better than the other, it depends on what you need for that role.

      You don’t want a generalist (no matter how good) upper level IT management coding in house apps. They don’t have the time to devote to doing it properly and it will rarely be as good as what a decent programmer can knock out in a fraction of the time.

      And you might not want your chief programmer crafting CBAs and ROIs to present to the board. There are hoards of IT people who got promoted to management because they were great at their niche…and found out that it’s a whole different job where tech skills play a smaller part than they would like.

      Not that I have any knowledge about that kind of thing.

      disclaimer: I know there are exceptions to the above and some people can do everything brilliantly. I’m speaking for the majority where core competencies aren’t always equal.

  3. Programmer*

    “”I don’t know how to do graphic design or computer programming, but I can manage people who do those things. “”

    No you can not. If you are unable to program you will fail to understand what the programmers require as resources, how they do their job, what is important to them and you, etc.

    I (and most competent programmers) will refuse to work for a manager that can not program for very good reason.

    1. Ask a Manager* Post author

      I’m not going to be directly supervising a team of programmers, but their boss needs to report to someone, and that someone is probably not an I.T. person. Otherwise you’d need every company to be run by a programmer, which doesn’t make sense. As a chief of staff, I had a bunch of department heads reporting to me, covering all kinds of areas, and that’s typical.

      1. Anonymous*

        I think there’s an apple/oranges thing going on in this discussion. I would totally agree that the head of a company generally does not need to know how to do every single position at that company. (Although there are certainly some companies where management *is* trained on a wide variety of typical roles at the company as part of the orientation process) But what I think a number of people are actually arguing is that an effective manager knows how their immediate reports do their job. In the example here of a programmer, the manager of the programmers should understand what the needs, concerns & reasonable timelines are for programming. But the manager’s manager doesn’t need to understand programming, they need to understand what goes into managing teams.

        Having worked in an artistic field, there was nothing more frustrating than trying to work for managers who don’t understand what goes into the production of artwork. They would often make completely unrealistic promises to upper management (“Of course we can turn that around by tomorrow!”) without understanding how any of it fits together, and then leave the team to scramble to try and fix all the related problems that the promises created. And for every manager like the other reply here, who is harmlessly clueless and allows the staff to tell them what is needed to get the job done, there’s ten that refuse to believe the staff when they try to explain an issue. This leaves the staff with two options: (1) Pull an all-nighter, and somehow magically manage to cobble together a suboptimal solution which only reinforces to the manager that he/she was correct in the first place, or (2) Fail miserably which generally results in the staff being punished for not meeting goals, not the manager.

        On the management side, there are also issues for not understanding how jobs get done. At one studio I worked at, managers did not understand what fixes were quick and what fixes took time. The artists there developed the habit of telling anyone who asked that every tweak took two weeks, even if it was as simple as fixing a typo on a layered file. (For non-artists, that’s a 30 second fix that can be done quicker than writing an email to tell someone it would take 2 weeks). The opportunities that were dropped because there “just wasn’t enough time” to get files put together was staggering to me. (Eventually at that studio, management wised up and the artists found that they’d totally blown a really good situation–instead of keeping a large unmotivated FT staff, the company began relying more on outside freelancers who were hungry for work and willing to turn things around quickly.)

    2. Anonymous*

      If you are unable to program you will fail to understand what the programmers require as resources, how they do their job, what is important to them and you, etc.

      As a programmer who has had non-programmer managers, I can safely say that that’s not universally true. She even approved my request for the latest and greatest gaming video card the day after it was released, after I explained that it was for research purposes.

    3. Anonymous*

      A bad manager can’t effectively manage designers or programers, but if they have an idea of how to program they are going to be a little less bad on some aspects. A good manager can manage regardless of if they can program or design themselves. Sorry you’ve had poor managers but don’t paint all of them with the same brush. Some are great even if they don’t know how to do my job. Competent managers are hard to find so you may have never had one. (I’ve only ever had 2 personally.)

  4. Tonya*

    It’s funny – NOT knowing how to do everything has had a major effect on how I’ve grown as a manager. When I first started out, I was terrified that if I didn’t know how to do absolutely every task that it wouldn’t be done correctly (yep I was a micromanager). As I grew in my role and became more confident, I found that allowing my team to handle projects and tasks distanced me from the work, but gave them confidence and ownership at the same time. This also allowed me to spend more time on training and development for all of us.

    I find that once you can let go and trust your staff, you can really start to build the relationships and see who can not only do the work, but who is capable of moving to the next level themselves.

    My job is to allow my staff to excel by working with them to identify roadblocks and opportunities. As long as they let me know what the roadblocks are I can get them out of their way – or walk them through removing the problem on their own.

    So I don’t know how to do everything anymore, but I think we’re a better team because of it.

  5. Anonymous*

    It’s strange that on both threads, only IT people seem to be saying this. Probably why they make terrible managers.

    1. Esra*

      As someone who has worked on a few web teams, I think the reason it comes from programmers a lot is because we very frequently have managers who don’t know how to program and are completely unrealistic. Personally I’ve had a couple managers who have been really in tune with asking their people how soon something can realistically be accomplished, but I’ve had far more who view web/IT/design work as some black box that should work magically in often ridiculous timeframes.

  6. Smithy*

    I am essentially an administrator and for some 7 years I managed a seven storey office block (the Head Office of an organisation where I started as a junior clerk). I was responsible for contracts, maintenance, office moves, telecoms, health & safety and a hundred other things. I had to manage the security staff, heating & ventilliation engineers, plumbers, electricians and other trades. In theory I could have done some of their work (and did at times) but in general I had to know enough to ensure the job was done. Obviously I did not know how to do every job – that’s what I employed them for.

    1. Anonymous*

      “…but in general I had to know enough to ensure the job was done. ” This is key. If someone is managing multiple departments, it’s ridiculous to expect them to be an expert on everything, but they should have a general idea of how things should be done. If they don’t know, they need to make sure they find out.

      A poster above mentioned dealing with IT and design managers without tech experience and act like computers = magic. This is not good. I work in design and have had numerous managers who come in with their great ideas that have no basis in reality…because they are totally unfamiliar with graphic design and the design process. Do they need MFAs? No, but they should at least be familiar with the basics.

  7. suzanne*

    I had one delve into managing and it was a nightmare not because I didn’t know the profession, but because I couldn’t get anyone to show me the processes that were in place. It was an academic library, and, for example, there was a process for getting books out of the rare book storage area which made no sense to me. I could not find anyone who could explain it to me, nor could I get the library director to shed any light on how it had been done in the past or give me, the newbie who had never dealt with rare books in any form previously, any idea how he wanted things done. I honestly think he had no clue about most of the day to day operations.

    At another job, a temp job at a phone company, it was obvious very quickly that the managers had no clue whatsoever about the databases we used to do the work. Sooooooo much time was wasted submitting things that would come back the next day because they were done wrong. We temps knew we didn’t know what we were doing, but no one seemed to care. The only thing that got the manager’s attention was when someone accidently disconnected a 911 line.

    I don’t think a good manager has to know all the details of what everybody does, but does need to know who knows the details. I quit the library managing job that no one could give me any direction on. How could I manage student workers when I didn’t have any idea what they were supposed to be doing or why or who could tell me?

  8. Anonymous*

    Maybe it is a software thing. In this industry, the manager of the people writing code or doing QA should really be even better at those things than the people being managed. It earns respect. The workers trust the managers decisions and judgments.

    It’s really frustrating to have to work with a clueless manager in this field. When that happens the best you can hope for is for them to have a hands off approach and let you mostly manage yourself.

    Once you get above that level however, it becomes less important as at that point there are a lot more business priorities to take into account in decision making.

Comments are closed.