Stacey Borne 0:00:11.8:  

Welcome everyone. Thank you so much for joining us today. I am thrilled to introduce Jake Epley to you. Jake is from Brookfield Properties, and he is here to talk about the amazing story where he has created a very strategic Center of Excellence within Brookfield. A few housekeeping items for you. We are going to hold all questions until the end. Jake said he's happy to answer questions that you may have, but we want to get through his story first. So please hold till the end. My name is Stacey Bourne. I run the Center of Excellence Program for Anaplan and the Certified Master Anaplanner Program. All right, Jake, let's go ahead and get started. So as we get started, could you provide context on what is the big picture that you're focusing on at Brookfield. It would be really good to hear about Brookfield's business and how your own journey as an Anaplan expert led you to Brookfield and what your mission is now that you're leading Brookfield's consolidated Center of Excellence.  

Jake Epley 0:01:24.9:  

I may forget one of those along the way, so remind me. So Brookfield, for those familiar or who are at Anaplan Connect in previous years and you were at Brookfield Place, the mall where Convene was, that's Brookfield. We are lots of different things, but for the Anaplan practice that we'll be talking about today, it's over our real estate business. So we have funds where we go out and gather investors, and then we go and purchase properties that then we lease. Those are managed by multiple different companies. Then we eventually sell them and return back. So very generally, the real estate business is what we're talking about, and our various use case hits anywhere in that business cycle. For me, I previously was at Goldman Sachs for five years, also in their Anaplan space, doing more financial modeling, more on the workforce side, and compensation. Then came over as Brookfield was engaging with Anaplan, kicking off about three years ago as one of the early hires on the group that's focused on the property side, and then eventually we merged the team into one to manage the entire real estate portfolio. For strategic vision, we're really looking at how do we manage growth and how do we deliver products that do what they need to be, what they need to do while scaling. There's a huge tech stack and a complex tech team that's working on warehousing, integrations, and all of those things, and the various platforms along the way that support the business process, Anaplan being one of them.  

Jake Epley 0:03:03.0: 

So we as our CoE are really just working to make sure that our business has what they need and that Anaplan is playing its appropriate role in the mix and that we have data moving, we have the business able to interact with models the way they need to, the calculations work. We have good testing in all of those protocols, so people feel really safe in the platform, and obviously, there's challenges in any implementation. So also overcoming those road bumps to gain adoption and then continue to scale as we want to build more and more and people get excited about the tool.  

Stacey Borne 0:03:36.6: 

Amazing, and when you and I spoke before, you mentioned that you consolidated two Center of Excellence teams into one, and you grew the team from two people to 14. All while moving away from implementation partners. Could you walk us through what that journey looked like and particularly what key decisions you made to build that internal capability and the trust of the teams that you are supporting?  

Jake Epley 0:04:04.5: 

Sure, so I'm going to start with, it's very much not just me, it's our whole finance group partnered with our tech business, which has really supported rollouts across the board. Once again, we're having to work with data movement, our various strategies, our reporting, everywhere that needs to go, and originally, we just had two different groups that were doing Anaplan for different reasons. So we started off with two different leadership groups that were each running their things independently, working with different partners for different use cases. Over time, we saw that we didn't need to be doing that. There were opportunities to bring those teams together, centralize the way that we were using models, using data, and also allow our resources and our really skilled architects and model builders to work across the platform, and also just be part of one larger team where we could be a little more flexible. So that was huge. We started off working with implementation partners, which most do, and that was really great. They brought some industry expertise that I didn't have coming from Goldman. I didn't know anything about real estate and commercial real estate, and so that was a huge journey and great to have those partners who could come in and do some of that work and support in the builds, but then as we went through and matured over time, and we were able to hire, train, and work with folks, we were able to move more of that work internally, take those new implementations, enhancements, and everything in-house, which just is a lot easier when you're trying to build relationships.  

Jake Epley 0:05:43.1:  

