Who does what on an engineering team?

Who does what on an engineering team?

Every engineering title answers one of three questions: which layer of the application the person works on, which step of the release pipeline they own, or how much scope they carry. Frontend and backend are layers. DevOps and SRE are pipeline. Senior and staff are scope. Once a title resolves to its question, the person's actual week comes into focus.

Most real titles combine two of the answers. "Senior Backend Engineer" is a layer plus a scope. "Staff Site Reliability Engineer" is a pipeline step plus a scope. Reading a title means splitting it into its parts and checking each part against the work the hiring manager describes.

The layers come from how software gets built: a visible part, a hidden part that does the work, and a database holding the state. The pipeline comes from how code travels from a laptop to a customer. The scope levels are a ladder that runs across all of it, from owning a task to owning a system to steering an organization.

This guide is the map of the whole cast. Each section names the titles in one region, says what the person does on an ordinary Tuesday, and links the lesson that goes deep on that region. The payoff is caught mismatches: a req titled "DevOps Engineer" that describes building product features, or a "data scientist" opening that describes moving data between systems. The title and the work drift apart often, and the work is the truth.

Who is in the room when a feature gets decided?

Three roles, with a clean division of labor. A product manager decides what gets built and why. A product designer decides how it looks and feels. Engineers decide how it works and then build it. The first two carry no code, and both sit inside the engineering organization on most org charts.

The product manager owns the question "is this worth building". They talk to customers, rank the possible work, and write up what each piece should do. The designer turns that into screens and flows before any code exists. The lesson on who works on a software team walks through both roles and the engineering manager, the person who manages the engineers as people: hiring, growth, and performance rather than the technical decisions.

These roles connect to the path from idea to running app covered in station one, and their meetings are the rhythm described in how the team moves. For a search, the boundary matters because product managers and engineers are entirely different pools. A "technical PM" req still describes a PM.

Which titles map to layers of the app?

The largest population of engineers splits along the line drawn in the frontend, the backend, and the API. A frontend engineer builds what users see: the screens, the buttons, the parts that respond to a click. A backend engineer builds what users never see: the code on the server that stores data, enforces the rules, and answers the frontend's requests.

A full-stack engineer works both sides. The label is honest and also elastic. At a five-person startup it means one person builds the entire product. At a large company it often means a frontend-leaning engineer who can make backend changes when a feature needs both. The size of the company tells you which meaning applies.

Mobile engineers build the apps installed from an app store, and mobile is usually a separate search from web work. The phone platforms use their own languages and their own tools, so a strong web frontend engineer and a strong iOS engineer hold different resume nouns. The lesson on backend days and the mobile split covers what each of these people does hour by hour, and where cross-platform tools blur the mobile boundary. Adjacency still counts: station two's lesson on what transfers explains why an engineer one shelf over can often ramp quickly.

Which titles own the pipeline and the machines?

Some engineers work on the product. Others work on the system that builds, ships, and runs the product. That second group carries the titles DevOps engineer, site reliability engineer (SRE), platform engineer, and infrastructure engineer. Their material is the cloud, the deploy pipeline, and everything that keeps the product running at three in the morning.

The word "DevOps" misleads because it began as a practice rather than a job. It is a compression of "development" and "operations", and it named the idea that the people who write software should also run it, instead of throwing it over a wall to a separate operations department. The practice worked, and then companies started hiring "DevOps engineers" to own the tooling that makes it possible. Both meanings are alive, so the title alone says little.

SRE stands for site reliability engineer, a title Google coined for engineers who keep large systems up. An SRE's week revolves around measuring reliability, responding when the product breaks, and fixing the causes so the same break stops recurring. This connects directly to why software is never done: running software degrades without constant tending, and SREs are the profession built around that fact.

Which titles work on data?

Four titles, one pipeline, four searches. Data flows through a company in a sequence: it gets collected, moved and cleaned, analyzed, and finally used to build models. Each step has its own title, and the lesson on the data quartet takes each one in turn.

A data analyst answers business questions with existing data: which customers churned, which region grew. A data engineer builds the plumbing that collects and moves the data, a backend-flavored role that leans on the storage concepts from where the data goes. A data scientist applies statistics to find patterns and build predictive models. An ML engineer takes those models and makes them run reliably inside the production product, the most software-engineering-shaped role of the four.

The pipeline ordering is what makes these different searches. Each role consumes the previous role's output, so the skills barely overlap: an excellent analyst and an excellent ML engineer share almost no tools. A req that says "data scientist" while describing pipeline construction is describing a data engineer, and candidates read that mismatch as a company that has yet to figure out what it needs.

Which titles work on AI?

The newest region of the map, and the one where titles are still settling. The load-bearing distinction comes from station three: a tiny number of companies build models, and everyone else builds with them. Research scientist and ML engineer titles cluster at the model-building labs. The "AI engineer" title lives on the much larger building-with side.

An AI engineer connects models made by the labs into a product: wiring model calls into the backend, shaping what the model sees, and handling the ways model output can go wrong. It is close cousin to backend work, built on the new plumbing that station three introduced. The lesson on whether AI engineer is a real title traces where the title is a genuine specialty and where it is a fresh coat of paint on an existing role.

The honest complication is that AI work is also spreading into every other title on this map. A frontend engineer now builds interfaces for AI features, and a data engineer now feeds pipelines into model systems. "Experience with AI" on a req can therefore mean a specialist search or an ordinary search with one extra skill, and the surrounding description settles which.

How does the seniority ladder work over all of them?

Every title above comes in levels, and the levels measure one thing: scope of ownership. A junior engineer owns tasks and gets meaningful guidance. A mid-level engineer owns features end to end. A senior engineer owns systems and the hard decisions inside them, and mentors the people below. The years attached to each level vary wildly by company, so the scope is the reliable signal.

Above senior, the ladder forks. One path stays technical: staff and principal engineers work at the scope of several teams or an entire architecture, shaping direction without managing anyone. The other path is management: an engineering manager trades most coding for responsibility over people. The fork is a change of profession rather than a promotion, and strong companies pay both paths equally. Tech lead floats beside the ladder as a hat rather than a rung: an engineer coordinating a team's technical work while a manager handles the people side.

Two more groups complete the cast. Quality assurance (QA) engineers and security engineers each own a property of the software across all the layers, and the lesson on QA, security, and the ladder covers both alongside the rungs in detail. Small companies then bend every convention: founding engineers, forward deployed engineers, and sales engineers are titles that describe a company stage as much as a job, and they close out the module.

With the full map in hand, a title plus three sentences of hiring manager description resolves to a real role: a layer, a pipeline step, or a rung, and a Tuesday you can describe back to a candidate accurately. The next station, reading the profile, turns from the role to the person filling it.