Veeva Systems

Leading-edge software and security best practices.

Good/competitive compensation.

The CEO is involved in the hiring process for every single employee. The CEO has certain rules that cause disruptions and distractions to solving business problems, such as:

• Blacklisting certain companies.

The CEO has created a rule for recruiters and hiring managers to not hire from specific companies (Cisco, Intel, and Apple are some companies on the list). When I was hired from one of these companies, my manager had to provide a 2-page written report every 3 months for the first year, and he presented it in person to the CEO to continually prove that I should be allowed to stay at the company.

There were extra interviews at the onboarding stage to ensure I was a good fit, and it all felt like a huge waste of time. This rule was constantly brought up when I attempted to introduce new innovations in our tools and processes. I was told more than 15 times in both private and large meetings that "my ideas were not welcome because I had come from one of those blacklisted companies."

It was never surprising when my proposals were later reintroduced by someone else and then were accepted and integrated as business solutions. It just felt more and more frustrating as time passed. Additionally, senior managers would describe the process of denying my suggestions based on where I came from previously as "a test to me, and now let's see if I'll stay in a company that doesn't want my big corporate ideas."

• Separation of engineering teams meant tools and innovations were kept secret, such that each team needed to reinvent the wheel in their own way to solve common problems.

This concept made the jobs for IT system administrators and security extremely difficult since the teams they were supporting could not share information and tools. If one DevOps team solved a series of issues related to the migration to a common software, the other DevOps team was forced to learn how to solve the same business issues without the benefit of communicating with the other team.

There was no sharing of knowledge, even if it meant fixing problems that hurt the bottom line. In the business of deploying solutions to production, this was a bad decision that was constantly being replayed and causing frustration across multiple teams.

Attend some common best practices courses, such as ITIL, to understand why best practices are available to solve common problems.

By deciding to react only after you have seen problems, you are just proving the entire premise behind the concept of best practices – that these issues are predictable. It is not a matter of "if" the failures will occur, causing loss of customers and loss of profit; it is a matter of "when" they will occur.