The Team Around the Code
Software is almost never built by one person alone. Behind any real app stands a small crowd — and most of them never write a line of code. Knowing who does what is how you read a team, understand a job posting, and find your own place in it.
Think of a film. The actor on screen is one role among dozens: there are writers, a director, camera crews, editors, and sound engineers, all shaping what you finally see. Software is the same — the developer is the visible role, surrounded by people who decide what to make, how it should look, and whether it actually works.
The roles below aren't rigid job titles every company uses identically — small teams blur them, and one person often wears several hats. They're responsibilities that exist on every team, however they're divided up.
More Than Developers
It's tempting to think developers decide what to build. Usually they don't. That decision sits with the product side, and a whole chain of people shapes the work before and after the code is written. Here's the cast, grouped by what they own.
| Group | Roles | Owns |
|---|---|---|
| Product | Product manager / owner, business analyst | What to build and why |
| Build | Developers (frontend, backend, full-stack), designers | How it's made and how it looks |
| Quality & run | QA, DevOps / operations, support | That it works and stays up |
| Stakeholders | Customers, management, legal | The needs the software serves |
The Four Sides of a Team
The product side decides direction. A product manager or product owner figures out what's worth building and in what order; a business analyst digs into the details of what's needed. They turn fuzzy wishes into clear work for the team.
The build side makes it real. Developers write the code — some focused on the frontend, some the backend, some both. Designers decide how it looks and feels so it's usable, not just functional. This is the role most people picture, and it's one group among four.
The quality and run side keeps it honest and alive. QA (quality assurance) makes sure it actually works before users see it. DevOps or operations people get it running and keep it up. Support helps the humans using it. These roles are why software keeps working after launch, not just at the demo.
Stakeholders, and Where Code Comes From
Stakeholders are everyone with a stake in the outcome but no hand on the keyboard — the customers who'll use it, the managers paying for it, sometimes legal or compliance teams. They rarely agree perfectly, and a big part of building software is balancing what they each want.
And not all software is written in-house. A team can build it themselves, buy a ready-made service (often software rented over the internet, called SaaS — software as a service), or adopt open source — code that's freely shared for anyone to use. Choosing not to build something is often the smartest engineering decision a team makes; we return to open source and licensing near the end of the course.
Now meet the team you'll follow all book. Priya is the product owner — she decides what Cadence should do and why. Marcus and Lena are the developers who build it. Nora is QA — she makes sure it works before users get it. Theo, a designer, lends a hand on how it looks. And surrounding them are the users who never see the code but depend on it every morning. Four people and their users, building one app — that's the cast for everything ahead.
- "Developers decide what to build." Usually the product side does. Developers shape how it's built and flag what's hard, but the what-and-why is generally someone else's call.
- "QA just clicks around looking for bugs." Quality assurance is its own engineering discipline — designing how software is tested, not idly poking at it. A whole later chapter is devoted to it.
- "A real team builds everything itself." Mature teams buy and adopt as much as they build. Writing code you could have rented or reused is often the wrong choice, not the impressive one.
- Knowing the roles lets you read any team's structure and understand who owns what — invaluable on your first day, and when deciding where you fit.
- It sets up the Cadence cast you'll see in every chapter, so the practices land on real people instead of floating abstractly.
- It reframes "developer" as one role in a collaboration — which is exactly the mindset the rest of the course builds on.
Knowledge Check
On a typical team, who usually decides what gets built?
- The product side — a product manager or owner
- The developers themselves, since they are the ones who actually write the code
- QA, since they test the software
- The designers, since they shape how it looks
Which best describes the QA role?
- An engineering discipline that makes sure software works before users see it
- Someone who randomly clicks around the app hoping to stumble onto bugs by chance
- The person who decides what features the product should have
- The role that writes most of the application's code
A team needs a feature that an existing paid service already provides well. What does this topic suggest?
- Buying or adopting it can be the smarter choice than building it themselves
- A serious team should always build everything itself from scratch to prove its skill
- Using outside code is cheating and should be avoided
- Only managers may decide this, with no input from the engineers
You got correct