Senior DevSecOps & Platform Engineering Lead
Full-Time W-2 | Fully Remote (U.S.) | Federal Civilian Practice
The Problem We're Hiring You to Solve
A 20-year-old federal platform sits behind a home loan benefit that millions of American families depend on. Your job is to help retire it without anyone noticing.
You will own the DevSecOps and platform engineering ecosystem for a modernization program that runs legacy and modern stacks side by side: pipelines that move code from commit to production in under an hour, zero-downtime production deployments, environments built and torn down as code, and observability deep enough to explain a failure before the customer reports it. You will do this inside real federal security constraints, with real authority over how the engineering system works, and with AI as a first-class engineering tool.
The Opportunity
Most DevSecOps roles hand you an inherited pipeline and a backlog of tickets. This one hands you an engineering system to shape.
The program spans multiple applications, technology stacks, and platforms: a legacy suite that must stay stable and secure until it is decommissioned, and a modern cloud platform (Salesforce-centered, supplemented by serverless capabilities in a government cloud) where new capability lands every month. Production runs 24/7 against contractual availability targets. Releases ship to production at least monthly. Critical vulnerabilities must close in 30 days. The monitoring bar is full business transaction visibility, not “the server is up.”
You will lead the engineers who make all of that true. Not from a status meeting. From the architecture, the pipeline definitions, the incident bridge, and the customer conversation. You will decide how code moves from a developer's hands to production, how failures get detected and diagnosed, how security gets enforced without slowing delivery, and where automation and AI replace manual work.
The outcomes are measured, visible, and attached to a mission that matters. When deployments get faster and incidents get rarer, the customer sees it, and so do the people the program serves.
A note on the stack. If “Salesforce” made you hesitate, read this twice. You will not become a Salesforce administrator, and this role will not narrow your career. The application platform is Salesforce. The engineering system around it is not. The CI/CD architecture, environment automation, serverless cloud components, observability, security automation, legacy systems, and AI-enabled workflows are general-purpose platform engineering, and that is where you will spend your time. A strong platform engineer picks up the Salesforce-specific pieces quickly. The reverse is not true, which is why we are hiring for the former.
What You'll Own
- The delivery platform. Design and run CI/CD that lets teams move code from commit to production across multiple applications, stacks, and environments with minimal manual intervention. The standard: builds, tests, and deployments complete in under an hour, and production releases ship monthly or faster.
- Zero-downtime release engineering. Build deployment automation that verifies a release in production before users touch it, and rolls back cleanly when verification fails. Boring deployments are the goal.
- Environments as code. Automate provisioning so a complete environment stands up or tears down in days, not months, and configuration drift stops being a source of incidents.
- Security engineered into the pipeline. Make quality and security gates automatic, surface vulnerabilities early instead of at audit time, and drive remediation inside federal 30/60/90-day windows for critical, high, and medium findings. Support multi-year authorizations to operate and the program's Zero Trust alignment as engineering work, not paperwork theater.
- Observability that explains itself. Build monitoring that covers infrastructure, applications, interfaces, batch jobs, and full business transactions, with alerts that tell the team what failed, why, and what to do about it. The target: no incident the customer discovers before we do.
- Production reliability. Own incident and problem management, root-cause analysis, capacity and performance management, and tested disaster recovery for systems that run around the clock. Drive the change-caused incident rate toward zero.
- The legacy-to-modern transition. Keep the legacy platform stable, patched, and authorized while the modern platform absorbs its functions, including the data bridges between them, until decommissioning finishes the job.
- Developer experience and engineering metrics. Instrument the engineering system itself. Measure build times, deployment frequency, defect escape rates, and toil. Then improve them, visibly and repeatedly.
- A stronger team. Lead, mentor, and grow the engineers who do this work with you, and set standards the whole program builds on.
AI-Native Engineering
AI is part of how PhoenixTeam works, and this role is expected to lead by example.
We are looking for someone who already uses tools like Claude Code, Cursor, or GitHub Copilot as a normal part of engineering, not someone whose AI experience is mostly conversational. In practice that looks like: generating and reviewing infrastructure definitions, accelerating scripting and pipeline work, diagnosing build and deployment failures faster, analyzing logs during incidents, expanding automated test coverage, keeping documentation current without hating your life, and spotting repetitive work that should stop being done by humans.
Beyond personal productivity, we want you to design AI-enabled capabilities that improve the engineering system itself: pipeline diagnostics, automated remediation, vulnerability analysis, engineering knowledge retrieval, developer self-service, and agentic workflows that reduce toil across the team.
Two things anchor all of it.
First, judgment stays human. You know when AI output is wrong, insecure, incomplete, or inappropriate, and you review accordingly.
Second, boundaries are non-negotiable. Federal environments govern what tools may touch government code, systems, and data. Use AI wherever it creates leverage, and understand the security, data, privacy, and authorization boundaries governing where and how it can be used. Someone who treats those boundaries as an obstacle to route around will not succeed here. Someone who finds real leverage inside them will thrive.
Tools will change. The mindset we're hiring for won't: continually ask “why are humans still doing this manually?” and act on the answer responsibly.
What Great Looks Like
Twelve months in, we would expect to see:
- Deployments are faster and less eventful. Manual intervention in the pipeline is measurably down, deployment and rollback are automated and verified, and release day stopped being stressful.
- The release cadence holds. Production value ships at least monthly with zero escaped critical defects, backed by automated regression coverage the customer trusts.
- Security findings surface in the pipeline, not the audit. Vulnerability remediation consistently lands inside the 30/60/90-day windows, and authorization evidence falls out of the engineering process instead of being reconstructed after the fact.
- Monitoring catches problems first. Incidents undetected by monitoring approach zero, and mean time to diagnose drops because observability explains failures instead of just announcing them.
- Environments are a solved problem. Provisioning is automated end to end, and standing up a full environment is measured in days.
- AI-enabled workflows are in production use. Several are running inside approved boundaries (pipeline diagnostics, test generation, log analysis, or wherever you found the leverage), with measured reductions in manual engineering work.
- The team is stronger than you found it. Engineering standards are documented and lived, your engineers have visibly grown, and the bar for what “done” means went up.
- The customer asks for more. Direct stakeholders trust the platform team enough to expand its scope.
What You Bring
We care about evidence more than resumes. Expect us to ask what you built, what you automated, what broke at 2 a.m. and how you fixed it, and what got measurably better because you were there.
- Deep hands-on DevSecOps and platform engineering. You have designed and operated CI/CD, infrastructure as code, and deployment automation for real production systems, across more than one stack, and you still write and review the code.
- Federal delivery experience. You have engineered inside a regulated federal environment and understand authorizations to operate, federal security controls, vulnerability remediation SLAs, and mandated tooling as engineering constraints to design within, not excuses for slow delivery.
- Production ownership. You have carried responsibility for availability, incident response, and root-cause analysis on systems people depend on, and you diagnose systemic causes instead of treating symptoms.
- Security as an engineering discipline. You build controls, scanning, and evidence generation into the delivery process rather than bolting them on before an assessment.
- Demonstrated AI-in-the-loop engineering. You can show us, concretely, how AI tools function in your daily workflow today and what they have made measurably better.
- Technical leadership. You have led engineers directly, raised a team's standards, made architecture decisions you were accountable for, and explained hard technical tradeoffs to non-engineers clearly.
- Judgment under ambiguity. You investigate, decide, and act when requirements are incomplete, and you gain alignment without waiting to be handed a spec.
- U.S.-based, and able to obtain and maintain a federal Public Trust clearance.
We do not screen on degrees or year counts. If your evidence is strong, we want to talk.
Helpful, Not Required
- Salesforce platform or Copado pipeline experience. The delivery platform is partly cloud-native to Salesforce, and a strong engineer can learn it.
- Experience with government cloud environments, Splunk, or enterprise monitoring integration.
- Prior work supporting authorization packages, POA&M management, or Zero Trust initiatives.
- Experience decommissioning legacy systems or running dual-stack transitions.
- Mortgage or housing finance experience is not required. We will teach you the domain.
Leadership Expectations
This is a player-coach role, and both halves are real.
You will have direct reports. You will hire, mentor, and grow engineers, set engineering standards, and be accountable for the quality of the team's work. You will also stay in the work: architecture decisions, pipeline engineering, gnarly production problems, and code review are yours, not things you delegate and forget.
You will work directly with federal customers and decision-makers. That means explaining complex technical decisions in plain language, defending engineering positions with evidence, and respectfully challenging technical direction when it is wrong, including ours. Silent disagreement is a failure mode here.
When something is ambiguous, you make the call, document the reasoning, and own the outcome.
You'll Probably Love This Role If...
You are the engineer who cannot walk past a manual process without itching to automate it. You want authority to match your accountability. You like customers in the room, not abstracted behind three layers of account management. You find federal constraints interesting rather than suffocating, because delivering fast inside them is a harder and more satisfying problem than delivering fast without them. And you are already the person your team asks about AI tooling, because you actually use it.
This May Not Be the Role for You If...
We would rather you self-select now than be unhappy in month three. You may struggle here if you:
- Need fully defined requirements before you can start.
- Prefer managing engineering to doing engineering.
- Avoid challenging technical decisions, especially with customers or leadership.
- Default to manual processes when automation is possible.
- Treat security as another team's job.
- View AI as a novelty rather than an engineering capability.
- Stopped learning when you became senior.
None of that makes someone a bad engineer. It makes them a bad fit for this particular job.
Why PhoenixTeam
You have probably never heard of us. Here is why that shouldn't stop you.
- We are practitioners, not a staffing shop. PhoenixTeam is a woman-owned small business founded and led by housing finance technologists who still do the work. Our teams have spent years embedded inside federal housing programs, from loan guaranty to rural housing lending to mortgage insurance, with real depth in the systems, data standards, and compliance realities of the domain. You will not report to an account manager who has never shipped anything.
- Your decisions have visible consequences. This is a lead role on a major federal modernization where deployment speed, reliability, and security outcomes are measured monthly and reviewed by the customer. Impact is not hypothetical here.
- Direct customer access. You work with federal decision-makers yourself. Your technical judgment reaches the people who act on it, without three layers of translation in between.
- You set the standards. You are establishing engineering practices for this program, not inheriting someone else's and maintaining them.
- AI-native is practice, not positioning. AI is part of how PhoenixTeam delivers, and we fund ongoing AI education and development for the entire team. In this role you will build on that investment, not fight for permission to use it.
- Fully remote,S.-based, permanently.
- Mission you can explain at dinner. The systems you improve support a home loan benefit for the people who served this country.
Position Requirements
- Full-time W-2 employment with PhoenixTeam.
- Must be based in the United States.
- Fully remote.
- Work supports a federal civilian agency.
- Must be able to obtain and maintain the required federal Public Trust clearance. A Secret clearance is not required.
PhoenixTeam is a woman-owned small business focused on federal and commercial housing finance technology.