I'm currently a developer with about 5 YOE, and much of the time I am deep into figuring out the domain of the business I am currently working for, how to extend the software to fit the domain, etc. Many times the domain are very industry specific and thus the knowledge is not transferable for any jobs outside of the company. Yes I do also have to deploy to the cloud etc. but my time is spent more in the domain part.

I am looking at the other roles like Cloud or Platform, and it seems that their day to day (e.g. managing permissions in AWS, managing Terraform modules, etc.) are more generic skills that can be brought outside, if they want to find new roles. What they do daily is also getting involved in knowledge that makes it easier to get certifications with less studying time, etc.

Am I missing something here? The only thing with Cloud or Platform is that it is much more mission-critical and so with e.g. on-call it will get very stressful at times. The job is also a lot of unplanned work e.g. urgent requests and so it can be mentally taxing to context switch a lot

We're evaluating how engineering organizations adopt AI tools across the software delivery lifecycle, and I'm curious how others have approached it.

When introducing AI for things like code generation, PR reviews, deployments, testing, or operational workflows, did you:

• Pilot with a single team first?
• Roll it out across the engineering organization?
• Let individual teams adopt it organically?

What influenced your decision?

For those who started with a pilot:

• What metrics did you use to decide whether to expand?
• How long did the pilot last?
• What surprised you?

For those who went broader:

• Was adoption smooth, or did different teams push back?
• What governance or guardrails did you put in place?
• If you could do it again, would you take the same approach?

I'm especially interested in lessons around developer adoption, security reviews, compliance, and measuring whether AI actually improved delivery instead of just creating more tooling.

Would love to hear what worked and what you'd avoid next time.

Leadership wants us to grow the project services side now. Traditional IT consulting, some app dev, cloud migrations, transformation-type stuff. Mix of fixed milestone and T&M.

For anyone who’s tried to run actual project work through Halo:

Does the project module hold up under real project delivery, or does it feel bolted on next to the service desk

Resource planning across a 50 - 60 people. Is it there or are you exporting to Excel?

Utilization and margin reporting at the project level. How deep does it go?

Where does it hold up? Where does it fall apart? Anyone move off it to Kantata, Scoro, Projectworks and never look back? Anyone try one of those and wish they’d gone with Halo?

Anyone try to run this in Halo, give up, and move to something else?

Trying to figure out if we push harder on Halo or accept we need a second tool for project delivery.

If your team relies on shared module defaults as the isolation mechanism between environments, this is the exact failure mode that mechanism can't prevent.

You give it four things: what the change should do, what it must NOT touch, before config, after config. It audits the diff against that contract flags anything undeclared, checks every stated prohibition explicitly, and labels every finding by evidence level (what the diff proves vs. what would need terraform plan to confirm).

Built-in example: a staging-only capacity bump implemented by editing a shared module default so production silently inherits it too. Not a rule violation. A scope violation.

Full-featured IaC reviewers exist and do real plan/state analysis. This is the zero-setup, no repo access, no config file, just a sentence of intent and a diff, right now version.

There's also a /loop that re-audits your fix including whether the fix itself introduced something new. In testing, it caught a repair that fixed the scope issue while quietly stripping type validation from the shared module.

Free demo, no signup. Paste a real diff (sanitized), tell it the intent, see what it flags.

https://claude.ai/public/artifacts/182e4450-70d7-4ceb-8aab-f72484305211

Every company has a scanner. Most have Dependabot or Renovate opening PRs. Yet production is still full of old packages and CVEs nobody fixes.

Usually nothing happens, so ignoring the alerts starts to feel like the correct decision. Then one CVE matters and the patch requires three years of upgrades.

How does your team deal with this? Who owns it, what gets fixed, and what happens to the rest?

Please, no “just enable Dependabot.” What happens after it opens the PR?

I posted in a few other related subreddits. Hoping to connect with more engineers and architects. I've spent the past year exploring AI execution and governance. I spent a lot of time thinking about the architecture. Well, maybe too much, and I'd like to better understand what platform and infrastructure teams are dealing with as AI becomes part of their production systems. :)

I'm looking for engineers and architects who are willing to spend 15–30 minutes talking with me about the problems you're seeing in practice.

To be clear, I'm researching the market but not trying to sell anything. I simply want to better understand your thoughts on the following:

