Ask LH: How Can I Start Well In A New IT Job?

Ask LH: How Can I Start Well In A New IT Job?

Dear Lifehacker, I’m starting a new job as a systems administrator in a few weeks. I have a few years’ experience managing a help desk, supporting between 300-400 users, and doing some Windows admin with a few servers (

I’ve spent the last few hours scouring the web for ideas, and I’ve read through The Practice Of System and Network Administration, but there don’t seem to be any tips specific to starting your new job properly. I would like to know if there are any suggestions you or your readers could offer to help someone in my situation to get accustomed as quickly as possible to the new environment; I know I’ll need to draw the network layout – what servers do what and the like — and decide who the best people are to discuss managing tasks on those servers, and who uses them – but are there any specific methods or guidelines I should try to follow? Thanks, The Guy In The Next Room

Dear Guy In Next Room,

I’ve never had to administer more than a couple of servers at a time, so I’m not going to pretend to have any massive insights here — I’m trusting our readers who work in this field may be able to offer some more specific tips. The one thing that strikes me in your situation is that it may be a good idea to seek out a couple of one-day training courses early on. Once you’ve got a good idea of what’s in place you may discover that there’s some systems you’re less familiar with. Given that your boss doesn’t have technical skills, getting some extra training on those technologies would make sense for both you and the company. I’m assuming you wouldn’t have been hired if you weren’t already familiar with the key technologies used at this workplace — and that’s something to remember if you’re feeling swamped! — but IT roles invariably require regular skills updating.

Beyond that, I’m asking the wider Lifehacker community: what would you do to ensure a good start in this kind of position? Share your thoughts in the comments.



  • Just be honest, and if there are other technical people there, ask questions whenever you are unsure. There’s nothing worse you could do than feign understanding, because that will catch up with you eventually, and unpleasantly.

    Documentation is definitely the first step, if there isn’t any decent doco already, and it’s an easily justifiable activity for the good of the business long-term. Documenting everything (or verifying that the current documentation is up to date) will also give you a good understanding of all the technologies involved, and highlight any areas you may need to brush up on.

    If you’re unfamiliar with something, a good way to familiarize is to create a working implementation on a computer at home (or in a VM) that mirrors what the production servers are doing – this way you can tinker without breaking anything. Obviously in the M$ world this can be difficult, since they want money for a lot of their stuff, but I’ll leave you to decide how to deal with that (I’m a *nix guy).

  • Working as an infrastructure consultant I have seen people in a similar role coming in and everyone has different ways of going about it.

    Everyone learns differently, some people like reading documentation done by the previous admin (if any) and some like to make their own fresh. This can be a good way to go about understanding how everything is set up and making yourself look good to others in the team and giving yourself time to let it sink in. A good level of docs I have seen in a spreadsheet, sharepoint or better yet a wiki. From this you will start to know what you don’t know and can fill in the gaps of your knowledge as you go.

    Outside parties like consultants that work with the organisation often can be a wealth of knowledge and you shouldn’t be afraid to ask the silly questions to make sure you understand who’s who and what’s what.

    For the first week or two you will probably be thinking, OMG how am I going to learn all this, but if you tackle it in small bites it will become clear how it all fits in and most concepts of how things work in a small environment are mostly similar in the large with just more expensive gear/software.

    If applicable to your site, training I would recommend is Commvault (if using BackupExec you should be able to work it out), maybe some VMware, even just so you have an environment you can play with in the labs and if you haven’t dealt with it and they run it and you are to look after it, Citrix (XenApp). These can have a steep learning curve and proper training can make it easier. At least try and understand what you have before going on the training though so you know what questions to ask the trainer/others in the course.

    So in short my advice would be, document and don’t be afraid to ask questions of ANYONE and try not to be overwhelmed, small bites.

    Feel free to email me if you think I can help.


  • I’d say you have a perfect opportunity to set up some new management partnerships early on. With the project manager being a bit green and typically for your job, not directly related in experience to your server admin role; you can weed out the higher ups/psycho’s who micro manage.

    Also, don’t just know what servers do what, find out the upgrade path/policy for hardware upgrading/replacement; get this started now because management always listens to the bean counters FIRST!

    Join the Stack Exchange forum & read the blogs on The Register. Lastly, try to get a foothold into where the company wants to head in the future – basically means if it involves IT in any way, you should have a ‘small voice’, you’ll save yourself from some nasty surprises.

  • “pdf” is right. Don’t fake competency. It will catch up with you (prior experience!). Just tell your superiors that it might take you a while to get settled in, as this is different from your last job. I walked into my current job interview with lots of computer experience, but no business experience. My boss saw the potential and hired me. Three years on, I know the system inside out and can do my job with little to no supervision.

    Also, although this is jumping the gun, take notes on everything and compile them into a “manual” you can give to the next IT guy, or even use yourself when you forget.

    As for the initial learning, ask forums and call support numbers. For example, you can call Microsoft and ask for help managing SQL Servers, or you can call XYZ Inc. for help with Product B. Your procedures will be different from the last person (e.g. You might tick box A, he might click box B) but as long as everything runs alright, you’ll be fine. Besides, if you snag their number, you can call them for advice for the first few weeks.

  • Having been in a similar situation, I have learned 3 invaluable rules:
    1) Do NOT make any change until you know how to reverse it. (This also implies making one change at a time, where possible, and document everthing)
    2) Do NOT make any changes on a Friday afternoon. (Murphy’s law dictates that you will spend Friday night and probably the best part of the weekend undoing what you did, even if you did follow Rule #1)
    3) Write-up, have your boss, your boss’s boss and their boss sign off on, and then distribute circumstances when you can be called out after hours. (Nothing wears you down more than being called 24/7 for frivolous reasons)

    Otherwise, get to training when you can (especially the basics, you can usually learn the in-depth stuff yourself) and talk to other techs (join SAGE-AU ( if you don’t know any).


  • Download Spiceworks 5 on to your workstation and then scan the network. It’s a free programme and it does Network mapping. Give it a go and see what it finds.

    • Don’t download and run anything new in a new environment. Lots of old things break/fall over from being scanned. There is a fair chance that it is illegal to do a scan like that unless you get the written permission from the business. It can set off all sorts of alarms for intrusion detection and people will shut things off.

      Really bad bad advice!

  • Get to know the business managers and service management / incident management teams (who you’ll be calling if everything falls over). You may not need them on your first day, but they’re contacts you’ll regret not having, when you need them.

    As previously mentioned, find out about refresh / replacement / maintenance on hardware, storage AND databases.

    Find out your escalation points for when someone important asks you to do something which you think is a really bad idea. Always keep your integrity, if you think it’s a bad decision, say so & specify the risks.

  • Never assume the last guy knew what he was doing. There is a good chance he was lazy and incompetent. So you need to make sure the fundamentals are in order:

    1. Backups. Your first real job (after working out which servers are the important ones) is to make sure the important data is being backed up, can be restored, is sensible. Get the back logs. Audit them. Disaster Recovery planning should be looked at as well – but not until you know the shop is in order.

    2. Logs & Alerts. Make sure that list of important servers has proper alerting and logging going on and you are receiving important notices.

    3. Support contracts. Make sure all important boxes and software have up to date support contracts/warranties. Otherwise you are on your own.

    4. Log/write down everything you do. Think twice and re-read anything you are doing as root/admin. Keep records – I have been saved at 3am by reading a log of a terminal session from an install I did 3 years earlier.

    5. Stats and capacity planning. Otherwise your critical disks will fill up or your boxes will grind to a halt. just before end of month/market crash etc and everything will halt.

    6. Computer room. Make sure the cooling/power/cabling is in order and sensible – sounds obvious but I have seen some disasters. Try to put yourself in the situation of going in at 3am, what it will be like? Trying to pull the correct cable out – if everything is a mess you will make mistakes.

    Your job is to make yourself redundant. Automate everything. Document everything. Only then can you get promoted and move into architecture work. Be enthusiastic, take on everything and attempt to learn everything, read everything.

  • Your first step is to understand the environment. Your first few days should be information gathering and fire fighting. Figure out the network and how the environment hangs together. Get a remote connections list sorted out so it makes sense. Figure out what you’re managing and where it is. Figure out the change control process and what your expected daily/weekly/monthly tasks are.

    Basically spent a few days getting your head around WTF you’re working with and wtf you’re supposed to be doing. Deal with any major fires if you have to – but don’t expect to be productive for your first few days.

    Then once you’ve figured out roughly where you are and what you’re supposed to be doing – start making at least a mental, but preferably a managable and documented ‘to do’ list of things that could be better. Things you could document better. Things you could automate. Workflows you could improve. Architecture that could be improved. Etc. Don’t marry the list – you probably don’t have enough experience for all of your ideas to be right. But as you get time going forward, start working through that list – looking into things in enough depth to figure out if your idea had any merit, and if it does – what you need to do to knock it off. Continue to iterate through the list knocking over small or really important projects as you get time and reviewing the list. When the list is empty – you should be redundant and you should have a really impressive title.

    If you have a ticket queue or something, read through it. At least briefly, before you actually do anything. Just get your head around what’s in the queue. What issues are problematic/outstanding. Figure out if you can consolidate multiple tickets relating to the same issue, or if you have some facillity for consolidating multiple issues to a problem. Think of this process as triage rather than actually doing anything immediately productive. The goal is to understand the state of outstanding work and then where possible simplify it – and get at least a mental list of how long things are going to take and how urgent they are – then figure out which ones you’re going to do first.

    Keep a bunch of notes. Ask a bunch of questions – even if you know you won’t get the answers. Demonstrating that you’re working through getting your head around the situation and you’re putting active effort into the process makes it clear that you’re a busy, hard working and producive administrator – not a nerd who drinks coffee and sits quietly in the corner and doesn’t do anything.

Show more comments

Log in to comment on this story!