Season 1, Episode 3: "How do I interpret business requirements?" with Jon Macy, Director @ Cerner

Jon Macy: So a lot of times, we don't get business requirements. We get, already specked to a certain degree technical, because somebody has interpreted some set of business requirements and have already picked product, design, and process and procedure. And are handing it to us.

Speaker 2: How have you enabled your infrastructure fundamental change over the last five years and partnering with the business is critical? The tools exist on the cloud change at the rate necessary, secured by design inaudible

Andrew: Hey, it's Andrew, and welcome to Network Disrupted, where IT leaders talk about navigating the disruption in our industry. In this episode, we explore how a leader in healthcare IT approaches requirement setting. My guest today is Jon Macy, a director at Cerner who works across the businesses functions to create technology architectures for the entire organization. Coming up on 15 years with Cerner, Jon started in the infrastructure space as a technician and moved his way across and up the technology stack. Today he's problem- solver for the entire company. He has developed some really wise opinions on requirements setting as a result. He's also somebody I've worked with for quite some time. And I appreciate both as a customer and a friend, let me know what you thought of this episode. You can tweet me at Network Disrupted, leave a review on Spotify or Apple podcasts, or email me at: andrew @ networkdisrupted. com. Now let's get into it. All right, Jon. So thank you for joining.

Jon Macy: Sure.

Andrew: This is something that, I think all product people, struggle with, right? Because, you're... The customer has some sense of what the solution is, and so they're going to propose the solution and leave out the context, and leave out what they're actually trying to do, which from my perspective, it makes it difficult to learn, because what we really want to know is what customer's trying to accomplish, and potentially there's a better way to do it. So when that happens, Jon, what do you do? What's your process for trying to discover what that context requirements might be?

Jon Macy: So, it is getting down to the point of, I understand that you've picked this one, but you want to do this, what was the drivers? And literally writing it down, right? So that, you can come back to it later. We have instituted some review processes at Cerner. And we're a large organization, we do both development, we sell our own software, we sell other software, we host software. There's a very wide range. My experience says that what's good for the development of an organization, isn't necessarily good for the infrastructure operations. At least not one for one. There are things that they need to be able to do and have to be able to track and maintain, and then there are things that other groups need to be able to do there is a convergence there somewhere. But we are actively now spending a lot more time and rigor, reviewing the base information and being able to express why we want to do what we want to do. So, when we were examining container platforms, we spent quite a bit of time explaining why we need to do container platforms, right, and how we expect people to use it. And it's part of really building into the culture of the paved road constructs, that cloud computing is bringing to us. And not just in the cloud computing context. So, instead of flexing the technology all the time, which is horribly expensive at the end of the day, both people, and time, and capital, instead of doing that, what we want to do is we want to create a baseline of functional capability and then see if the business can take what their needs and requirements are and use that capability to its fullest, changing with the idea that we will need to change the capability. We're not saying that it's static, but the only time we change the capability is when we have a good enough rationale to do that. So it's an ongoing process, you don't crosstalk want it done, right.

Andrew: In some way, John sound's like you're describing basically, building your own business focused platform as a service, right? You're building reasonable services that should provide components of building blocks for what they need.

Jon Macy: Yes. And it goes... It's not where platform as a service has a connotation of very technology focused, et cetera. I expand that out to a larger concept. It's really, business as a service, if you will. And the fact, underlying technology is really just an important detail, but it's really just a detail for meeting the requirements. I'm a technologist, but I've always had a foot in the business view in that, I can build and design and operate the coolest technical stacks and functionality that the world has ever seen, but if my business can't sell it or money on it, it's pretty much a fail.

Andrew: Yeah, What's the point?

Jon Macy: Right. Other than being cool.

Andrew: Right? One of the things we struggle with, and I'm using the broad we here, is how to balance the requirements of a single customer versus what's good for the market, or the company, or your strategy. We're building a strategy, this is where we want to invest, versus speaking to a bunch of customers and trying to get a budget general requirements and build something for them. In the industry we're in, we oftentimes get the sort of requirements you get, meaning this is exactly what we want. And by the way, we're in an RFP purchasing process. So this is what we want, this is how it needs to work. And you have to check yes or no, and if you have a better way or different way to do something, you have to write, no. And then in a comments field, oh, but by the way, you know, and it sounds like an excuse. And so oftentimes, I find that process might be limiting, but on the flip side, as we develop and build new things, we spend time with customers. We speak to experts in certain areas. Sometimes we speak to one person too much, sometimes we speak to the wrong people, so it's a process that we are always trying to get better and better. My point is it's always... It's more than who you speak to. There's always this negotiation we're going through internally on, do we do this because critical customer wants it. Do we take capacity away from what strategic in order to do this? How do we figure out the business value of this? And should we be actually doing something? I'm assuming, you go through a lot of that with the different businesses you serve inside of Cerner as well, just that sort of, how do we do the trade off? And I'm curious your thoughts around that, or maybe a couple of times-

