YPrime Reviews

Work/Life Balance: The workload demands were much too high in comparison to the time and employee resources available. Therefore, many employees from many different teams and departments were seen working late hours from home and even on weekends. Culture: YPrime is a small "family business" that began without a real strategic business management plan, mission, vision, and short or long term objectives. YPrime came to fruition because of the spark of an idea for a clinical trial software product. Then, as more and more clinical trial sponsors and CROs liked what they saw and began asking for new things, the powers that be would merely say "yes" and just throw it in the laps of the project management, software development and testing teams to figure it out and make it happen. It was as if every software system built for a new clinical trial protocol was an entirely new and different system from the standard system that the company originally created. To give a simple analogy: If YPrime only had the materials, knowledge and man power to offer one simple recipe of cherry pie to its clients, yet one client suddenly asked if YPrime could bake and decorate an elaborate 9-tiered wedding cake in one hour and twenty-five minutes, YPrime would say "yes" and make their employees figure it out. This “business strategy” for "staying innovative and competitive" was very taxing on the employees who had to pull off these new endeavors. Compensation & Benefits: I was not there long enough to see a bonus or merit increase period go by, but when I first came to the company, my colleagues told me not to hold my breath for those things. Career Opportunities: There didn't appear to be much room yet to spread your wings and fly from promotion to promotion or from department to department within the company, merely because the company is still young and so small. Other: HR does not have a training team to conduct a useful and beneficial new hire training program. I am not speaking of a new hire orientation. I refer more so to generalized training regarding the skills, knowledge and expertise required to perform work at that specific company, with its specific products and services, in its specific industry (training required regardless of one's specific job position). There are also no well established training programs for specific departments or job positions, aside from reading and electronically signing off on mandatory company SOPs and policies via the document management system. The quantity and quality of job specific training provided to new employees varied dependent upon what department they worked in, and how their manager handled new employee training on his/her team. It also depended on whether or not those with senior roles on the team had the time to provide on-the-job training, and give regular feedback and support to the new employees. I witnessed several well-educated, experienced, talented and eager new employees who were left to sit idly at their desks for months (upwards of six months if not more if I recall correctly) without receiving the training necessary to perform even an iota of their job duties. Their managers and senior team members were too overwhelmed with workload to provide on-the-job training, or even schedule periodic training meetings with them. That is ironic too, since their workload would have decreased if they would have just trained those new employees so they could then help with said workload. Instead, the new employees often sat at their desks and did nothing, read a few emails that they were carbon copied on throughout the day, asked neighboring colleagues if they needed help with anything, and did occasional assigned busy-work such as creating or proofreading documents. Apologies and excuses were made regularly by the new employees' managers and senior team members, and they stated that things are just so busy and they will have time to train them soon. Let it be said that these new employees did not take advantage of the situation either. I know many people who would love to get a job where they are paid to sit and stare at the wall for 8 hours per day for 6+ months. No, these employees wanted to work, they asked for work assignments daily and they regularly requested the training necessary to complete their work. It was a shame. An even greater shame was when I watched some of these new employees get set up for failure (as if they weren't already, that is). For example, a senior team member would go on a one or two week vacation or a leave of absence. All of the other team members were so inundated with work, therefore the only back-up person for the absent employee was one of the recently hired and untrained employees. Everything was left in that untrained employee's hands, with their managers' making encouraging promises that they'd help them through things every day until the absent employee returned to the office. Then, their managers would be in meetings all day every day, or too busy to assist them. Other team members and even employees from other departments would do all they could to help these struggling newer staff members left in these situations, but again they too were extremely overwhelmed with work which limited their abilities to do as much as they wished they could in order to help. As a result, I watched this create a domino affect where the client (sponsors and/or CROs), trial sites, depot vendors, and other employees in many other departments were negatively impacted by just one missing/weak link (that was no fault of their own). Some negative consequences were mere inconveniences, while some were highly escalated with very angry clients, deviations and corrective action/preventative action plans.

There continue to be massive communication gaps in the company. Things are constantly being changed and reorganized without addressing the real problematic processes (or people) and without getting any feedback from the employees who will be affected by said changes on a daily basis. An incredible amount of time and resources were spent trying to make YPrime an Agile company. There was a false notion among management that it would increase productivity across the board, but it has done the opposite. The only meaningful/novel lesson of Agile is to deliver working software in small frequent iterations, but we had nothing to gain from this since almost all of our projects are already on short timelines (a few months at most). So all we got out of the Agile transformation were the numerous weird rituals that distract everyone from the real work that needs to be delivered to our clients. The results have been: - Even more meetings - Even more time tracking - Even more messing around with ticket boards - Even more micromanagement - Even more personnel changes - Even more bouncing between projects (zero focus) - Even more politics - And of course, overexposure to all the absurd buzzwords that come with the Agile obsession At least half of the developers here are "study devs" and it is an awfully thankless job. For each new project (clinical trial), the study devs fork off of a central repository, which is a base version of the product, and customize the code based on the study's requirements. There is an enormous problem here, because the base repository is developed upstream by a totally separate team of devs who: - Operate in complete autonomy - Add/remove features at will (nobody knows where their requirements come from) - Have little to no experience with real studies and what they typically require - Do not document their code at all, despite a lot of it being messy - Do not communicate any important changes - (Bonus) refer to themselves as "full-stack engineers" and do not associate with the rest of the devs unless there's a five-alarm fire As each new version of the base product is on the verge of release, the folks in management/sales start selling new studies that will feature this new version. However, what they fail to realize time and time again is that the base product is still absolutely loaded with bugs and missing features. So many promises are left unfulfilled and each study is sold under a false assumption that the base product is in good working condition. Then the lowly study devs are left on their own to sort out the chaos -- frantically trying to figure out what changed and how to fix everything, all while being mandated to stick to the original naive timelines. In the end, most of the feedback falls on deaf ears, most of the fixes/features don't get incorporated back into the base product, and the cycle repeats again and again.