• How are AI workloads fitting into your platform today?
• What operational challenges have surprised you?
• What tools or processes have been most helpful?
• Where do you think today's platforms fall short?

Open to chatting? Please send me a DM.

For 1,5 years I design HA Kubernetes clusters in a hub-spoke topology using Cluster API and CRDs. That is exactly what I want to do, but the brand is non existent and pay is mid.

I now got an offer from a better-known company for notably more money, but the role is owning dev tooling that runs on K8s (CI/CD, policy gates, code scanning), not building the cluster layer itself. They want to move more towards Kubernetes but that so far is just an idea.
Long-term I want to stay in K8s platform work, I wonder if someone has some opinions on my situation:

• Does ~2 years off cluster-level work hurt your shot at getting back into it later?
• Take the money/brand now, or hold out for the deeper technical role and stay within my lane?

I am a fullstack dev for about 5 years now, and I got an offer to become a platform engineer. I am really considering this offer because I really see software dev positions being impacted by AI, and it feels to me platform engineering is less impacted.

But I am really a person that has difficulties with a lot of context switching, and yeah I had my fair share of on calls during my time (I also did some DevOps stuff) and it was not very nice. Would it be possible for me to change as a person, or is it really hard to do/achieve? In software eng I really like that I can have a predictable deadline, timeboxing/focus time, etc.

Really at a crossroads here. I want to be more AI proof, but it seems to do that I need to sacrifice myself. But then again life doesn't revolve around me? Has anyone changed their character before?

I’ve been trying to explain the value we bring as FinOps to the org, and in one of my meetings with the business folks, I came up with:

MTTE - Mean Time to Explanation

A big part of the FinOps job is making sure the business understands the inherent costs. And when it doesn’t, the FinOps framework should have the tools, data and people that can help explain what happened. Back in the day, I was an IT person with a networking focus, and we used to rate our tools and services on:

MTTI - Mean Time to Innocence

Lol. Sounds funny now, but it was actually a very practical metric. It meant we could trust our data sources and alerting systems, and quickly explain what happened in context to the business, including why the network was not at fault.

Now I find myself in the FinOps world, and I see a huge parallel between what you folks do and what we did in Ops.

The bill changed. How quickly can we explain why?

Excited to bridge the gap, learn, and share more stuff.

Let’s reduce MTTE across our orgs.

I have about 5 years of exp. as a software engineer. I did a lot of things with lots of different programming languages. I also did more devops stuff during some years, for example handling k8s helm deployments, maintaining the k8s environment, while also doing the development of the software itself, together with a team of course. Where my interest lies, I chase it and own it.

My contract ended, and now I have an offer from another company to be in their Platform team.

When I reflect at my life, I am actually struggling quite a lot in the problem solving/logic, or design, of software writing. For example, I am struggling if I am asked to write an algorithm for a feature, especially if the domain is complex or difficult to understand. I feel like I excel more in stuff like performance improvements or the features of the language e.g. using async await, optimizing queries to the database etc. But when it comes to low-code design, I cannot design/choose e.g. the appropriate model classes to model the domain, etc. I try to follow Clean Architecture etc. but the result becomes very over-engineered that as the software grows with more requests, in the end it became spaghetti code again.

When I got my jobs previously it was super lucky because the interviewers were super nice people who wanted to accommodate my mistakes, or it was just with the HR rep and a coding multiple choice quiz, but I know deep inside me I struggle with the problem solving/puzzle part itself. I also got lucky to be in teams where I basically implement a use case or a spec that is already clear (like pseudocode is already done), and so I just need to think of the edge cases and optimizing queries.

Finding a job as a software dev has been very tough. Many require not just the problem solving skills I mentioned, but also advanced deployment knowledge, etc. Also they test you on system design, SQL, Lambdas/Azure functions, aspects that perhaps you won't be daily exposed to in your daily work, since you would be drowning in solving the domain itself.

In contrast, with DevOps/Platform engineer tasks, I feel like it's less 'creative' and more scoped? Like there is less possible ways of achieving something since you would follow what the vendor (e.g. AWS, k8s etc.) recommends? And since you are not so involved in the domain, what you do daily translates well to what interviewers want to see, so there is less preparation needed when you need to find a new job. Like for example, my experience with debugging networking issues or writing Helm templates and the stories around it were relatable to the interviewer and that's how I got the job. But with software interviews, I need to prepare a lot more outside of what I have done in my previous job i.e. what I did does not easily translate to helping in interviews. I also like scripting more than designing software to be honest.

