Software Engineering Jobs: Product Teams vs Agencies

Comparing two common engineering job archetypes

In the software engineering industry, it’s common to divide jobs into two broad classifications: product and agency. A product job involves working for a company who sells or actively develops some software product that’s consumed by end users. The company owns the product, and the product in some way contributes to the company’s bottom line. An agency job, conversely, involves working on a contractual basis for a multitude of clients. A development agency might specialize in a few smaller markets, but typically the work load is more broad and is spread across a number of clients.

Each of these classifications comes with its own set of benefits and detriments, of course, and you’ll find developers that prefer one over the other. It can be hard to know exactly what each kind of job entails without a large amount of experience on both sides of the divide, but let’s break down some key pros and cons for product and agency jobs.

Product Companies


Identity and Ownership

Because product teams focus on delivering core business functionality and impacting the company’s bottom line, they typically encourage a strong sense of team identity and product ownership. It’s easier to feel connected to the software you’re building when there’s a clear sense of how it impacts the company for which you work. Product teams are also typically more visible and in closer communication with core business stakeholders. Being closer to the “product owners” allows engineers a clearer vision of how their solutions further the mission of the company.


Product teams offer an environment with less variation than most agency jobs. Because there’s one core product or business identity, there’s less variation in the categorization of the solutions and products the engineers build. For example, a SaaS company that sells marketing and advertising software is typically going to create software solutions related to marketing and advertising software. There’s less room for context shifts with product teams, and engineers are able to retain and transfer industry knowledge between teams and products.



Although some product companies encourage moving around between teams or projects, it’s not always feasible for every engineer. A lot of engineers will work on a single project year after year for most of their tenure at a product company. To some degree, this affords the engineers stability as mentioned above. However, it’s easy to fall into a rut and to feel stifled without a dynamic environment.

Legacy Code

Along with personal stagnation, product companies own their codebases for as long as they exist. This means, as an engineer, you’ll likely be maintaining code that was written previously by current or former engineers from the company. “Legacy Code” can sometimes be misrepresented as a four letter word in the software engineering world - it’s not always bad. There are plenty of well maintained, well documented “legacy” code bases serving enormous user bases across the world. That being said, there are just many spaghetti codebases without tests. Your mileage may vary here, but know that at a product company you will likely be inheriting at least some code.

A Static Stack

Since product companies have full ownership of their technology, the stack and solution architecture tend to be somewhat set in stone. A good product company will always strive to find the right tool for the job, but there will likely be less room for tinkering and working with bleeding edge technology. Whether this is truly a con might be subjective. Some developers lament “fatigue” and early adoption of new technology, but others relish in the opportunity to work on the cutting edge.



Fast paced, dynamic environment

Agencies tend to work a lot faster than average product companies. When companies contract out work, they’re typically looking for shorter implementation timelines in order to minimize their risk. Because of this, projects tends to move a lot faster. If you’re someone who can be annoyed by overbearing working processes, meetings, and red tape, this might be a selling point for agency work.

Freedom of exploration and experimentation

Where product companies typically hold at least some loyalty to a specific toolchain or technology stack, agencies can be more willing to experiment and explore multiple technology options. Unless the agency is highly specialized (e.g a WordPress shop or a Rails consultancy), the technology choices will typically be more tailored to individual clients and projects, and so you might be exposed to a wider variety of technologies.


Difficulties with ownership

Since agencies work on a contractual basis, projects have a set end date. When projects are over, development stops. Some agencies will take on longer term maintenance work after a project’s delivery, but this maintenance work is frequently contracted to another, often offshore, company instead. It can be hard to find a sense of ownership and pride in a project that will be handed off in the relatively near future.

Shorter timelines, tighter budgets

Another issue with contractual work is a more fixed budget - in terms of time and money. When projects have a concrete delivery date, it can lead to crunch time and overwork. A good agency with an effective working process won’t run into these issues, but the environment around fixed budget and fixed timeline projects can be more conducive to “death marches” as deadlines draw near. Look out for unpaid overtime, lofty promises, and unreachable deadlines.

There are developers that prefer product companies and there are developers that prefer agency work. I’d recommend working a job from each paradigm if possible throughout your career, as each environment has a lot to offer in terms of skillsets and experience.

This is not an exhaustive or definitive list! I know there are product companies with tons of room for internal research and development, and I know there are agencies with iron clad working processes and solid contract hand offs. These are just a few things I’ve noticed in my few years of experience, and some things I’ve heard from other developers.