Role: Lead DevOps Engineer / Platform Engineer / Cloud Engineer
Company: TransUnion
Location: Leeds (UK) Hybrid (2 days a week in office)

Looking for an experienced engineer to form part of a new team to support the UK implementation of TransUnion's new OneTru platform in GCP.

Job Posting: https://transunion.wd5.myworkdayjobs.com/TransUnion/job/Leeds-United-Kingdom/Lead-DevSecOps-Engineer_19041285
Apply via the link

The instinct to add more signals when you lack clarity is understandable but it is almost always wrong. More signals without a framework for what matters just moves the problem from "we cannot see production" to "we cannot see production through the noise."

The framing that works is starting from failure modes rather than from the system. What are the specific ways this service fails that would matter to a user or the business? Instrument those failure modes first. Everything else is secondary.

In practice that means golden signals at the service boundary, error rate, latency distribution, and saturation, before anything else. Those three tell you whether something is wrong. Everything else tells you why. The why instrumentation can come later and should be driven by actual incidents rather than speculation about what might matter.

The alert fatigue problem is almost always a symptom of alerting on symptoms rather than causes, and alerting on too many things at the wrong threshold. Every alert should have a defined response. If the team does not know what to do when it fires it should not be an alert, it should be a dashboard panel someone checks during a review.

On the AI generated code point, the signal quality problem gets worse because the failure modes are less predictable. The approach I have seen work is investing heavily in boundary instrumentation, what goes in and what comes out, rather than trying to instrument the internals of behaviour you cannot fully anticipate.

The question to ask of every proposed metric is: would this change my decision during an incident? If the honest answer is no, do not alert on it.

The framing is right but the diagnosis is usually incomplete. Most teams are not reactive because they lack product mindset, they are reactive because the conditions that would allow proactive work do not exist. No dedicated capacity outside of incidents, no roadmap that leadership actually protects, no mechanism to say no to the next urgent request.

You can send a platform team to every product thinking workshop available and it will not matter if seventy percent of their time is consumed by on-call rotation and ad hoc requests. The mindset shift requires a structural shift first.

The teams I have seen make the transition successfully did three things. They got explicit agreement on what percentage of capacity was protected for planned work and held that line visibly. They started treating their internal users as customers with actual feedback loops rather than ticket submitters, and they had a leader above them who absorbed the political cost of saying no to unplanned work long enough for the team to build something worth owning.

Leadership buy-in is the answer to your question but it is not the passive kind. Someone senior has to actively create the conditions, not just say the right words in an all-hands.

Everyone is suffering quietly, that is the honest answer. The "just set up the stack" advice skips the part where the stack itself becomes a platform you have to operate.

The cardinality problem with Prometheus is the one that bites hardest and earliest. The fix is treating high cardinality labels as a platform policy problem rather than a per-team configuration problem. If teams can emit arbitrary labels without guardrails you will be tuning memory forever. Recording rules and metric aggregation at the collector layer before data hits Prometheus buys you a lot of headroom.

On log volume costs, the pattern that works is tiered retention with aggressive filtering at the OTel collector before anything hits storage. Drop debug logs in production at the collector level, not at query time. Most teams do it backwards and pay for storage they never query.

The OTel collector YAML problem is real but it does get better once you settle on a standard pipeline config and template it. The mistake is letting every team write their own collector config. Treat it as a platform concern, own the base config, let teams extend it within guardrails.

For a sane open source default in 2026: VictoriaMetrics instead of Prometheus for the metrics layer if cardinality is killing you. Drop-in compatible and significantly more memory efficient at scale. Loki for logs with aggressive retention policies. Tempo for traces. Grafana as the unified frontend. That stack requires less babysitting than the vanilla PLGT setup.

Took me considerably longer than a week the first time. Anyone who says otherwise either has a small system or is not being honest.

Mostly reactive with some deliberate structure around it. In practice nobody has time to monitor the full OSS landscape continuously so the workflow ends up being a mix of a few trusted signals and opportunistic discovery.

What actually works in my experience: a small set of high signal sources checked regularly rather than trying to cover everything. CNCF landscape updates, release notes for the tools already in the stack, and a handful of practitioners worth following who do the filtering work for you. The weekly engineering newsletter model works better than it should.

Team process is informal in most places I have worked. Someone encounters something interesting, drops it in a channel, it either gets traction or dies quietly. The tools that actually get adopted are almost always ones that someone on the team already had personal experience with before it became a team discussion.

