After spending 4 years working for a software agency that built websites and apps for other people I wanted to try out working for a software company that built their own product. I recently hit my two year anniversary at the product company, and I'm here to talk about what it's like to work in these two different environments.
First, some background on the two companies. Both companies are fairly small: the agency being about 25 people and the product company closer to 150. The agency has one office everyone works from, and the product company has a main office in the US, an office abroad, a satellite office, and several remote workers (like me). The agency is almost all developers with a couple sales people, project managers, one marketing person, and couple support staff. The product company has quite a few more non-developers: more sales people, product managers, a marketing department, a customer support team, and a managed services team.
You'll get more variety at an agency
Working on something you don't like? If you're at an agency, wait a few months until the project ends and you can start something completely new. At the agency, I worked on projects for organizations ranging from a local union to a Fortune 500 company. Many projects started as beautiful blank slates just waiting for my code. There's nothing like spinning up a brand new project. At the product company, I've spent the majority of my time working on the same application, which luckily for me, I enjoy a lot.
At an agency, you're closer to the people using your work
This is a pro and a con for both types of companies.
As a lead dev at an agency I regularly met with the people who would be using what I was building. It's obvious why less client interaction would seem appealing, and it definitely reduces stress and gives me more time to focus on coding. But it came with some benefits: firstly, I built connections and relationships with some of those clients. I practiced my communication skills. The biggest benefit was that working with them directly on their apps gave me insight onto how they were using them that I never would've gotten without talking with them directly. My user insights at the product company come second-hand from customer support team members or tools like Fullstory.
One of the best things about working at the agency was the feeling when you show the final product to the clients and they love it. You built what they wanted and you can get that feedback right away, which is more instantly gratifying than deploying something and waiting to see if the users are actually clicking on the right things.
It's easier to try new technologies at an agency (usually)
At the agency, we wanted to try typescript. When the next project came up, we used typescript. At the product company, people were curious about typescript. My experience was fairly positive. We decided next time we started a new product, we'd seriously consider using typescript. The opportunity to create something brand new from scratch with typescript has not come up. And even if we do, we know we might be working on that product for years to come--do we really want to commit to typescript? We also have to consider how much more difficult using typescript might be when on boarding new employees. There's a lot more to consider.
On the other hand, at the agency we wanted to use .NET Core. The next project came in and the clients were very technical themselves, and wanted us to use ASP.NET, because they were familiar with it. At the agency we often had requirements to use specific tools because the company CEO heard about it somewhere. Product users usually don't care so much what tech stack the software product is built on as long as it works.
Deadlines mean less at a product company
One of the biggest culture clashes I experienced coming from an agency to a product company was the difference in how deadlines are treated. At the agency, we had paying clients expecting certain things to be done by a certain time. Deadlines were written in stone. At the product company deadlines felt more like they were written in pencil.
At a sprint retro I expressed distress that we weren't going to meet a deadline for a particular set of features. I was told not to worry, the deadline had been removed. Deadline? Removed? These two words did not belong together. I learned that deadlines were often created somewhat arbitrarily and then ignored by the developers. I've worked with the team to help create a healthier relationship with deadlines: creating them based on estimates using team velocity and actually paying attention to them. I like having them not as rigid, but making them meaningless removes their motivation. Other product companies are likely more deadline-driven, but it doesn't compare to an actual customer expectation.
Product companies can be more agile
When I started at the agency, everything was pure waterfall. At the end of a project, we'd present this result the client hadn't seen before in its entirety and then wait for the long list of things we did wrong. It didn't work. I was (still am) a Certified Scrum Master at the time and I presented the concept of agile and the scrum methodology to the company. The agile concept was easy to sell: we needed to show in-progress work to clients sooner so changes could be made iteratively instead of reworking large pieces of a project at the very end. We tried out scrum briefly, but with clients paying for work estimated in hours and being billed by the hour, the company was very hour-focused and couldn't leave that behind. Instead, we developed a modified approach that worked better with prescriptive budgets and timelines.
At the product company, scrum is followed almost by-the-book. Occasionally we break the rules, but there's always a good reason.
Product companies can foster a stronger sense of ownership
I've been working on the same application for two years and I'm the tech lead for the product. It's mine. At the agency, I felt ownership of projects when I worked on them, but after handing them off to the clients and time passing, the ownership felt less immediate. It went from "this is my project" to "that was that app I built a couple years ago." It wasn't something I was working on improving anymore. This doesn't mean my current product is perfect: far from it. I'm constantly improving user experiences and adding new features.
What's Better?
I'm not here to say what environment is better. I love continuing to improve a product I know inside and out, but I miss the instant feedback of showing a finished app to paying clients.
Would you rather work at product company or an agency? Let me know your thoughts in the comments!
Cover image via the wocintech stock photo library.
Top comments (8)
This is not true, technologies used are always outdated due to existing heavily invested old systems and clients don't wish to invest huge on new technologies.
At product companies, new technologies are must, because products are being used by many users and you have to support all new technologies. At the same time, to innovate and bring new features in the product, new features are planned to fit well in new technologies.
Not everyone’s experience is going to be the same as my own. This was mostly true at the agency I worked for and the product company I work for now. (I did say “usually” and noted an exception that’s similar to what you described.)
Let’s say both companies have frontend engineers that are really interested in using Vue. They’ve researched and decided Vue is the best frontend framework at this time. (I’m not saying this is true; this is hypothetical.)
At the product company, the existing frontend codebases are all in React. The amount of effort to convert any one of them to Vue would be astronomical. The frontend would need to be entirely rewritten. The impact to users would be minor. Even if one was switched, it would mean frontend engineers at the company would need to be experts in both React and Vue. The product company’s best bet would be to start the next new product in Vue, but maybe the company’s more invested in improving old products than creating new ones. The likelihood that these engineers will be using Vue anytime soon is unlikely.
At the agency we used Angular. If we wanted to use Vue, we’d have to wait for a new project to start that Vue would be appropriate for. Given the rate of new projects coming in at the agency, this would probably take a few months. The new project could be done in Vue, and the engineers could reflect and determine if they want to continue and use Vue on the next project and or go back to Angular. (While I presented this as a hypothetical, this actually happened at the agency after I left. They use Vue now.)
But not every agency is just like the one I worked for—some clients might have more demands about what technology is used (see my example about the client that insisted on ASP.NET—but we were still able to use .NET Core in another project). Some product-based companies have more flexibility. There are also plenty of companies that don’t fit in the “agency” or “product company” boxes.
I've worked for several agencies and have friends who work for product companies and my experience is broadly the same as Alli's.
Sometimes in agencies you have to use a particular technology, sometimes you get to pick and choose. As long as you can justify it to management and the client, it's usually ok - but this includes the justification that it's ok to add yet another technology to the list you have to support.
I think that's mainly true for Indian agency-like companies. Not for other countries mostly.
Interesting! I’m thinking about going in and adding definitions of what I mean by “agency” and “product company” because it makes sense that they might not hold the same meaning everywhere.
In India, they're broadly categorized into service and product companies.
Product companies follow the same definition you've mentioned in your post, and service companies can be anything from web dev agencies/startups building stuff for other companies to mass recruiters like Infosys and Accenture, who recruit tons of students through campus placements(known as career fairs in America if I'm not wrong) from nearly every single engineering and tech college, and usually allocate them randomly to support and maintenance projects, while severely underpaying them. The starting salary at these companies has been the same since 2 decades!
These huge mass recruiting MNCs have development work too, but it's like 5% of what they do.
Hence, the crazy amount of Indian people grinding Leetcode and Hackerrank, and trying to get into top-tier companies.
The company I work at is both product and service. We have our own Ed-tech products, as well as we do tech consulting and build Ed-tech products for other companies.
This gets even more hazy when compared to my experience. I'm more of a contract labor to the company where I am located. My employer is an onsite/offshore dev/support company and making it even more removed from your two concepts is the fact that neither is marketing software to an outside client. I'm developing enterprise software to manage data in a fortune 100 company and may work on the same application for years or be moved to another one once my work is done. I have learned to enjoy it. Both of the scenarios you describe are nice but very different than I'm accustomed to. This is a very diverse industry and I think that makes for the ability to make whag you want of your career.
Yes, there are companies out there doing completely different types of things than the two I talked about in the article. I haven't worked for a company like yours but I'm interested in hearing about what else is out there.