Junior Platform Engineer

An early-career engineering role inside Operate, our managed service. Security or observability background — either is welcome.

You have been working for eighteen months to three years in a hands‑on technical role — a platform team, a SOC or security engineering team, an MSP or MSSP, an infrastructure or DevOps team, a vendor’s support or professional services desk — and you are looking for your first move. You have had your hands on something that runs in production and matters to somebody. You want to go deeper, faster, in a smaller business where the work you do is seen. This is not a graduate scheme and it is not a helpdesk. It is a real engineering seat with real customers, real supervision and a clear path up.

About Apto Solutions

Apto Solutions is a Bristol business that runs telemetry, observability and SIEM platforms for other organisations. Banks, airports, energy companies, engineering firms and government bodies depend on those platforms to tell them whether their systems are healthy and whether they are under attack. When those platforms are quietly working, nobody notices. When they are not, our customers find out the hard way. Our job is to make sure they never do.

We work across Splunk, Cribl, Microsoft Sentinel, Grafana, Datadog and OpenTelemetry. We are a partner‑led business with deep vendor relationships, and we build a lot of our own platform tooling on top. We are small, profitable and growing fast — the plan is to triple the business by 2028 — and we are hiring engineers who want to grow with it rather than be carried by it.

The Role

This is a hands‑on engineering role inside Operate, our managed service. You will help run customer telemetry platforms day to day, improve them, and contribute to the platform that lets us run them well. You will do this as part of a small engineering pool, with a senior engineer checking your work before it reaches a customer and a line manager who is accountable for your development.

Operate has two shapes and you will work in both.

Operate Core is always‑on. It is continuous ownership of a customer’s platform — health, ingestion, data quality, alerting, upgrades, capacity. There is no handover and no final deliverable. The platform is ours to keep healthy for as long as the customer is ours. Success is measured in the absence of surprises and in the platform being demonstrably better in six months than it is today.

Operate Attach is sprint‑based improvement. A customer has a defined problem — noisy alerts, a data source that will not normalise, ingest costs running away, a detection gap, a migration — and we take a scoped block of work and fix it. Attach has a start, a shape and an end. It sits on top of Core, for the same customers, with the same engineers.

Alongside that you will take a share of professional services delivery: shorter, project‑shaped engagements that are usually how a customer first meets us.

What You’ll do

Everything below is done with supervision at first and with increasing independence as you show you can carry it. We will be explicit with you about where that line is and how it moves.

Day‑to‑day health of customer platforms.

Ingestion pipelines, data quality, alerting, licensing and capacity, upgrades and patching. You will start by owning a slice of a named customer estate, and you will be expected to notice problems before the customer does.

Incident and problem work.

Triage, diagnosis and resolution — and then the harder part, which is the root cause and the permanent fix so it does not come back.

Content and configuration.

Detections, dashboards, parsers, normalisation, alert rules, pipeline routing — built properly, peer reviewed, version controlled, documented.

Attach sprints and PS work.

Taking a defined piece of a scoped improvement, delivering it, and being able to show what changed.

Automation.

If you do something manually three times, we expect you to want to automate the fourth. Most of our platform tooling started as an engineer being annoyed by something.

Documentation and runbooks.

Your own, to a standard, every time. Undocumented work is unfinished work.

What this role is NOT

Being clear about this matters as much as the role definition itself.

It is not a SOC analyst seat.

You are not sitting in a queue triaging alerts against someone else’s runbook. You help build and run the platform that the analysts depend on.

It is not a service desk or first‑line support role.

You will talk to customers about technical matters, but the work is engineering, not ticket handling.

It is not a data science role.

We work with very large volumes of machine data, but the work is systems and operations engineering, not modelling or statistics. Python and dashboards are not the same thing as running a platform.

It is not a graduate scheme.

We paused our graduate hire to open this role instead, because we want someone who has already spent time in a production environment and knows what it feels like when something breaks at an awkward hour.

It is not a project role with a finish line.

Core has no end date. If what you enjoy is shipping a thing and walking away, you will find the continuous half of this job frustrating.

Who we are looking for

We are indifferent to whether your background is security or observability. Either one is a good starting point, and the interesting work at Apto sits where the two meet — the same telemetry usually has to serve both a security question and an operational one. What we need is depth in one and genuine curiosity about the other.

If your background is security:

• Microsoft Sentinel and KQL, Splunk and SPL, or another SIEM at the level of having onboarded log sources, built or tuned analytics rules, and fixed things when ingest broke.
• Some understanding of the detection lifecycle — writing, testing, tuning and retiring rules — and of why normalising messy multi‑vendor data matters.
• Curious about how platform health is measured, what an SLO is, and how observability people think.

