Network-Automation GCC Capability Blueprint Director

The mandate

The operator plans to create an India automation capability after years of domain scripts, vendor tools and central orchestration initiatives produced overlapping changes with uncertain rollback. Leadership has not decided whether the centre will own intent design, platform engineering, assurance logic or only development capacity. Without that choice, hiring profiles and supplier negotiations are already drifting toward another fragmented factory.

The five-month deliverable is a board-ready capability blueprint plus two tested automation-product designs. Milestone one at week four establishes the domain and failure baseline; milestone two in month two fixes authority, architecture and sourcing boundaries; milestone three in month four completes controlled laboratory trials; the closing milestone packages investment, launch waves, leadership roles and acceptance evidence.

The client will provide representative configurations, telemetry, change failures, supplier contracts, access to a non-production network laboratory and named domain owners. Acceptance requires both pilots to detect unsafe preconditions, produce traceable intent, invoke defined rollback and show an India leader can arbitrate a cross-domain conflict. The network officer and security head will sign the final evidence record rather than approve a slide presentation alone.

Production change command, live subscriber data, collective bargaining, vendor procurement and execution beyond the controlled pilots are outside the engagement. The consultants may recommend tooling and challenge incumbent boundaries but cannot select a supplier or approve a network change. Client engineers operate all laboratory infrastructure and retain credentials throughout testing.

Each artefact must remain usable when vendors or consultants leave: intent templates, decision matrices, failure scenarios, talent profiles, unit economics and launch gates will therefore be taught through working sessions. The final month includes an India-led blueprint revision using a previously unseen automation candidate. Any implementation support after acceptance would be separately commissioned and cannot delay transfer of editable materials.

Why this is external work

Domain teams, incumbent suppliers and the prospective GCC each benefit from different definitions of automation ownership. The operator needs a design grounded in real network failure, not a location case built from salary and role counts. Independent cross-domain experience can expose control gaps while leaving live network authority with accountable operators.

What you will own

• Inventory radio, transport, core and cloud automations with triggers, dependencies, telemetry, failure modes and current owners.
• Separate intent policy, orchestration platform, domain adapter, assurance logic and operations responsibilities into coherent capability products.
• Define change authority, segregation, simulation, canary, rollback and emergency-stop rights for India and Canadian teams.
• Recast supplier boundaries around interfaces, knowledge, source access, support obligations and measurable captive independence.
• Design leadership, reliability, network-domain, platform and product roles with realistic scarce-skill acquisition sequences.
• Prove two candidate automations through laboratory faults, stale telemetry, conflicting intent and incomplete rollback conditions.
• Deliver editable architecture, operating charter, sourcing model, economics, hiring waves, pilot evidence and investment choices.

Candidate qualifications

• Designed carrier-grade network automation spanning at least three of radio, transport, packet core, cloud and service assurance.
• Established safe intent or closed-loop changes with simulation, canary controls, telemetry confidence and deterministic rollback.
• Built an India network-engineering capability that owned operational outcomes instead of producing scripts for overseas approvers.
• Unbundled proprietary supplier tooling while retaining support, interface knowledge and continuity through a staged transition.
• Led laboratory evidence sessions where domain conflict or degraded observability invalidated an apparently successful automation.
• Produced a capability investment case connecting change quality, availability, engineering throughput, talent depth and supplier economics.

Non-negotiables

• Can complete two India residencies and four Toronto acceptance milestones within the five-month delivery calendar.
• Will disclose operator, network-vendor, orchestrator, cloud, systems-integrator and automation-platform relationships.
• Brings production network-automation design and GCC formation evidence; generic DevOps transformation is insufficient.
• Accepts client-operated laboratories, editable artefacts and dual sign-off by network and security executives.

1. 49 words maximum. Describe a closed-loop network change you rejected because its rollback evidence was inadequate.
2. 49 words maximum. Which automation decision belongs with an India product owner, and which must stay with live operations?
3. 49 words maximum. Name the network suppliers or orchestration platforms that could create a conflict for you.