Subtle signs that you just got hired in the wrong IT company
31 Aug 2020Originally published in JAXenter issue of December 2018 and reposted here with permission.
Passing the interview process and landing a new job is always an overwhelming experience. This is especially true if you are also a recent graduate and this is your first job. You are filled with equal amounts of excitement and anxiety for what lies ahead. Is this company finally the dream job?
If you are a seasoned veteran and have already changed companies a few times, you should hopefully also know what to address in the interview process in order to avoid “bad” companies. Information Technology is slowing becoming an integral part for all companies, not just software ones. So, it is important to understand that the level of software maturity and how a company treats the software development process differs a lot between each organization
Unfortunately, this also means that several people are working for companies with less than ideal conditions without even realizing that this is not how things are supposed to be. It is very easy to stay for several years in a company – becoming another cog – if you are not aware that your daily routine would be much better in another organization.
For this purpose, in this article, we will see a list of 10 red flags that should tell you whether your current company treats software development in a serious manner or if you should be preparing your CV for your next position.
Red flag 1: You get hired and there is no workstation/laptop/desk for you
Now don’t get me wrong. If you arrive in the morning and they tell you that your desk will be ready in the afternoon, everything is fine. If you arrive on Monday and the company has a full training program for the whole week until your workstation arrives on Friday, this is also fine.
But arriving in your department and realizing that you have no equipment to work for more than a day is a red flag. First of all, it shows that the company is unorganized in general. Ordering a new workstation is not rocket science. In a big company, the amount of spare equipment should at least prevent such cases by providing a temporary solution. If the company cannot meet the deadline of delivery for a single workstation, can it meet the deadline for a complex software project?
Secondly, it shows neglect from the people involved in your hiring process. The HR manager, your department manager, and even your new team leader should all be concerned with what you should be doing in your first month. If your inability to work does not concern them, it means that your position is not a critical one and was only created for some unrelated reason (e.g. budget allocation).
In summary, waiting for more than 1-2 days for your workstation to arrive should only happen with an important excuse. Fun fact: I know a person that waited for two months until getting a workstation. In the meantime he was just reading books for the technologies used in the project. He no longer works for that company.
Red flag 2: Developers are isolated from everybody else (even their managers)
Remember that the hiring interview is a two-way evaluation process. The company evaluates you and you evaluate them back. During the interview, always ask to see the working space for the developers. This will tell you a lot about the company. It’s a really big red flag if a company refuses to show you where developers work until you get hired. If this happens, then just say thank you and walk out of the door.
When you do get to see the other developers, notice the mood on their faces. Are they sad? Exhausted? Demotivated? These are signs of your future if you work there. However, an important thing to also notice is the location of managers according to their respective team. Ideally, each manager should be in the same space as the teams they are managing.
Working in a team means that everybody is communicating with one another. Effective communication is one of the pillars of software development. Communication between developers themselves but also between developers and managers is something that should happen easily and spontaneously. If the managers are in a completely different building than their developers, it means that the company not only hinders communication between the teams, but also treats developers as sweatshop workers that should stay in their rooms (usually in the basement) producing software like working on a factory floor.
Multidisciplinary teams are a huge plus for all companies that understand that software is a collaborative process. Your team should be a mix of developers, test engineers, designers, and managers. All of them should be collocated in the same space. The only exception to this rule is if the company works in a remote or distributed manner. But, for the run-of-the-mill typical corporate organization, looking at the allocation of people between buildings is an important factor to understand how easy communication is between members.
Red flag 3: Daily stand-up meetings take more than 15 minutes
Without getting into details about the Agile process, it is at least important to understand the purpose of the daily stand-up meeting. The objectives of this meeting are well defined. Each person on the team has three questions they should answer:
- What work was finished the previous day for the sprint?
- What work will be done today for the sprint?
- Is there a blocker issue that prevents work?
That’s it! These are the only topics that should be mentioned. The stand-up meeting is not a discussion, it is not a stakeholder status update, it is not an analysis meeting, and it is certainly not a brainstorming session. Yet, a lot of companies misuse it and let stand-up meetings drag on for one or even two hours instead of the original 15 minute deadline.
This is a red flag for multiple reasons. Firstly, it wastes everybody’s time. Discussing topics that are only relevant to some members of the team is demotivating for the rest of the people. It is ok if extra discussions happen after the stand-up, but only if they contain the subset of the team that is actually involved or needed.
Secondly, it shows that the company does not understand what Agile is. If the company misinterprets a 15 minute stand-up as a full hour meeting, it will probably misinterpret other parts of the software lifecycle as well such as time to deployment, code quality, commit feedback loop, etc.
Lastly, it shows a lack of effective management in general. If the stand-up meeting has become a status update for stakeholders, it means that the existing “official” process for actually getting a status update is not enough. Therefore, people are misusing the stand-up as a substitute.
Red flag 4: Your new team is indifferent towards you
Typically, getting a new person in a team should be a positive experience. Ideally, the team needed a new member, a position was announced, and the interview process finished with your arrival on the scene! Maybe you have a skill that the team needed. Maybe you will be trained on something the team needed. Maybe a new project started and the team size needs to be adjusted.
Your new team should welcome you and make it easy for you to blend in. A mentor should be assigned to you that will be responsible for your onboarding process. Your team is also your primary source of information in the starting months.
Now, it goes without saying that getting a negative reaction from your team is a huge red flag. If your new team is actively aggressive towards you then something is really wrong with the company. However, a big negative sign is also indifference towards you. If the team is apathetic towards you, there are two possible reasons why.
First, the company may have a bad working environment and thus a huge personnel turnover. People are coming and going all the time in your department. Maybe new developers are getting hired, see the mess in the code or the software process, and instantly search for another company. In that case, your team knows that you will leave once you realize the situation. So, they don’t feel like they should invest in you. Alternatively, they are the ones that are already applying to leave, so they don’t feel they should make any connection with you if they are going to change companies soon.
The second reason might be that simply your team does not care. After so many long hours, missed deadlines, frantic firelights, and time-consuming meetings they simply do not have the energy to welcome you and connect with you.
Both reasons are equally bad. Your team’s reaction towards you says a lot of things about the time you will stay in the company.
Red flag 5: Team bonding comes from working long hours
You join your new team and, after some time, you realize that people know intimate details about one another. Everybody knows everything about every other team member and topics that are discussed within the team are the same ones that you would discuss with very close friends.
It is important to understand quickly where this attitude comes from. Of course there are some very rare cases where a team is composed of like-minded people who enjoy working together and are also meeting outside of work or in company team bonding events. In most cases, however, a good colleague is not always a good friend. While it is perfectly normal to make friends from some work colleagues, it is highly unlikely that you would like to discuss your personal matters with your whole team.
Unfortunately a more common occurrence is having teams that are working really long hours to meet deadlines. Working 12-14 hours every day and even weekends with another person will force you to bond with that person since the job starts to become your full life. People are especially more likely to bond with one another under periods of heavy pressure and stress, as there is the common feeling of having to endure the same problems together.
This is a red flag because, while on the surface you see a well bonded team, the big problem is the long hours the company imposes on its people. Ironically this bonding is also one of the main reasons that keep people in companies like this, as they “enjoy” their team and think it is the “best team ever”.
Don’t fall into this trap. Creating bonds out of long hours is a problem and you should not let your “good team” blind you.
Red flag 6: Being given tasks by many managers
Task management is one of the most basic problems a company must solve. There are many software suites for this issue, so it should be easy to understand how tasks are created, who assigns them, and who owns them. One of the classic questions that you should ask in the interview is who assigns tasks to your team.
In a well-organized company you get tasks from a single person – your manager. Each task has also an expected time frame, importance, and difficulty. It is okay if another task needs priority before the one you are currently assigned to. You should suspend it and resume working on it later.
A big problem is the unclear ownership of tasks. A typical bad day looks something like this:
- In the morning, you get a task from your manager and start working on it.
- At noon, another team is having issues with a deadline. Another manager asks for your help. You switch tasks.
- Something breaks in production and a third manager asks you to fix the issue right away. You switch tasks.
Then, the next day, the first two managers are sad to realize that you didn’t work on what they thought you should work on.
Problems like this are a big red flag for the organization of the company. It is okay if the tasks you work on come from multiple people, but they should also be aware of one another. Ideally, only a single person should be your manager. Having multiple managers passing you tasks shows that the company treats software developers as factory workers who can quickly move from one machine to another just by shouting over.
Red flag 7: Being asked all the time about your current task
Going back to the subject of task management, I already mentioned that there are a lot of software suites designed exclusively for this reason. Any internal or external project stakeholder should be able to get at a glance the current status of a project. The task/issue system should be the single source of truth for the status of the project. Reports and status updates should be easily exportable from the system itself without the need for manual intervention.
Of course, this assumes that the company has a good issue system in place and people know how to use it. Unfortunately, this is not always the case. A very common problem for developers is getting continuous interruptions in regards to what they are working now and what they are going to work on next. This is a red flag for several reasons.
Getting interruptions all the time is a bad way to work as a developer. Getting into the zone requires uninterrupted periods of time that allow you to think and write code. It is very difficult to get work done if most of your day is spent on micromanagement discussions.
The more important problem is that this micromanagement shows an unorganized company. Either the task management system is ineffective or the company does not know how to use it. Lack of knowledge on task management almost always maps to lack of project management in general. Missed deadlines, wrong estimates and unrealistic expectations go hand-in-hand with micromanagement.
An even bigger red flag is being required to attend special meetings that were created specifically for “getting a status” update on the project. Wasting people’s time with something that is already offered by the system shows a company that doesn’t understand how software gets developed.
Red flag 8: Not getting access to production environments or new tools
A professional in a field is somebody who has access to the best tools of the trade and also knows how to use them. The same is true for developers. New tools and technologies come out all the time. In most cases, they solve problems that needed manual work before their appearance.
Your company should have an official process for getting access to new tools, updating existing tools, and generally keeping up with the developments in the specific business area. Developers should have the freedom to evaluate new technologies and create prototypes for interesting tools.
Unfortunately, a lot of companies still think with the “if it works, don’t fix it” mentality. Legacy projects are announced as frozen and tool upgrading becomes a lengthy process with various layers of manual approvals. If you realize that you spend more time every day battling with the company process than actually getting work done, the battle is already lost.
In a similar topic, developers should also get access to production systems and all the systems they need access to. It is okay to have extra security checks and failsafe facilities in place, but the company should trust its developers that they can get the job done without having to jump through extra hoops.
Red flag 9: Limited Internet access and no admin account on workstation
Another way companies do not trust developers is when they limit Internet access and workstation privileges. Working with the best tools possible is a prerequisite for any developer. Any developer should be able to choose their favorite terminals, editors, IDEs and so on. A company that locks down workstations essentially does not trust their developers to have the knowledge they are supposed to have.
Another red flag is limited Internet access. Disabling all sites for social media might seem like a good idea initially, but it also cuts developers from learning about new tools and technologies. Content filtering solutions are never perfect and they can often be problematic in what content they allow through. Treating developers with mistrust and assuming that they will want to slack off all day is a red flag as it shows how a company treats people in general and not just in their browsing habits.
Fun fact: There are several companies that instead of cutting access to specific sites do the exact opposite. All sites are banned by default and you need to request access for a specific site that you need. Sad, but true.
Red flag 10: Getting a counter-offer when you say you are leaving
Maybe you learned everything you could learn. Maybe you got bored. Maybe you had long hours. Maybe you found several of the other red flags mentioned here to be true. At some point, it is perfectly normal to leave your current company.
In some cases, you might get a counter-offer. Your company is giving you a raise to stay. There are many articles online that try to propose a solution and whether you should accept the counter-offer or not. I am actually amazed at why this topic is so controversial. The answer is very simple. You should reject the counter-offer and move on. Getting a counter offer is a huge red flag in the first place.
First of all, it means that the company knows it is underpaying you. If they are ready to offer you a raise for the same role, why didn’t they do it earlier?
Secondly, it doesn’t solve the problem of your original decision to leave. The reasons that forced you to leave will still be there if you accept the counter-offer. If the original reason was about money, then trying to get a raise by trying to leave is the worst way possible to achieve it.
Getting a counter-offer shows that the company does not pay attention to its most important capital, its people. This is also true if you learn that one of your colleagues was presented with a counter-offer, it doesn’t have to be you to understand the mentality of the company.
In conclusion
There you have it! I hope that this article gave you some ideas on what to ask in your next interview, how to understand if your company values you, and how to talk to friends that are trapped in horrible companies because of “the good team”.
Go back to contents, contact me via email or find me at Twitter if you have a comment.