A Day in the Life of a Network Engineer
In this article, I'm going to cover what my day-to-day responsibilities were as a Network Engineer. I'd like to say that your day HIGHLY depends on the organization.
First, I'd like to give you a little background on the company. Baltimore City Schools has a large enterprise environment of about 200 locations (Schools), headquarters, and two data centers. During my time there we managed approximately 2,000 switches. Our busiest times of the year were the opening of schools and during standardized testing periods. I worked with a small team of 8 people including myself each with our areas of focus (i.e. Routing and Switching, VoIP, Wireless and Analog Telephony). We were all expected to have a basic understanding of all roles in case extra support was needed.
My focus areas were routing and switching, network monitoring, data center, and some project management. I also worked on maintaining inventory and updating network diagrams/documentation.
Typical Schedule
8 - 8:30 AM - Arrive at Work
9 AM - 12 PM - Review down devices, trouble tickets, follow up with users (time spent varied based on the volume of tickets)
Cleaned up the ticket queue by closing out requests that are resolved, updated tickets that may have been related to more significant issues, reassigning tickets to other teams.
I worked to do remote troubleshooting on our switches. Including changing port configurations, clearing network loops and updating switch configuration. If the issue were something physical or required additional troubleshooting at the site, I'd either update a colleague who was in the field with what I had done or gone out to the site.
If we had a request from our Server and Security teams, I worked with them to complete the request which often was updating a switch configuration in the data center.
I worked with our Tier 1 and 2 folks to address issues they saw at the schools.
12 Noon - Lunch/Study Time
1 PM - 5 PM - Project Work
During the afternoon hours, I'd work on projects. In some cases when I was the project manager, that meant spending time writing project plans, reviewing bills of materials, organizing and meeting with resources, scheduling maintenance windows...etc.
As a project resource, this time would be spent completing my assigned tasks.
There were days when I need to do both, so I worked based on priorities and deadlines.
Typically, my day ended at 5 PM unless there was a last-minute emergency that popped up or maintenance that needed to get done after hours which was rare. We usually completed maintenance over the weekend.
Now, this schedule wasn't my every day. There were days when I didn't work on tickets at all. During those days I focused solely on projects and other administrative tasks like inventory and updating documentation. I also often worked with TAC on issues we'd see and required assistance troubleshooting. We had meetings throughout the week, and the "hey drop what you're doing" requests were frequent. We also had our share of network emergencies (i.e. the network is down) that took priority and required the team's attention. On our quiet days when there were no tickets that needed to address, and projects were on track - I took time to study. Management encourages us to expand our skills because as a government entity, there wasn't always a budget to hire new talent. Also, there was no on-call rotation, but in the event, something significant happened during off-hours, we'd have to provide support.
IT life is not perfect and changes every day. The schedule above is what I like to call a good day. Time management is your best friend as an engineer since you'll often be working on multiple projects at once. Also, it's important to point out that priorities change. So you must be able to shift your focus at a moment's notice if required. Again, your day-to-day depends on your environment. For example, as a network engineer consultant, I spent time meeting with our client and working solely on the projects I was assigned and resolving network issues. I had very little interaction with the users in the organization. As you're interviewing, it's a good idea to get an understanding of the typical day-to-day and the expectations for your role beyond your job description. At Baltimore City Schools, for example, I was expected to have an understanding of how our VoIP environment worked and be able to work on VoIP-related projects while as a Consultant my only expectation was completing network-related projects and tasks. The key to being successful is to be able to adapt to rapid changes and understand that there's no such thing as balance, only priorities.
Please share your day-to-day below.