It's hard for anyone in the business to work with a consultant who might not be there three months later, consultants roll off of projects, they need to get reassigned. Some people go to consulting because they want to work with different businesses all the time, and so it's hard when you say, hey, we don't know that this person's going to be here. The continuity isn't going to be there long-term, and so our long-term strategy had to be our own internal staffing to bring things, and we also found a fantastic partner called Proxet that we partner with to say, hey, they're bringing us resources, but we're really part of one team. It's a forever model, not a, hey, come in for three months, and then we'll see if we need to extend you type of thing. So that model has worked really well for us as we look to scale and get our products where they need to be.  

Stacey Borne 0:06:37.4: 

That's a really incredible story of how you've been able to scale your team. I hear a lot of questions and discussions around how do you find the right Anaplan talent. So this is something that you've done really well. Could you walk us through what skills and traits you were looking for as you were growing your team?  

Jake Epley 0:07:02.1: 

Yes, so the biggest one is cultural fit. For some of those in the audience who work with me, you can't go on a call without me, without me telling a joke, probably a silly icebreaker along the way. It's going to get dumb, and we really need people who are excited about that. We're a team that likes to mess around and have fun while knowing that we can do really, really good work and so that balance works for us. So as we look to hire and train internally, we had to make sure that people were going to be excited about that type of work environment, and it was going to fit them, and it's okay if it doesn't, but that was step one, and so I think finding something that fits whatever your work culture is, is really important for someone to be long-term happy in a role and to fit in with the team. After that, I think the big things that come in are curiosity and really wanting to know why things work the way that they do, and a plan naturally is complicated. Business processes are really complicated, and if you have someone who is just excited about building technology, that doesn't necessarily support building and Anaplan. You have to be excited about why the business does the stuff the way that they do, and likewise, whether it's marketed or not, as anyone who's a great Excel user can pick up Anaplan tomorrow, it's just not true. You don't have everyone who has that understanding that can understand multidimensionality and what that might even mean. So you really do need someone who can flex into that technical role and understand some of that architecture side.  

Jake Epley 0:07:02.1: 

So as we look to interview, just thinking about how people think, they don't have to have the Anaplan experience, but having a question be, talk me through how you would approach this thing, and it doesn't have to be an Anaplan thing. It could be talk me through how you think about walking your dog and training how to walk a dog. Okay, great. That thought process is really important to think about and think about how you can apply that to the business. So I think understanding someone's thought process is really important.  

Stacey Borne 0:09:11.7: 

Amazing. So, understanding thought process, critical thinking, curiosity, and drive to learn about the business. Those are all amazing call-outs there. So it's clear that you've scaled Anaplan really impressively. You have 300 end-users. You've taken key business processes from two weeks down to two days. Beyond the time savings that you guys have achieved, how has this shift to internally led development changed the conversations that your team is having with the business, and how is it allowing them to be more strategic and dive into strategic analysis?  

Jake Epley 0:09:54.0:  

Sure. I think that it really just helps someone when you can say, this person. It's really easy to say, hey, and then Chloe's going to go look at those dashboards and work through retrofitting that to fit the business. When someone can point at someone, they can see their name on Teams or whatever, it just allows for that buy-in to be a little bit stronger, or they can go get coffee and talk or whatever it looks like, rather than saying, hey, we're going to bring someone in. That unknown entity makes it hard for people to get excited about something because they haven't seen it, they haven't felt it, and so having that internal business, it helps when you have long-term knowledge, you have knowledge transfer when someone is going to leave or move to another team, and so it just sets up for a lot more long-term success. You also have the challenges, and you've been through those, and so you have someone who's been through when that data connection didn't work. They were there last time. They're going to be there for the next time, and so it helps to have that, they know how to solve things. They've been in the production environment. They understand the data, they understand the business, and they will call them up rather than have to be like, oh, let me escalate through my management team, who's then going to reach out to your group, and so it just limits the coordination, which just streamlines, especially when things aren't going well. It's nice to be able to talk to someone who's working on it rather than someone who's going to talk to someone who's going to work on it. 

Stacy Borne 0:11:26.4:  

That's amazing. So there's so much more ownership then and people are gaining more trust in Anaplan and the team owning Anaplan through that. Incredible. So you've taken a really thoughtful approach to adopting the new technologies and features, like CoModeler. You're balancing innovation with your business needs. What is your vision for the next level of innovation at Brookfield?  

Jake Epley 0:11:51.9: 

