I'm moving from managing a 15-person global SecOps team at an enterprise with more than 20,000 employees into a Director of Infrastructure & SecOps role at an approximately 1,800-person B2B healthcare SaaS company. My experience is strongest in security operations, incident response, SOC leadership, and security architecture. In the new role, I'll be bringing cloud and enterprise infrastructure together with SecOps in a high-volume, regulated environment subject to HIPAA, SOC 2, and PCI requirements.
Before my start date, I have about 30 days to prepare. I'd appreciate practical advice on what to study regarding cloud infrastructure, SRE, platform engineering, and managing technical owners; how to build trust with experienced infrastructure engineers without micromanaging; how to avoid bringing large-enterprise bureaucracy into a faster-moving SaaS organization; and what discovery priorities to focus on during my first 30, 60, and 90 days. I'm especially interested in lessons from people who have made a similar transition.
3 Answers
Make capacity planning an early discovery topic. In a healthcare SaaS business, growth, reliability, compliance, and infrastructure lead times can all collide. Security leaders sometimes focus heavily on controls and underestimate how long it takes to provision capacity, redesign a dependency, or test a recovery path at scale.
During the first 30 days, map the business’s critical services and dependencies. By 60 days, identify the largest reliability, capacity, and operational risks and agree on owners. By 90 days, you should have a prioritized roadmap tied to customer impact, risk reduction, and engineering capacity rather than a long list of disconnected projects.
I’d spend less time trying to finish a reading list and more time preparing the questions you want answered during your first week. Start by understanding the biggest customer-facing failure modes, current SLOs, recent incidents, deployment frequency, change-failure rate, backup and restore testing, cloud-cost ownership, PHI and payment-data flows, production access, patching exceptions, and who owns audit evidence.
The enterprise habit to watch is creating a committee for every decision. A lighter SaaS approach is usually better: one accountable owner, a rollback plan, evidence that the control works, and an explicit risk decision when necessary.
For credibility, don’t try to present yourself as the deepest infrastructure expert. Ask senior engineers what they believe is fragile, what they’re tired of explaining, and what they would fix if they had a month without interruptions. Those conversations will teach you more about the real environment than an architecture diagram.
There probably isn’t a universal book that will prepare you for this move because every SaaS organization has a different risk surface, architecture, and operating culture. Treat the first quarter as a structured learning and assessment period rather than arriving with a fully formed transformation plan.
Your security background is an advantage, especially in a regulated healthcare environment, but the key is to learn how the infrastructure team makes decisions and where its technical ownership sits. Support the existing experts, clarify decision rights, and connect infrastructure work to reliability, customer experience, compliance, and business growth. That will help you earn trust without pretending to know every tactical detail.
That makes sense. I’m expecting the move from a large financial-services environment into healthcare SaaS to change the risk picture quite a bit. I’m mainly looking for resources on managing engineers and technical owners, since I don’t need to be the expert in every infrastructure domain when I’ll be working with an established team.