Latest News

Reorganising a Software House: How To Change Its Technological Profile and Choose a Specialisation on the IT Market?

Every software company has its own technological profile. It is often the case that for technical people this is more important than the company’s domain profile. This is because IT developers rather see themselves through the prism of the technology in which they work, e.g. I am a programmer of systems built in C#. However, whether they are doing a project for a company dealing with training or producing boxes is of secondary importance. Of course, domain knowledge is always useful to programmers, but it does not change their perception of themselves through the technological dimension – says Robert Marek, Co-founder & CTO at FINGO.

FINGO is a Polish software house that has been providing programming services for over 20 years. In 2022, the organization successfully changed its technological profile. In addition to the offered programming services in Java and .NET technologies, it added Node.js and has completed all projects created so far in PHP.

Why was this move made? What does the process of self-organizing change look like? And what was the result? Find out by reading our interview with Robert Marek.

Before we start talking about the process of changing the technological profile itself, could you tell us what the company looked like before its reorganization?

If you follow FINGO’s 20-year portfolio, you will find projects for the financial, real estate, automotive, e-commerce and many other sectors, which are more or less related to each other. It is a bit of a coincidence – over the years such projects have appeared, and we have been developing our team. But this state of affairs was largely influenced by our technological profile (Java, .NET, PHP), under which we were looking for further orders.

However, I felt that it was not good for our business. A large technological spread is generally not good for a software house the size of FINGO. It may be easier to find a project, but more difficult to ensure the exchangeability of people. I’ll give you an example. Suppose you need 5 developers for your project. There are 6 people sitting on the bench, but only 2 know the technology required in the project. This state of affairs means that there are still 4 highly paid specialists out of work, for whom you need to provide work. On top of that, you need to make 3 people familiar with the required technology to ensure the project is staffed.

Nevertheless, the comfort of having a well-functioning business prevented us from implementing the changes. We had projects, regular long-term clients, and experienced programmers. In such an environment, it is difficult to make the decision to start changing something.

So what made you decide to change the technological profile at FINGO?

At the beginning of the pandemic, the market froze. Companies, not knowing what would happen next, refrained from continuing current projects or starting new ones. It was a time when even programmers feared losing their jobs. We wondered what to do. We didn’t want to lay people off, but on the other hand, we needed something that would make us stand out from the crowd.

In around May 2020, as the owners of the company, we found that without making bold decisions, the situation may deteriorate. We had the most projects, and therefore experience, in the financial sector. In addition, we had a product part that offered software that enabled the implementation of mandatory reporting in the banking sector. The financial sector was a natural choice for us.

At that time, it seemed to me that FinTech and the financial sector were unlikely to use PHP in their projects. So I assumed that by focusing on this sector, we would move away from PHP and remain only with Java and .NET. With this information, we went out to the team at the general meeting of the company.

So it was the outbreak of the pandemic that forced you to decide to change the technological profile of FINGO?

Yes and no. After sharing information about the specialization, we appointed a working team consisting of several experienced programmers with a flair for business. Its task was to check what are the trends, technologies and popular solutions in individual countries when it comes to the financial sector. Their analysis confirmed my earlier assumptions, that PHP was a rarity in financial projects. At the same time, they recommended developing competencies in Node.js, which is valued, even in the world of start-ups.

In our company, we cherish the concept of turquoise management, where, amongst other things, we openly consult projects that are significant for the organization with the entire team. Thanks to this, people feel the impact on the development of the company, but also feel a co-responsibility for the decisions made.

Therefore, the initiative of switching to Node.js, which came from the bottom-up, still had to be approved by the rest of the FINGO team. However, it soon turned out that there was a strong desire to develop in this direction. Perhaps it was a special time when we were all afraid of the future in various dimensions (economic and health aspects, etc.). Paradoxically, this increased acceptance of the decision to take up the challenge.

How many people had to acquire new technological competencies?

In total, the change involved 15 people. They had to decide whether they wanted to develop as frontend developers or remain backend developers and create solutions in Java, .NET or Node.js.

One of these people was a full-stack developer who had already declared himself a frontend developer, so in his case the decision was easy. Consequently, 2 people chose Java, and the remaining 10 chose Node.js.

Two testers also took part in the reorganisation, and they also had to learn the new technology. Our firm’s policy is to write tests in the same technology as the manufactured product. When the tester is temporarily unavailable, this approach gives us a sense of security; writing tests can be temporarily taken over by the programmer.