It goes back to our overall group. So Anaplan doesn't live in isolation. It's not an island, and it can't be for our business to be successful, and so when we're talking about a new request that comes from a team, we need to understand, is Anaplan the right tool for it, just because it can do it, and do we want to take that project, do we have staffing for it, all of those things, but the first thing is, a business group doesn't come to us and say, hey, we have an Anaplan project. They come to us and say, hey, we have a need, and we say, great, what is that need, and then when they come and they say, okay, great, we want data that's in Anaplan, so it should be in Anaplan, and we need to get an Excel page that has three tables on it formatted this way. That is not an Anaplan solution, and it's going to get nasty if we try to do it that way. My team might not have the tool stack for that and so finding our wider tech teams to be able to fit that business need to say, that's not an Anaplan solution. We need to look at a different option, and so to have the business not pick the tooling, unless they have the expertise to pick the tooling, is a big part of how we think about what's next and what tools we should bring in. If we have that business use case that we don't have a tool for, we're going to go out and see if we want to build it or buy it to fit the need. Or maybe one of our existing vendors does have something that's going to come out. We're constantly in those conversations with Anaplan to say, what is the AI roadmap, what is this going to look like tomorrow? Or should we go build our own thing, or should we go work with a different group? 

Jake Epley 0:13:32.9: 

So having those conversations across the tech stack is just absolutely crucial for having a strategy, and that's where really, even if the Anaplan's team sits within finance, they have to be fully embedded into your engineering or tech stack to be able to scale and build the right things and the right tools.  

Stacey Borne 0:13:54.3: 

Amazing, so if we double click a bit into CoModeler, how do you see capabilities like CoModeler evolving from a tool that handles tedious stuff at your business to something that unlocks entirely new strategic possibilities for your teams?  

Jake Epley 0:14:10.4: 

Sure, so right now we've been on a CoModeler for a few months, and it's okay. It's really good at some things, it's really bad at some things, and it's going to continually get better at things, but so we're really finding what opportunities there are to use it right now, but then once again, knowing what things are going to look like in the future. If you were in the other session, I don't see it replacing, you're not going to have CoModeler and be like, great, we didn't need three less model builders. It's just not how it's going to work. It's not how it's designed. It really is that side-by-side thing to say, okay, go build those lists. Great. You go do that while I think about our overall architecture, and so it can handle some of those tedious things right now. In the future, and what we do right now is, we'll use another AI tool that's really good at language to know how to prompt CoModeler, because right now, CoModeler needs very specific prompting to be successful. So we use other tools to develop the prompts to then prompt it with. I think over time, that will get better. Also, what it can do will get better. Right now, it can only touch modules, line items, and lists. At some point, actions will come into play. That's going to be huge. Access, okay, great. Can you do a check for me to see, can this user run that full process before I promote that to a test environment, so you don't have that. Yes, this thing didn't work immediately because I couldn't click the button, and so I think as it evolves, we'll just see more opportunities to test with it, to do validations and also do pre-validation.  

Jake Epley 0:15:55.5: 

One of the things that does do pretty well right now is if you say I want you to build a forecast for me, it's going to ask you the questions to be able to build it well and those questions help the CoE to know what to ask the business if they're not educated in that area. Is it quarterly, are these things drivers, blah, blah, blah, blah, blah, and so I think that's an avenue that will continue to evolve and we'll see our CoE be able to use power there.  

Stacey Borne 0:16:23.6: 

This is one of the questions I hear a lot. So many CoEs start off as an operational support, but they're aiming to be seen by their leaders and by the business as a strategic innovation hub who is responsible for hundreds of end users and for millions of dollars in value. If a new CoE were to come to you and ask you what your advice is on how to ensure their team becomes a trusted strategic partner rather than a support function. What key lessons would you share from your journey at Brookfield with them?  

Jake Epley 0:17:07.1: 

