Software House or Internal IT? Over the last few years, I have changed employers quite often and have never settled anywhere for a long time (but that’s a topic for another story). This had many disadvantages, however, the undeniable advantage was getting to know many environments, work systems, and types of performed tasks. Thanks to this, I could find out what suits me best, and today I would like to share with you my thoughts on working in a software house vs. working in the IT department of a company that is not strictly related to software. I would like to point out in advance that these are 100% my subjective opinions, which may be due to where I was working. I’d love to hear your thoughts on this. Today I will briefly describe my experiences related to software houses and internal IT teams.
Software house
The main distinguishing feature of an SH is that we do not create software for our company, but instead for a client. Sometimes a project team is entirely on the side of the SH, while sometimes we are ‘borrowed’ in order to work with a team on the client’s side. What has caught my eye during my career?
“Blind” decision
One common feature (probably for all larger software houses) is that they do not hire for a project, but instead for the entire company. This has its advantages in the form of relative stability of employment, however, during the recruitment interview the candidate is often unable to find out in detail what he will be working on, how the work organization looks, etc. This is because to most of questions, they hear the answer: “It depends on the project”. This is a bit of a nuisance, because we make a “blind” decision.
Recruitment
The second aspect is internal recruitment. I was extremely shocked by this, and it turned out to be quite a popular practice. In a nutshell, the point is that before being assigned to a project, we have another technical conversation with people from a specific project. If it would only be to show the new employee what the project is about, there would be nothing wrong with it, but such conversations often turn into technical conversations in which a new person has to prove his skills once again.
“Brave patient” sticker
In this type of company, employees are usually assessed on the basis of some kind of template. They are given ratings, points, stars, smileys and so on. I understand that such unified processes are necessary with a large number of employees, but I have not encountered such systems in other companies, even when dozens or even hundreds of programmers were employed. Is it really impossible to do it in a humane way – developing competencies = a pay raise, and not gaining points from superiors, leaders, bosses, gurus, or anyone else?
Training and personal development
When it comes to training and the development budget, it is also structured, which in my opinion is a significant advantage. Employees do not have to inform their superiors about their willingness to participate in a training or conference by word of mouth. All this is done according to a key (whether it’s the annual budget or the number of hours that can be spent on self-development). These conditions are usually clear and transparent for both parties.
Atmosphere
The last point is the atmosphere. Again, it depends, but there are some common features. I do not know if this is because of the complicated algorithms for granting pay raises, or because of the desire to get additional “brave employee” stickers, but I do not remember the atmosphere in such companies positively. There is a frequent lack of communication, feedback that was supposed to be up-to-date but is only once every two weeks (because we have such a process in which 1 to 1 takes place every two weeks, and you cannot talk between meetings), and a constant focus on forcing a client to take as many employees as possible (although there is not enough work for the current number). These issues are super subjective, but it is hard to ignore them.
Internal IT departments
We are talking about companies that have their own IT department that works fully for them. Often (but not always) end users are the company’s employees. There are a few issues that are worth noting:
Scope of design work
As I already mentioned, we write software for the company in which we work, and the scope can change a lot. This is obvious because once a company sees some potential profit, they will want to adjust their software as soon as possible. In such a situation, sprints, roadmaps, and other such ‘inventions’ are not important. We are launching the ‘all hands on deck’ mode to deliver functionality as soon as possible. Such a situation does not take place in an SH because the client has paid for a certain scope of functionality, and its change is not something that can happen just like that.
Working with the customer
Who is really the customer? In fact, anyone can be: the analysis department, the marketing department, the head of the financial department, etc. This is of course a great help when the customer and an employer are the same person. The communication path is then shorter, and access to knowledge or the possible clarification of assumptions is simplified. Unfortunately, it also has its downsides. It may happen that you are drinking your tasty morning coffee, looking through e-mails from yesterday, when suddenly Ann from the accounting department comes to your desk asking when the ticket she submitted 4 days ago will be ready. It doesn’t matter that you are in the sprint, and PO has repeated hundreds of times to contact him about such issues. Ann wants information here and now, and you cannot do anything about it.
Silos of knowledge and arcane knowledge
In the internal IT department, we do not create one defined product, but we rather follow the wave of business. The company started with a few people, where they hired one technical university student who set up an e-mail, wrote a simple website, etc. The management understood that in the 21st century it is impossible to function without developed IT systems, so the IT department began to expand. A few or a dozen years have passed and now dozens of developers are employed, but all the systems that had been written from the beginning of the company’s operation are still in operation today. This is conducive to the formation of silos of knowledge and the creation of arcane knowledge. At a certain stage of complexity, it is not so much the programming skills that matter, but instead the understanding and knowledge of the entire company’s microenvironment. It can be quite overwhelming for new people, especially because of the fact that even being the best programmer in the company, we will never beat the one guy who has been in the company for 10 years, and knows every nook and cranny of the code like the back of his hand.
Atmosphere – subjective again
Every major company carries out some kind of image communication, whether it is presenting itself as a happy family, or as a group of the best specialists. Due to the fact that everyone in the company works on one common goal, and they are not divided into separate teams working separately for other clients, such identification and the level of familiarity is at a much higher level. I often hear feedback from colleagues who have returned to the company, or stayed despite other offers, that it is because of this atmosphere and transparency. This is an undeniable advantage.
Summary
I do not want anyone to be offended by this article, because as I wrote, it is a set of my subjective opinions. I am aware that it may look completely different in other companies, but I have noticed some regularities that were repeated in more than several different employers. What do I think about it? My vote definitely goes to the internal IT department. Above all, the way employees are treated is crucial here. In a big SH, I felt like an entry in Excel, while in companies that do not deal with software development, the approach to employees is more ‘human’ (I never thought that I would ever hear the sentence: ‘I know that there is no job for you, but the company gets a commission for you, so you will stay in this project’ (sick!)). In addition, the issue of artificially created ranges/barriers/points/ratings contributes to the atmosphere of a rat race, and as my colleague from the project once nicely said:
“Barrack testosterone is in the air”
When it comes to financial matters, there are no major differences in this field, and the belief that SH will always, and also everywhere, pay more is a myth. It all depends on skills, the situation, and a lot of luck.
He finished Business Informatics graduate. He works as a .NET/Fullstack Developer. During his studies, he was involved in a Student Government and was part of many social events. He runs his own business in the transport industry. In the evenings, He is a football fan.
