Building software without hiring anyone

A number of enterprises in Finland rely heavily on external contractors for software development even though the software is a core part of their business. Often the product owners, project managers, and possibly architects work for the company, but the designers, developers, ops, QA specialists, and data scientists work for consulting companies.

Contractors are the obvious choice when you need extra staff quickly or when you need someone with skills that your organization does not have.

For example, many years ago when I worked at ZenRobotics, none of us were experts in building user interfaces. Our product, the robotic recycler, needed a control panel, so we hired a consulting company to build it. I wasn’t too happy with the result back then¹, but the premise still makes sense to me.

But why use contractors as the backbone of your software development organization? I have a couple of educated guesses, but lacking insider knowledge, I’m going to keep them to myself for now. Instead, I’m going to highlight a couple of oddities compared to the more traditional solution of hiring people.

Teams are thrown together. When the client needs more hands, there’s no hiring process. Instead, there’s either a sales process or a public tender. The client has little agency in picking the specific persons they want - the consultants are assumed to be interchangeable.

On the upside for the consultants, if you work for a company with a good reputation, you’re assumed to be competent. Bullshit interviews and whiteboarding are much more rare.

Contractors are second-class citizens. You may be excluded from internal communications, meaning that nobody will tell you about the client’s product strategy, or the upcoming office renovation - even though you may work at the office every day² for years. They’re even less likely to ask your opinion.

If you’re driven to build great products, you can still do that as a contractor, but it’s hard to have the same level of ownership as an employee could have. I think this is partially because contractors exist outside of the organization chart, so they cannot “officially” own anything.

People management is weird. In the traditional setup, if you are an individual contributor (IC), you’d have a manager who is your boss and whose responsibilities include supporting you and your growth.

In the consulting setup, you don’t have a people manager at the client. There is probably a some kind of project manager, but its not their responsibility to support you. You probably have some kind of boss at the consulting company, but typically they have very little insight into the day-to-day work at the client and they cannot support you.

You may end up in a team where no two people have the same employer, which makes peer-to-peer support harder to establish.

Incentives are weird. Let me crudely over-simplify: the contractors do not have incentives to ensure the business success of what they build, but they may have incentives to generate more work for themselves and their company. For employees, the incentives are opposite.

My point is: from the day-to-day perspective, building your software development organization on contractors is not an obvious recipe for success. I’d like to understand why it is so big thing in the Finnish IT scene.