I think the first one and something that we still struggle with and will continue to always be working through, is really finding final solutions and not Band-Aids. It's really easy to have a short-term view to say, great, we have this working for now, and that just comes back eventually, every time, and so as you start working on things, as solutions start to go live, when things don't work quite right or they just barely work, not settling for that being good enough, and then be like, okay, cool, on to the next thing. Because things are going to end up breaking in a big way soon enough, and that's really hard to build trust and rebuild trust, and so that's something that we struggle with and work through. How do you test things really well? Do we have a strong data strategy where we know what the data is going to look like every time it comes in. What is our API picture and how is that tying in with different processes and do we have things that complete the loop that check to see if a load was successful or whatever that looks like. So I think really that long -term approach is really important and I think also something that goes back to having internal groups involved early is really important because implementation partners are fantastic, but they don't know how the business has changed over the last three years to know how it's going to change over the next two to be able to work through and future proof some of those plans.  

Jake Epley 0:18:43.7: 

So I think that's a really big one. The other one has to come down to documentation. It's a tedious thing, but it is really important to have great documentation, and that comes, a lot of times, from having a really strong product management team or business partners who are leading that business-based documentation so users know how to use their models, and don't always look for an Excel way to do things. If someone's using your Anaplan models to dump stuff into Excel, the models aren't built in a good way, and the solution is not a long-term solution.  

Stacey Borne 0:19:21.5: 

That's an amazing answer. So what I'm hearing out of there is validations. Think about what could go wrong before it goes wrong and build in the safeguards to prevent that, and to make sure that your end-users are building trust in the platform. Well, that is all the questions that we had prepared. We'd like to go ahead and open it up for any questions from our audience.  

Audience 0:19:49.7: 

Thank you for the presentation. How much of the folks in your business side are Anaplan model builders and actually build?  

Jake Epley 0:19:57.5: 

In our current world, no one in the business. So our CoE, there is what not in our CoE, there are other parts of Brookfield that also use Anaplan and there is one person there who is a businessperson who also is building things. The rest of the things we run through the CoE with the business reaching out to us and us just being partners on a solution. 

Audience 0:20:23.6:  

Got it, thank you, and follow on, you mentioned you had 14 people on the team. What is the profile of them? Do you have a master, a few architects, a few model builders, and a BA? Or what does it look like? 

Jake Epley 0:20:32.5: 

Yes, so the way that we look to approach things is having a solution architect aligned to each work stream. For us, a work stream might be one model, it might be four, just depending on the scale and how many enhancements and new builds are coming through. So when we have a new model complete work stream come up then we're looking at do we need to add an architect or does someone have capacity to flex across that and then model builders really just depend on how complex a given solution is. Brookfield is very much a strategy from bringing in at the architect level and starting there and so we look to have our architecture really owned internally, and then we early on looked at, should our model builders all be internal before we had developed a relationship with Proxet and found great model building solutions there, should we have staff, or should we have partners that we bring in some model builders temporarily, but early on, our goal was fairly much to own the architecture internally, and so starting with architects there. I think technically, I think that we have six or seven solution architects. One person is a master Anaplanner, but some of our solution architects are more experienced than some of the master Anaplanners. I'm big on certifications not being the only thing that makes a qualification.  

Audience 0:22:07.5: 

I have a couple of questions, and one of the first questions, like in Anaplan, you will be receiving the data from various applications, right? So as part of, what's your operating model? As you said, innovation, it's an innovation hub. So you are part of IT, or you're outside of IT, you're part of the business, and how the data flows in, like who's responsible for integrating all the various other applications? That's first.  

Jake Epley 0:22:37.3: 

Yes, great question. So we sit in IT, I report directly to our CTO, and then I have a dotted line to our CFO. So we sit in IT, but are very, very close to finance. For who owns integrations and those things, it depends on which tooling we're using, but really, it is an ecosystem. So Snowflake is our warehousing tool and how we move data from Snowflake to Anaplan, from Anaplan to Snowflake or to other applications. It really is a joint effort to say, hey, for this product, how are we going to work things through? And if a pipeline fails, it's not just the integrations team, because it also affects the warehousing team, and it also affects the modeling team, and so it really is a product focus to say this business product is the entire work stream. It starts, made up scenario, but it starts in Snowflake, There's an API that brings data to Anaplan, Workiva picks it up, and then that gets sent out. That whole thing is the product, and so the integration is owned usually by, or the data movement is usually technically owned by the product managers and owners because they have that full lifecycle view instead of just a, hey, Jake's group owns the Anaplan side, let's go check to see if that's an issue. It's the product team who has that larger focus.  

