EZLinks was definitely a revolving door. People would check-in, look around, and quickly split. I went through this process myself and jumped ship after about 6 months. My decision to leave was primarily based on the quality of the software and the attitudes of some key team members.
Regarding software quality... Really it's all across the board in terms of quality. But as a new team member, most likely you will inherit the lowest quality first. Imagine a web app, written in classic ASP pushing 15 years old. This project might have been acquired via the acquisition of another company. There may very literally be zero other employees, from the previous company, left, that can answer specific questions about this project. Congratulations, on day one, you are the subject matter expert. There were numerous projects that I inherited that no one in the company knows how to set up.
Additionally, EZLinks has a lot (might be an understatement) of business logic in stored procedures on the database server. For instance, the logic that enforces password strength is written in SQL. Issues, in this regard, are not realized until run time and are difficult to identify within your debugger, increasing development time.
Deployments, involving 2 dozen people, can take 6+ hours with the complete possibility of eventually failing. I came from a previous position where we had fully automated deployments that could be scheduled, in advance, to run hands-off in under 2 minutes, so it was definitely a couple steps down at EZLinks. On top of that, there was no real possibility of ever improving.
Regarding bad attitudes... Sometimes my boss instructed me to submit IT tickets. Almost 100% of the time IT would lash out at me and close my (bosses) ticket, without fulfilling the request. However, I noticed that requests submitted directly by boss received much more professional support. I found this a little two-faced and disrespectful of my position on the team, sort of like IT visualizes the submission of requests as "the new guy telling them what to do". I loathed any interaction with IT.
New team members do not receive any training. As a metaphor, consider the teams' git branching strategy. The way a team member learns about this strategy is via a series of frustrated instant messages. The issue is that these messages inform the team member when they have done something wrong, but do not include clear information on how to do it right. This means the issue will persist, and happen again, leading to more frustrated messages. Over time, via each message the team member is able to slowly paint a picture of what is expected of them. Basically trial and error at its worst. Branching strategies are not that complicated, and there's several to choose from that are fairly well documented.
