Own the technology. Lead the people who run it. Leave both able to continue without you.

The job is an operating picture that leadership and the operators can share: what is running, who owns it, cost, risk. The team should not depend on the last architecture slide, or on the person who still remembers it. Most organizations are not “in the cloud.” They are running across several of them. Azure may be the primary gravity well, AWS services that grew up elsewhere, Oracle Cloud for the ERP or databases, occasionally a sovereign tenant with its own portal. Those are the planes. The practical problem is not their presence. It is the absence of a coherent picture: unclear boundaries, unowned resources, and diagrams that no longer match what is actually deployed.

The work is to make that picture legible to the people who have to live with it. Resource Graph and equivalent tooling across clouds reveal what is running, not what the last slide claimed. Subscriptions, landing zones, networking, and policy are treated as a single operating picture. The goal is boring reliability and a map that survives the person who drew it.

• Operating picture
• Named ownership
• Sovereign tenants
• A map that survives the author

The control plane is how the team stops depending on one person’s memory of leftover registrations and credentials. SSO is easy until it is not. The failures that matter live in the edge cases: application registrations that outlived their projects, service principals with lingering credentials, tokens embedded in runbooks, and directories that do not share a plane.

The practice treats identity as the primary control plane of the estate. Every significant application is mapped to a clear identity path. Conditional Access is applied where it actually reduces risk. Credential lineage is tracked rather than assumed. Global Administrator is a break-glass privilege, not a working account. When a SaaS platform cannot enforce recipient-domain restrictions, the response is operational—not another policy document. Successors are walked through the map until they can handle the odd registration without external help.

• Control plane
• Credential lineage
• Break-glass only
• A successor who can handle the odd case

Perimeter work is a recurring discipline the operators can explain, not a scan that only a specialist can read. A public IP is not, by itself, a finding. The useful questions are layered: Is the resource even running? What controls sit in front of it? Does the certificate name match the DNS people actually use? Did a CNAME grow around the intended path?

What is reachable is enumerated across clouds. A clear disposition vocabulary (approved exception, remediation, decommission, false positive) keeps the backlog from becoming a list of opinions. Certificates, domain portfolios, and default-deny settings on collaboration and analytics platforms are brought under the same continuous review. The result is an explainable attack surface rather than two competing truths—one from the security tools and one from the people who actually run the systems.

• Recurring review
• Disposition vocabulary
• Certificates and domains
• An explainable surface

The work is to keep industrial and corporate planes separate and understandable to both the network team and the plant engineers. Manufacturing and industrial estates are not office networks with more dust. OT networks, plant automation, and SCADA-adjacent systems require strict segmentation. A well-intentioned peering or routing change can quietly collapse the boundary both groups depend on.

On the campus and WAN side this is still frequently Cisco—firewalls, edge routing, VPN termination—sitting next to Azure VNets and whichever cloud the ERP chose. That is what is actually there, not a certificate. The director’s responsibility is named change authority: what may route, what must not, and who is allowed to change it. Keep those planes from becoming one fabric by accident.

• Intentional planes
• IT/OT boundary
• Named change authority
• Understandable segmentation

The successor inherits how the work is run: the picture, the meeting, the named owners. Not only the diagrams. The through-line of the practice is not a particular technology. It is a contract: take ownership of the technology and of the people who have to live with it, then leave both able to continue. A long engagement that leaves the organization dependent is a failure of the original ownership.

The method is consistent across scales. Living artifacts, clear ownership with actual names, sandboxes on the surfaces that hurt, and a defined period of advisory support after exit. In earlier years this meant training clients until they no longer needed outside help to keep Novell and SCO Unix environments operational. The test remains the same: can they run the next cycle with the previous owner out of the room?

• Living artifacts
• Named ownership
• Transfer test
• Advisory after exit

Most AI initiatives die in a deck. The standard applied here is the opposite. A capability ships only when it performs a job a person already does, on systems the organization already owns, with a clear owner, data boundary, and fail-closed behavior. The person decides what earns a place. The model does not.

The current working example is a receptionist on a published number (and in the browser) that reads the calendar, books or moves time, and takes messages during defined business hours. That same discipline is applied when evaluating where models belong inside a larger estate: identity boundaries on the tools, data that is appropriate for context, and a refusal to stand up copilots that no one will open on a Tuesday. Predictive or operational use cases in manufacturing are considered only when they meet the same bar—clear job, clear owner, clear failure mode—not as science projects.

• Defined job
• Clear owner
• Data boundary
• Fail-closed