Audience 0:24:08.: 

That product team basically is part of the innovation team itself, right?  

Jaze Epley 0:24:15.0: 

We have different models for different products. Some of our product teams sit within the business or are a layer between that are a digital transformation team, or our process and improvement really focused on particular businesses, and in some cases, the product sits directly within our technology team. It just really depends on how complex the business is and how mature they are.  

Audience 0:24:38.0: 

Excellent. So the last thing, what you talked about from a capacity perspective. Since you're serving the business sitting in IT, how do you say that it's the Band-Aid? I really love what you said, that we want to find the real solution, not just put some Band-Aid on, which means sometimes it's going to take longer. So how do you convince your business or what's the, again, the operating model that people have adopted?  

Jake Epley 0:25:07.0: 

Yes, so luck is the start with that. We have some really, really strong senior management folks who have a really good eye to tech to understand, hey, let's do this right and let's get this fixed. Even if it means that I can't use a tool for 10 days rather than struggling through it constantly for a while and having that last for two quarters. So I think really that sponsorship and the partnership are really big. So that way you're doing that solution together and you're working in the business to say, hey, that enhancement that you really want, let's pause that. Let's push that out to the next thing because we have a big code change that's going to come through. Let's figure out the code change. Make sure that we're okay with it, and then we can get back to enhancements, and so I think really focusing on what you have now instead of always pushing for new is big, and that really, once again, comes from trust with the business.  

Audience 0:26:12.8: 

You mentioned some quite significant headcount increases. In terms of getting approval from that from senior management, was one of the things, if you can just talk about that and was some of it which could demonstrate real significant time savings from the Anaplan processes. You mentioned things from two weeks to two days, so management could see there was reduced labor need overall.  

Jake Epley 0:26:38.7: 

Yes, so we have quarterly touch points with management to talk about what Pipeline looks like, what people want to be doing in the tool. For those who aren't in Anaplan yet, the classic pipeline is, you do one project and people get really excited and want seven different things and they want to build back one step, they want to build forward two steps, and they also have this really annoying other process that, oh, everyone can just put their data into Anaplan, let's make a consolidation tool. That's not where we originally used it for budgeting, but everyone put their headcount into that, and yes, it calcs some stuff, but it can just collect data. That's great, and so I think understanding that that rush is going to come in, and then working with your senior leadership to prioritize, plan. So what we're really looking at, for the most part, is our headcount is coming up because we have more processes that we're building in, more use cases, more work streams. It's not about, hey, we have this one thing that is taking us a month to do. If we had a second person on it, it could take us two weeks. It's really looking at additional solutions.  

Audience 0:27:52.2: 

So when it comes to quality of code, model building code, do you have solutions for that? Do you maybe peer review the code manually? Or maybe you're looking into automating some of the code review to improve quality?  

Jake Epley 0:28:08.8: 

Yes, so code review, so the first thing is we have a design standard on how we should be writing things, how we name things, from line items to modules to actions to pages. We also have a design guide for how we're building pages from our UX specialist, and then we do, so each item gets developed and then peer reviewed before it goes into a UAT. So that happens and then we aren't doing it now but something that we have had conversations about is also doing some sort of, probably quarterly maybe semi-annual depending on the business process overall product review to go back through and that's where I see CoModeler being a great assistant there, because it can look for some optimization efforts, it can document things, you can find, ask it which modules are absolutely crucial to this process, and figure out maybe there's some areas where we need to move some things around.  

Audience 0:29:11.2: 

Hey Jake, great talk. Can you talk a little bit about support and how you think about post-production support on models that you've built. How does that factor into the CoE that you guys have built? Are there things that you're doing to optimize that or make that better?  

Jake Epley 0:29:30.9:  

