How To Talk About Epic With Those Unfamiliar
Though Epic is well known to many, there are boundaries to where its name will reach. Imagine a Venn diagram of three sets: people in the state of Wisconsin, people in the healthcare industry, and people in the software industry.
In a broad sense, this diagram represents the realm of those familiar with Epic. There are, of course, always exceptions in either direction, but if find yourself needing to discuss Epic – whether interviewing (job, graduate school, news article, podcast) or just in casual conversation – this can help you keep in mind that most people in the world will have no idea what you’re talking about.
Do not take a name for granted.
Are you aware of just how many companies out there go by Epic or Epic Systems? There are even quite a few other Epic Systems, Incorporated... So, if you’re talking to someone on the outside, do not assume that they will recognize Epic by name alone (even if they are aware of the company) when you are asked about your previous employer.
Rather, start with "a healthcare software company in Wisconsin named Epic." In this way, you open the door for the other person to mention any level of familiarity with Epic, and in so doing you give yourself a gauge for the level of detail or abstraction you should use in describing your role and work there.
Do not assume people understand an EHR/EMR/CHR/PHR/etc.
If you need to provide additional background or context about Epic, "Electronic Medical Records" is still too broad for many. Instead, start with a few sentences that walk them through it in a relatable way; something like "Epic specializes in digitizing medical information. So, if you have been to ABC Hospital (usually a local example) you will have seen them checking you in and documenting your information on a computer. I helped make that happen."
If they don't understand Epic, they won't know how you fit into the puzzle.
In interviews, people often find themselves needing to discuss the overall structure of Epic to provide some context around what an Application Manager, Implementation Executive, Technical Coordinator, Big/Small Team TL, and such mean. It helps to explain that Epic itself can be decomposed into module-specific sub-teams, and that spanning these teams within the company are role-based divisions (software development, software testing, customer support, project management, and so on).
With that foundation, you can begin to expand upon any role-specific detail required. For example, implementation teams were made up of project managers from each of the module-specific sub-teams, each managing their project as a portion of the program. Overseeing the program, a single program manager made sure that projects operated on the same timelines and worked in the same direction, helped to remove roadblocks, and managed high-level challenges.
Many companies approach things differently.
If you come from IS or TS, you may find that other companies won't have as robustly defined project management methodologies. The availability of structure in that area is something many take for granted at Epic. If you come from QA or R&D/BID, you may find that other companies use actual project management practices (both waterfall and agile) in the development cycle.
Even if processes and tools line up, certain terminology might not. Question terms – especially acronyms – before you use them because others might not understand. Instead, consider the goals of different processes and tools you used as their descriptions: project planning, requirements gathering, expert review, status reports, allowing sub-teams to do their work and report back rather than trying to manage each individual task, etc.
It will also benefit you to pull out the processes and tools that you found useful and apply them in ways that might work in other environments at a new job.
Recognize that those on the outside will not understand that Epic is a start-at-the-deep-end, sink-or-swim environment.
Not knowing what your tenure is or was, and though there is some amount of lead-in variability across roles, most are given quite a bit of responsibility very early. So, if interviewing with someone who doesn't know Epic, it can be helpful to talk about being able to dive right in. Even if you were only at Epic let's say roughly 2.5 years, you were probably actively contributing to customer work and/or meaningful projects for that entire time. Everyone has a slightly different timeline experience, but it helps frame the type of responsibility you were given in contributing to projects while still learning rather than taking an extended time to on-board before being able and willing to show your value.
Growing others is not exclusive to management.
If you're taking interviews, you will be asked about direct reports quite a bit. TL experience can make this a slightly easier response, but not all are, were, or ever wanted to be an Epic TL. And, if you spend any of your post-Epic time in consulting, you will mainly find a centralized HR structure where few people have direct reports.
Many companies will not consider project team leadership to be the same as direct report leadership. While in several respects this is accurate, the two share a number of the same requirements. In that light, if you were not a TL, you can emphasize the importance you placed on playing an active role in the personal and professional development of others on your project teams through coaching and providing feedback (both good and bad), as well as relating similar experiences within the framework of the mentor program, AM/AC relationship, Advisor TS role, EDI LAC, and other intra-team leadership roles.
Regulatory and compliance needs exist almost everywhere.
People will talk about how regulated certain things in manufacturing are, how convoluted legal requirements have become in European data markets, how complex their models are from an industry governance board, and the like. So, relate that to regulations and changes happening in healthcare and the complexity of understanding and configuring the billing rules or clinical documentation requirements for something like Medicare. That is usually an example that everyone can understand and generally agrees is complex. It shows that you can tackle those types of difficult situations and value adhering to the policies and rules.
Many specializations want to be recognized for their achievement.
In the manufacturing environment, and very likely in many other industries, there are a lot of highly-skilled people who are only swayed if you show value in their expertise (similar to doctors). So, when working with these individuals or in responding to interview scenarios that involve problems with unhappy groups, think about using examples from the time when ABC physician or XYZ billing director needed to be brought on board as a way to relate to working with other groups like Engineering.
May 2018
About the Contributor
Briana graduated from Indiana University's Kelley School of Business with majors in Marketing, Management, and Supply Chain Management. She began working at Epic shortly after graduation and moved up quickly to the role of Implementation Coordinator. Eventually, Briana left Epic and began working for Fullscope handling ERP implementations with a focus on Trade and Logistics before finding her way back to the Epic world as a Senior Consultant for Nordic where she expanded her horizons to include Affiliate implementations. Briana completed a certificate course in Six Sigma Green Belt at Villanova University and obtained her PMP, then proceeded into a new arena as the Continuing Improvement and Strategic Initiative Manager, now Strategic Projects Manager at Grande Cheese. Briana is energetic and passionate about the projects that she is involved in.