Pros
$$$$$$. They can only put your money in front of you, but it might less if you're good enough.
Cons
1. Managers don’t know the software and don’t understand how the program works properly 2. No development chance for engineers to learn the new technology and to improve the efficiency for work 3. No career plan for engineers to help engineer grow, there are only many ARs (action requests) to ask engineers work very hard to fulfill the requirements from users. 4. Managers don’t care your life, they only care their reputation and their performance in the higher management. They even ask engineers to work very late to deliver what they want. 5. Still use Delphi 7 (yes, Delphi 7 not the 8 or 200X or XE or 10.) which should be retired in the present day for the reports and agents. 6. Very unstable middleware to the database. It’s written in Delphi 7 with DCOM. I don’t know how to criticize this point, it is very unbelievable to happen in a “software department”. Nowadays, it should be something written in Java, C# or Go. Even Python might be faster and stabler than Delphi 7. 7. Every project came and sunset soon once it got credits, they claim they resolve a lot of issues happening in the factory, but it won’t last too long because people need to accomplish another thing before the next performance evaluation, so their best strategy is to sunset the system they just delivered. 8. Although it’s CIM, the “data science” team is the most comfortable team to stay because they don’t need to be on-call and to own the programs which may cause issues for the products. Plus, they usually have good performance because their work can highlight people to do and make actual credit from that. 9. Don’t have system design meeting, code review and endorsement meeting for publish as a software department. Instead, you need to have a lot of signatures/approvals from users and managers to let you publish new programs on the production environment. Once issues happen, managers only care the impact scope and ask you fix it ASAP. They don’t want to be responsible for your work. 10. Engineers in CIM need to be multiple roles i the same time. You need to be RD, QA, DevOps and PM by yourself because managers don’t show up in the meeting with users and you need to face them by yourself. They are only aware of that you’re doing some projects when users are requesting something. 11. Unbalanced workloads between engineers. Performant engineers usually have a lot of applications to own. That is, you need to work from 8 to 22 to have meetings, tracing bugs and developing something new. However, the engineers with lower productivity or high chance to make mistakes don’t get work. They can just go office at 8:30 and leave the office at 17:30. In total, bad money drive out good. 12. Sometimes, you may find the CIM managers just a person with mouth and no any real know-how to guide you and help you in the work. They act like emotional animals to ask you do anything they want. For example, one manager don't know how the function works in their project with the energy statistics or Docker, but he always ask people to use these 2 things to complete projects, then he can get the credit. 13. Engineers need to share machines instead of having a PC for your own. 14. Good engineers are leaving one by one, and there are almost no good engineers leaving.