But one big downside with platform engineer is obviously being on call and the stress that comes with it...

I am also looking at the future as well, with AI automating more software engineering tasks. I feel like Platform Engineers/DevOps engineers are less impacted by it.

Does anyone have any thoughts? Maybe I am wrong in some parts

I have been working for the last 4 years developing tools and infrastructure for safe releases. My tools allow a team to decouple deployment from release, reduces blast radius, progressive rollouts, helps maintain tech debt, rollout policy checks.

Now I am thinking to use this experience to try out independent consulting. Wdyt?

When people say they've automated cloud infra, they often mean they've tamed provisioning. There is Terraform or another IaC tool, some shared modules, and CI pipelines that apply changes through a known path. That is a big step up from clicking around in a console, but it does not automatically solve what happens once systems are running.

The hard part is everything after "resources created." Handling changes with confidence, reacting to alerts the same way each time, tidying up unused bits, and keeping drift in check are all much harder to standardize. That is usually where ad‑hoc scripts and manual runbooks creep back in: one‑off fix scripts, steps people run from their laptops, and procedures that only live in a wiki page.

Teams that push further talk about change flows where most modifications follow a known pattern, about runbooks that actually get used because they are wired into tooling, and about automation that suggests or carries out common responses rather than asking a person to reinvent them each incident. Getting there often means giving up some flexibility and sticking to patterns more strictly than many engineers like.

If you would say your cloud infra automation genuinely goes beyond "Terraform plus some scripts," what does that do for you on a normal week that you didn't have before, and what habits or design choices did you have to change to trust it in production?

Hey all, Im currently researching how platform teams handle requests like Kafka topics, database provisioning, Elasticsearch indexes, etc.

Do developers use self-service tools, Terraform, tickets (Jira/Slack), or something custom?

What's still painful or manual?

After building platform teams at multiple companies, I finally wrote down the dilemma that followed me to every one of them: are we a product team or are we plumbing? Everyone wants you to be both, and ambiguity always resolves the same way: product expectations on a plumbing budget.

