Approach
Six operating principles I have learned by running programs where the deliverable was hardware in a store, a network in a rack, or a data platform underneath both.
Code merged isn't the finish line for me. The finish line is the team that inherits this being able to run it on a Monday morning without me in the room. Honestly, if they can't, I haven't shipped anything yet. Every program I run has an operating model with real owners, a real cadence, and an escalation path that works. If that model isn't credible on paper, the program isn't credible.
I write documentation the way engineers write code: with a reviewer, a source of truth, and a change log. If a decision isn't captured somewhere durable, it will be re-litigated in six weeks. Confluence pages, runbooks, close-out reports, DAX libraries. That's the shape of the program a year after go-live.
The metric on the executive slide and the metric the store manager looks at have to be the same metric. When they aren't, the program is measuring itself instead of the outcome. I build the reporting layer early and validate it against what someone on the floor or on-call actually experiences, not what the dashboard looks like in a demo.
If a program cannot land, because the enforcement mechanism doesn't exist, or the network won't support the device fleet, or the operating cost is untenable, the least expensive time to say so is now. I'd rather cancel a program with the documentation intact than ship a rollout that erodes trust for the next three.
I don't run a network program without spending time with a network engineer, or a store-tech program without walking a store. Program management above the shop floor gets brittle fast. I want to understand why the DHCP scope is shaped the way it is, and why the store lead doesn't trust the last device audit. That context is usually where the real risk is hiding.
Any one program can be run well and still fail the portfolio. The intake process, the prioritization cadence, and the reporting spine that connects them decide whether a group of programs adds up to a strategy or a pile of Jira tickets. I design the portfolio the same way I design a program: with an owner, a cadence, and a metric it lives or dies by.