On Four Types of Development Companies

When companies are looking for developers, they tend to focus on technicalities: what language, frontend, backend, devops, or “do everything yourself” full-stack.

What is often omitted is what type of company you are going to work for. This is problematic as it can affect your work much more.

Cost Center or Revenue Center

All businesses¹ allocate people into two categories: cost and revenue centers. In short, cost centers are the “infrastructure of the business” that makes it function, and the goal here is to keep it as frugal as possible. Putting in more money just means spending more money.

Revenue center is why your company exists and produces whatever value you are charging for. In a functioning company with a working business model and a sufficiently large market, spending more money should give you even more money back.

Good companies know this doesn’t mean driving cost centers to the ground. Good infrastructure is a productivity multiplicator and bad infrastructure is a frustration plague (excellent infectivity, high mortality). Yet when the time comes for hard decisions, you can guess where the company saves money first.

The Company Types

I only list companies that make development part of their business (aka revenue centers). I hope it helps you pick the one you’ll thrive at.

The Glorified IT Department

A decade ago, this would be a cost center and a part of the infrastructure, allowing the company to do its business well. But then CEOs started throwing the digital transformation buzzword around and a decade later, the word starts to have a meaning. The core business is trying to merge with the digital environment and the IT department helps with it. The first attempt at recognizing the new world is usually just transferring the original business into a computer form and realizing only later on that it needs to do the “digital native” version. In some cases, this will lead the company to become The Product Company (see below; a good example of this transformation would be Netflix; a good example of companies refusing the digital native world initially and then being forced into it very quickly by disruptive competition would be banks).

Here, your work is mostly handed over to you in the form of requirements since the domain experts are elsewhere. If the IT department itself wasn’t transformed, you may also encounter continuation of past trench wars where IT was the service department for others.

This is a good training ground. Having other people care about the product means you can focus on technologies. Those companies often have historically outsourced a lot of their digital competencies, hence you may do a lot of integrations and ETL work. Boring to senior, it can be a good opportunity to learn your trade as well as the discovery of various business systems.

Avoid if you want to have a significant say in the product.

The Digital Agency

This comes in two flavors: the one-time product and the body shop.

In the former, the company asks for a site or system and wants it delivered for an agreed-upon price to specified requirements. In the latter, you (or more often, your team) are subcontracted to another company to help them get their job done.

Both share a similar environment. You rarely work on one thing for a very long time. Deadlines are flying around and you are expected to meet them. A single client is a king to be satisfied and you may have limited capability to decline their wishes, however quirky they may be.

There is an opportunity for greenfield development, which gives a chance to pick up new technologies. A project may be a one-time wonder, which means mistakes can be covered with duct tape and forgotten about. Having a new project every few months means you can cover a lot of ground in terms of learning various job positions and expertise, as well as technologies.

Avoid if you prefer long-term investments and seeing your projects grow. I’d also skip if you want to have a larger say in the product and hate doing something “because the client insists”. I have also seen more late-night pushers here than in other companies as you can’t compensate for deadlines that are too tight through other business means. You may also need to work with client’s systems that can be their own category of abominations.

Note that some companies try to look like The Product Company and advertise their own product, but end up being a digital agency since they need to customize a product for each and every customer. Those are a special crossover and different teams are essentially different companies. There is usually a significant tension between the teams that develop the shared part of the product and the customizations.

The Product Company

The company develops a product that is sold to customers. This is what most people mean when they say “tech company”. The product is developed for years and decades and offered to all customers as-is with minimal custom development.

Even more than elsewhere, your experience will depend on company size. The smaller the company, the larger your influence on the company itself, on the product, and a chance to have a broader set of responsibilities. The larger the company, the more of a chance to gain deep-to-worldwide expertise in a very narrow field, the higher chance of having a well-prepared and well-paid career path, and a larger set of truly world-class colleagues².

In any case, this is an excellent choice if you prefer to work on a single thing and see it grow. It’s also great for learning sustainability and maintenance since if you stay around, your past mistakes are guaranteed to hunt you down.

Avoid if that is your definition of hell you’ll get bored to death in. Also, reconsider if you don’t like the product itself. The long term also means you may be limited in technologies you can use and doing changes may be hard. There is also usually some legacy code dragon hidden somewhere, the one that runs half of the business, but burns everyone who dares to touch it. You may need to get along.

The Data Crunchers

A relatively new addition to the list is people running the numbers and data visualization business. The previous iteration often was a pie chart created by a journalist through their wizard in PowerPoint or the most widespread information system in the world: the CFO’s Excel sheet.

Yet as both companies and media are going digital, the data insights and data visualizations are becoming part of the business itself, part of the package customers buy.

In a way, this is the form of “internal body shop”. Your work is usually driven by other people and asks for random, short-term projects (sometimes in the form of literal overnighters). You often have complete freedom in how to do the interactive microsite for the launch or figure out the proper graph before the paper goes to print.

This is a good pick if you want a lot of variety in your work and you like to self-organize. You will also get a lot of insight into other domains that work well if you run on curiosity. There is a lot of hacking and one-time work and your code may be composed of duct tape only.

Avoid if you hate throwing your work away or want a fixed schedule in your life. This also calls for a particular specialization and you will not have a chance to learn much more, development-wise. You should also be senior enough to be able to complete the tasks on your own since your team will probably be split among a lot of projects and not a lot of mentoring may be available.

Pick Your Poison

As always, there is no good universal answer. I hope this list helps you figure out what’s right for you.

Good luck.

Thanks to Honza Javorek for inspiration and feedback.

---

1. If they don’t do it consciously, they do it as a byproduct and that’s usually not a good sign. I am including non-profits here as well since they also optimise on revenue, which is just not produced in money. ↩︎

2. Yes, small companies are founded by top-notch people as well. But corporations have more cash to give world-class people the world-class compensation and it’s hard to monetise a lot of narrow expertise on a small scale. This is especially true for infrastructure-related expertise. ↩︎