Jon Macy: Yeah. Oh, it happens. It happens for us, all up and down everywhere, right? From our clients that we serve. So, we build software, we build solutions, we host solutions. The whole gambit. So, we see all of that and Cerner makes, on a regular basis, decisions to incorporate features and functions, based on a client request. I think that the key to success in that space, is making sure that you have appropriate engagement across who you're serving, right? And so that can occur at any level within the business, but whoever you're serving, you need to have adequate engagement so that, they feel comfortable with engaging an idea that may not be fully formed yet with you. So that, there's a vision process. You see where your road maybe leading and can start to extrapolate out on that, that's where you can also create value. So, a single client's request or demand, right? We get them both ways, could actually generate a whole new line of business aspect for you. If you can take that concept and expanded out to the rest of your client base. Now in the process of doing that, that easily could modify what that client was asking for. And if you can adequately express the vision back to them, they may accept that as," Hey, this is a better idea than what we pointedly were specifically asked you for." And that gets folded then, into your strategy, into your long- term planning, but there will always be business needs or requirements that are single customer base, aren't necessarily matching what you currently have in your storyline. My answer to that is, if the business wants to make that decision to do that, they should fully understand the fact that it doesn't fit the vision, and we need to go back and change the vision, and they should support that. But it's not a no, crosstalk they know, but we shouldn't, within the technical design and implementation space.

Andrew: Right. Right. So-

Jon Macy: It's how much it costs.

Andrew: For sure. For sure. So how does... Is there a formal engagement model with the business, is there a formal way they engage with you? Or do you actively try to spend more time with them? What does it actually look like?

Jon Macy: Yeah. So, at the business level with our clients, we have... There's a formal process for making those changes. Then as it flows into inwards to the company, I would say that it probably gets less rigorous and less specific. Sometimes I get a phone call or a request that comes in, that we have very short period of time to respond to, because nobody thought that they needed to inform us of where they wanted to go. But I also have relationships that pretty much developed over my career at Cerner to... That allows those individuals out in those other areas, to pick up the phone literally and call me and say," Hey, we're thinking about doing x, can you come over and walk through where we think this might go." And that's engagement very early on in the process. I would say the inaudible being able to engage early. And with some frequency, regardless of where in that set of relationships you are, but it's not always going to work out that way. You shouldn't get bogged down in process and procedure as much as making sure that at the end of the day, that businesses fulfilled. The paved road concept has a lot to do with a given vendor, product, solution or capabilities, expression of their vision, right? And how they believe things should work going into the future. Because to a certain... If you can do that effectively, then business will start to align itself within that space, because it is the path of least resistance, especially if it meets needs and fulfills ultimately the business goal. We call that at Cerner, in the clinical space, we call that our model experience. And that's the idea where, if you've got the data to back it up, I can look at how clinicians behave and operate, and the patient care that it's getting delivered between two entities. And if I actually can do that across a thousand entities, I now have the ability to parse that data, to understand which ones are doing what parts extremely well? And then you express that back to everybody and you start to bring all of the ships up, right? All of the ships float together. That's the optimum way of addressing the... I got an RFP that says that I need this very pointed thing. And the customer may not really truly understand that that's not really what they need to solve this other problem. And somebody has jumped to the conclusion that, you making a change in yours, will solve that problem.

Andrew: Right. Right. Right. I heard a couple of things in there, which I agree with, but one is... Part of this is personal, right? You develop a reputation for somebody who understands what the business needs, somebody who's a good business partner, somebody who could meet their requirements, somebody who frankly, can push back when you should push back, right. You become a valuable resource, and I think part of winning is, they're bringing you in early because they want you to be there early, they trust you, they trust your opinion, you've proven track record. And I think that takes experience and it, it takes failures to become successful. Right?

Jon Macy: Oh yeah. Yeah. I have a laundry list of things that didn't make it 100%. Right? And I don't know whoever said it, but" the perfect is the enemy of good." But there's a corollary to that, right? You should understand what perfect looks like and not necessarily have a high degree of disappointment when you hit good.

Andrew: Right. No, for sure. Yeah. Yeah. Meeting the business requirements that there's the functional, non- functional sides of the two. There's cost, there's time there's whatever the case. Right? But when you're the... I like the example you gave around the data measuring the success rate, whatever, whatever-

Jon Macy: crosstalk delivery of patient care, the efficiency of the clinicians crosstalk into that. I glossed that over. Really?

