30-60-90 day plan for network engineers
On this page
- How is a network engineer's first 90 days different from a systems administrator's?
- What does the 30-60-90 day plan look like?
- What goes in the network source of truth?
- Which rules and directives should a new network engineer check?
- Which numbers should a new network engineer baseline?
- What does "on track" look like at day 30, 60 and 90?
- A filled example
- How should the hiring manager use this plan in the final interview?
- What should the manager ask at the check-ins?
- What the manager owes a new network engineer
- Common mistakes
- Adapting the plan
- Questions people ask
A 30-60-90 day plan for a new network engineer should check the network's source of truth in the first 30 days (devices, software versions, configuration backups, IP space, circuits and firewall rules); take a share of changes and on-call through the change process in days 31-60; and by day 90 own a domain such as the WAN, a campus, the data center or the security edge, with an end-of-support replacement list and one measured fix. As of November 2026, two dated references belong in that list: CISA's directive on end-of-support edge devices (BOD 26-02, binding on federal civilian agencies since February 5, 2026) and, where the network carries the company's phones, the FCC's 911 rules for multi-line telephone systems.
This page is for the IT manager, infrastructure lead or network manager hiring a network engineer or network administrator into an existing team. Servers, identity and patching are in the 30-60-90 day plan for systems administrators; service reliability, SLOs and error budgets in the 30-60-90 day plan for site reliability engineers. If the network engineer will report to someone who also runs the service desk and vendors, the 30-60-90 day plan for IT managers shows what that manager is working on in the same months.
How is a network engineer's first 90 days different from a systems administrator's?
| Area | Network engineer | Systems administrator | Site reliability engineer |
|---|---|---|---|
| Owns | Routing, switching, firewalls, wireless, circuits, DNS, DHCP and IP space | Servers, directory and identity, backups, patching, endpoints | A service's reliability: SLOs, alerting, incident response, capacity |
| A typical risky change | A routing or firewall change that can cut off a site, including the engineer's own access | A patch or group policy that breaks an application | A deploy or config push that burns the error budget |
| Main records | Device inventory, configuration backups, IP plan, circuit list, rule base | Server inventory, backup and restore log, patch report, admin accounts | SLO dashboard, runbooks, postmortems |
| First 30 days are about | Finding what is undocumented before touching it | Proving backups restore and patches land | Learning which signals matter to users |
In small IT teams one person does all three. If so, combine the plans and start with whichever record is weakest: an unbacked-up firewall and an untested restore are both day-one risks.
What does the 30-60-90 day plan look like?
30-60-90 day plan — [Name], Network Engineer, [team]
Reports to: [IT manager / network manager] Start date: [date]
Sites: [N] Devices: [N routers / switches / firewalls / APs]
Vendors: [ ] Carriers: [ ] Voice: [on the network / hosted / none]
Tools: [monitoring, config backup, IPAM, ticketing, change system]
Change windows: [days / times] On-call: [rotation]
DAYS 1-30 — Check the source of truth before touching anything
Goals:
- Read-only access to monitoring, config backups, IPAM and the
ticket and change systems
- Device inventory check: model, software version, vendor
support contract and end-of-support date for every device
- Confirm every device's configuration is backed up; compare
running and saved configurations and list the drift
- Walk one site and one wiring closet or data hall; label gaps
- Read the last [6] network incident reviews and the circuit list
- Make [3-5] small reviewed changes through the change process
Deliverables by day 30:
- Source-of-truth gap list (devices, configs, IPs, circuits)
- Risk list ranked by impact, agreed with the manager
DAYS 31-60 — Change safely and take a share of the load
Goals:
- Production changes in agreed windows, each with a pre-check,
rollback plan and post-check
- Secondary on-call for one rotation
- Firewall rule review for [one firewall pair]: owner, purpose
and last-hit data for each rule
- End-of-support list: devices to replace, in date order, with
cost and dependencies
Deliverables by day 60:
- Rule review findings with owners and removal dates
- Replacement list the manager can take to budget
DAYS 61-90 — Own a domain
Goals:
- Own [WAN / campus / data center / edge] end to end, including
its monitoring and vendor tickets
- Primary on-call
- One measured fix from the risk list (example: config backups
for every device, or a single point of failure removed)
- Write or update the runbook for the [3] most common network alerts
Deliverables by day 90:
- Owned domain with current diagrams and inventory
- The fix, measured against the day-30 gap list
Check-ins: weekly with [manager]; reviews at day 30, 60 and 90.Numbers in brackets are examples; size them to the network.
What goes in the network source of truth?
The day-30 gap list compares what the records say with what is running. These are the records a new network engineer should be able to find, or report missing:
| Record | What it holds | Why the new engineer needs it |
|---|---|---|
| Device inventory | Every router, switch, firewall, access point, load balancer and controller, with model, software version, support contract and end-of-support date | Unsupported devices stop getting security fixes |
| Configuration backups | A current saved configuration for every device, and a record of changes | A failed device without a backup is rebuilt from memory |
| IP address plan | Subnets, VLANs, DHCP scopes, reserved and static addresses | Address conflicts and overlapping subnets are common inherited faults |
| Circuit list | Each carrier circuit, its ID, bandwidth, site, contract end date and support number | Opening a carrier ticket during an outage starts with the circuit ID and the support number |
| Firewall rule base | Each rule with its owner, business purpose and review date | Rules nobody owns are rarely removed, and some open more than intended |
| Diagrams | Physical and logical topology, including out-of-band access | Out-of-band access is how the engineer gets back in after a bad change |
Which rules and directives should a new network engineer check?
Stated as of November 2026; not legal advice. Which items apply depends on the employer: federal directives bind federal civilian agencies only, and the FCC rules apply where the company runs a multi-line phone system.
| Item | What applies | Source |
|---|---|---|
| End-of-support edge devices | CISA's BOD 26-02 (February 5, 2026) defines edge devices as those on the network boundary that are reachable from the public internet, naming firewalls, routers, switches, wireless access points, load balancers and network security appliances. Agencies must inventory end-of-support devices within three months, remove them within 12 to 18 months and run continuous discovery within 24 months | CISA BOD 26-02 |
| Known exploited vulnerabilities | CISA says organizations should use its KEV catalog as an input to their vulnerability prioritization; BOD 26-04 (June 10, 2026) sets risk-based remediation timelines for agencies and revoked BOD 22-01 and BOD 19-02 | CISA KEV catalog; BOD 26-04 |
| Firewall policy | NIST's guidelines on establishing firewall policies and on selecting, configuring, testing, deploying and managing firewalls (September 2009) | NIST SP 800-41 Rev. 1 |
| 911 from company phones | A person "engaged in the business of installing, managing, or operating" a multi-line telephone system must configure it so users can dial 911 without a prefix such as 9; send a notification to a central location where someone is likely to see or hear it, where the system can do so without new hardware or software; and convey a dispatchable location: fixed phones by January 6, 2021, and on-premises non-fixed and off-premises devices by January 6, 2022 | 47 CFR 9.16 |
| Card payment networks | Where the network carries cardholder data, the PCI Security Standards Council's PCI DSS applies; its resource hub lists version 4.0.1 materials | PCI DSS |
The 911 rule matters more than its age suggests. A phone moved to a new floor, a softphone used at home or a new building added to the network can break the dispatchable location without anyone noticing until an emergency call. Put a test call, coordinated with the local emergency communications center, on the day-60 list if the network carries voice.
Which numbers should a new network engineer baseline?
The measures are examples. Build the baseline from the monitoring, ticket and change systems in month one, and set targets only once the engineer owns a domain.
| Measure (examples only) | What it shows |
|---|---|
| Availability by site or circuit over the last 90 days | Where users actually feel the network |
| Incidents caused by changes, and changes rolled back | Whether the change process protects production |
| Devices with a current configuration backup | How much could be rebuilt quickly after a failure |
| Devices running vendor-supported software, and devices past end of support | Exposure to unpatched vulnerabilities |
| Firewall rules with no owner, or no hits in the review period | Rule base hygiene |
| Peak utilization on WAN and internet circuits | Capacity problems before users report them |
| Time to restore service in network incidents | Spares, runbooks and access when things break |
What does "on track" look like at day 30, 60 and 90?
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Gap list compares records with what is running; drift and unbacked-up devices listed; small changes made through the process | Changes made outside the change process; no written findings; still waiting on access with no escalation |
| Day 60 | Changes carry pre-checks and rollback plans; rule review findings have owners; replacement list costed | A change locked the engineer out with no out-of-band path; rules deleted without asking their owners |
| Day 90 | Owns a domain with current diagrams; one fix measured; primary on-call handled calmly | Diagrams still out of date; the fix announced but not measured |
A filled example
Network engineer: Tomasz Wierzbicki (invented), joining a three-person infrastructure team at a regional distribution company with nine sites, reporting to the IT manager. All details are examples.
Day 30: The inventory missed two switches added during a warehouse expansion, and neither was in the configuration backup job. One site's firewall pair ran software past its vendor's end-of-support date. The circuit list had no contract end dates, so one carrier contract had renewed automatically.
Day 60: His first production changes ran in the Tuesday window with written rollback steps. The rule review on the main firewall found many rules with no owner; their owners were traced through old tickets, and those nobody claimed were scheduled for disabling first, then removal. The replacement list put the unsupported firewall pair first.
Day 90: Every device was in the backup job, checked weekly. The firewall pair replacement was approved for the next quarter. He took primary on-call and rewrote the runbooks for the three most common circuit and wireless alerts.
How should the hiring manager use this plan in the final interview?
Give every finalist the same brief: the sites, the main vendors, a simplified diagram and one known problem. Score the plans with the rubric in how to evaluate a 30-60-90 day plan in an interview. A strong network plan checks the records and the backups before changing anything, and treats rollback as part of every change. Questions that test it:
- "You find a firewall rule allowing any traffic from a vendor's address range. Nobody knows why it is there. What do you do?"
- "A change in tonight's window could cut off the remote site you are working on. How do you plan it?"
- "The inventory and the monitoring tool disagree about which devices exist. Which do you trust, and how do you find out?"
- "A site is down and the carrier says the circuit is fine. Walk me through the next hour."
The network engineer screening questions cover certifications and on-call fit earlier in the process, and the network engineer job description template sets out the role's scope.
What should the manager ask at the check-ins?
- Day 30: Which device worries you most, and why? What would we lose if it failed tonight?
- Day 60: Which changes did you roll back, and what did you learn? What is first on the replacement list, and what does it cost?
- Day 90: What is now documented that was not? What is the next risk you would fix?
What the manager owes a new network engineer
- Read-only access on day one, and a written path to change rights tied to reviewed changes.
- The change process, change windows and who approves emergency changes.
- Vendor and carrier support contracts with the account numbers, so the engineer can open tickets.
- The history: recent outages, half-finished migrations and anything a previous engineer built that nobody else understands.
Common mistakes
- Trusting the diagram. Inherited diagrams are often years old; verify against the running network.
- Changing without a rollback path. A remote change with no out-of-band access can turn a ten-minute job into a site visit.
- Deleting unknown firewall rules. Disable first, watch, then remove after the owner is found or the review period ends.
- Ignoring end-of-support dates. A device that works today may never get another security fix.
- Forgetting voice. A network change that breaks 911 location is a safety problem, not a ticket.
Adapting the plan
- Cloud networking: the source of truth becomes cloud network configuration and infrastructure code; borrow the staged access and drift check from the 30-60-90 day plan for DevOps engineers.
- Network security roles: weight months two and three toward the rule base, remote access and the edge device list, and agree escalation rules with the security team; the 30-60-90 day plan for cybersecurity analysts covers the security operations side.
- Federal agencies and their contractors: put the BOD 26-02 inventory and the BOD 26-04 reporting duties on the calendar from week one, and check the contract for which ones flow down.
- Managed service providers: each client network is its own source of truth and change calendar; add the client's approval rules to month one.
Questions people ask
What should a new network engineer do in the first 30 days?
Get read-only access to the network management, monitoring and configuration backup tools; check that every router, switch, firewall and access point is in the inventory with its software version and end-of-support date; confirm configurations are backed up and compare running configurations with the saved ones; read the last few network incident reviews; and make small changes through the change process with a senior engineer reviewing. The month ends with a source-of-truth gap list and a risk list the manager agrees with.
When should a new network engineer make production changes?
After they have made reviewed changes in a lab or a low-risk part of the network and worked through the change process at least once with a senior engineer, usually in the second month. Every production change should carry a pre-check, a rollback plan and a post-check, and the first ones should run in an agreed change window with someone experienced on the call.
What is CISA's directive on end-of-support edge devices?
Binding Operational Directive 26-02, issued February 5, 2026, requires federal civilian executive branch agencies to inventory end-of-support edge devices such as firewalls, routers, switches, wireless access points and load balancers within three months, remove them over 12 to 18 months, and set up continuous discovery within 24 months. It binds only those agencies, but its definition and timeline are a practical model for any network's replacement list.
How is a network engineer's 30-60-90 day plan different from a systems administrator's?
A systems administrator's plan is built around servers, identity, backups and patching. A network engineer's plan is built around the paths between them: routing, switching, firewalls, wireless, circuits, DNS and DHCP, and the change process that protects them. An outage on a network engineer's watch usually takes out a whole site or service at once, which is why the plan stages access and changes so carefully.