I was asked an interesting question today by a helpdesk technician….
I think I am a great helpdesk support tech, but I would really like to make a change and move up the ladder to become an entry level email admin, what should I do?
Wow!! The first step here is to recognize where you want to go – and this tech had it nailed!! If you are in this position – this first step is a biggie!
After further discussion I found that this person already had identified why they wanted to go into email administration, why they felt they were competent enough, and what they wanted this to lead to.
The technician felt that email was looked at in the company as high priority application (despite it not being a core business application) and this person wanted the corporate visibility and close customer interaction that this would give them. Further, the technician realized that there is more training freely available for things like email administration then more highly customized applications so they felt they had a better shot at growing their skill sets.
The technician had been fielding outlook related tickets for some time and had begin to read more support articles on the web. Having already achieved a computer related associates degree and working on a MIS degree, the tech felt that they could comprehend things beyond the basic outlook issues.
The end goal for this tech was far beyond email administration though. The tech was looking to get into enterprise architecture (which is drastically different then basic email administration) – but the tech was thinking that with the support calls they were taking interacting with groups all over the company, it was easy to assume that an email admin would gain insight into these other areas.
Impressed as I was at the ambition, I was skeptical of the question…. I had never been approached in this way before for such candid advice. Happy to be in a position to give the advice though, I thought carefully and started with the basic response about how to learn the technology. I then setup some follow-up time to make sure that this person was going to be successful in their long term goals. I wanted to post the advice I gave here for others to use. First the basics of learning the technology, I’ll post on the other stuff after I actually deliver the advice!
The first bit of advice was simple – go get a book, a VM, and some time!!
Starting to read about and play with these things is always the first step. Understanding the tools and the concepts behind using them begins to even the playing field when approaching a new technology. Think about when you learned to drive – the first thing you did was to get a book and take a class about driving (or maybe your parent took you into the car and gave you some one on one instruction). The first step here was understanding what the tools were (guages, pedals, gear shifter, etc). The second step was to take a car for a spin!! Yeah it was thrilling to get behind the wheel – a danger to society – but it was in a safe environment with people watching over you or at least controls in place to prevent a disaster. Step three? Well you practiced!! You practiced driving, you re-read the manuals, and you asked questions of your parent or instructor about how to actually drive and what to do in different situations (4 way stop, 5 way stop, etc).
Learning a new server product is not a lot different – and should be approached in a similar fashion. If you jumped behind the wheel of a production email system today you would be a threat to society – if you jumped behind the wheel (or administration tools) of a virtual test environment – like a controlled driving practice – you would be less of a threat and more likely to learn something. Add to this some knowledge about what the tools are called (what are the guages to look at in the email system? What pedals make email go slower and faster? How do passengers get in and out and do they need to buckle up or can you buckle up for them?) There are loads of questions that the books will give you instant insight to. This is why starting with a book or a class from no knowledge is critical. This is also why starting in a test environment is critical. Applying that basic knowledge from the books is easy to do incorrectly (yes – push the gas pedal but not THAT hard).
With a healthy dose of book/class knowledge and some real time investigating the different components of the email application, such as:
- How does email come in and out of the system
- How do users access the email from their desktops, laptops, and mobile devices
- How are spam and virus messages captured
- How are mailboxes added/removed from the system
- How are resource/shared mailboxes and distribution groups handled
- How are size limits, email addresses, etc configured
A savvy technician would be ready to spend some time with a production system working on basic tasks with confidence. This confidence is the key, a team of email administrators and architects would rightly be weary of letting just anyone touch the system, but being able to demonstrate an understanding of these basic components – a tech could easily convince a more senior administrator that they are worthy of an opportunity to learn more.
Obviously there are more things this tech is interested in learning from me, and we are planning to chat again late next week – I’ll post again after we chat….