Scrolling through job listings this past month, I noticed roles titled DevOps Engineer or Platform Engineer or Infrastructure Engineer that were listed with almost identical responsibilities.

I know innately that these roles have some differences, but the titles are often used interchangeably by hiring teams.

Where DevOps came from

DevOps is a word created from the combination of the words Developer and Operations. To understand why that portmanteau word became a job title, you need to understand the problem it was trying to solve.

Traditionally, software teams were split in two. Developers wrote code in one room, and an Operations team —sometimes called Ops— deployed and ran that code in production. Each group had different incentives e.g. devs wanted to ship fast whilst ops wanted stability. That tension caused friction, slow releases, and potentially a blame culture when things broke.

The DevOps movement, popularised in part by The Phoenix Project (Kim, Behr, Spafford, 2013) and The DevOps Handbook, proposed a cultural fix to tear down that wall. If developers owned their code all the way to production, they’d build with operability in mind. They’d care about deployment pipelines, alerting, and recovery because those things would become their problem too.

DevOps is meant to be a shared practice of principles across teams, and not a single person’s role. But organisations found it easier to spin up a DevOps teams or hire someone with the DevOps title who embodied that DevOps mindset to show some adoption of “DevOps” when it was first cool.

What a DevOps Engineer actually does

In practice, the DevOps Engineer tends to be embedded within a product team, sometimes as the only person with that focus. Their job is improving the speed and safety of getting code from a developer’s machine into production.

That means CI/CD pipelines (think GitHub Actions, TeamCity, CircleCI, or similar), automated testing, deployment automation, monitoring and alerting, and security gates. If a developer is waiting too long for a build, or a deployment is a manual, error-prone process, the DevOps Engineer is the one called on.

My own experience working in this role felt exactly like that: a solo DevOps expert embedded in a development team, focused on making the production path faster and more reliable. In smaller companies you will probably get the opportunity to pick up other development tasks outside of the usual job description. This helps you experience the pain that engineers go through to build better solutions.

Platform Engineering

Platform Engineering has similar tools and similar outcomes, but from what I’ve seen, the scope and audience are different.

Where a DevOps Engineer typically serves one team, a Platform Engineer serves many. This role, I think, is oriented around building an Internal Developer Platform (IDP). An IDP is a curated set of tools, templates, and standards that every engineering team in an organisation can use. The CNCF communities often describe this as building golden paths: opinionated, well-maintained routes that make the right thing the easy thing for developers to do.

Think of it as the difference between solving a problem for your team versus building the infrastructure so any team can solve that problem themselves. Platform teams treat internal developers as their customers. They build self-service tooling —things like standardised deployment workflows, observability stacks, or secrets management patterns— so that product teams don’t have to reinvent those wheels independently.

This tends to appear at larger organisations, where inconsistency across teams becomes a bigger cost. At a company with ten engineers, one strong DevOps person can handle everything informally. At a company with five hundred, the absence of shared standards can create chaos.

The tradeoff here is somehow creating efficient standards to keep things stable, but also giving optionality to engineers so they have autonomy over the tooling they choose.

A good tool to know about is Spotify’s open source Backstage tool: https://backstage.io/

Infrastructure Engineering

Infrastructure Engineering overlaps with both DevOps and Platform, but sits slightly further from application code in my experience.

An Infrastructure Engineer is typically focused on the foundations: cloud architecture, networking, access management, and the security controls that sit beneath the application layer. They’re thinking about VPCs, subnets, firewall rules, load balancers, DNS, and how services communicate across boundaries. Often this involves deep expertise with IaC tools like Terraform and close familiarity with the cloud provider’s lower-level primitives.

A DevOps Engineer might spend their day modifying a GitHub Actions workflow or adjusting a Dockerfile. An Infrastructure Engineer might spend theirs designing the network topology that those pipelines eventually deploy into.

That said, in my experience, in any organisation you have problems to solve and there is never a clean separation. So you’re owning all of it, and carrying all three titles simultaneously whenever something is required.

Why the roles overlap

There are more than the three role titles I’ve talked about too, e.g. Systems Engineer, Site Reliability Engineer, Integration Engineer, and many others that cover similar responsibilities with decent overlap.

Part of it is because fashionable titles shift over time; DevOps was the go-to term but now it feels like Platform Engineering is. This is probably because it better captures the product-focused, team-of-teams thinking that scales for devops/platform teams.

Each organisation decides on responsibilities differently depending on team size, product maturity, culture in the industry, and even the background of whoever’s hiring. So the title they’re given is essentially a best guess based on responsibilities required at the start of the role, which often morphs into different roles as projects progress.

