Should you build an in-house programming team?
Grzegorz Papaj, 4 October 2019
Should you build an in-house programming team?
In the age of computerization, there is practically no serious business that doesn’t rely on digital solutions. Nowadays, many companies use off the shelfsoftware available on the market. Nevertheless, with the growth and specialization of businesses, more often than not,the need to create a dedicated software arises (more about custom IT products this article: Custom-made applications – ten advantages). A dedicated software can be ordered from a supplier or createdby your own development team (if you have one).
It is better to build your own team of programmers or to hire a company?
When the decision about creating a dedicated software is made, the company faces a choice between involving an external company or hiring a programmer/programmers to develop the system in house.
Creating a programming department – advantages and disadvantages
Each of these approaches has advantages and disadvantages. In the first case, it is possible to choose between several models of cooperation (more about the you can read in the article – Cooperation models with software development company). In this article, we will focus on the second option – creating an in house team of programmers.
Understanding the needs
Creating your own programming department may give your company a lot of benefits. The most obvious one is assuring good understanding of your business needs. No one will understand the requirements and expectations of the company and employees better than an employee himself/herself. An in house programmer can be a great developer of dedicated software because this person works inside the company, has extensive knowledge about its internal processes and simply knows who to ask.
On the other hand, your own team can sometimes have a slightly distorted perspective. Routine and attachment to common procedures in the company can have an impact on the project decisions. Attachment to technologies is also a common thing. Mainly because if the members of the team know and like them, they are eager to use them, even when those technologies aren’t an optimal solution for a given problem. This is one of the reasons, some companies hire external consultants as they can objectively calculate possible returns of using different solutions.
Another argument for building your own dev team are costs. It is obvious that when both you and a programming company employ a programmer with the same market salary, the second one has to add their the margin to the programmer’s hourly pay. Thus, the cost of the employing a programmer is much lower than outsourcing one.
Nevertheless, the supplier takes on other costs like the burdens of the recruitment process, ensuring continuity of team’s work (e.g. replacements in case of illness) or administration. These costs can be difficult to estimate, as they are easily overlooked, but it is worth remembering about them in bottom line.
Unfortunately, employing a programmer involves a number of risks. The biggest one is hiring a person with inadequate qualifications. This risk is specially high, when hiring the first IT specialist in company – without a trusted person with great technical knowledge and skills it is extremely difficult to verify abilities of a new programmer. Even with the help of an experienced coder, it’s still easy to make mistakes in this field (soon described in detail in a separate article).
As most companies start to build a programming department by employing only one employee, the risk significantly increases. Moreover, other risk factors appear in one-person programming departments. Here are some that we have observed in our clients:
- incompetence to conduct large projects – a programmer, who is good at small projects, doesn’t have to be able to deal with big systems;
- lack of continuity of work – when the programmer isn’t available for a long period of time (for example because of an illness), the projects development is suspended;
- attachment to nonoptimal technologies – programmers tend to use known and liked solutions and don’t always care about expanding their knowledge of new technologies;
- experimenting – the programmer uses a company project to learn a new technology (often these are quite “exotic” technologies for which there are very little specialists available on the market);
- no control – basically no one in the company knows what programmer is doing and whether they’re doing it right or wrong;
- focusing all project knowledge in one person can become problematic when the programmer leaves the company.
The last four points often lead to situations which we described in one of the previous articles: IT Systems – unusual problems.
Flexibility is one of the most important factors which decide about successful or unsuccessful launch of a software in your company. Usually working with your own team lets you achieve high flexibility – after all the boss or management decide about the direction and scope of the programming work. They aren’t bounded by any contract which would have to be renegotiated or even sometimes abandoned. However, at this point it is worth mentioning that there is a chance for flexible cooperation in the case of programming services supplier (about which we wrote in an article: Cooperation models with a programming company).
On the other hand, hiring a team is a long-term liability. Dismissing a company’s employee is never an easy or pleasant thing to do. It’s much easier to terminate a supplier’s contract than letting go of a team member, which can impact the whole team. That’s why if you don’t have plans to constantly develop software in your company, it’s probably better to think about outsourcing.
Choosing the right technology for a project is another aspect of flexibility. As it was mentioned above, the programming team tends to prefer technologies known to them, which are not always best suited for the situation.
However, if you decide to create your own programming team, it is worth knowing that it takes time and involvement to build a good team (this applies to not only programming). Selection of candidates, verification of their skills, training (both in used technology and in company’s procedures), team management and solving current problems require a lot of work.
One- or two-person teams often work directly “under management”. But if the team is bigger, it becomes necessary to have a trusted manager. taking care of administration issues and etc., letting the management focus on strategical goals of programming department. Unfortunately, finding a good IT manager is even harder than finding a good programmer.
We described the key characteristics of a programming team manager in the article: Three pillars of a good IT project manager.
When considering building a programming department in your company, you can expect that:
- the company’s needs will be well understood,
- the direct costs of employment will be lower,
- project management can be more flexible.
At the same time:
- there will be a number of risks associated with employing incompetent people,
- there will be less flexibility in the selection of technology,
- creating a team requires time and costs (of recruitment and administration),
- hiring employees is usually a bigger commitment than working with an external supplier,
- at some point a manager will be needed.
So, is it worth to build your own programming team? Mostly it depends on the company’s situation, planned launch or future course of development. There isn’t one simple answer for everyone.
Nevertheless, when you have never conducted a programming project, it is better to hand it over to a competent supplier. This way you can also learn valuable information about IT projects from the supplier and later use it to build your own team if you want to.
It is also possible to try a “hybrid” approach and start by hiring an in-house manager who will supervise and direct the work of an external team. With a proven candidate for this position, this can be a good solution for the beginning. After all, even specialized programming companies sometimes use suppliers.
Finally, if we think that one programmer will meet our needs, it is usually better to think about an external supplier in order to avoid administrative costs