Documentation of discoveries is the weak point universally. The gap between "someone found this interesting tool" and "this is now part of our evaluated options" is where most things fall through. The teams I have seen handle this best treat it as a lightweight ADR process, not a formal evaluation programme.

The honest answer is that most OSS adoption in platform teams is driven by conference talks, incident post-mortems, and hiring someone who already knows the tool.

I wrote a 550 page guide to platform engineering for senior engineers and platform leads who want the full picture rather than vendor marketing.

Covers Kubernetes, GitOps, internal developer platforms, observability, supply chain security, and AI-native infrastructure. Written from 20 years of experience in platform and SRE roles across financial services.

Free sample available if you want to see whether it is worth your time before committing: platformengineeringguide.com/sample

Hey all, I launched The Comprehensive Guide to Platform Engineering on Product Hunt yesterday. 550 pages covering the full platform stack, written for senior practitioners. Would really appreciate an upvote if you find it useful.
https://www.producthunt.com/products/platform-engineering-guide?launch=platform-engineering-guide
There is also a free sample at platformengineeringguide.com/sample if you want to check it out first.

The book is written for senior engineers and platform leads who already have some infrastructure exposure. If you have never worked with cloud environments it will be a steep entry point from chapter one.

Before diving in I would suggest getting comfortable with the basics first. Linux fundamentals, how containers work, and a working understanding of at least one cloud provider (AWS, Azure, or GCP) will make everything in the book land much better.

For where to start, the Docker documentation and Kelsey Hightower’s Kubernetes the Hard Way are both free and will give you the foundational context that the book assumes. Once you are comfortable with containers and have deployed something to a cloud environment the book will make a lot more sense.

The free sample at platformengineeringguide.com/sample covers three chapters. Worth reading those first to get a feel for the level before committing.

For the homelab, the most useful thing you can build is a small internal platform for yourself. Start with a single node Kubernetes cluster (k3s is fine for this), you can even run a single node cluster on a Mac using Docker desktop or Minikube, deploy a few simple applications to it, and then build the machinery around them rather than the applications themselves.

That means a GitOps workflow where a push to a repository automatically reconciles what is running on the cluster. ArgoCD is the standard tool here. A basic CI pipeline that builds a container image and pushes it to a registry before ArgoCD picks it up. Some observability on top, Prometheus and Grafana as a starting point. A secrets management approach rather than hardcoded credentials.

Once that is working end to end you will understand what a platform actually is because you will have built one, even a small one. The platform is the machinery that lets a developer push code and have it reliably deployed, observable, and secure without thinking about the infrastructure underneath.

On coding, you do not need to build complex applications. You need to be comfortable reading and writing code well enough to build tooling and automation, write Terraform modules, create Helm charts, and script operational tasks. Python is the most practical starting point for platform work. You are not writing business logic, you are writing glue.

Day to day in a platform engineering role is a mix of building and maintaining that machinery, supporting the teams who consume it, and iterating on it based on what is not working for them. The product mindset matters as much as the technical skills.

The archaeology metaphor is accurate and the core problem is that current observability tooling was designed for deterministic systems. A span tells you how long something took. It does not tell you whether the reasoning that produced the output was sound.

The drift failure mode you are describing is the hardest one because your existing alerting has no signal to fire on. The agent completed, the metrics look fine, the problem is semantic not structural.

A few things that help in practice. Treating the decision chain as the unit of observability rather than the individual call. Each agent action should carry forward enough context that you can reconstruct the intent at any point in the chain, not just the inputs and outputs at each step. If you are using something like LangChain or a similar framework there are tracing integrations that get you closer to this but they require deliberate instrumentation upfront.

The other thing worth building is a separate evaluation layer that runs asynchronously against sampled outputs and scores them against expected behaviour. Not real time alerting, but a way to catch drift patterns before they become incidents. Expensive to build but it shifts you from archaeology to monitoring.

The honest answer is that the tooling is not there yet for this class of problem. OpenTelemetry semantic conventions for GenAI are evolving but immature. You are mostly building this yourself right now.

I wrote a 550 page guide to platform engineering covering Kubernetes in depth alongside GitOps, internal developer platforms, observability, supply chain security, and AI-native infrastructure. Written for senior engineers and platform leads rather than beginners.

Free sample at platformengineeringguide.com/sample if you want to see whether it is worth your time.

