Why our offices in Prague and Brno met their infamous ending – part II.

Continuation of Part I of the Article

Adaptation and trial period

The adaptation period began with new colleagues from Brno and Prague spending first 2 to 4 weeks in Opava at our main branch. That aspect helped us a lot in the early days of training. The only downside was that this requirement logically cost us some of the promising candidates. No wonder. If you want a Prague developer to temporarily leave his home and his comfort to move to a smaller city on the other side of the republic for a few weeks, it’s not really on their list of favorite things to do. More so, as there are enough companies in Prague that will not require similar personal sacrifice. However, when our new colleagues were in Opava, everything seemed fine, and not the slightest problem was in sight.

Our mutual expectations then gradually began to diverge when the newcomers returned to their home branches in Prague and Brno. For context, it is good to mention that we are talking about the time before the COVID-19 epidemic, as in time when we had absolute minimal experience with long-distance collaboration and Skype video calls were freezing like icebergs in the Arctic Ocean. At the time of writing, we have 15 months of continuous cooperation in this mode and are more experienced in many ways we weren’t back then.

So, what would we do differently to adapt newcomers nowadays?

  • Not only we would want them they come to us, but we also have to come to them. Not to say that we haven’t had the effort to travel to our new colleagues in Brno or Prague, but the periodicity and selection of people who went there to assist probably was not the best. Remote branches were most often visited by personnel from Human resources or technical departments, who tried to help with the general issues during the assimilation process. They then spent only about 3-4 days a month at the branches and later even less. In retrospect, we know that the best option would be for individual developers to take turns at remote branches and be available there for a much longer period of time. The experience of already integrated developers with knowledge of the domain, development environment, methodology and development methods would surely help newcomers the most. Whether we would find enough volunteers for business trips to Brno and Prague, we’re not really sure of. In any case, this is one of the things that we would certainly have to address next time before deciding to open new branches.
  • Integration into already established teams – This is to some extent related to the first point already described. In the case of Brno and Prague, we tried let the newly formed branches operate as separate teams working on their own modules. In retrospect, we see this as another mistake. The best proceedings would have been the other way around, to integrate newcomers into already established teams. The transfer of all knowledge, skills and habits would be hugely helpful in their adaptation. Also, we believe that it would help us mostly avoid even the previously mentioned divergence in the ideas and approach to development. In the later stages of cooperation, there were already some attempts to integrate remote colleagues into local teams, however, this was not during the adaptation period and thus it was perceived rather negatively, as an uncomfortable breakdown of their already experienced habits.

Problems of everyday developer life

In addition to the above-mentioned difficulties from the adaptation period, which then further moved on into the everyday life of a developer working at a remote branch, other difficulties have also accumulated over time. Looking back, the absence of the Leader in the newly established branches and teams seems to be the biggest problem.

Our company is unique, among other things, in the fact that it has a very flat organizational structure. There’s not much play or need for superior vs subordinate relations and unlike most other development companies, there is no position of “Team Leader” as a person who somehow manages and coordinates the development within his team. Such person who would be responsible for the performance and quality of delivered work. The absence of a team leader, on the one hand, means great freedom and autonomy of the team without having to answer directly to a boss, but on the other hand it means that the responsibility that such leader bears on his shoulders must logically be divided equally among all team members who in a way are all guarantors of quality and speed of work. In Opava, this way of autonomy works very well for us. Looking back at the offices in Brno and Prague, the absence of a team leader was probably a mistake, for the following reasons.

  • A team leader is simply a leader. He or she is the person who leads the people in his teams, is the person they can go to immediately in case of any need or doubts and start working on fixing their issues immediately. He is the person who guides the development in the right direction. Person making sure that the team does not lose sight of the broader perspective of the whole project.
  • The team leader is also a mentor. He is a person who is able to ensure the improvement of people in his team in terms of technology or methodology. He is able to continuously monitor the progress of his people and give them regular feedback. He helps integration, but also professional growth.
  • The team leader takes responsibility. Dividing the degree of responsibility for the result of work among all developers in the team works well for us in Opava, where we have a lot of developers with many years of experience with this approach. Automatically expect the same level of responsibility from newcomers who had never worked in a similar regime before was a mistake.
  • Team leader as a referent for culture. The guiding principle of our company is our corporate culture – autonomy, flexibility, freedom and trust. We have failed to some extent to integrate our values at all branches. The result was the emergence of a kind of subculture at remote branches. In some respects, it differed from the habits of the rest of the company. Today, we believe that Team Leader could be the person who would proudly carry the banner of our company culture and contribute to the better cultural assimilation of new colleagues.

Although we are definitely not going to introduce the position of Team Leader into our current structures, it is clear that in the case of establishing a new branch, this should be our goal. It is probably good to mention that especially in Brno, the developers responded with the demand for such a person. However, we did not react upon such request and believed that our system without managers would succeed even in remote branches. We believed that it would improve in time. How it would turn out in the end, we will never know. Both branches were closed.

Closing time

The article would probably not be complete if we did not conclude the last days and weeks of Pompeii.

In the case of Prague, it was relatively simple. Long driving distance, high costs, the low success of the recruitment process and the last proverbial nail in the coffin was the departure of one of our two guys in our Prague team. The moment he came up with the resignation, we knew what to do. We will not continue in Prague and will close the branch.

Brno looked very promising for quite some time, but then in a short period of time 5 people finished our cooperation, including some of the more experienced ones. Two have finished the project they were working on and three other found work in a competing company, where, by the way, they had a Team leader from day one. And then there’s Ostrava.

We haven’t talked about Ostrava yet, because this Blog is supposed to be about our oversights, failures and what we’ve learned from them. It’s not that we have always succeeded in Ostrava, but in general we consider the development of the Ostrava offices to be a success, which is why they have not been discussed here so far. However, it was also these offices that were behind the final closure of the Brno ones. We managed to recruit some 10 new developers to Ostrava over the course of some time, so we simply realized that the easier way to go would be the one to Ostrava in the end. If you ask us why the branch opening in Ostrava turned out better than in other locations, then we probably do not have a clear answer to that. It is certain that contact with people from Ostrava has been and still is more natural and extensive, people visit each other at branches much more often, which is positively related to the transfer of corporate culture and the overall atmosphere. Another possible answer is that we simply do not have as strong competition in Ostrava as in Brno.

But frankly, you simply won’t find a better IT company in the Moravian-Silesian region.

Did you like this article?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.