A great question. Absolutely something we're looking at. When you roll a tool out, it's never perfect, and sometimes that's because people don't know how to use it, and sometimes it's because it wasn't built perfectly, and a lot of times it's both. So when we do have a big thing go live, either a brand-new model or app or just a big enhancement come through, we're always expecting some post-prod support to be more heavily intense. The real thing that we look at with that is staffing and as we're looking to roll out three new products in Q3, we know that even though we want to start on new stuff in Q4, we need to have those people who are on that work stream available for post-prod support and not just working on the brand new thing. So right now, it's more on the allocation side, but something that folks on the team are really good at too, is just getting on a call. The biggest challenge is when people are sending pings and emails and especially if you don't have a ticketing system or people are not using it, you have so many things flying around and things get dropped. So our business is really good at it, and the CoE really strives when there are issues, just get on the phone with people. It's so much faster to resolve things, and a lot of times it's like, oh, you just need to click that button and then it will be live, and other times it's, hey, we have a really big issue. Let's go look at that right now rather than check out that email two hours later.  

Audience 0:31:09.5: 

Thanks, Jake. Thank you for sharing all of that. I'm Nancy Kiriro from Ares Management. I have two questions. My first one is, we are rolling out builds, Anaplan builds, and what I'm observing is our teams are excited and they start to use them, and then when they get into quarter end, they lock out. These are like our fund accounting teams, and they jump into Excel if they need to do something or tweak something that doesn't exist on the model, which like just the trend and the adoption is not great. Have you run into that and how have you dealt with it?  

Jake Epley 0:31:50.0: 

Yes, I think it's pretty common that early on in a solution people haven't thought of everything or the business has changed and there's a new requirement there's a new lever that you need to push and pull on. I think there's two different ways. We actually just had a conversation with a group in our business about this. One is to say, hey, if we know that things are going to change, leaving room for some level of override to come in. It's not ideal. No one wants to have a manual override in there, but if you know that the business is going to change, that's really important, and then what we look at is having that postmortem immediately after the cycle to say, hey, great. We got through it, you guys had to go to Excel for this piece. Let's talk about those three letters that you pulled on, and let's make sure that they're in for the next quarter, in for the next round, and also some of it comes into how management is presenting the solution on what's an acceptable margin of error and what can we footnote versus what needs to be exactly a certain way in the tool. I think the overall strategy has to be making sure the business understands that the next time they won't have to do that manual thing again, and there might be a different manual thing, but eventually you're starting at that 80 per cent of the business process, and you're slowly going to build your way up to 95, and the remaining five per cent is always an unknown. You just can't plan for it.  

Audience 0:33:12.2: 

Thank you. I thought so. So it's just good to hear somebody who's further along on the journey validate that. The other question I have is you have that CoE, which you've said is about 14 people. One of the things we're concerned about, even just working with consulting resources, is again with our primary users, which is this accounting team, they go into this blackout period at the end of every quarter. We lose them for about a month, a month-and-a-half. So part of my anxiety with having full-time staffing on a CoE is what do you do with them during that blackout period?  

Jake Epley 0:33:51.5:  

Yes, so it's a great question, and I think it really depends on your business. Depending on how complex your models are, a blackout period is fantastic for going back and looking at that documentation start spot, looking for optimization, planning your enhancements to say, hey, this works okay, but it would be great if we could do this, and so we have tickets or things that are raised by the business that we work on, but we also have our own internal ones where it's like, I really don't like the way that this thing works. It works, but I really don't like the way that it works. In between the next time, when we aren't getting enhancement from the business, when they don't have time to test, let's go take that one off. We're going to go fix, fix. We're going to go change that to work a way that we can work with it better. Whether it's breaking outline items and multiple formulas, changing things from like a saved view to a published view, whatever that looks like. I think that's big. The other part is just understanding, are there other parts of your business that you can be talking to. We have 14 people across six different workstreams. We also have a big backlog through 2028 of things that people want. So if one of our groups says, hey, we don't need that anymore, we have other things to do. So I'm not worried about our staffing situation, but that obviously comes with that understanding, the trust that's built, the number of businesses that are aware of the platform and use cases that are going to make sense.  

Audience 0:35:27.2: 

Thanks, Jake. I was wondering, how does your team quantify the feedback you guys get from stakeholders to measure the outcome of new builds or enhancements that you guys do?  

Jake Epley 0:35:41.4: 

