Today, we meet Roman Arnaut, NOC Engineer, one of the people who helps keep the network stable even when unexpected situations arise.
In a role where quick reactions, clear communication, and staying calm under pressure make all the difference, Roman shares what working in NOC means beyond monitoring, how he grew professionally during his first year, and what motivates him to keep getting better every day.
How would you describe your role today, in terms of the impact you have?
My role is defined by one core responsibility: being there when no one else can be.
I react to unexpected circumstances – the ones that don’t wait for business hours – and I resolve them at the moment they matter most.
In NOC, the value you bring isn’t always visible when things run smoothly.
It becomes clear the moment something breaks at 3 AM, and someone has to step up. That someone is me.
Looking back, what would you do differently in your first months, knowing what you know now?
I would communicate earlier and more openly. In my first months,
I tended to troubleshoot in silence – heads down,
trying to solve everything on my own. While that determination had its place,
I didn’t realize the cost: it took longer to resolve issues, and the people who needed to be informed weren’t always in the loop in time.
I’ve since learned that speaking up early – even before you have all the answers – is not a sign of weakness.
It keeps the right people informed, opens the door for someone to offer a helping hand, and ultimately leads to faster, better outcomes.
In NOC, silence is never the safest option.
What skill or habit contributed the most to your progress in the first year, and how did you develop it?
Documentation. Getting into the habit of writing clear, structured incident notes forced me to think more systematically.
Over time, those notes became a personal knowledge base – and they helped the whole team, not just me.
What does a “good day” in NOC look like for you today, from a network stability and performance perspective?
A good day in NOC is a quiet one – but quiet for the right reasons.
It’s a day where the network runs smoothly, and that silence gives you space to be proactive: automating repetitive tasks, refining processes, or building tools that make the next incident easier to handle.
But even on days when things do go wrong, a good day is still possible. It just looks different – it’s defined by how fast the team reacts, how cleanly the incident is handled, and how little time the network spends in a degraded state.
In NOC, the goal isn’t the absence of problems. It’s building an environment where problems don’t linger.
What is one thing people often misunderstand about working in a NOC role?
That it’s just “watching dashboards.” In reality, it requires deep technical knowledge, fast critical thinking, strong communication under pressure, and the ability to make judgment calls with incomplete information – sometimes all at once.
How has the team concretely helped you grow in this role over the long term?
My team never just handed me the answer. They pointed me to the cause, then guided me toward the solution – letting me work through it myself. That approach forced me to understand problems at a deeper level, not just fix them. Over time, that’s what shaped the way I think about networks today.
What motivates you to keep improving every day in such a dynamic role?
Networks are living systems – they evolve, scale, and fail in new ways constantly. That keeps me curious. Also, knowing that my work has a real downstream effect on people’s ability to communicate, work, and access services is a genuine motivator. It doesn’t feel abstract.
Can you describe a real situation where you had to react quickly to an incident and what you learned from it?
During an incident where traffic through one of our upstream operators was degraded, I quickly identified that the issue was on their end – not ours. Rather than waiting for them to resolve it, I rerouted the traffic through an alternative operator, minimizing downtime for our clients. It was a simple decision in hindsight, but it required fast diagnosis and the confidence to act. That’s what NOC is about – knowing when to wait and when to move.
What is a difficult decision you had to make during an incident, and how did you approach it?
During an incident where traffic through one of our upstream operators was degraded, I quickly identified that the issue was on their end – not ours. Rather than waiting for them to resolve it, I rerouted the traffic through an alternative operator, minimizing downtime for our clients. What I learned from that experience was twofold: how to properly read BGP logs to diagnose upstream issues faster, and that waiting for someone else to act is not always the right call. Sometimes you have to trust your diagnosis and move.
What would make you say, a few years from now, that you have succeeded in this role, from a professional perspective?
If I’ve moved from reacting to incidents to preventing them – and if I’ve helped someone newer on the team grow the way my colleagues helped me. Success in this role isn’t just technical mastery; it’s becoming someone the team can rely on, and contributing to a culture where everyone gets better together.
