Habush Habush and Rottier

Thursday, July 31, 2014

Epic's Principles, Part 8

Epic's 13 principles
1. Do not go public.
2. Do not be acquired.
3. Expectations = reality.
4. Keep commitments.
5. Be frugal.
6. Have standards. Don't do deals.
7. Create innovative and helpful products.
8. Have fun with customers.
9. Follow processes. Find root causes. Fix processes.
10. Don't take on debt for operations, no matter how good the deal.
11. Focus on competency. Do not tolerate mediocrity.
12. Teach philosophy and culture.
13. If you disagree, dissent. Once decided, support.

Principle 10 is interesting--it used to be "Don't take on debt, no matter how good the deal," but apparently Judy had to buy some buildings on credit. It's nice that day-to-day fiscal responsibility is a priority, but unfortunately, I'm in no position to know how well Epic is doing on that. The company is privately owned specifically to keep this kind of information out of the public.

Epic gets a bye on this one, due to my lack of insider information.

Because of that, you get a twofer this week. "Focus on competency. Do not tolerate mediocrity." As with most things, Epic takes an inconsistent approach to this.

Judy most assuredly does not tolerate perceived mediocrity in its employees, but she sure is happy to have the least mediocre EHR out there. There's a difference between Best and Least Bad. Epic is adequate, but the volume of user complaints and bug reports preclude any claims of excellence. Epic does try, though; they're just hampered by how they enforce their ban on mediocrity.

I'm talking about how Epic churns and burns through its employees. New employees are trained to a level of adequacy, then left to sink or swim on their own. If they start to sink, rather than fish them out of the pool and enroll them in swim lessons, Epic lets them drown.

Most business knowledge that I've come across (google: retraining vs replacing employees) advocates that retraining is the more sound business decision. In terms of lost productivity and monetary expense, replacing costs more. Consider Epic: When I was there, communal wisdom stated that it took about 9 months for a TS to become self-sufficient after being hired. Retraining the under-performing employee should take about a month or two of concentrated effort. Replacing that employee starts the 9 month counter over. If most people are leaving sometime between 1.5 and 2.5 years, then the customer is getting minimal competency from their TS.

If training were better, and could be compressed into a shorter time frame, that would help Epic live up to its principle. Get the employee competent faster. If Epic retrained the underperformers--time management skills, prioritization, troubleshooting shortcuts, etc--then they wouldn't have to give up 9 months of non-productive time. Epic wouldn't have to pay that new employee for 9 months on the promise of only a couple months of productivity after that.


While Epic tolerates mediocrity in their product, they are quick to fire mediocre employees, which is a no-tolerance response. Epic has historically struggled with getting its employees the right training, and Epic never retrains. Competency is assumed, never questioned, and never corrected if necessary. There's little proof of a focus on competency. Epic fails on this principle.

Friday, July 25, 2014

Epic's Principles, Part 7

Epic's 13 principles
1. Do not go public.
2. Do not be acquired.
3. Expectations = reality.
4. Keep commitments.
5. Be frugal.
6. Have standards. Don't do deals.
7. Create innovative and helpful products.
8. Have fun with customers.
9. Follow processes. Find root causes. Fix processes.
10. Don't take on debt for operations, no matter how good the deal.
11. Focus on competency. Do not tolerate mediocrity.
12. Teach philosophy and culture.
13. If you disagree, dissent. Once decided, support.

"Follow processes. Find root causes. Fix processes."

This one has always bothered me from a semantics angle. What is the Epic Employee to do with the knowledge of the Root Cause? Why was the employee told to find it? What if the process wasn't the root cause of the problem? I would have rephrased it to "Follow processes. Find root causes of problems. Fix root causes."

Epic has a lot of processes that need fixing, and since several of these processes have been flawed for the better part of a decade (at least), it's clear that Epic has no interest in fixing them. The most obvious example of this is their HR practice. Epic follows the practice of hiring the best and the brightest of the inexperienced. Shortly after the employee becomes competent with solo work, the load gets bigger until the employee either buckles under the strain or decides that the strain isn't worth it. At that point, the employee starts looking for work outside of Epic, taking all that experience with him.

The root cause of that problem is firing the employee instead of investing in their growth. Since Judy has gone on record at a staff meeting to lament their employee retention numbers, she could kill two problems by fixing one root cause.

Then there's the problem of Epic's development. Everyone who's gotten a peek behind the curtains knows that Epic's code base is held together with chewing gum and baling wire. A bona fide Patient Safety Escalation comes out every other week, and there are about a dozen Care Concerns each week.

Development processes were followed; Epic has numerous checklists for that. Problems were introduced into the product. Root causes were discovered by the Patient Safety committee. The problems were fixed after the fact (mostly), but the processes that allowed those issues into the software weren't modified.

The root cause of a given PSE is relatively easy to discover, and the code change required to prevent that specific problem from occurring in the future is manageable. However, the root cause of Patient Safety issues in general hasn't been looked at. How can Epic prevent buggy software from going out? I've heard suggestions (and posited some of my own), but nothing has changed.

While Epic talks a big game about fixing processes, they don't really deliver on that.