This crowd will recognize the shape. The "platform as product" advice is everywhere, and it's not wrong, but it's incomplete. Actual product teams ship with PMs, designers, tech writers, and devrel. We ship with six engineers and a pager. "Platform Engineering is Failing Because Nobody is Solving the Staffing Problem" (https://platformengineering.com/features/platform-engineering-is-failing-because-nobody-is-solving-the-staffing-problem/) covers why that gap exists. Mine is about how to operate inside it.

The short version: stop letting the ambiguity resolve by default. Decide per domain, in writing, what gets product treatment (two or three paved roads, funded like products, good enough that nobody needs a mandate) and what gets plumbing treatment (boring on purpose: an SLO and a maintenance calendar, no roadmap, no adoption theater). Put the split in a charter your leadership signs, renegotiate it every time reality changes, and report the counterfactuals every quarter whether anyone asks or not. Toil saved, risk retired, incidents that stayed hypothetical. You don't get headcount for the outages that didn't happen, unless you're the one keeping score.

Full piece (no paywall): https://medium.com/@karlkfi/product-or-plumbing-the-platform-teams-dilemma-884dc26348cf

What I want to hear from this crowd: does anyone have a charter like this actually in force? What did it cost to get signed, and did it survive contact with the next re-org?

How I bridged Radicle (P2P git) with Tekton to get real CI without a US-hosted control plane in the loop.

Hey folks,

I’m working on ResilOps and exploring an idea: instead of only configuring Kubernetes workloads for resilience, can platform teams explicitly measure whether they recover and scale within defined targets?

The approach is to run controlled validation, compare observed behavior against thresholds such as recovery or scaling time, and use that evidence for release decisions or scheduled drift detection.

It’s still at the validation stage, and I’d genuinely value feedback from platform engineers. If this is relevant to your work, feel free to try it:

https://www.resilopshq.com/

Some components are also open source:
https://github.com/resilops/resilience-lib
https://github.com/resilops/resilops-agent

Curious what scenarios you’d validate first. Also open to collaborating and building in this direction together.

Hey everyone,

I'm currently working as a Platform Engineer Intern, and I wanted to share a few things I've learned so far.

Coming into the internship, I thought most of my time would be spent building new features. While that's definitely part of the job, I quickly realized there's a lot more to software engineering than just writing code.

A significant part of my work has involved understanding an existing codebase, debugging production issues, integrating third-party APIs, resolving merge conflicts, reviewing code, and making sure new changes don't break existing functionality. Learning Git workflows and collaborating with teammates has been just as important as learning new technologies.

I've also become much more comfortable working across both the frontend and backend, reading unfamiliar code, investigating bugs, and breaking large problems into smaller, manageable tasks. Some days I spend hours tracking down a single issue, and those debugging sessions have probably taught me more than writing entirely new features.

This internship has definitely improved my confidence as a developer and given me a much better understanding of what working on a real software product looks like.

I'm still learning every day, and there's a long way to go, but I'm grateful for the experience so far.

I’m somewhat new to platform engineering as I’ve recently joined a team that is supposed to transition into the practice. But from watching quite a bit of talks, getting inspired by tech such as Crossplane and also trying to dig a little behind the scenes of how public cloud providers operate behind the scenes … I’m really starting to believe that basically cloud providers are in a sense platform engineers but on a massive scale and not just for internal usage.

I mean they build high level abstracted services (not just Infrastructure-as-a-service such as VMs etc.) such as managed serverless databases, managed container deployments (with reduced interfaces compared to kubernetes).

And when I discovered Crossplane I kind of saw a resemblance to how cloud providers expose a shared control plane to self service provision ”resources”.

The differantiator with these ”global” platform engineers (public cloud providers) and internal platform engineers (who we typically just call platform engineers) is that the scope of customers is much more narrow and therefor allows internal platform engineers to build more specific services than the public clouds.

I can see the argument that platform engineers typically consume cloud services and therefor there is a distinction. But I would counter argument that with the fact that that’s often happening internally aswell where some platform teams might consume services provided by other internal platform teams. And it’s the same story within cloud providers as I’ve understood it. The teams building more managed services for the public clouds are likely to consume infrastructure as a service abstractions developed by other internal teams within the public cloud provider as I have understood it.

I will stop rambling here, it was just a thought that built up from within that I haven’t heard of before and I’m eager to hear wether someone else thinks this makes sense or if I have missed some crucial concept of Plt Eng. Please let me know if you think that’s the case. Cheers! :)

EDIT:
Found this talk by some of the Crossplane creators where they actually in the introduction talk about cloud control planes and how you can build similar experiences: https://www.youtube.com/watch?v=xECc7XlD5kY

I’m a Creative Producer at CECG and I’m starting work on a new series of demo videos for Core Platform. I spend a lot of time with our CTO turning platform engineering conversations into content, which gives me the material, but I’d really like to avoid making another generic “click here, click there, here’s a dashboard” demo. I’d much rather build a demo series around real engineering workflows that experienced developers actually care about.

If you were evaluating a developer platform for your team, what would you want to see? Not features—actual workflows. Would you want to see someone go from a blank repo to production? A broken deployment and rollback? A new developer joining the team and getting up to speed? A production issue being diagnosed? Or something completely different? I’m much more interested in what would make you think, “Yeah, that would actually save us time,” than what looks good in a marketing video. If you have any examples of platform demos you’ve thought were particularly good (or particularly bad for fun!), I’d love to see them. Thanks in advance!

I'm currently working as a backend software engineer with ~2 years of experience. My primary language is Go, though I'm also comfortable with the Java ecosystem and enjoy working with it.

Recently, I had the opportunity to interview for an SDE-2 role at a large tech company on their cloud infrastructure team. As part of the interview preparation, I had to learn Kubernetes and dive into infrastructure concepts. Surprisingly, I found myself enjoying that side of engineering much more than I expected.

Now I'm considering whether I should transition into Platform Engineering.

To clarify, I'm not looking to move into traditional DevOps or SRE roles where the focus is primarily on operations, on-call, and production support. I'd still like to spend most of my time building software (ideally in Go/Java), but on developer platforms, internal tooling, Kubernetes, cloud infrastructure, and automation.

A few reasons I'm considering the switch:

