Creating Safety for Your Finance Team
Today, we’re exploring what it looks like to transform the way your company finances itself in a new, agile world. Many of our clients, as they shift toward an iterative and incremental delivery approach, realize that the old way of funding the business just isn’t cutting it anymore. Annual funding, long wait times for approvals, and all the read tape that goes along with that, aren’t as agile as the teams are.
But you can’t just wave a magic wand and expect the finance team to forget everything they know and start trusting that you’ll deliver what you say you’re going to deliver based on just a wink and a handshake. There’s work that needs to be done to get them to see the value in a flexible funding model that can support the new agility your delivery teams possess.
Video Transcript
Mike Cottmeyer
So you’re basically suggesting is rather than approve a project that is made up of a bunch of requirements and assumptions about the market and approving the business case based upon the build of those requirements, what you’re really suggesting is abstract the requirements up into a set of OKRs and KPIs that are independent of the requirements or the implementation details so that when the teams are building sprint over sprint or the organizations are delivering release over release, they can measure against the OKR rather than a set of requirements. And so we’re giving the teams or the product lines the ability to pivot the requirements if they believe that is what is going to increase the ability to achieve the OKR that where we’re going
Andy Fine
Dead on. Yep. Okay. And if you look at it from finance’s perspective, you still have a business case. You still have ROI, you still have budget and actuals. So it’s very similar. It’s just elevated up and your funding problems, not solutions at the end of the day.
Introductions
Mike Cottmeyer
Hey everybody, this is Mike Cottmeyer. How are you guys doing? We are here recording for you on a Friday afternoon. I have one of our principal consultants named Andy Fine. Andy Fine’s been with us for what about four years now, Andy? It’s been a month.
Andy Fine
Three coming up on three.
Mike Cottmeyer
Cool. Just feels like four maybe. It’s just kidding. Yeah. So what we’re going to explore when you came and joined us, a big part of your background was in the area of financial analysis and controls, maybe call it modernizing your project, budgeting, your financial modeling, that kind of stuff. Why don’t you set up the problem for us and let’s go ahead and step in and see if we can have an interesting conversation here about how to solve some of these challenges you’re thinking about.
Andy Fine
I appreciate it, Mike. So did come from a unique situation where I was going through multiple agile transformations and seeing the disconnect that the funding side had when we reformed these teams and allowed the teams to have more flexibility and autonomy on what they wanted to deliver. The historical financial processes behind the scenes were not allowing the teams to move or shift as fast as they wanted to when they needed to. And lived it for, I want to say seven, eight years where it just wasn’t a thing. And all of a sudden, I would say in the last five or six years, you’ve had a lot of agile transformations that have been successful, A lot of areas where they’ve matured and to our point, what we believe they’ve become predictable, trustworthy systems. And they’re starting to see that this is a common theme, especially at larger companies with a lot of oversight and overhead that they really need to modernize and get finance and portfolio management to step into the change as a learning organization and figure out how to create. So what I’ll say the solution is create more fungible or flexible funding models to allow the business to deliver the value that they’re trying to achieve.
Funding Models: Why the Status Quo Doesn’t Work
Mike Cottmeyer
So, as we step into it, why don’t you talk to us about how things are typically done now and maybe what kind of organizational behaviors that drives?
Andy Fine
Yeah, so I’m sure everyone has taken a stab at this or at least attempted to do something. So there’s a lot of band-aids out there now in organizations, but historically what you would see is you would see a runway where March, April people start talking about what they want to do the following year, June, July, they get high level swags or estimates, and you get all your senior leaders in a room and they say in June of 2024, this is what we’re going to start January, 2025, and by the way, it’s going to take three to five years to deliver this. What do you guys think? And they create solutions and estimate the solutions and get all this stuff packaged up ready to go. And it sits there as people talk about it for six months. And then if we’re lucky and the money is available come January, February, 2025, we find the right folks and we pull them into a project team and we kick it off and we start running a multi-year project where we know for a fact and everyone’s seen this, or if it’s four months, two months, a year down the road, what we’re doing shifts, market dictates the shifts, customers change what they want and do we have the ability, and historically you don’t see it in these companies to kill the project, kill the solution, or shift to the right thing that the team needs to be working on.
That’s a drastic case, but that’s what we see historically from a runway to delivery.
Mike Cottmeyer
Yeah, that’s okay. Lemme tell you how I experienced that in the past. So prior to starting leading Agile 13 years ago, prior to my time with Pillar, prior to my time with version one, I grew up in the financial services industry. And you’re absolutely right. So six months before I was kind of in the project program management office, we would get all the business leaders together, we’d come up with a list of all the initiatives and we’d put them into the classic gigantic interdepartmental Gantt chart kind of a thing. Everything would be planned out largely waterfall, some of it wrap, but the hallmark of it is that we would allocate dollars to those initiatives and then we had a functionally siloed organization. And then the resources, I know that’s provocative in the agile community, but what we would call ’em, we call them resources, would be allocated to the projects.
And then as you said, the funding would show up, the people would be assigned, typically assigned to multiple projects in the portfolio at any given time. And what you end up with is this tangled up mess of projects and technology and people that are all on this 12 to 18 to 36 month kind of tear, just hoping that you could deliver it at all. But to your point, typically three, four months in business conditions change, the organization needs to pivot and all of that planning just goes out the door. Is that kind of what you’re talking about?
Andy Fine
Yes, historically that’s, I mean I lived it for almost a decade, seen it quite a bit in other companies.
Mike Cottmeyer
Go ahead.
Andy Fine
I was going to say that’s the starting point and then over the last decade you’ve seen a lot of companies come in and maybe this is where you’re going. And they’ve done transformations, some of them bottom up, some of them top down. But with the delivery teams focused on how do we deliver work faster, how do we become more flexible with requirements? How do we create more fungibility in our teams and be able to shift to meet market demands? And so that’s the unique space now where we’re living, where we still see that historical funding model, but we have these dynamic delivery teams that we’ve built and they’re starting to be a gap that’s becoming more present, I would say.
Mike Cottmeyer
Okay. So let’s see if we can explore that a little bit. I’m just going to try to keep putting this into some of my own language and frame so I can pull this thread with you. So we’ve gone through and we’ve done, let’s say we’ve done a well done transformation, not just going in training practices or trying to change culture or something like that, but we’ve actually done creating encapsulated teams. Those teams are operating off of backlogs. Those teams are able to produce a working tested increment at the end of every sprint. And so maybe we’re doing safe or we’re doing something like a leading agile where we have a lean agile program and portfolio governance on top of a bunch of teams. So we have encapsulated products or we have encapsulated value streams or encapsulated business capabilities. Those are all subordinate to a portfolio. So you’re describing an organization where the portfolio can theoretically run small batch projects, decompose the work into epics and features, get those features and user stories down to the team. So the system of delivery has the ability to operate incrementally and iteratively and produce working tests of software at the end of a sprint or at the end of the release. But they’re still subordinate to a financial model that is still attempting to do resource driven long-term project planning.
Andy Fine
Correct.
Mike Cottmeyer
Am I tracking?
Andy Fine
Okay, cool. Yeah, it’s not just because the way you hit on that, the financial model plus how the company strategically creates those initiatives or projects upfront, and that’s playing games with finance. But if we’re tracking that way in that model that you’re still getting your business representatives or partners creating these large solution based projects and then injecting them into that system of delivery you just described, which creates complexities for those portfolio teams on how to manage.
What’s Needed to Change Your Funding Model
Mike Cottmeyer
Yeah, for sure. So in early days when we were articulating our four quadrants model and the base camps expeditions to base camps model, sometimes what we would have to do is changing those financial constructs in the way those projects are conceived is sometimes very difficult out of the gate because the organization doesn’t really trust the system, it doesn’t trust that it can deliver what it says. So what we basically do is we take these project funding allocations and then somehow divvy them up into products and portfolios and teams and business capabilities and all those things. But you’re right, there’s a lot of complexity there.
What would have to be true in the organization for finance to even consider looking at that differently because there’s a lot of safety for the financial controls people and being able to say, here’s a business case, here’s the requirements, here’s the date, here’s the commitment, here’s the expected ROI. And now you have these agile teams underneath it that are basically saying, oh, we’re going to inspect and adapt and we’re going to change and we’re going to figure it out. What are your thoughts on how to balance that disconnect between the delivery organization and the financial control organization?
Andy Fine
Yeah, so I think we were talking about this earlier too. There’s no right or wrong answer. And I think the intent is to come in and not disrupt across the board minimal disruption to achieve whatever you’re trying to do. Your minimal viable product at the end of the day is to create the just right amount of flexibility or fungibility in the system to allow the teams to deliver what they need to deliver. So if the organization set up the way you’re set up, when you look at finance, what they need is they need that trustworthy system. They need the ability to believe what they are going to fund can be achieved. And historically, they’re looking at it from a solution base that’s been chopped 10 different ways for them. And they have confidence that the team, because they chose the right folks and have the right budget can achieve that. In this scenario, we want them to believe that this is the throughput or output that this team is delivering consistently. This is the product that they specialize in and these are the key results that they want to achieve. And if that’s the case, then let’s create a business case around that product that gives them the autonomy to meet market demands. And it could be bucketed by a timeline quarterly annually, but there’s ways now that folks are doing this to create that flexibility.
Mike Cottmeyer
So I’m going to see if we can pull a thread just so everybody listening to us understands the language we’re using. So we talk a lot internally in leading Agile about the idea of establishing a trustworthy system, something where I can put dollars in and I can get ROI out in a really reliable and predictable way. And talk to me a little bit about your view of what does it mean to finance to have a trustworthy system that you can delegate into
Andy Fine
Finance, just it’s black and white. They need to be able to produce the artifacts and reports, and they need to be able to have a hundred percent confidence that the data coming to them is correct. And so whatever processes get implemented from a transformation standpoint, they need to have trust that that system is going to operate and produce the data, the financial data, the metrics that they need to produce either the public facing reports, the audit compliance reports that are out there. If they don’t have that trust in the system, then they’re going to look for ways to gain that trust. And that’s where you’re going to create these one-off teams that are building additional reports, additional functionality that are needed. So finance can have that comfort feeling that what they’re putting the money towards, they’re going to see the return on.
Mike Cottmeyer
Well, I’ve never worked in that office. I’ve worked side by side in project offices and obviously through the work of leading Agile, we end up interacting with that function quite a bit, but it is kind of traditional project management. It’s like even though we know that our plans are wrong or they’re likely to be wrong, there’s a certain comfort to leadership that some leader has said, yeah, this is true and I’m going to go make it happen. So it feels to me like maybe one of the big hang-ups might be is, okay, we’ve put millions or billions of dollars into an initiative and we’ve said this is what’s going to happen. The business has proved the dollars based upon the desired outcome. And it sounds like what you’re suggesting is that at the end of every three months, we might come back to finance and say, oh, we need to pivot. Oh, we need to pivot. Oh, we need to pivot. I can imagine how that might be problematic. How would you recommend these organizations think about that? I mean, how do they tolerate or absorb that much potential change?
Andy Fine
So, this gets into the strategy planning, strategic intent, how you guys are going to line up your objectives going forward. Thematically, what we’ve seen is if we have encapsulated products or value streams and they have objectives that they need to achieve, and those are business driven objectives that the team needs to achieve, that you can wrap a business case with those key results around that. So instead of building a business case for a single solution that you might need to shift in three months, you’re building a persistent business case with key results that you plan to achieve within that calendar year. If it’s an annual basis or within that quarter, or it could be longer. There’s no defined timeline. But what that does then is it allows the business to come in quarterly if they need to. And if they have to adjust those key results, then that’s a conversation with finance. They need to have the teams themselves though they have the autonomy to build any solution against that larger business case to support those objectives and key results. And so it’s giving the teams the flexibility to build and do the right thing instead of producing, just building against the technical requirements that sit in front of them, even if they know that that’s not what the customer needs at the end of the day.
Mike Cottmeyer
Okay. So what you’re basically suggesting is rather than approve a project that is made up of a bunch of requirements and assumptions about the market and approving the business case based upon the build of those requirements, what you’re really suggesting is abstract the requirements up into a set of OKRs and KPIs that are independent of the requirements or the implementation details so that when the teams are building sprint over sprint or the organizations are delivering release over release, they can measure against the OKR rather than a set of requirements. And so we’re giving the teams or the product lines the ability to pivot the requirements if they believe that is what is going to increase the ability to achieve the OKR, that kind of where we’re going
Andy Fine
Dead on. Okay. And if you look at it from finance’s perspective, you still have a business case. You still have ROI, you still have budget and actuals. So it’s very similar. It’s just elevated up and your funding problems, not solutions at the end of the day.
Mike Cottmeyer
So, what it sounds like what we’re doing is instead of giving finance a specific set of requirements, what we’re really doing is we’re making a commitment to finance that we’re going to achieve this OKR and we can make local decisions about how to do it. My guess would be is that the sampling rate would have to be a lot higher. So you’d have to have the ability to do incremental delivery. You’d have to have the ability to make and meet commitments. So while maybe finance, maybe they start off and they’re not all that comfortable, but they get the idea. But then the teams, the organizations develop a track record of consistent performance and consistent hitting.
How Can the Finance Team Protect Themselves?
Mike Cottmeyer
I guess what I’m really kind of hunting for is how does the financial group protect themselves really, how do they protect themselves from maybe a team that doesn’t meet the OK R, the KPIs, because I would suggest they would fiduciary responsibility to have the appropriate controls to make that happen. Any thoughts?
Andy Fine
Yeah, so it’s interesting you said we give to finance, and I think as we modernize our processes and we work with finance, we should do it with finance. And I think this ties into the system of delivery at leading Agile that we implement where we’re not giving stuff to our business partners anymore, we’re building with our business partners and they have a seat at the table. And so as we move forward in 2024 and we’ve changed how we deliver software and we operate as companies, we really are looking for finance to have a seat at the table with the decision making that doesn’t embed a hundred percent trust into them right away just because sitting at the table. But it gives them the transparency into the team and what they’re working on. It gives them the transparency into what they’re making decisions against. It’s not an isolated business case thrown over the wall asking for $10 million. They’re now understanding within this encapsulated product or value stream all of the optionality that goes into that area and what’s the best way to fund work and what’s the best thing to work on. And I really think there’s a shift in mindset for folks coming from finance or portfolio management, which is kind of the middleman in between the two to get that seat at the table and be a part of the decision making process.
Mike Cottmeyer
So, I’m going to pull an example thread. So what we’ll do is we’ll put in the show notes underneath this. There’s a talk that I did a couple years ago, I think I called it Faster Food and a Better Place to Sleep. And it is kind of like two abstracted case studies. One was with a hotel group we worked with and one was with the fast food group we worked with and we were attempting to build a governance model around the creation of new food products. And as you might imagine, it is hard to know how much a new food product is going to cost because the acceptance criteria is do customers like it does the owner, it does it meet the brand standards of the organization. So it’s not like you can specify that the flavor characteristics of it. It’s a very subjective thing.
And so what we ended up doing and the process down at the bottom was food scientists and cooks and different supply chains, and it wasn’t software at all. We put an agile, a decisions framework in the middle where we were actually iterative and incrementally making decisions about how to invent that sandwich. And then the top governance model was a design thinking process and whatever, gosh, I don’t know off the top of my head, but the Stanford design thinking model with the five different steps. And so this is what we did. So we basically said, okay, hypothetically the company’s going to put a million dollars in developing a sandwich and they’re going to run through the design thinking process. They’re going to orchestrate all the components. They’re going to build a sandwich. At the end, we’re going to say, do we like the sandwich or do we not like the sandwich?
If the sandwich is close enough, then done. If the sandwich isn’t close enough but we think it’s going to work, we go back to the beginning and we say, okay, another million dollars, we’re going to do another rev. And we can decide Rev to rev to Rev to rev, how many revs we want to do. We might bound it. We might say, okay, we’re going to do 10 million and 1 million increments, or we’re going to do 3 million and 1 million increments, but at any rev we have the opportunity to kill the development of the sandwich or to let it go. So again, show notes if you guys want more detail on that. I don’t know if that’s relevant in this conversation, but it’s like somehow the financial management process has to be able to deal with the reality that where we’re going into market is uncertain and there has to be some sort of control around that and some sort of expectation.
Andy Fine
I don’t know, honestly, I think a lot of companies are starting to trend that way. There’s a lot of different solutions out there in market right now, but folks are trying to figure out how to be more flexible. So I don’t think we’re preaching something that’s like AHA to folks that they haven’t heard of before. And I think a lot of companies are trying to make that shift right now. I do think that some of the companies are making that shift though without that trustworthy system in place.
Mike Cottmeyer
That’s what I was going to
Andy Fine
Go for. They’re going to fail. Yeah.
Mike Cottmeyer
Yeah. I apologize. Didn’t mean to interrupt you there, but No, I think that is the difference. So there’s a lot of talk about OKRs, KPIs. We’re getting involved in a lot of that stuff with our clients. People understand that people understand the idea of adaptive governance, doing things in smaller batches, starting to maybe get some mind share with the finance guys. But what I just heard you say, which I agree with you, is that it’s the intersection between that and having an organization that can do what it says it’s going to do that actually bridges the gap and makes it work.
Andy Fine
Okay. In that sense. Yeah, and I mean, I love your example. I like to take on and get a lot of examples like that, but halfway through building that second iterative of the sandwich, you realize they don’t want sandwiches, they want burritos. And historically you’d have to go back and rewrite a new business case to support building a burrito for someone. But if you had the business case leveled up where you’re still solving the same problem and going to get the same result, the team should within the same day be able to kill that and start the requirements for building burritos. And in essence, that’s all we want to do is give the flexibility to the system of delivery to make the right decisions. And in some companies it could be a very minor tweak. In other companies, you can see complete overhauls they need based off of the governance and systems that they have in place.
Mike Cottmeyer
So it’s the difference between initiating something that says, Hey, I want a new sandwich, versus, Hey, I want a new product that can go into these markets with these performance characteristics and drive this kind of revenue. If it starts off as a sandwich, great. If it turns into a burrito, then maybe we don’t care.
Andy Fine
As long as we’re hitting those key results, the solution shouldn’t be an issue anymore with how the teams work.
Cultural Barriers to Financial Transformation
Mike Cottmeyer
Do you have any thoughts on some of the cultural barriers? I mean, there’s a lot of change required to be able to do this. What are your thoughts on maybe the cultural conceptual mindset barriers that get in the way of maybe being able to do this kind of thing?
Andy Fine
Yeah, I don’t know if it’s specific to financials at this point, but what I see with all transformations, since people have perceived roadblocks or impossible things that can’t happen inherently, a lot of that is just driven by company culture over a decade of how they operate. And the reality is some of the things that are must haves at companies, data has to be this way or delivered at this time might not necessarily be the truth. And so, it’s getting people to have an open mind about entering this with the ability to shift how you perceive the company and processes to be for the last 10 years that there possibly could be change that leadership has said no to in the past.
That’s the toughest thing for finance themselves. It’s black and white right now. And I say that jokingly because if you actually get into time sheet costs and time sheet reporting and cap and expense splits, the reality is it’s kind of a joke across the board. If I’m managing a project and I run out of cap, I’m going to go find it somewhere else on another project to get what I need done. So what the reality is versus what’s submitted usually is I think we used to say about 60% true, but finance can hold someone accountable. They can come back and say, Jerry, you spent 20 hours of your time on this project. If they have to do an audit, and the way we’re looking at this, not everything is black and white for them, and that’s scary for them. That’s where they need to trust the system. But when you get in the weeds, if we actually implement something the way we want to and we start with a predictable system, implement the financial transformation layer over the top, we’re probably in the 95 to 96% range on trustworthy data because you don’t need to game the system anymore to do what you want to do.
Dealing with Audits and Compliance
Mike Cottmeyer
Let’s explore that idea of audit and compliance. I think that’s kind of a real thing. I have a thought on it, but I’m going to ask you first. It’s like what if you have an audit and compliance framework? I don’t know if that’s the right word for it, that actually says some of these legacy controls have to be in place and the way they have to be in place. Have you ever seen anybody change the way they do audit and compliance to accommodate this new way of thinking about things?
Andy Fine
No. So the change for me is the type of company I’ve worked with private companies where that’s minimal to none worked with public facing companies, but depending on the industry, they might have little tweaks and nuances in there. And then obviously government entities and agencies are a whole nother ball game with the compliance. They have to, that’s where you have to build customized processes and flows. The minimal viable product that works for one company won’t work for another based off of their compliances that they have, the audit compliance structure they have to meet.
Mike Cottmeyer
So, my last corporate job before leaving for version one was with a pretty medium, pretty big financial services company. And we got squarely into this space because they had built all of their audit and compliance frameworks around a waterfall governance model. So you had to do all the analysis, get sign off, you had to do all the design, get sign off all the build, get sign off, all the tasks, get sign off, right? UAT and Signoffs before we went and into deployment. And what I learned there, and I don’t know if this is universally true, but apparently what they were being audited against is their own definition of what their process was. And what was fascinating is that everybody would blame the auditors and say, well, the auditors require us to do this. The auditors require you to do that, what you said you do. And we were actually able to change and create an alternative path through audit and compliance that if we were delivering a project this way, this was the set of audit and compliance controls, and then the external auditors would audit us against what we said we were going to do. Have you ever seen anything like that in practice?
Andy Fine
So there’s a nuance there, right? Yeah. Yeah. So the processes that you put in, this is the perceived culture too I was talking about that was all internal audits, right? Not external auditors. So you build an internal audit process based off of probably how you operate in 1980 or 1990 and that stuff. To your point in areas, people just haven’t thought about change with that. They just believe that is the truth and is needed. But if you talk to your external audit partners, even just around how you capitalize software that’s changed drastically in the last six to seven years, what’s acceptable, what’s not? So times have changed, and those internal audit processes are the first thing I would look at to really see is that the truth? And if you can change some of those, you quickly can transform some of the, I would say, impediments that the company faces when it comes to flexible funding.
Mike Cottmeyer
Okay. Cool. This has been a cool conversation. Anything else that you think we should hit on before we kind of put a bow on this for today?
Andy Fine
No, it’s a good starting point. I think it ties a lot into strategy with OKRs these days. Those two kind of tie off together. I know we really didn’t go down that path, but what I’d want to end on is at the end of the day, the objective here is not to go in and run a full scale financial transformation for someone. It’s just to allow your delivery team to produce as much value and the right value as fast as possible. And so it’s really just how do we create that flexibility with our internal financial processes to allow that trustworthy system that we’ve stood up to deliver maximum value?
Mike Cottmeyer
Yeah, I say it a different way and maybe build, and if I get it wrong, feel free to weigh in and get the last word and we will wrap it up. But sometimes what has to happen is that we have legacy controls in place and we have legacy controls in place for a reason because it’s what keeps the organization safe. And so a lot of times in an early stage transformation, we have to get the system reliable and predictable using agile, using lean, lean program and portfolio governance, investment decisioning, all that kind of stuff. But often in an early stage transformation, you have to translate some of that stuff up into the existing audit and compliance controls. As the system gets into kind of a critical mass and we can actually demonstrate that enough of the overall system is operating in this way, that’s when we can start to think about flipping the top level stuff. That was some of the work that we did with one of the auto manufacturers we worked with where we got the system delivery working at scale and then went and tackled. So there wasn’t any point in complaining about audit and compliance and financial controls in the early stages. We hadn’t reached critical mass, we weren’t trustworthy, and it was only once we got trustworthy that we could go change those critical systems in the organization. Any parting thoughts on that?
Andy Fine
Just this is at scale versus running a pilot or a slice of an organization. And you’ll see this with cloud transformation too. Actually, one of my clients was pretty funny, but with an agile transformation or cloud, you’re funding the transformation. You’re not funding the work at that time. So like, Hey, Mike, here’s a hundred million dollars. Go run your Agile transformation with whatever work you need to and have that team deliver. And I see a ton of results. Cloud transformations a real conversation with a client. I asked him how is processes working? I goes, well, my area, I just get 50 million a year, but everyone else has to go through 15 layers of governance to deliver something. And so what happens is you show all the success within this encapsulated area and then you say, let’s scale this to the organization and this is where the financial controls come back and say, no, we were giving you a pocket of money to go show this experiment, but we can’t scale what you just did to everyone. We need to put some more governance around what you’re doing. And so the lack of ability to scale or fit into the rest of the organization kind of ties off to where once we’ve gone through enough slices and the majority of the folks are there, we should be able to get them to shift the mindset to this is now the new norm and this is how we need to operate.
Mike Cottmeyer
Cool. You brought up a really interesting thing. We don’t have time to go down into, we should really maybe next time talk about how the role of cloud migration, tech modernization, tech uplift, product extraction, how all that plays into some of our ability to create some of these financial control changes as well. Because the more alignment we have between the technology and the people and the business and the finances, then I think this makes it easier to go down this path.
Andy Fine
Yeah, I totally agree. And that would be a cool thing to talk about next time.
Mike Cottmeyer
Yeah. Cool. So one thing I’d ask everybody who’s listening to this, this is an interesting thing to talk about, right? There’s so much nuance and there’s so much different paths you could take. If you guys have listened to this all the way to the end and you guys have any questions for me or for Andy or anything you’d like us to follow up on a specific use case or concern when we pick up the conversation next time and we start to leave Interleave some of the technology conversation into this, we’d be happy to pick up some of those questions and see if we can address ’em for you. But thanks Sandy for joining me. I really appreciate it.
Andy Fine
Appreciate it, Mike. Thanks for having me.