Jad Seifeddine
Contact

Leadership and communication

Clear thinking, clear words, when it matters most

Technical depth is only half the job. The other half is leading the people who run the systems, earning the trust of the customers who depend on them, and explaining complex problems in plain language, especially when production is down and the stakes are high.

01 · Leading teams

A hands-on team lead

I have led and mentored engineering teams for most of my career, across networks, systems, platform engineering and development. I lead from the keyboard: I pair on the hard problems, review the work and write the runbooks, so the standard is set by example rather than by memo.

Good teams are built deliberately. I make expectations explicit, give people ownership of real systems, and invest in the practices that let a team move fast safely: infrastructure as code, CI/CD, observability and blameless reviews. When I introduced Terraform, Jenkins and Prometheus to a team, the goal was never the tools. It was a team that could change production confidently without me in the room.

What that looks like

  • Clear ownership, priorities and definitions of done
  • Pairing, code review and mentoring as everyday practice
  • Standards set by example: documented, automated and reviewed
  • Shielding the team from noise while keeping stakeholders informed
  • Growing engineers into the next generation of leads

02 · Partnering with customers

Business first, then technology

Much of my work has been directly with customers: business clients relying on voice, network and data centre services, and today, AI and high-growth technology companies that bring me into live production. The pattern is the same every time. Understand the business first, then the technology.

How an engagement runs

  1. ListenWhat the business does, what it is trying to achieve, and what an outage or a delay actually costs.
  2. AssessThe current platform, its risks and the team running it, written up plainly with no surprises.
  3. RecommendOptions with costs, risks and trade-offs side by side, and a clear recommendation.
  4. DeliverSmall, reversible steps, with progress reported in business terms rather than ticket numbers.
  5. Hand overDocumentation, runbooks and a team that can run it confidently without me.

03 · Making the complex simple

The same truth, framed for who is listening

Complex systems fail in complex ways, but the people who need to act on that information rarely need the complexity. My job is to translate: to find the sentence that explains what is happening, why it matters and what we are doing about it, then adjust the depth for who is listening.

The rules I write by

  • Lead with the impact, then the cause, then the plan
  • Say what we know, what we do not know yet, and when the next update will be
  • Plain words over jargon; one good diagram over ten paragraphs
  • Numbers people can act on: customers affected, time to recover, cost of each option
  • Write it down, so the decision and its reasoning outlive the meeting
Illustrative example

One incident, three audiences

A carrier link in one region starts dropping, and some customers there cannot connect.

For the executive team

Some customers in one region cannot reach our services. We know the cause: a fault on one of our carrier links. Traffic is moving to our backup path now, and we expect full service within 20 minutes. Next update at 10:30.

For customers

You may see slow or failed connections from some locations. We have found the cause and are rerouting traffic now. No data is affected. We will update you by 10:30.

For the engineering team

BGP session to upstream A is flapping (hold-timer expiry) and prefixes are being withdrawn. Lowering local preference on A to shift egress to B, carrier ticket raised, watching convergence. Root cause review after recovery.

04 · Calm under pressure

Communicating when the stakes are high

When a critical system is down, every minute has a cost: to customers, to revenue and to trust. In those moments clear communication is not a soft skill. It is part of the fix. Calm, structured updates stop speculation, keep decision-makers in the loop and give the engineers room to work.

The update I send, every time

Impact
Who is affected, and how
Known
What we know, and what we do not know yet
Action
What we are doing now, and who owns it
Next
A specific time for the next update, and we keep it

Every incident ends with a blameless review written for two readers. Engineers get the timeline and the root cause. The business gets the impact, what changed, and what it would cost to prevent a repeat.

05 · Knowing what matters

Understanding business criticality

Not every system is equally important, and not every risk deserves the same urgency. I map systems to what they mean for the business, such as revenue, customers, contracts and compliance, so that priorities, budgets and on-call effort go where failure would hurt most.

It also changes how I speak. A change window, a migration plan or an outage is described in the terms the business uses to make decisions, not in the terms the tooling uses.

In practice

  • Lead cross-functional teams to ship robust, scalable solutions that improve performance, resilience and cost.

    Profile

  • Deliver DevOps, SRE and platform-engineering engagements for AI and high-growth tech clients, running live production where reliability, scale and cost are critical.

    Mercor

  • Improve incident response and reliability through SRE practice, runbooks and deployment guardrails.

    Mercor

  • Led and mentored the IT team in Terraform, Jenkins CI/CD and Grafana/Prometheus practices, lifting uptime and cutting time-to-resolution.

    Next Generation Networks

  • Supported more than 2,000 VoIP and PBX clients alongside multi-data-centre network operations.

    Next Generation Networks

  • Led a comprehensive Azure/AWS cloud-migration strategy delivering cost savings and resilience.

    Next Generation Networks

FAQ

Questions people ask

Is Jad Seifeddine a team lead?

Yes. Jad is a hands-on technical team lead who has led and mentored engineering teams across networks, systems and platform engineering, and leads cross-functional teams that ship robust, scalable infrastructure. Jad leads by example, pairing, reviewing and documenting alongside the team.

How does Jad Seifeddine communicate during a major incident?

Jad runs incident communication to a fixed structure: the impact first, then what is known and not yet known, the actions under way and who owns them, and a specific time for the next update, which is always kept. Updates are tailored for executives, customers and engineers, and every incident ends with a blameless review written for both engineers and the business.

Can Jad Seifeddine explain technical problems to non-technical stakeholders?

Yes. Jad translates complex infrastructure, network and AI topics into plain language for executives and customers, leading with business impact, cost and options rather than jargon, and backs every recommendation with clear written documentation.

Does Jad Seifeddine work directly with clients?

Yes. Jad delivers engagements directly for AI and high-growth technology companies running live production, and has supported business customers on voice, network and data centre services for two decades. Engagements start with the business goals and the cost of failure, and end with a documented handover.

Have a hard infrastructure problem?

Open to select consulting, contract and advisory work. Tell me what you are building and where it hurts.

Get in touch View resume