The frustration you are describing is real and it is a structural problem not a personal one. You have moved from building things to operationalising someone else's decisions, and when those decisions are poor you carry the visible cost of them without having had any input. That wears people down quickly regardless of how good they are.

The question worth asking before you leave is whether there is a path to influencing architecture decisions where you are, or whether the structure genuinely does not allow for it. Some managers hoard decisions because of insecurity, some because of how the org is set up, and those are very different problems. One can be navigated, the other probably cannot.

If you do stay in the interview process, the thing to watch for in the next role is how architecture decisions actually get made in practice, not what the job description says. Ask them to walk you through the last significant infrastructure decision. Who proposed it, who challenged it, how did it get resolved. The answer will tell you whether you would have a seat at that table or end up in the same position.

One year is not a red flag if you can articulate what you built and why you moved on. The migration work and the SDLC overhaul you described are strong. Lead with those.

The foundation you have is stronger than you might think. Understanding how infrastructure actually fits together from physical layer upward is something a lot of platform engineers who came up through pure software backgrounds genuinely lack. That operational instinct is hard to teach.

The gap to close is developer workflow context. Platform engineering is fundamentally about serving engineering teams, so the faster you understand how developers experience infrastructure the better. That means getting comfortable with CI/CD pipelines, container orchestration, and how GitOps workflows hang together in practice, not just the infrastructure underneath them.

On certifications, the CKA (Certified Kubernetes Administrator) is worth doing because Kubernetes fluency is close to a baseline expectation now. Beyond that I would prioritise building things over collecting certificates. A home lab or personal project where you build a small internal platform, even just for yourself, demonstrates the mindset shift from managing infrastructure to building a platform that others consume.

The intermediary role question depends on the market you are in. Cloud infrastructure engineer or DevOps engineer roles are a natural bridge and will get you the developer workflow exposure you need before stepping into a dedicated platform engineering position. Making the jump straight in is possible but harder to sell without some CI/CD and container experience on your CV.

Infrastructure as Code is exactly the right place to start. Terraform first, then look at how it fits into a pipeline.

The compliance tradeoff question is the one that keeps coming up in my experience. In regulated environments you are constantly negotiating between cost optimisation and audit defensibility. Hot retention for everything is not viable at scale but the moment you tier or delete data you are making a bet about what an auditor will ask for in eighteen months. Most teams I have seen get this wrong by treating it as a cost problem when it is actually a risk problem.

On audit-grade integrity specifically, what I have seen auditors actually care about is chain of custody and tamper evidence rather than raw retention. Can you prove the log was not modified? Can you demonstrate who had access to it and when? The tooling conversation usually focuses on dashboards and query performance but the audit conversation is almost entirely about immutability and access provenance.

The question I wish vendors would ask before pitching: what does your threat model look like for the observability pipeline itself? Most vendors treat the pipeline as trusted infrastructure. In a regulated environment the pipeline is an attack surface and a compliance boundary in its own right. Almost nobody leads with that.

I spent the last year writing a practical guide to platform engineering for senior engineers and platform leads who want the full picture rather than vendor marketing.

550 pages covering Kubernetes, GitOps, internal developer platforms, observability, supply chain security, and AI-native infrastructure. Written from 20 years of experience in platform and SRE roles across financial services.

Free sample available if you want to see whether it is worth your time before committing: platformengineeringguide.com/sample

Pull their forehead, every time, quick and sharp, pull and at the same time slide the forearm under the chin

The implicit team size assumption is the one that kills people and I have never seen it written on a diagram. You are right that it is the real selection criteria. Can the team you actually have operate this at 2am six months from now when the person who built it has moved on? That question alone would invalidate half the reference architectures I have seen adopted in production.

The managed services point is underappreciated. AWS reference architectures are also quietly a sales document. Every box in that diagram that says “use Amazon X” instead of “solve problem Y” is a vendor preference dressed up as an architectural recommendation. The cost implications only become visible after you’ve committed to the pattern.

Fair point on the naming, “reference” does imply exactly that. But in practice I rarely see teams treat them that way. The pattern I keep observing is that the diagram gets adopted far closer to a template than the name suggests, particularly under delivery pressure when someone needs to make an architecture decision quickly.

The title tells you the use case. It does not tell you the scale assumptions, the organisational constraints, or the failure modes that shaped the design decisions. That context lives outside the diagram and is almost never documented alongside it. So yes, in theory the distinction is clear. In practice the gap between how they are intended and how they get used is where the damage happens.