Andrew: No, for sure. But I guess, I heard that as an example of, okay, there's not necessarily a business requirement for this. What you're doing is, taking your knowledge, the data, the systems you have. And in this case, you're basically proposing a new solution to the business. And this is how innovation works. Right? I mean, if we're just constantly listening to requirements of somebody else, and especially when it's a bunch of different people then... And not necessarily looking for the patterns between them and what solution, that's technology innovation, right? you're predicting what they might need, building something brand new, and now you're almost selling what you have. And I think that for me, certainly, it's what I get most excited about it, and there's nothing that excites me more than... We've got a research team here, and sometimes they come in with this very, matter of fact attitude, and ask me if I got a couple minutes, they want to show me something. And like 50 minutes later, my jaws are on the floor, and these are things that there were no requirements for. We weren't thinking about, we didn't hear from our customers. Just, somebody who has seen a lot of data in this case, or in the case you were talking about thinking about better ways to do something or how we can extract more value from it. We see a lot with everything, from different ways to visualize the data, or simulate different things, or, I don't... Just, you know what, crosstalk screw the RFC, right?

Jon Macy: That specific thing may never see the light of day with any of your customers, but you could use 99% of it to solve something else. Because it existed, and somebody could re- envision, right? The use cases and the functionality for it. Yes. That happens a lot, but I would also characterize... When you talk about innovation, innovation occurs from leaders, innovation rarely occurs from followers. So, if you're leading, you are committing to a vision and a strategy, and have a high degree of understanding of what that means. And when you do that and can express it, that's the other key. If you can't express it in terms that the people you're serving can consume it, then you're going to have trouble. You can be right, and they won't go there. So, being able to express that in ways in which they can adequately consume it is paramount.

Andrew: Yeah. So John, maybe give me some advice. So, we've worked with you, I've known you for about six years now, and we've really screwed a couple things up in terms of understanding requirements. And we've talked about it before, in some cases, listening only to you, in some cases, not talking to you, so give me some advice on how you'd like to see my team work with customers to understand requirements.

Jon Macy: You have to find the right individuals, right. Within those contexts, to do that work. So, a partnership... And it doesn't matter what relationship it is, business personal or anything else. But if you classify it as a partnership, there will always be miscommunications or misfits, or divergent views within the same context, the ability to take a step back and be accepting of that fact in our relationship, I look a lot further past my immediate needs, for example, and try... I'm trying to look two, three, four years in advance of where I think things are going. And then, I depend on you guys to have that lens into a broader grouping, to help either tamp down my enthusiasm, to go in a certain direction, or a belief. But I have put the... Done the thought exercises and created my vision and my strategy. And I depend on my partners to help me flush that out and to litmus test it across different areas. So it's always evolving. And I think parts of different organizations are very timid or very afraid that if a customer isn't satisfied immediately in a given way that that's a bad thing, don't get me wrong, as a customer, I want to be satisfied, but really, I want to be satisfied in the context of knowing that I am doing the right thing for my organization and my company, and that the partnership that we've developed supports that. And that includes, taking input or making corrections to my view within the space, I would say, overwhelmingly Andrew, our interactions, between these two organizations, we have created much better outcomes for both evolved and have probably pushed the bar with the capabilities of a lot of other customers in the IPAM DDI space. Because we collaborated and no, we didn't always see eye to eye or meet all expectations, but that's part of the way it goes where it needs to go.

Andrew: Yeah. That's how it works. It's the reason we... I enjoy working with you so much, Jon. You want to have... Look, not everything's going to work. And the key is building that trusting relationship like we were talking before, so that, that's the nature of what we're trying to do with technology, especially if we're trying to push the boundaries. So we appreciate the relationship very much Jon.

Jon Macy: I appreciate it too. We wouldn't be able to achieve all that we have achieved and our goals and aspirations. I would point out to you that some of the architectures and the designs that we worked on together, and the relationship between the companies, preceded you, Andrew. I want to point that out. And it's not just a six year endeavor, it's more crosstalk like a 12 year endeavor. But those designs that Cerner developed, that I worked on specifically, those have actually evolved into something that is now relevant to a larger population of your client base. The distributed model for control and zones of... Fault zones, fault domains, all of those concepts. I guarantee you that, that has translated across that and is specifically translating into the cloud efforts that everybody is making today.

Andrew: Yeah. Cloud crosstalk absolutely. But cloud efforts and data center design today... Designing around fault domains is... This isn't an uncommon conversation we have with customers today, it was years ago, when we started talking to you. So yeah. For sure.

Jon Macy: We're not alone. I know for a fact that you have, from Tabs and everything else, that you guys have got multiple other clients that are thinking in different stages and slightly different ways, but they were on the same road that alignment of some of those concepts is now taking shape across the industry. I love that. Right. I like having a vision that is now something bigger than me.

Andrew: Yeah. Yeah. That's exciting.

Jon Macy: That's huge. That's why I get out of bed.

Andrew: Yeah. Well, I'm right there with you. Fantastic. Jon, this has been great. I've really enjoyed talking to you. Thank you for joining on network disrupted and I look forward to talking to you again soon.

Jon Macy: Excellent. And thank you, Andrew, for the opportunity to have this discourse, and I hope everybody finds it valuable.

Andrew: Fantastic.