Software development: make or buy?

As more and more digital offerings have to be created, the “demand” for developers has increased enormously. I often see larger companies toying with the idea of building internal teams for their platform projects instead of relying on external service providers. This may or may not work out well. In fact, it often goes wrong. Ironically, however, very few management decision-makers realize this. Mostly because they simply don’t know enough about software development.

(Reading time 4 minutes)

In theory, the matter is clear: it is cheaper, more direct and therefore easier to assign an internal team of software developers to a project. The labor costs are usually 50% of the price you would have to pay an external service provider. The teams are available at all times and there are no change requests.

The dream of having your own team ends in “endless storming”

Unfortunately, the reality is all too often not so great. Since in-house development in large companies is notorious among really high-caliber developers (because of the old-fashioned, tedious culture, alpha-dominance, etc.), usually only the B-selection is found. So the ones who are either not very good or the ones who just come for a high salary (which, by the way, is about as bad).

The perfect ingredient for such a team is usually a product owner who knows a lot about nothing. In other words, they have virtually no development experience themselves, but think they are the ideal person for the job. Such people usually also think that they are great motivators. In reality, however, they just stand in the way of the few capable people, figuratively speaking.

This mixture means that a team never gets beyond the storming phase. And as the frustration and the constant poaching of developers lead to a high level of fluctuation, the team remains there.

It goes without saying that deliverables are produced that are somewhere between unusable and inadequate. Or, more rarely, the quality is ok, but it simply takes an infinitely long time. “Real Artists Ship” also applies to teams.

Of course, my example is exaggerated ad absurdum. But it is essentially true. Unfortunately, many “customer teams” have just such problems.

Nearshoring for the win. #NOT

I now get a real sense of schadenfreude when company representatives announce that they are “launching” an external development team abroad. I can always mark it in my calendar: 18 months later, they regret the venture. Not necessarily financially, because developers in the East in particular continue to work on very favorable terms. But the results are usually very poor. This does not mean that there are no very good developers there. In most cases, however, the most talented ones are drawn to Europe or America in the long or short term.

“There are no shortcuts to places worth going

”
My experience with various nearshoring teams shows that it can definitely work. But you have to take care of it. That means being on site every two weeks, getting involved, looking after the people, integrating them. And developing the product together. The naive idea that you can simply send a concept down and get a finished product “for testing” is complete nonsense.

The killer CTO

But there are also customer teams that work. From my point of view, you need one thing above all to build an internal dev team: a really excellent CTO. Many people will now think that an excellent CTO must be a genius. Someone who intuitively designs solutions and can program incredibly quickly and well. I think that’s wrong.

Above all, the perfect CTO must be able to deal with developers. He must be able to motivate them in a natural way, he must be popular, he must be able to recognize real quality at lightning speed (a quality that generally gets you far), he must be interested in non-technical matters and he must be able to solve many problems at the same time. And yes, of course he has to be an above-average developer himself. This is a combination of skills that is very, very rarely combined in one person.

So if you are thinking of building your own team, look primarily for this CTO. Once you have him or her, and probably have to pay a ridiculously high salary, everything will suddenly become easier. The high salary will already be put into perspective when you acquire additional team members. Instead of having to pay a commission to technically underqualified recruiters, your CTO will simply bring the core team from their last employer with them. This is bad for the old company but good for you. Such a team quickly reconnects and is able to quickly communicate its culture to new recruits. The team delivers quickly and thus reduces the time to market.

Alternative models: Team & Method

An alternative to building your own team is to buy one. Only a few service providers offer this, including us at AOE. This is not body leasing or outsourcing, but the service provider makes an experienced team available via a budget retainer. However, the service provider does not become a mere biller, but develops the team further, takes care of know-how transfers from other teams and ensures that velocity and quality remain high.

For you as a customer and product owner, it feels like having your own team. Simply without the hassle that having your own team can bring: Internal disputes, fluctuations, a certain degree of sick leave, training absences, etc.

The service provider takes care of this for you and, as it has many years of experience in this field and also offers the team a physical environment in which it can develop, there are not even any personnel infrastructure costs.

I did full cost and comparative calculations last month. These show that, including quality and time to market, the Team & Method model is also ahead in terms of costs.

Hybrid model? Yes, please.

Of course, both models, i.e. Team & Method and own team, can also be combined. For example, to enable a quick start, the foundations for a platform are developed with a service provider team and new developers are recruited at your leisure. Ideally, they should be “tested” by the purchased team to ensure that their understanding of quality, skillset and culture are a good fit.

In this way, an internal team can be “set up”. If the original team, consisting of internal and external developers, then becomes too large, two teams are simply created. Ideally, these should then be split into internal and external employees.

In this way, you can create a good internal team without having to sacrifice high-quality performance during the development phase. And that’s basically what it’s all about.