If your background is observability:

• Grafana, Prometheus, Datadog, Cribl or OpenTelemetry at the level of having built or maintained dashboards, alert rules, collectors or pipelines that other people relied on.
• Some understanding of metrics, logs and traces as different signals, and of why alert noise and ingest cost are engineering problems rather than facts of life .
• Curious about how attacks show up in data, what a detection is, and how security people think.

Behavioural

Beyond the lens, the things that actually predict success here are behavioural. We look for five attitudes, and we look for them in the evidence you give us, not in the adjectives you use about yourself.

• Engagement — you take on the problem in front of you rather than the ticket in front of you.
• Empathy — you can see the situation from the customer’s side, and from a colleague’s side.
• Resourcefulness — you get unstuck. Documentation, source code, a lab, a colleague, a vendor. You do not sit and wait.
• Curiosity — you want to know how it works underneath, not just which button produces the result.
• Building — you leave things better than you found them, and you build the tool rather than repeating the task.

Experience we’re looking for

Roughly eighteen months to three years in a hands‑on technical role. We care much more about what you have actually done than about the number of months attached to it, and we know that at this stage most of what you have done was somebody else’s decision. That is fine. We are looking for the shape of it.

• You have had your hands on a telemetry, SIEM, observability or monitoring platform that was running in production — not only in a course or a home lab. You have onboarded a data source, tuned an alert, applied an upgrade, or been the person who had to work out why the data stopped arriving.
• You have carried something over time rather than only delivering a task and moving on — a set of alerts you looked after, a customer estate you knew well, an on‑call rotation, a service that was yours to keep healthy.
• You are comfortable in Linux, in at least one query language, and you have written scripts that did something useful. Python is what we mostly use; anything credible is a fine starting point.
• You have automated or fixed something real and you can show it. A script, a repo, a before‑and‑after number, a description concrete enough for us to ask sensible questions about.
• You can write. A clear runbook, a readable incident note, a straight message to a customer. This is a customer‑facing role.
• You have worked in at least one of our vendor families — Splunk, Cribl, Sentinel, Grafana, Datadog, Elastic, Prometheus, OpenTelemetry — or a close analogue. The specific product is negotiable. Real exposure is not.

If you meet most of this and not all of it, apply anyway and tell us which parts you do not have. We would rather read an honest gap than a padded CV.

Where this role sits, and where it goes

You report to the Operate Service Manager. They are your line manager: workload, priorities, performance, development and your quarterly evaluation. Day to day you work alongside the senior and mid‑level engineers in the pool, who review your work, pair with you and are the people you ask. Technical authority sits with our Solution Architects. The customer relationship sits with the Technical Account Manager, so you will spend time in front of customers on technical matters and you will not be left to negotiate scope on your own.

Progression at Apto is capability‑based, not time‑served. There is no minimum tenure. We run a published capability framework across technical competence, project discipline, customer orientation, behaviours and attitude, and a quarterly evaluation that draws on your line manager, your Solution Architect and your Technical Account Manager. You will know exactly what the next grade requires of you from your first week. The distance between this role and a mid‑engineer is capability, and we will tell you honestly where you stand against it every quarter.

The platform work – why this is interesting

Most managed service jobs are the same job with a different logo on the ticketing system. This one is not, because we are building our own platform underneath the service and you will work on it. We have replaced a vendor‑licensed telemetry backend with an open‑source stack we run ourselves. A base platform (secret ;-)) On top of that sits multi‑vendor collection — the pattern that lets us onboard a Splunk, a Cribl or a Sentinel customer without rebuilding it from scratch each time. Beyond that, the vendors are all shipping AI and agentic layers — MCP servers, agentic investigation, cross‑vendor gateways — and we already have that work live with a customer. You will get early, hands‑on exposure to it while most of the industry is still writing slide decks about it.

Working at Apto

Apto is a small business at an important stage of growth. The team is highly capable and works to standards that matter. We do not have the layers of process that large organisations have, which means you will have real responsibility earlier than you would elsewhere, and real accountability for the outcomes. We are based in our office in Clifton, Bristol three days per week, remote two days per week.

Salary is £35,000 to £42,000 depending on experience and assessed capability, plus bonus, pension and the usual benefits. The position is permanent and full‑time. You will need the right to work in the UK; we are not able to offer visa sponsorship for this role.