The biggest problem with this company was that it totally *failed* to keep pace with changes in the "DevOps" ecosystem. Originally built on top of Amazon Web Services, EY management had a vision for an IaaS ("Infrastructure as a Service") agnostic system; for example, deploying on AWS for one project, then over on, say, Rackspace Cloud for another, then maybe on Windows Azure for a third - all of them with the same interface to the end-user, but managing the differences under the hood.
This vision, combined with tons of technical debt due to the "ship it now" mentality over the "let's make sure this is maintainable and works" mentality, is what prevented the company from keeping up with changes to the general technology ecosystem.
When EY was first on the scene with its automated PaaS product, a lot of the tools that developers at various organizations and on various teams take for granted today, didn't yet exist. This is where EY filled the gap, providing a great toolchain and workflow to provision and configure EC2 instances, MySQL (and later, PostgreSQL) databases, external storage volumes (Elastic Block Store) and so on. Then they provided a pipeline for deploying custom Chef code (configuration automation, see chef.io), and deploying their application(s) to the environments.
Sadly, that basic tool set never evolved past that state. When Amazon released ELB, for example? Couldn't use it for years after its official release, and even then, had to be "turned on" under a special feature flag for the platform. Maybe you wanted to use RDS - too bad, go roll your own account at Amazon and wire it up that way. Perhaps you wanted to language other than Ruby - well, they eventually pushed super-weak Node.js support (they threw the entire process for research, building and future feature improvements on *ONE* engineer alone!), then even weaker Java support, and then dropped both. So umm...no?
And this is a symptom of one of the company's major problems: management ADD. It was like the former CEO (nice guy, don't get me wrong, but not great in this respect) couldn't decide where to focus. Various teams were being told to stop on a dime and shift direction to this new shiny thing over here, and then THIS new shiny thing over here! This happened so frequently that nothing ever actually got DONE. All the while, the major product that had users and generated revenue, never got any significant updates or upgrades.
All while that was happening, Amazon was building multiple separate tools for each of these - and other - uses, that developers could "pick and choose", wire them together as they saw fit. Things like Elastic Load Balancing (ELB), Auto scaling (which we tried to do, but executive-level politics prevented), Virtual Private Cloud (VPC), Continuous Delivery systems, ways to deploy your code through Amazon, Relational Data Store, Web Application Firewall(s), Authentication and Authorization management, and a slew of other major things that people wanted from Engine Yard, were being not only developed, but *released* and *improved* by AWS.
Pretty soon, the question became: why bother with Engine Yard at all when, for the same price, or cheaper, I can cut out a middle-man and use Amazon's services directly?
This led to multiple former customers cutting ties and reducing reliance on EY as a vendor, which of course caused major problems in reaching profitability for the company.
They've recently hired a new CEO and cut a lot of costs with laying off a huge chunk of the company. They've also re-focused on Docker container management (an idea that was embraced by competitors long ago under LXC since Docker didn't exist at the time), but it might turn out to be too little, too late.
If you're thinking about accepting a job offer here, my advice is "don't". Unless you've got another job lined up as a backup and can work remote (or otherwise won't have to move). You may not have a job in N months because of the poor decisions made over the years.
