Network Operations Engineer
1. About the role
Share is the global marketplace for bandwidth. We aggregate telco infrastructure into a single layer and give ISPs, hyperscalers, and AI companies a clean path to deliver connectivity into every home and business across Kenya and the continent. Behind that marketplace is a real network: a BGP edge peering with Tier 1 transit, hyperscalers, and local exchanges, an MPLS backbone, aggregation and access gear, and the systems that watch all of it.
For the partners who run on us, the network is the product, and the NOC is where they feel it. A clean shift is a partner who never knew anything happened. That is the bar.
We are early and the team is small, so we cannot afford a pair of hands that only knows how to escalate. We need a capable network engineer who can stand a shift, resolve real faults without waking anyone, and then keep building the network while East Africa sleeps: propagation and peering checks, health passes across the estate, config changes through to merge, tickets off the board, automation that takes the next repetitive job off everyone's plate. The watching is the floor of this role, not the ceiling.
The NOC you would be joining is not a legacy one. We are building it as an AI assisted operations environment from the ground up. The forwarding plane runs on open source routing and forwarding software, every device configuration lives in Git, and an LLM layer sits on top of the live network state. When something moves, that layer reads the telemetry, correlates it against the topology and the config history, and puts a probable cause and a candidate fix in front of the engineer on shift. The point is not to replace your judgment. It is to collapse the time between an alert firing and you knowing where to look, so mean time to repair is measured in minutes.
You sit inside that system. You use it, you push back on it when it is wrong, and what you catch that it misses is part of how it gets smarter. As we build automation out across the NOC, you are not just a consumer of the tooling. You help write it.
2. What you'll do
Watch, and know what you're looking at. Sit on our monitoring stack (Zabbix and Grafana dashboards, flow telemetry, alerting) and actually read it. Learn what normal looks like so abnormal jumps out at you: a BGP session that dropped, a link that went down, latency climbing on a path, a capacity threshold breached, a partner suddenly pushing or pulling nothing.

Troubleshoot and resolve. This is where you earn your seat. Confirm the alert is real, gather the facts, and localise the fault: one peer or many, us or upstream, a real outage or a monitoring blip. The assistive layer surfaces a likely diagnosis and a suggested fix, the config history is right there in Git, and the runbooks are live. Your job is to read all of it critically, decide what is actually true, and close out what you can on your own. Every ticket you resolve yourself is one our senior people did not get pulled out of deep work, or out of bed, to deal with.

Keep the network healthy, not just alive. A quiet shift is not an idle one. Run the proactive passes: check that routes are propagating the way they should, that RPKI and filter chains are doing their job, that peering and transit sessions are clean across the edge, that no PoP is drifting toward a capacity wall. Catch the slow degradations that never trip an alert. The day team should inherit a network in a known good state.

Build and automate. The repetitive parts of this job should not stay repetitive. Write the scripts that turn a manual check into a scheduled one. Push our config automation forward (Jinja driven generation, NAPALM or NETCONF/gNMI against the devices) so changes ship from data, not from memory. When the assistive layer keeps missing the same thing, that is a candidate for automation, and you are well placed to build it during the hours nobody else is online.

Move the work forward. You are part of the network team, working the same board they do. Pick up tickets from the Linear queue, take config changes through review to merge, and keep our source of truth (Nautobot) accurate as the estate changes. Real work lands while East Africa is offline, so the team wakes up further ahead than they went to bed.

Report exactly what is happening. For everything you cannot or should not fix alone, the handoff has to be clean: what is wrong, where, since when, what is affected, whether it is getting worse, and what you have already tried. No guessing dressed up as fact. No "the internet is down." A clear, written incident note a senior engineer can act on the moment they open it, and a tidy handover to the East Africa team at the end of your shift.

Escalate well. Know the ladder cold: what you are cleared to touch, what you must not touch alone, and who to bring in for what. Escalating early on a genuine outage is good judgment. Sitting silently on a problem because you were unsure is the one thing that gets people out of bed angry. Handle what you can, raise the rest fast and clearly, and do not turn either dial too far.

3. Who we're looking for
A network engineer who can stand on their own through a shift, and who treats the quiet hours as time to build rather than time to wait. You will not be the most senior engineer on this team, and you do not need to be. The people you escalate to are CCIE level. What we need from you is independence and range: work a problem properly, resolve a fair share of it yourself, and use what is left of the shift to actually move the network forward. Pair that with clear reporting, sound judgment about when to bring in help, and the instinct to question a machine's suggestion rather than follow it blindly, and you are who we are looking for.

Must-have

• Strong networking competence, held in your hands rather than on paper. CCNA and well beyond it. You understand TCP/IP, routing and switching, IP addressing and subnetting, DNS, DHCP, NAT, and how t