80 jobs found

Who this is for 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.   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   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.    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.