Incident Operations Lead, Alpaca

• You have stood up an incident command or major-incident function, not only worked inside one - you have owned the severity model, built the roster and driven adoption across teams
• 5+ years in production engineering, SRE or technical operations, including hands-on command of high-severity incidents
• You have led a distributed team across time zones and run a 24x7 rotation
• You get engineers you do not manage to do things, and you can defend a severity call to someone who disagrees with it
• You have built reliability metrics people trust, and you know the difference between improving a number and improving reality
• You are disciplined about scope. You can say "that is not ours" and route it, in the middle of an outage, without leaving a gap
• You write well enough that your process documents actually get used, you can hold a bridge calm under pressure, and you can brief an executive mid-incident without either downplaying it or dramatising it
• You understand FinTech and the trust stakes of API-driven financial platforms
• You use AI and agentic automation to remove toil rather than to add tooling

Desirable

• Lead the team that commands Alpaca's most critical incidents
• You will build the function and then keep raising its bar: the severity model, the escalation and communication paths, 24x7 follow-the-sun coverage, and the KPIs that prove it is improving
• You will do that across boundaries - with the engineering teams who own the services, with SRE on reliability standards and on-call readiness, with Risk on financial and regulatory materiality, with our partner communications teams on what reaches a customer, and with reliability programme management on what happens after
• You will own how well we respond
• Not the fix, not the partner communication, and not the reliability standard
• Holding that line is a deliberate part of the design and a core part of the job
• Build the team and stand up 24x7 command. Recruit and certify Incident Commanders, build a follow-the-sun rotation across APAC, EMEA and AMER with warm handoffs at every regional boundary, and carry a rostered slot yourself. Keep the team sharp between real incidents with game days, tabletop exercises and simulations, and coach them through the live ones. Build a blameless review culture that treats an outlier as a process gap rather than a person's failure
• Own the process, and keep raising it. Drive severity maturity with Risk on financial and regulatory materiality - in a regulated brokerage a severity call can also start a reporting clock, so the model has to map cleanly onto those thresholds. Own the escalation path and what happens when a page goes unanswered, agree the thresholds for taking an incident to engineering leadership, and keep the service catalogue and its ownership current - time spent working out who owns a failing service is customer impact
• Own both bridges. Your team connects the engineers and technical support fixing the problem, who need uninterrupted focus, to the partner communications teams, who need a continuous and accurate feed. You open the channel, supply the facts and hold the update cadence to account. Afterwards, your team runs the retrospective with SRE - who own the technical depth - and builds the post-incident package while the room is still warm, every item ticketed, owned and tagged, delivered inside a service level you define and then hold, before reliability programme management drives it to closure. You then synthesise the discussion into short, digestible learnings and publish them to the whole engineering organisation, so one team's failure becomes everyone's lesson instead of a document three people read
• Own the KPIs. Time to respond and time to mitigate end to end, including the definitions and data hygiene beneath them: what separates mitigated from resolved, and whether a timestamp means what it claims. Establish a defensible baseline before committing to targets, then move them by severity. Review and approval, not authorship, is where postmortems stall, so report overdue reviews by team and incident with a next action against each
• Build it as a product, then automate it with AI. Everything is documented, versioned and deployable, so you can stand up command from the artefacts alone; the process needs to scale considerably faster than the team
• The automation we are after is AI workflows and agents rather than scripts and dashboards - agents that set an incident up, assemble the timeline as it runs, draft the RCA and the action package, and chase the update that is due or the review that is overdue. You own that roadmap: what an agent may do unsupervised, what still needs a commander's judgement, and the decision-tree quality that makes either of them safe