Lead engineer on a small team: security, reliability and the platform at once

At a non-profit organisation I was promoted from DevSecOps engineer to lead security, reliability and platform engineering for the application and data teams. There is no separate security team, SRE team or platform team. There’s me and the engineers I work with.

On a big team, a lead can specialise. On a small one, the job is closer to running a small company inside the company: you own the outcomes in several areas at once, and there’s never enough time for all of them. This post is about the habits that have made that workable.

Five jobs, one person

• Security
  • Risk register and threat model
  • Essential Eight self-assessment
  • Remediation programme after a crisis simulation
• Reliability
  • Incident response, P1 acknowledged in 15 minutes
  • DR plans against agreed RTO and RPO
  • Go/no-go gate and rollback plan for a launch
• Platform
  • AWS and CI/CD architecture
  • Self-service sandboxes and previews
  • Roadmap agreed with engineering leads
• Cost
  • Monthly FinOps review
  • Removing what nobody uses
  • Paying for always-on only where it earns it
• People
  • Design reviews
  • Mentoring
  • Auditors, testers and vendors

Each of these could be a full-time role somewhere else:

• Security: the security roadmap and risk register, a threat model, alignment with the Australian Privacy Act, audit preparation, and an internal Essential Eight self-assessment that brought the security documentation for cloud, identity, devices and SaaS into one place.
• Reliability: incident response from detection to post-incident review, with response targets by priority (a P1 is acknowledged within 15 minutes), on-call practice, and disaster recovery planned against agreed recovery objectives.
• Platform: the AWS and CI/CD architecture, and a platform roadmap agreed with the head of engineering and the stream leads.
• Cost: a monthly review of what we spend and why.
• People: design reviews, mentoring, and being the contact for external auditors, penetration testers and vendors.

The skill isn’t doing all five at full depth. It’s knowing which one needs you this week, and making the others run without you.

One list, three questions

← scroll sideways for the full diagram →

When work arrives from incidents, the risk register, the roadmap, requests from teams and audit findings, the worst thing is to keep five separate lists. Each one feels urgent in isolation, and the trade-offs between them stay invisible.

So everything goes into one list, and three questions sort it:

1. How bad is it if this goes wrong? Likelihood and impact, the same way the risk register scores them.
2. How many people does it unblock? A fix that unblocks two teams beats a fix that helps one person.
3. Does it remove future work? Automation, templates and documentation pay back every week after they ship.

Two examples:

• Vulnerability findings. The managed Mac fleet (about 54 devices) produced more than 6,000 findings. Working through them in order would never finish. Sorting by whether a vulnerability was being actively exploited put the handful that mattered first, and the rest into a planned queue.
• A crisis simulation. After a cyber crisis exercise, the findings became a remediation programme of seven workstreams and about 34 items: break-glass access, immutable backups, containment playbooks and contractor access. Turning a long list of findings into a programme with owners and an order made it possible to deliver alongside everything else.

“Later” is a real answer, as long as it’s written down with a reason. A forgotten ticket and a deliberate decision look the same on a board, but only one of them survives an audit.

Make the secure path the least painful one

Years across banking, cloud support, retail and media taught me one thing above all: if a security standard is hard to follow, people will find ways around it. So most of my time as a lead goes into design reviews and mentoring, and into making the secure path the easiest one to take.

In practice that means:

• SSO for every human, so nobody needs long-lived keys and leaving the company actually removes access.
• Self-service sandboxes and preview environments, so testing safely is faster than testing in shared environments.
• Templates with the guardrails built in, so the default choice is the compliant one.
• Moving SaaS and vendor admin accounts off personal logins onto a shared billing mailbox and a password manager, so access doesn’t leave when a person does.

Design reviews beat gatekeeping. A conversation before something is built changes the design; a rejection after it’s built just creates resentment and workarounds.

Write it down

On a small team, whatever only exists in your head is a single point of failure, and that includes you.

• A go/no-go gate and a rollback plan for the launch of a new member portal. Launch capacity was sized from CloudWatch data, and Lambda concurrency was raised from 1,000 to 5,000 ahead of the launch. Writing the gate down meant the launch decision was a checklist, not a debate under pressure.
• Runbooks and response targets for incidents, so whoever is on call knows what “good” looks like.
• One security and operations knowledge base, so audits, new starters and incidents all start from the same source.

Cost is part of the job

Nobody else is going to look at the AWS bill line by line, so a monthly FinOps review is on my calendar. It has removed things nobody used, such as an unused IP address management deployment, and replaced a paid email testing service with a self-hosted one.

The bigger change is structural. Our workflow orchestration ran in one shared managed environment that charges for being always on. I’m rebuilding it as isolated environments defined in code. Non-production already runs on self-managed containers, so it no longer pays the always-on fee.

Work through other people

A lead on a small team has very little formal authority and a lot of influence. The platform roadmap is agreed with the head of engineering and the stream leads, not handed down. Security priorities land better when the people doing the work helped shape them. Mentoring is how the team gets better at things I’d otherwise have to do myself.

What I’d tell someone stepping into the role

1. Keep one list. Every source of work competes in the same place, scored the same way.
2. Sort by risk and leverage, not by who asked loudest or most recently.
3. Make the secure path the easy one. Guardrails in templates beat policies in documents.
4. Write it down. Gates, runbooks and decisions, including what you chose not to do and why.
5. Own the cost, because on a small team nobody else will.
6. Spend your time where it multiplies: design reviews, mentoring and automation.

The work never gets smaller. The goal is that it stops depending on you being in the room.