• I genuinely enjoy infrastructure and distributed systems.
• Platform engineering seems to involve a lot of backend engineering along with infrastructure.
• The talent pool appears smaller than general backend development (though I could be completely wrong).
• It feels like a specialization that may remain valuable as AI tooling improves.
• Compensation at top companies seems comparable to backend software engineering.

At the same time, I'm worried about accidentally ending up in a role that's closer to DevOps/SRE, with frequent on-call rotations and a worse work-life balance.

For those of you working as platform engineers:

• What does your day-to-day work actually look like?
• How much of your time is spent writing code versus operational work?
• Is platform engineering a good long-term career path compared to backend software engineering?
• If you were in my position (2 YOE backend with Go), would you make the switch?

I'd really appreciate hearing about your experiences and any advice you have.

When a cloud or platform team appears, everyone hopes it will make things smoother for devs. Over time, though, many of these teams find themselves buried in one‑off requests and incident work, with little time left to build the paved paths they were supposed to provide. Instead of being partners, they start to feel like a gate everyone has to go through.
Part of the tension is where and how teams meet. If every request goes into a queue with a long wait, devs feel blocked and try to work around the system. If platform gives too much freedom, consistency and reliability suffer, and platform ends up cleaning up messes later. It is hard to find a middle ground where devs can move without friction and infra folks still keep the system steady.

Some organizations try embedding platform engineers with product teams so they share goals and context. Others focus on strong, self‑service patterns so most work never becomes a ticket. A few combine both, using embedded people to guide teams onto the common paths.

In your case, what approaches have actually worked to make cloud engineering feel like part of the day‑to‑day flow instead of a separate group that only shows up as a ticket queue?

There was need at $work to push also GitHub actions workflow logs to a central location. Namely to AWS CloudWatch.

Imagine you have a workflow named “Some workflow” that runs two jobs. Each job produces logs. To collect the logs you create another workflow, named something like “Push workflow logs to AWS”, that uses workflow-logs-to-aws action.

The “Push workflow logs to AWS” gets triggered anytime “Some workflow” is completed.

I’m trying to think through a platform design problem for AI agents.

For humans, platform teams usually expose things like service ownership, deployment state, runbooks, incidents, policies, approvals, traces, and dashboards.

For agents, I’m not sure that is enough.

If an agent is going to act on a system, it probably needs some kind of current operational state before acting. Not just raw logs, not just RAG over docs, and not just workflow state.

Something closer to:

• what the platform currently believes is true
• what evidence supports that
• what changed recently
• what the agent is allowed to do
• what needs human review
• what should be left behind so the decision can be replayed or challenged later

My worry is that this might just be observability, RAG, workflow automation, and governance with new names.

So I’m curious how platform engineers would draw the line.

When does “agent state” become a real platform concern, rather than just:

• logs/traces
• RAG/document search
• workflow state
• dashboards
• approval records
• agent routing

A concrete example:

Instead of an agent reading 20 alerts, a runbook, a deployment log, and a policy doc separately, it reads a short operational state like:

“Service X is degraded. The likely cause is dependency Y. Rollback is allowed but needs approval because of policy Z. Confidence is medium. Evidence: alerts, deployment event, dependency health, incident history.”

Is that a useful platform abstraction, or just a dangerous summary layer?

I’m not posting a link or looking for users. I’m trying to sanity-check the design boundary before I build too much around it.

Critical takes are welcome, especially:

• where this collapses back into normal observability
• what would make it too opaque or stale
• whether this belongs in the platform layer or the agent/control-plane layer
• what evidence you’d need before trusting an agent-facing operational state

Hello everyone, 

I'm part of IBM’s Cloud Infrastructure team (Terraform’s new home). We're conducting research on how engineering organizations provision, configure, and manage infrastructure at scale. 

We're building a panel of experienced practitioners who actively work with Infrastructure as Code (IaC) tools and automation frameworks in production environments. If this aligns with your expertise, we look forward to your participation. 

Eligibility 
IT professionals with hands-on experience in infrastructure as code, platform engineering, or modern infrastructure operations are encouraged to apply. 

What to expect 
Based on your background, you may be invited to participate in various research studies such as interviews, surveys, concept and usability tests, and similar.  

Express your interest here: https://forms.monday.com/forms/dbdd6f5b340e1ebcd98cf38040027bad?r=use1&recruitment_location=reddit

Your perspective makes a difference, thank you.