Rich Lau is the VP of Software Engineering at Omnicell. His team is responsible for building the software that powers the company’s Autonomous Pharmacy medication management solutions for hospitals and acute care facilities. Rich previously led engineering teams at Honeywell and CA Technologies and holds more than 20 software-related patents.
We sat down with Rich to learn more about his “getting stuff done” approach to team management. Rich discussed strategies for providing engineers with customer context and shared insights on promoting an entrepreneurial spirit to address customer issues and foster innovation.
Our conversation has been edited lightly for brevity.
First off, I like that there’s an easy-to-remember moniker: PRIMED. I especially like “passionate transformer” because that is what we do. My peers and I are here to transform not only our company’s direction, but potentially an entire industry.
For example, with Autonomous Pharmacy, we’d like to eventually automate the entire medication management practice to remove all humans from the medication loop. That would eliminate an enormous number of medication errors, reduce costs, and leave healthcare professionals with more time to spend with patients.
I also like “entrepreneurial” because to me that’s really about solving the customer’s problem. The healthcare space and the types of problems we have to solve are complicated. I think resolving them takes a bit of entrepreneurial spirit.
I’m a big believer that engineering needs to be connected directly with our customers to fully understand the problem and to get the full context of what the customer is experiencing. That’s a lot different from just reading a user story in Jira.
Engineering today isn’t just about writing code. We want to foster that relationship with the customer in order to not just build what they are asking for today, but to understand what they may need tomorrow.
In fact, that’s where a lot of my innovation patents have come from — by seeing where the customer was going with their technology and processes and then trying to get ahead of it.
We’re fortunate enough to have relationships with a number of hospitals and acute care facilities across the country where we can visit them and observe what they’re doing and see how they distribute medication, how they store it, and how they order it. Each facility is a bit different, so it’s helpful to see things first hand.
I’ll give you an example from when I was at Honeywell. I worked on a lot of industrial fire systems. They were often installed in large warehouses that had 30-foot ceilings. To test them, someone had to get on a ladder and use a really long pole with a tester at the end. Everyone was used to doing it that way and didn’t question how impractical it was.
As a technologist, I took one look at that and thought, “I have a drone at home. Why can’t we just attach the tester to a drone and fly it up there?” My peers and I actually worked on a patent for that solution. Unfortunately, I wasn’t there long enough to see it through, but I do have the patent with my name on it.
That’s an example of how seeing something in practice can help us better understand a customer’s needs so we can come up with a solution.
As engineers, we often like to have a very clear picture of what needs to be created so that we can build the best architecture, write the correct code, and test it the right way. But it takes a lot of time to get that full picture. Along the way, we often get stuck in analysis paralysis. That’s one of the behaviors I try to break.
I always, always bias for action. I’ll say, “OK, we don’t have the whole picture, but do we have enough of it to start building this software module this week?” And the answer is most likely that, yes, we do. Then I’ll say, “Great. While we’re working on that one, let’s start building out the next one.”
I like to use an analogy of driving down a foggy road. Let’s say we can’t see 5 miles ahead, but we can see 100 feet ahead. OK, then let’s drive that 100 feet. After that, we’ll drive another 100 feet, and so on.
The great thing about software is that if we make a wrong turn, we just rewrite it. There’s nothing that can’t be undone. This course correction approach is better than trying to build everything upfront before we know if it will work for the customer.
Anyone who has ever worked with me or for me knows that at the end of the week, or the end of a sprint, I need to see working, functional code. If all I see is a PowerPoint deck, Excel spreadsheet, Word doc, or a Confluence page, I’m throwing it out.
That’s how I bias my team for action. If they get it wrong, then OK — let’s rewrite it. No harm, no foul. Whether we write incorrect code or write no code, we’re in the same spot.
Then, in terms of measuring progress, it’s super important for us to get feedback from customers. We also lean on our internal SMEs. Again, if we find we’re not on track, we just readjust.
One hundred percent I do! One example I can share from Omnicell is that while we were working on some of our new product solutions, we considered going to a NoSQL database.
We evaluated MongoDB to see if it could fit into some of the other things we were building. From a technical standpoint, MongoDB was great — it had a lot of good features. But it didn’t work out for us from the standpoint of who hosts that data, who owns that data, and who can access that data.
Since Omnicell deals with some PHI, we needed to own that data. We did not want MongoDB to host it for us. So it ultimately came down to a business decision, and we parted ways. By then, we had spent more than a month on the evaluation.
I think my team did an excellent job determining what we don’t want to use, which is just as important as understanding what we do want to use from a technology perspective. But I don’t really want to call that a failure; I’d rather call it a learning experience.
Well, product’s job is to get what customers are asking for. But a lot of innovation comes from predicting what customers will need tomorrow instead of what they are asking for today.
When my team has an idea, we relay it to product management. If they see the vision that we have for innovation, then they will earmark it to work on later, or at least pilot it to see if it resonates with the customer.
We do a lot of POCs just to see if an idea will work. If it doesn’t, that’s fine — we just kill the project. Other times, an idea may gain traction and become a new feature or a new product altogether.
A lot of our internal ideas are born out of customer visits, like I mentioned earlier, or from collaborating across teams on a project. For example, our annual hackathons are an opportunity for developers to take an idea that’s been brewing inside their head and put a POC together to see if it works. We also encourage people to work with someone from a different group or department; that often helps foster some innovative thinking.
I have an example from my time at Honeywell. In the fire and safety industry, you need what is called a two-man test. One person walks through the building, testing all the smoke detectors, while a second person remains at the building’s fire panel watching the lights and switches and confirming that everything is operational and has been tested appropriately.
We developed a one-man test by creating a virtual fire panel for mobile devices. This eliminated the need for back-and-forth communication with a second person at the physical panel. With this one-man test, one technician can test smoke detectors anywhere in the building and see the panel operation on their mobile phone.
This became an important feature for Honeywell, but it wasn’t something that the customer had specifically asked for — it was the result of internal innovation.
When I first got to Honeywell, I put some DevOps processes in place, like a more agile methodology, automated builds, automated tasks. They had a little set up already, but I helped add more structure and put more formality around it.
But as I moved into different roles within the company, I realized the processes weren’t being implemented consistently across the board. So eventually, I helped scale the practice across the business units and roll out SAFe training for the entire organization.
There was an initiative called “zero to one,” and part of it was figuring out how to implement the project and then how to do it in a more DevOps way — in a more streamlined approach that keeps the customer in mind.
Part of the training became how to use the Amazon press release method: take the vision, break it down into a timeline, determine what to build each year, figure out how to align our release trains to it, and then start building that vision.
With a big initiative like this, you really need executive sponsorship. I was fortunate to work with my CTO to set up that training and roll it out globally.
Earlier in my career, I tended to look for people who had good technical skills, who could code, and who were really good at problem solving. But along the way, I learned that just because someone is a very skillful programmer, that doesn’t mean they’re going to get along with the rest of the team.
Today, I look for people who are a good cultural fit with my team, who are hungry to learn, and who are willing to learn new technologies, a new domain, new tools, and new ways of working. Programming skills can be taught, but I’m not sure you can teach someone to be hungry.
I’ve been doing BJJ for over 20 years, but there are still times when others get the best of me. The sport is constantly evolving, there are always new techniques and moves to learn. As the saying goes, “When you’re a Black Belt, that’s when you’re really ready to learn.”
That’s what I take into my professional career. I try to remember that I’ll never know everything, and that I have to be humble enough to learn new techniques and then incorporate them for next time.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Learn more →
