Innovation is Easy… If You Can Listen

This article originally appeared on InsNerds.com

I’m convinced that when attempting to innovate, working with small teams is the way to get it done. I’m going to lay out a quick tactical map on how anyone can try this quickly.

We often think of innovation as large changes. And some of the best innovations are large leaps, but those haven’t worked for me. I’ve been implementing solutions and building buy-in for more years than I’d like to admit, and through that time, I have failed miserably. A lot.

But through the failures, I have learned that the single key ingredient to making something work is finding an employee who cares that it works. Not lip service but really wants to change something.

Generally, this something is a task that they don’t like. They have thought about this task and personified it, and now, call it Ted the terrible task. They also have a plan to get rid of Ted. Or at least, the employees that you want have a plan to get rid of Ted. All you have to do is figure out how to listen to that employee.

I will say this – don’t listen if you can’t act. My employees know in many cases if they bring me something, we will sit down at that point if possible and make the changes or create the report immediately. Doing that incentivizes them to bring more to the table and iterate through quickly.

So here’s the quick and dirty –

Find mid to long-term employees that have been in the same seat for a while.
Ask a lot of questions. Understand the pain. I still screw this up. I think I know what they are saying, but I still miss it. Luckily, I have some staff that are patient and honest with me and give me awesome guidance.
What are the main tasks they don’t feel bring value? Pick one. Don’t commingle or try to eat the elephant.
Is there a feasible way to remove the tasks? The most efficient way is to get rid of the process – make sure that it still has value and is not just being done because that’s how they were trained.
Do they have a realistic idea on how to make it better? This is tricky because for them to have a realistic idea on how to improve it they need to understand the resources at their disposal. If they are a dreamer and have pie in the sky ideas – tell them that and tell them why and help shape the next iteration.
Can you craft a small version of the solution they came up with? I often ask myself when developing proof of concepts – what does the smallest version of success look like? And that becomes my target. Create a small vision of the solution and discuss it. Undersell here. If they want it to do 3 things, tell them it’s only gonna do 1 on the initial proof of concept. Do not promise the moon. It is key to set low expectations. I want them to help me figure out how to make it what they need. Not what I want them to have. It’s a subtle but significant difference. This is a mistake I see happen a ton. Big projects with big goals create big expectations, and in many cases, it’s difficult to reach the end. Small projects are so much better if possible.
Build/buy/try the solution. There are so many ways to solve problems today from outsourcing to technology that your team should be able to come up with some kind of solution. Fancy is bad. Simple is good. Think tiny.
Get the proof of concept into the hands of the user, and tell them to let you know feedback.
Iterate as needed. As some point, you will hit diminished returns, and this process will be done.
Now, you have an example to show to others that may opt to adopt the finished process/product with minor adjustments. I believe it’s critical to try to illustrate exactly how the solution will make the employee’s life better. If it doesn’t, marginal buy-in, at best, will be the result.

That’s my process, now, and I find it’s working better than ever. It allows me to have multiple projects going on in the agency to up the odds of one of them being really successful. I can also have different teams leverage different technology to suit their needs increasing buy-in and adoption. I’m of the mind that the best technology is “adoptionless” technology. This is technology that is organically driven by the staff and the problems they have. This is innovation as I know it, and I believe any organization can do this. You just gotta figure a way to listen.

As always thanks for reading. I hope it’s a good day for you.

About Ryan Deeds

I am a insurance operations and IT executive. I work in the middle of the intersection between insurance and tech and spend the majority of my time working on building solutions based on users input and then figuring out how to implement them. I'm also building a slack community and if you are in insurance id love for you to join.