A Great Customer Experience Starts with an Even Better Employee Experience.

CX stands for Customer Experience. EX stands for Employee Experience. I believe the two are connected, and for your customers to have a delightful experience, the same must be true first for your own teams. In short, thoughtful processes lead to better results for everyone.

LexBlog is in the midst of a significant challenge.  To review and rework our entire blog process from start to finish. While going through RACI charts, planning sessions, and various whiteboard processes (loving Lucid!), it has become glaringly obvious that our blog launch process needed a better employee experience. So that we can, in turn, provide a better client experience.

The Problem

The current launch process can take anywhere from 3 to 6 hours, depending on whether the blog is new, a migration, or a redesign. Over years of work in legacy platforms and different personalities leading the way, our launch checklist became bloated and tedious. Ultimately a process that would drain your soul dry by the end of the day and leave you wishing for a better life.

It felt like no one was benefiting from this. Notably, it was not a joy-producing task for our support team, and the complexities and tediousness of it spilled over onto our clients. Slower launches meant a lack of delight experienced by users blogging on our platform.

So here we have a single process that is hurting multiple people.  Fix one thing and make two lives better—a sound challenge to take on.

The Solution:

Our launch process is not great (this we know). It’s a BoT (Big old Thing– my term)  that is massive to unpack. Where does one begin? For me, it was to experience the pain firsthand. I’m grateful for our support team that allowed me to observe a few launches and partake in the pain of launching a blog myself. Albeit, I had the training wheels left on via Chris Grim sitting copilot and walking me through each step.

As I did this, an approach to fixing our launch process began to take shape:

1. Need to go through the process yourself – Feel its pain points and note any questions, frustrations, or just general thoughts that come to mind.
2. Need chart out the entire process – As tedious as this can be, it’s a critical step in seeing everything from a birds-eye view.
3. Need Experienced Eyes – They’ve been doing it for a long time, Possibly stuck in ruts. Carry a lot of the pain points of the process. It can give historical context as to why something is done.
4. Need Fresh Eyes – Will ask new questions. Not stuck in “this is how it’s always been done” thinking. Will challenge the norms. It can offer a fresh perspective.
5.  Need to Automate, Kill, Fix, or Remove  –This became the game-like plan for fixing our blog launch process.

The idea comes from a well-known game (Marry, Kill…) that was part of an Office episode that Jim leads as they wait in the parking lot due to a fire started by Ryan, the intern (“ Ryan started the fire…”).

Teams of two were formed, with one having the experienced set of eyes while the other had fresh. This allowed a mix of knowledge with youthful exuberance. Each team took on a section of the launch process and mapped it out in a linear fashion using a Lucid whiteboard. Once complete, each team reviewed every step in their section and tagged it as:

• Automate: A needful process that can be automated and reduce the amount of time taken by human hands.
• Kill: Not necessary. This could be due to a redundant item in the list. It happens. Over time as a process grows and the controls around its creation and review do not, which produce opportunities for duplicate items. When you see a step that needs to be killed, it’s obvious.
• Fix: This is a step that is critical but has some flaws. Like missing documentation or the tools used to complete have had a UI change, and the process has changed. Again, this is mostly around better documentation or corrective steps.
• Remove: This may feel redundant and less harsh than our “Kill” step, but it has a purpose. Anything tagged as “Remove” also requires a little team discussion. This may mean we need to remove it from the launch and make it part of another process not in the launch. It could be an old legacy step that was once critical, but now we have automation to ensure this action occurs.

Each action has a tag color (another great feature of Lucid) that allows you (once set up) to quickly, in a rapid-fire approach, mark each task as you go through your list. Once each step has a tag, the entire team meets and reviews the work validating the decision. Often more questions will arise where you’d need to get an outside opinion to confirm or deny your action. This is where we later added a “Question” tag that denoted a need to discuss.

Once complete, you can eliminate the “Kill” and “Remove” tags, and you have a leaner workflow to build out from. The second phase is to take all the steps tagged as “Automate” and review them with your product team. Create tickets, size, prioritize, and add to your backlog. You now have a new workflow with all the cruft removed. A process in place to review down the road, and hopefully, a happier team that can now focus their efforts on serving others in a greater way.