How should I prepare for moving from SecOps leadership to Infrastructure and SecOps management?
Asked by
MapleOrbit47
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 enterprise and cloud infrastructure together with SecOps in a regulated, high-volume environment subject to HIPAA, SOC 2, and PCI requirements.
I have about 30 days before I start and would appreciate advice on four areas:
1. What books, frameworks, or other resources would help me improve as a manager of cloud infrastructure, SRE, and platform engineering teams?
2. How can I earn the trust of senior infrastructure and cloud engineers without micromanaging areas where they have greater hands-on expertise?
3. How can I avoid bringing overly bureaucratic habits from a 20,000-person enterprise into a faster-moving SaaS organization?
4. What should I prioritize during my first 30, 60, and 90 days, especially when the existing SecOps function is already strong?
I'm particularly interested in advice from people who have made a similar move between large enterprises and regulated SaaS companies.
Answers
Make capacity planning one of the early discovery priorities. In a healthcare SaaS environment, compliance and reliability requirements can make infrastructure changes take longer than expected, and scaling decisions often have long lead times. That can expose hidden problems that are easy to miss when your background is primarily security-focused.
Reply to this answer
That makes sense. I’m expecting the move from financial services into healthcare SaaS to be a substantial change in risk and operating style. I’m mainly looking for guidance on managing engineers and technical owners rather than becoming an expert in every infrastructure system. Taking over an established team should let me rely on their depth while I focus on priorities, decision-making, and removing obstacles.
Reply to this answer
Spend less of the next 30 days trying to find the perfect book and more time building the questions you want answered during your first week. Every SaaS environment has a different risk profile, so your initial 30/60/90-day plan should focus on learning the business, understanding the architecture, and assessing the most important risks.
Early discovery topics should include customer-facing failure modes, SLOs, recent incidents, deployment frequency, change-failure rate, backup and restore testing, cloud-cost ownership, PHI and payment-data flows, production access, patching and exceptions, audit-evidence ownership, and the areas where engineers feel process is slowing them down.
To build credibility, don’t try to be the most technically knowledgeable infrastructure person in the room. Ask senior engineers what feels fragile, what they are tired of explaining, and what they would fix with a month of uninterrupted time. A useful SaaS operating model usually means a clear owner, rollback plan, evidence trail, and risk-acceptance path—not a committee for every decision.
Reply to this answer
Add your answer
Answers are reviewed before publication.
QuietHarbor8: Exactly. Your value will come from creating clarity around ownership, tradeoffs, reliability, and risk—not from trying to out-design the engineers. Use the first few weeks to understand how decisions are made and where the team needs leverage.