Photo by Shridhar Gupta on Unsplash
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
Pros
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.
Stability
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.
Cons
Stagnation
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.
Agencies
Pros
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.
Cons
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.
I'd love to hear from the DEV community about your experiences with product and agency jobs, and which you prefer. Thanks!
Top comments (5)
Before starting Semaphore, our company was an agency. One of the biggest reasons we were bored with agency work is that, since we worked with startups and 99% of them fail, we'd always build only the v1 of everything. No experience of what's it like when things lift off.
The technical challenges of a growing product far exceed what we could experience as an agency. If something is outsourced it's almost by definition either not very challenging or not very successful yet.
If a product goes the distance the scale and stacks will change significantly.
You've mentioned "Being closer to the product owners" — in practice what makes an even greater impact is being close to product users. That gives a deeper sense of meaning to the work. (If not then you're definitely not for a product company. ;)
It's weird, I work for what is technically an agency but my job is more like the product one, because it is a long term external project. All the cons are there definitely, plus some cons from the second type as well and those are worse, in my opinion.
I decided that next I will try to work on a proper in-house product. I'll see how this goes.
Kyle, I've tried to write an article about this very subject. And I'm half glad that I didn't! This blew my working draft out of the water haha. I was an agency dev for a while, took a job at a product company and really struggled. The pace felt snail like, and I couldn't work with the technologies I wanted to because of the legacy code.
Very well put. Thank you for writing this!
There are pleanty of agencies maintaining legacy code bases. Some buy them for that reason alone.
That's true, and I've maintained a few legacy code bases in my time at an agency. However, the work is still contractual in nature, and maintenance/legacy agreements typically have concrete end dates as opposed to being indefinite as they are at product shops.