There were also departures, but these were individual decisions. One person resigned from FINGO quite quickly, but it was due to the fact that he was developing the PHP community in Wrocław. It was natural that our expectations for cooperation began to diverge. During the ongoing process, for various reasons, 2 more people left the company.

Making a decision is just the beginning of the road. Did the company somehow help programmers acquire new competencies?

A strategic project was created to support developers in preparing for the fastest possible provision of services in commercial projects. At the beginning, we asked them to subjectively determine how much time they would need to acquire the necessary knowledge, such that it will enable them to confidently undertake work for external clients, assuming 2 scenarios. The first of these was with the support of a more experienced colleague, the second was without such support. In response, we obtained various estimates.

Some declared that with the support of an experienced Node.js developer, they would be able to join a commercial project even after only one month, and others only after a few months. It all depended on what previous (private or professional) experience you had and how much courage you had in yourself. It is also worth noting that we also had experience with this environment at FINGO. So we had a basis.

However, we did not impose on them a way of acquiring knowledge. All these people are experienced programmers who want to constantly learn. They have their own preferred learning styles. In general, the continuous acquisition of knowledge is somehow inscribed in the new technologies industry. Therefore, we decided that the most reasonable solution would be to simply provide them with the resources and time to learn.

We also reorganized the company. Self-organising guilds were created, where people working in a given technology, but not necessarily on the same projects, exchange acquired knowledge. As part of the Node guild, an internal project was also created, where one could test out the newly acquired knowledge. External courses were organised for volunteers.

However, what gave the most was the opportunity to quickly join projects. The best example of this was one of the orders we were working on, where we needed all possible hands. After obtaining the client’s consent, an experienced PHP developer joined the project, also working in JavaScript, who had no experience with Node.js itself. However, there were already experienced programmers in the project who were able to support a colleague and ensure the code’s quality.

Let’s talk a bit more about your clients. How did they react to your decision to move away from PHP?

The biggest internal resistance and sadness we had was with a project created for a client of 10 years’ standing. It’s quite funny, because one of our programmers had worked on it from the very beginning. Naturally, he knew more about the system than many managers in that company. It was difficult for us to explain our decision to them. Even though we had a month’s notice, we wanted to take good care of this client. We agreed to be available to them for another six months. Interestingly, after 3 months, the client ended the cooperation himself, due to an internal reorganisation of the company. This also showed that you should not dwell on things for too long. They should be done and that’s it.

It has been easier with other projects. Like other events, it happened quite naturally. For example, we had a client developing part of the system in Node.js. We agreed that our programmers, who had previously supported the project in PHP technology, would provide their services at lower rates for the first few months. In a way, this was compensation for the assumed lower efficiency of the team that had recently changed technologies.

How do you think the developers view this change now?

I think they’re happy. People in this industry like to learn. At the time, they had the time and money to study. They studied full-time, received a fully salary and could benefit from study grants. This certainly had a positive effect on their feelings.

Is Node.js better than PHP? This is of course debatable. Certainly, this technology is popular now, so we have entered a period of upward trend.

Some people initially felt regret upon leaving a long-term PHP project. But after a short time, they admitted that they had broken out of a certain kind of stagnation. And they felt the exciting breeze of new challenges. Overall I think it went well.

How long did the change last?

The whole process dragged on over time. Market verification took quite a long time. Working on reorganising of the company and parting company with customers also took a lot of time. In total, almost 2 years have passed since the creation of the task in Jira and its closure.

It is worth noting, however, that the longest gap between a developer transitioning from a PHP project to Node.js was just 3 months. This was related to his declaration of the time he felt he needed to join the project with more experienced colleagues.

What was the most difficult aspect?

I think just coming to the decision that it was time to change something. However, the awareness that if we do not change now, and in a year or two there will be nothing to change, significantly helped in making the decision more quickly.

It was also difficult to part with clients when no alternative was clearly visible on the horizon and the economic situation was not stable.

Throughout this process, we wanted to take care of our long-term clients, to make them calmly find an alternative, but also take care of ourselves. Ensure the preparation of programmers and their readiness to quickly take orders in the new technology.

If the CTO of another company came to you and said that he was also thinking about changing the company’s technological profile, what 3 pieces of advice would you give him?

Have a vision. Know why you want to do it and make it clear to your team where you are going and why.

Cooperate with your team. Talk to people, adapt your actions to what you hear, and take their capabilities into account. Do everything with people.

Do everything consistently, despite the moments of hesitation.

To Top

Pin It on Pinterest

Share This