A startup with five engineers often doesn’t have the headcount for specialisation. The person managing Terraform, building the deployment pipeline, and configuring the VPC is doing DevOps, platform, and infrastructure work all at once.

At larger companies, the separation becomes more meaningful. A Platform team with a product mindset and a roadmap looks very different from a DevOps Engineer embedded in a squad, even if both are deep into Kubernetes on any given Tuesday.

Read the job description

After reading many applications, the practical lesson is to read past the title and into the responsibilities. A “Platform Engineer” role at a thirty-person startup will look nothing like the same title at an enterprise company. A “DevOps Engineer” role at a bank might be closer to what a Platform team does at a tech company.

The questions worth asking in an interview: Are you embedded in a product team or sitting in a centralised infrastructure group? Are you building tooling for developers, or helping productionise a single product app? What does ownership look like when something breaks at 3am?

I like that DevOps Engineering is broad; I like having the option to do whatever is required to get the job done.

Types of Developers in the Workplace

In a dynamic and collaborative workplace, you’ll encounter various types of developers, each driven by different motivations and approaches to their work. Understanding these developer archetypes can help foster a more effective and harmonious team environment.

1. The Detective

Drive: Detectives love to investigate. They thrive in messy situations, dissecting problems, and fixing them. Their analytical minds excel at uncovering the root causes of issues and implementing solutions. They’re the team’s problem-finders, and a lot of the time, problem-solvers.

2. The Cowboy / Go-getter

Drive: Cowboys or Go-getters are known for their speed. They push code out the door quickly, often impressively so. However, they might leave a bit of a “dirty sink” behind, sacrificing some cleanliness for speed. They’re the team’s high-velocity coders.

3. The Artist or Creative

Drive: Artists or Creatives focus on the aesthetics of code. They’re meticulous about making sure their code is not just functional but also visually appealing and highly readable. While they may code more slowly, their work introduces less technical debt. They’re the team’s code beautifiers.

4. The Mad Scientist

Drive: Mad Scientists are tech enthusiasts. They eagerly embrace the latest technologies and enjoy experimenting with new libraries and features. Their adventurous spirit leads to innovation and pushing the boundaries of what’s possible. They’re the team’s tech trailblazers.

In a balanced development team, these diverse types of developers can complement each other, fostering creativity, efficiency, and problem-solving. Recognizing and valuing these different approaches can lead to a more well-rounded and successful team.

Simplifying Technical Jargon

To communicate tech concepts to non-technical individuals, analogies are invaluable.

The Barrier of Technical Jargon

In the tech world, complex terminology and buzzwords are commonplace. While they serve a purpose among peers, they can hinder communication with non-technical individuals.

Harnessing the Power of Analogies

Analogies act as bridges, simplifying intricate tech concepts for the non-technical. They make the unfamiliar more accessible, fostering better understanding and collaboration.

Striking the Balance

Balancing the use of technical jargon and analogies is key. Precision is vital in technical discussions, but in broader contexts, simplification enhances communication, collaboration, and innovation.

Types of Applications

Applications can be web-based (run in browsers), desktop (run on a computer), or mobile (run on phones). Examples like Netflix, Spotify, and Instagram show the diversity of platforms.

In simplified terms, an application’s Stack includes a Client (the end-user with a Laptop or Mobile device), a Server (handles requests, processes data, and communicates with the Database), and a Database (stores information). Think of this stack like a person withdrawing money from a bank:

1. Front-end -> Person/Client
2. Server -> Bank Teller
3. Database -> Money Stash

Understanding APIs

APIs (Application Programming Interfaces) are communication tools for technology. Think of ordering fast food: the client orders, the server takes the order, and the chefs in the kitchen fulfill it. An API is like the menu, specific to the restaurant you’re at.

If you go to Burger King and order a Big Mac, the server will not understand that request as it is not on their Menu.

Team Dynamics

Different types of team members, including detectives, cowboys, artists, and mad scientists, each have distinct work styles and motivations. Recognizing these differences can improve team collaboration.

Click here to read the full article on these archetypes here.

The Coding Process

Developers need uninterrupted time to code effectively. Minimize interruptions by scheduling meetings in blocks, improving productivity.

Future Technology

Full-stack development offers efficiency by using one language across all stack components. Libraries like React can translate web apps into desktop and mobile versions. Distributed technology, like blockchain, shares data across a network, reducing the risk of single points of failure and enhancing security.