Who works on a software team?

Who works on a software team?

A software team is a small group holding three kinds of people: a product manager, a designer, and engineers. Each kind owns a different decision. The product manager decides what gets built. The designer decides how it looks and how a person moves through it. The engineers decide how it works.

The sprint rhythm already covered how this group moves through a week. This lesson covers who is actually in the room when a feature gets decided, because every engineering title in this module describes a seat at that table. Once the three decisions are clear, the titles that sound alike start to separate on their own.

Who decides what gets built?

The product manager decides what the team builds and in what order. They talk to customers, read usage data, weigh company goals, and turn all of it into a ranked list of work. In practice that means they own the backlog: they write many of the tickets, they order them, and they answer for whether the finished work moved the numbers it was supposed to move.

A product manager does not write code, and they are not the engineers' boss. Engineers report to an engineering manager. The product manager holds authority over the what and the why, and the engineers hold authority over the how. When those two authorities disagree, the disagreement itself is normal and healthy, and a candidate who describes pushing back on a product manager is describing an ordinary Tuesday.

The title travels under several names. Some Agile shops say product owner. Many resumes shorten it to PM, which collides with project manager, a coordination role that tracks schedules without owning the what. Reading which one a resume means takes one look at the verbs: a product manager decided and prioritized, a project manager tracked and unblocked.

Who decides how it looks?

The designer decides what each screen looks like and how a person moves through the feature. Before any code exists, they produce mockups: detailed pictures of the screens, plus the flow that connects them. Which button sits where, what happens after a tap, how an error gets shown, where a new user goes first. The team argues about the design at this stage because changing a picture costs an afternoon and changing built software costs weeks.

Titles here split by focus. A product designer or UX designer owns the flow and the reasoning behind it. A UI or visual designer leans toward the surface: color, type, spacing. A UX researcher studies how real people get confused, and feeds that back into the mockups. At small companies one person wears all of these hats, so the title on a badge says less than the size of the company behind it.

Who decides how it works?

The engineers decide how the feature works. Given the what from the product manager and the look from the designer, they choose everything underneath: what data gets stored, how the backend answers requests, how the screens stay fast, and how the new work fits the existing codebase without breaking it. They also say how long it will take, which is why scope gets negotiated with them rather than announced to them.

One title belongs in this lesson because it names a posture rather than a layer. A product engineer is an engineer who works close to users and close to the what decisions: they sit in the customer conversations, sometimes propose the feature themselves, and care more about whether people use the thing than about the machinery under it. Companies that use the title are signaling they want engineers who think like the product manager thinks, and candidates who use it are signaling they want that kind of room.

How is a frontend engineer different from a designer?

Both work on the screens, which is why the two get confused, and the split is clean: the designer decides what the screen should be, and the frontend engineer builds it in code so it works on real devices with real data. A mockup shows one perfect moment. The built screen has to handle every other moment: the data still loading, the request failing, the list empty, the phone small, the connection slow. That gap between the picture and the working web app is the frontend engineer's entire job, and the two roles hand work across it constantly.

The tools differ too. A designer works in design software and produces images and prototypes. A frontend engineer works in an editor and produces code that ships. A candidate for one role shows a portfolio of flows and reasoning. A candidate for the other shows working software.

What is a squad?

A squad is a small standing team formed around one area of a product: a handful of engineers, a product manager, and a designer, all pointed at the same slice. A payments squad owns checkout and billing. A growth squad owns signup and onboarding. Companies also call this a product team, a feature team, or a pod, and the words are interchangeable.

The reason the structure exists is that all three decisions from this lesson happen faster in one room. The word engineers use for it is "cross-functional": the group holds every function needed to take a feature from idea to shipped without waiting on another department. When a candidate says "my squad owned search," they have told you their product area, their likely teammates, and the scale of what they answered for, all in one sentence.

What is a discipline?

A discipline is a broad area of engineering work: frontend, backend, infrastructure, data, mobile, security. It names the layer someone works at, and it says nothing about their level. A junior backend engineer and a twenty-year backend veteran share a discipline.

Disciplines matter because they are the real unit of an engineering search. A req is looking for a discipline first and a title second, and most of the confusing titles in this module resolve into one once the layer is visible. The rest of the module walks the map: the frontend, backend, and mobile lesson turns the layers into careers, DevOps and SRE cover the machines, the data quartet covers data, and the ladder lesson adds the vertical axis of seniority over all of them. The module guide holds the whole picture on one page.