Get in touch
Because more and more digital services are needed the demand for developers has increased enormously. Often my experience is that larger companies are considering establishing internal teams, rather than retaining external service providers, for their platform projects. This can work, but doesn't necessarily have to. Actually, it often goes wrong; something which, ironically, the fewest management-level decision makers realized. Most often because they simply know very little about software development.
The matter is clear – at least in theory: It's cheaper, more direct and therefore easier to assemble an internal team of software developers for a project. Salary, as a rule, comprises 50 percent of the price one would have to remit to an external service provider. The teams are always accessible and there are no change requests.
All too often, reality isn't quite as positive: Since in-house development in large corporations enjoys a rather negative reputation with highly qualified developers (due to an old-fashioned, tedious culture, alpha-dominance, etc.) one usually finds only second-string team members. That is, those who either aren't that good or those who simply come because of high salary (which, by the way, is almost as bad).
The perfect ingredient for such a team is then usually a product owner who knows a lot about nothing. In other words, POs that have next to no development experience, but consider themselves ideally suited for the job. Most of the time these people also think they are terrific motivators. In reality, and to tell the truth, they are usually literally standing in the way of the few truly competent people.
The result of this combination is a team that never gets beyond the Storming Phase. And, as frustration and the permanent recruitment of developers lead to a high churn rate, the team remains locked in that phase.
That this leads to the production of deliverables that are somewhere been useless and inadequate goes without saying. Or, something which is quite rarely the case, the quality is ok, but it simply takes an endlessly long time. “Real artists ship” goes for teams as well.
Of course my example is absurdly overdrawn. But in applies in its essence: Unfortunately, many “customer teams” have exactly such problems.
I'm overcome with a certain level of spitefulness when company representatives loudly announce that they will establish a team abroad. I can immediately write it in my calendar: They will regret this step 18 months later. Not necessarily financially, as developers – especially in the East – still often work at extremely favorable terms. But often the results leave a lot to be desired. This doesn't mean that there aren't very good developers there. Usually, however, the most competent move to Europe or North America sooner or later.
My experience with different nearshoring teams shows that it can work. But you have to take care of the team. This means being on-location every two weeks, getting involved, dealing with the people, integrating oneself. And continuing to develop the product together. The naïve idea that one can simply send over a concept and then get a finished product “for testing” is utter nonsense.
But they do exist, those customer teams that work. In my opinion one primarily needs one thing to assemble an internal dev team: A truly excellent CTO. Many will now think an excellent CTO must be a genius. Someone who can conceptualize solutions intuitively and is an excellent and quick programmer. I think this approach is wrong.
The perfect CTO, first and foremost, must be able to deal with developers. He must be able to motivate them intrinsically, he must be popular, he must be able recognize real quality extremely fast (a trait that generally helps in one's rapid advancement), he must be interested in non-technical issues and he must be able to concurrently solve many problems. And yes, of course he must be an above-average developer himself. This combination of capabilities is found only rarely in a single individual.
So, if you are thinking about building your own team, you should primarily be looking for just such a CTO. If you find him, and you will most likely have to pay him a ridiculously high salary for the privilege, everything will abruptly become easier. The high salary will already make itself paid when acquiring new team members. Instead of paying technically underqualified recruiters a provision, the CTO will bring along his core team from his last employer. This is bad for the last company but good for you. Such a team finds common ground very fast and is able to quickly convey its culture to newcomers. The team rapidly delivers, thus reducing time-to-market.
One alternative to building an in-house team on your own is the possibility of acquiring such a team. Only few providers offer such service, we at AOE among them. This is not body leasing or outsourcing, but rather a service provider putting an experienced team at your disposal through a budget retainer. However, the service provider does not degenerate to a pure invoice issuer, but rather develops the team further, handles know-how transfers from other teams and ensures that velocity and quality remain consistently high.
You, as customer and product owner, are given the impression of having your own team. But without the hassles that an own team can bring to the table: internal conflicts, churn, a certain degree of time lost through sick leave, lowered productivity through continuing training, etc.
All this is covered by the service provider and since he has many years of experience in these matters and can also provide the team with an actual physical work environment in which it can further develop as a team you won't even have any personnel infrastructure costs.
I made some total absorption costing- and comparative calculations last month regarding this issue and found that, if one takes quality and time-to-market into consideration, the Team & Method model is also in front in terms of costs.
Of course both models, Team &Method and the internal team approach, can be combined. Like this, for instance: To guarantee a rapid start one works out the basics for a platform with an external team from a service provider and then recruits new developers in peace and quiet. Ideally, one lets the acquired team “test” the newcomers and thus ensures that the understanding of quality, skillset and culture fit together.
In this way one can form an internal team. If the original team, comprised of external an internal developers, becomes too large, than one simply forms two teams. Ideally, these are then separated into internal and external team members.
Thus, you build a good internal team along the way, without having to forego qualitatively high performance during the establishment phase. And this is basically what it is all about.