I think it comes a little bit more back to the product side of those folks who are owning the end-to-end solution to give us that feedback of, hey, last cycle went fine. On a side note, people were pissed that the model was busy a bunch. Is that something we can do something about that? So we're getting that feedback from those who are really tight with the business. If you don't have a product team, you might be that group that's really close. For some things you can see it, right? There's amount of time it takes to run an action. There's a lot of data in the hyper models, or the hyper reporting models, if you have that, that tell you how often users log in, how many times they click certain things, how many times they open a page, and so it's great to be like, hey, no one ever opened this page. Someone wanted it at some point, but no one uses it. So let's not spend time maintaining it, editing it. Let's figure out a sunsetting for it, and this one's really important to people. So let's either not touch it because it must work really well. Or let's really focus on it, because people really need the information there, and there might be some opportunities. So I think whether you have that data directly, or you need to work with a team after, similar to here, those postmortems after, immediately after, are so important to understand how people are using the tool. Because a lot of times, it's not the way you think they are.  

Audience 0:37:14.6:  

Okay, we have time for two last questions.  

Audience 0:37:16.0:  

Thanks, Jake. A couple questions on the complexity of your models or work streams. Do you have a framework that you use to evaluate those in terms of resourcing and hiring, particularly around like solution architects?  

Jake Epley 0:37:34.3: 

Yes, so it's usually in our initial build assessment. So assuming it's a brand-new product, we're going to sit down with the business and say, what is this thing, okay, great. We understand that it should go into Anaplan, and then we're understanding what is the business case, and before we're even fully thinking about how many resources or committing to timelines, we're understanding what that complexity looks like. The short answer is super complex for some of our things. Between financial institutions and ownerships and things like that, real estate is just a weird world that has a lot of nuance, and so there is a lot of complexity, but it's that understanding we can get pretty early on. A lot of it also comes from talking to the business about how their stuff has gone. If they know that every year their stuff is really hard, and they're always updating their existing Excel models, you should expect that their Anaplan model's going to need a lot of work, that they're going to be making changes, that their business moves, that they're asked different questions every quarter, every month, whatever that cycle looks like. So in that, we're going to say, hey, that one we need a really strong architect on, we need someone who's that really flexible, they're thinking about scaling. We even look at our existing architecture, and I'm a loosey-goosey person. One of my other architects is a former accountant, and he's the guy that's going to tie everything to the number of being super discreet on it. He's fantastic at all of those things, and great with accounting.  

Jake Epley 0:39:08.6: 

I'm the guy you bring in when stuff gets weird, and you need to work around the tool, you need to work around the business to get through a process. So I think, as you have some scale, you can also flex the right people onto the right projects.  

Audience 0:39:26.4: 

Hey, you mentioned documentation around the models. What form of documentation do you feel is actually usable and helpful, is it Word documents or like notes on dashboards? What do you feel like users actually engage with? Because I find having Word documents, like a 15-page document, no one's really reading it.  

Jake Epley 0:39:50.2: 

It's something that we're always looking at as well, and we've done everything. For some places, we have PowerPoint slides that have screenshots and that point you to this does this, and some stuff it's embedded into Anaplan. I'm actually really excited about the insights panel coming to pages, because I don't see a lot of value in the worksheet type pages. So having that insights panel be able to pop out some directions without it always taking up space, I think will be really nice. We have Word documents, we have it in Monday.com, we have stuff in SharePoint. It's a little bit everywhere. I'm going to point it back to you really need to understand how the business is going to work with it and what they're going to do. For some they need an Excel version that shows them how a calc works because they just won't understand it any other way. Even though they're not going to use that for the model, it's not scaled, it shows them actually how the calculation works and how using an override works, but short answer is I don't have a great answer and it's super dependent and something that we're always looking at because it's hard.  

Stacey Borne 0:41:01.3: 

All right; these have all been amazing questions. Thank you so much for sharing, Jake. What I've heard out of this session is grow trust in the business, have a curiosity about the business, and do things really well without taking shortcuts. Those are some of the themes that we talked about, in addition to many others. I really want to thank you for coming on stage and sharing with everyone. The next session in this room is RGM. It's hard, but it matters more than ever. So if you're interested in that, feel free to stick around and check out the next session. Thank you so much for joining us.