I recently spoke to Emily Lancaster, who is the VP of Technical Operations for KIXEYE, a gaming company in San Francisco. In her 15 years in executive leadership, she has led every type of organization. Emily has specialized in everything from eCommerce, Online Marketing, Digital Product Creation, to Business Operations. In the following brief interview, Lancaster defines process improvement, explains her approach to improve processes in her organization and more.
Dan Schawbel: How would you define process improvement, and its importance to your business?
Emily Lancaster: Simply defined, process means “the way you do things.” “Doing things” is typically the point of being in business. I’m fairly certain that the moment we stop doing things which produce something that is useful to someone else, it is referred to as “vacation,” or “sleep.” I’m a big fan of both, but have not yet found a way to get paid for either of them.
When an organization has completely lost the ability to do things in such a way that produces little more than highly-creative swearing, turnover with a side of ennui, it’s typically because they have a process problem. At this point, most Managers fire up the PowerPoint, put a dozen meetings on the calendar, and eventually get to the business of hiring more employees. Clearly what is needed are more single points of failure, and a few kitten GIFs.
At its core, process is simply an agreement between all involved in order to accomplish a common goal. Process is the plan, the contract, the directions, the instructions, and the recipe.
Schawbel: How do you approach process improvement within your organization?
“Process improvement” can be interpreted to be an insult, a threat, or a beacon of hope. How well the concept of process improvement is accepted by your audience is dependent on the level of trust and buy-in achieved before you know the answer. My first step, when looking down the barrel of a broken organization is to ask questions. Lots of questions. Even the stupid ones. Especially the stupid ones. I talk to everyone involved, starting with the unhappiest customer. I define the problems in a cold, heartless manner with no favoritism or defensiveness. I make no assumptions, most importantly what the solution is, until I’ve heard from everyone. I’ll grab strangers in the hallway.
Me: “Are you involved with the ____ process in any way?”
Them: “Me? NO!”
Me: “Liar! Sit down!”
After terrifying the locals, it’s time to compile results and find the patterns. The most fun is identifying the common pejorative phrasing. Those nasty phrases are key, because if you hear the same snarky phrase uttered over and over, that is the perceived reality of the organization. It makes no difference if it turns out to be 100% false. It is to be treated as seriously, and addressed as fully as a real issue to solve. Perception is reality, I’ve heard.
Once your problem is fully defined, the solution isn’t far behind. Someone knows the answer already, and often 6 people each know about a ¼ of the solution. Your big brain puts it all together. Then it’s time for the buy-in. You shop the concept to the most influential, the loudest, and the smartest. I make a point to stop by the most ego-driven and the most sensitive as well, for good measure. If you get a thumbs up at this point, you’re golden. Chances are, during each conversation, you’ll be given more suggestions for improvement, or chances to mess it all up. Adjust accordingly.
At the end of the day there is only one metric for process improvement success. Adoption.
Schawbel: What are the biggest challenges you have from a tools / systems perspective to support process improvement?
Adoption. (There’s always time for measuring results and iterating later. But without adoption you’ve just terrified the temp receptionist for no reason, and that’s not cool.)
Me: “I understand that you’ve already tried what I’m suggesting. But, have you tried doing it right?”
The biggest issue is enticing others to change and release their death grip on the old tools and systems. Fear of change, and lack of information on the new solution, lack of listening when information is offered, usually drive this efficiency nightmare. This is where influence, bribery and a really nice Bourbon can come in handy.
Schawbel: How do you allocate resources / personnel to support process improvement?
It is everyone’s job to suggest areas of improvement. In TechOps, our most knowledgeable employees are our Systems Engineers who work directly with the customer and our internal tools. They know what’s broken, what needs to be automated, what and who the inevitable roadblocks are. System Engineers are all knowing when it comes to a problem(s).
Schawbel: What strategies have you found most valuable to overcome those challenges?
Ownership. Encourage the team to unearth problems. Then challenge them to offer solutions in the same breath. Each quarter we decide upon our key objects. That’s fancy talk for “goals.” (Why can’t we just call them goals? I miss having goals. I’m very goal oriented, I hear. But, I digress.) Nearly all of the organization’s projects are in some way a process improvement in disguise. Be it migrating from Managed Hosting to AWS to allow the DevOps Engineers to spin up new instances independently, or automating our own decommissioning script only to be used within the department thus reducing decom times from 60 to 5 minutes, the point is to work less and invest in ourselves. Just don’t call it “process.”