The DevOps Engineer is accountable for identifying repetitive, manual, and time-intensive tasks across L1, L2, and L3 service delivery workflows and eliminating them through automation. The role owns the discovery, design, build, deployment, and ongoing support of scripts, integrations, AI-assisted automations and CI/CD pipelines that reduce engineer toil and improve the consistency and speed of managed services delivery. The role embeds with L1, L2, and L3 analysts to understand operational workflows, prioritises automation candidates by delivery impact, and delivers well-documented automations that receiving teams can adopt, trust, and extend. The role reports to the Tools and Automation Lead.
Success in this role requires technical capability across scripting and integration, structured workflow analysis to identify and prioritise automation candidates, disciplined delivery practices grounded in peer review, documentation, and validated adoption by receiving teams, strong written communication so other engineers can adopt and maintain delivered work, and a service mindset that measures success by adoption and operational impact within delivery teams.
Key Accountabilities
Automation Backlog and Delivery
The automation backlog reflects current operational reality across L1, L2, and L3, drawing both from team-submitted requests and from first-hand observation of high-frequency workflows including alert triage, ticket enrichment, evidence collection, routine remediation, reporting, and onboarding tasks.
Submitted automation requests arrive in the active backlog as scoped, well-defined work items with clear acceptance criteria, refined collaboratively with the requesting team lead or engineer.
Candidate automations are prioritised by measurable delivery impact (time saved, frequency, error reduction) rather than personal preference or recency bias.
Backlog priorities remain current and trusted by delivery teams through regular reprioritisation with the Tools and Automation Lead, based on impact, urgency, dependencies, and team feedback.
Automation Delivery
- Automations are delivered to production using the right tool for the job — scripting (PowerShell, Python, Bash) where logic and control matter, low-code or iPaaS where speed and maintainability dominate, and AI/LLM-driven approaches (including agentic and prompt-based patterns) where the task involves unstructured input, classification, summarisation, or natural language.
- Delivered automations are durable engineering artefacts - versioned in Git, peer-reviewed, and structured so other engineers can read, run, and extend them.
- Production delivery is iterative - usable capability is shipped early, validated against real operational use, and refined from receiving-team feedback rather than predicted requirements
- The SIEM, ticketing, ITSM, monitoring, and Microsoft 365 / Azure / security tooling stack operates as a connected platform, with integrations that move data, trigger workflows, and reduce manual handoffs between systems.
- Internal tooling and infrastructure-as-code is delivered through repeatable, controlled CI/CD pipelines that engineers can trust for both routine and time-sensitive changes.
- Secure-by-design engineering is non-negotiable — secrets are managed correctly, credentials are scoped to least privilege, and integrations cannot be weaponised against the systems they connect.
Adoption and Production Reliability
- Delivery teams are able to adopt, run, and modify every deployed automation without dependence on the original author.
- Automations are implemented as supported capabilities, not imposed change - context, walkthroughs, and adoption support precede every deployment.
- Knowledge transfer is consistent - handover artefacts and runbooks remain accurate, current, and trusted as the underlying tools and workflows evolve.
- Production automations are observable - failures are detected and resolved by the function, not by the delivery teams that depend on them.
- Production automations remain fit for purpose as workflows evolve, with iteration driven by operational telemetry and structured feedback rather than assumption.
- Owned automations contribute to, rather than detract from, the reliability and SLA performance of the receiving service delivery teams.
Personal Performance & Professional Standards
- Maintain and grow specialist technical capability relevant to supported platforms through continuous learning and practical application.
- Personal Goals & Objectives are achieved as defined in the Staff Enablement Model.
- Continuous Service Improvement initiatives are led that deliver measurable operational improvements.
- Company values are demonstrated through honest communication, genuine ownership, and creating a psychologically safe environment.
- Collaborative relationships are maintained with Engineering Team Leader, Service Management Lead, Head of Technical Operations and Head of Delivery.
Skills & Qualifications:
- 1–2 years of experience in IT, DevOps, SRE, software engineering, or a managed services / SOC delivery role - or a relevant degree with strong hands-on project work.
- Working proficiency in at least one scripting language (Python, PowerShell, or Bash).
- Familiarity with Git and source control workflows.
- Exposure to at least one major cloud platform (Azure or AWS acceptable).
- Strong written communication - able to document what has been built so others can use it without the author present.
- Curiosity, ownership, and a bias toward shipping working solutions over perfect ones.
- Experience with CI/CD tooling (Azure DevOps, GitHub Actions, GitLab CI).
- Familiarity with infrastructure-as-code (Terraform, Bicep, ARM).
- Exposure to the Microsoft 365 / Azure security stack (Defender, Sentinel, Entra ID, Intune).
- Understanding of REST APIs and webhook-driven integration patterns.
- Exposure to AI/LLM-driven automation - prompt engineering, agentic workflows, or integrating AI services (e.g. Azure OpenAI, Copilot, or similar) into operational tooling.
- Experience working in or alongside a SOC, MSP, or MSSP.
Personal Qualities & Attributes:
- Curiosity demonstrated through asking why processes exist before automating them, investing time in learning the workflows of the teams being served, and keeping pace with emerging automation and AI tooling to spot where it genuinely helps.
- Bias to action - prefers shipping a working v1 over polishing a v2 that never lands, while still respecting the quality bar for anything touching production.
- Service mindset - treats delivery engineers as customers and measures success by their adoption and feedback rather than personal output.
- Strong written communication demonstrated through producing runbooks and documentation that non-authors can read and use independently.
- Ownership of outcomes from discovery through production support — the job does not end at the commit.
- Collaborative working style - comfortable embedding with delivery teams to learn workflows, gain trust, and build solutions in partnership rather than in isolation.
- Continuous improvement mindset demonstrated through actively measuring the impact of automations and iterating based on data rather than assumptions.
- Resilience and pragmatism - comfortable with ambiguity, legacy systems, and the trade-offs inherent to a fast-moving MSP environment.
- Attention to detail proportionate to risk - rigorous where automation touches production or sensitive data, lighter touch on internal-only tooling.
- Coachability - actively seeks feedback from the Tools and Automation Lead and peers, and acts on it.
Goals & Objectives
Individual Commitment - Committed to reducing engineer toil across L1, L2, and L3 service delivery through well-designed, well-documented automations that delivery teams adopt and trust. I measure success by the operational impact and adoption of what I deploy - not by personal output.
How to Apply
Please send your CV to kristen.brinker@infotrust.com.au.
