Unlocking Financial Model Secrets and Advanced Techniques with Stephen Aldridge

Tell me about the worst financial model you've ever seen.

This one did get me thinking a bit because what is it that makes a model bad? What makes it the worst? So I think the one I've gone for though, is one that we were auditing some years ago. The way we do that is we look at, find all the unique formulae, we check each of those, and 62% of those had some kind of error or query about it. It's very important to think about the human aspects of modeling and what goes around it as well, the assumptions we make and bias that can creep in and all these sorts of things. So we have a more tightly def standard in house than the financial modeling code. But in the wider world, having something that recruitment people can point to and say, you should use something that complies with this, I think that's helpful. I think there's a few basics which pretty much everybody probably should stick to, and that things like copying formally across and not using it.

Welcome to Financial Modeler's Corner, where we discuss the art and science of financial modeling with your host, Paul Barnhurst. Financial Modelers Corner is sponsored by Financial Modeling Institute. Welcome to Financial Modeler's Corner. I am your host, Paul Barnhurst. Every week we talk about the art and science of financial modeling with distinguished financial modelers from around the globe. The Financial Modelers Corner podcast is brought to you by Financial Modeling Institute. FMI offers the most respected accreditations in financial modeling. I am excited to welcome to the show Stephen Aldridge. Stephen, welcome to the show.

Thank you, Paul. A pleasure to be here.

Really excited to have you. So we kick off every episode with this question and I'm sure you have an answer. Tell me about the worst financial model you've ever seen.

Yeah, so this one did get me thinking a bit because what. What is it that makes a model bad? You know, what's. What makes it the worst? So there were a few candidates. So I think the one I've gone for though is, is one that we. We were auditing some years ago. And the way we do that is we look at all, find all the unique formulae and then we'll check each of those. And 62% of those had some kind of error or query about it. So I think it has to take the prize for the worst worst model. And that included all sorts, like 62%.

Of every cell like that has something formula.

So one that's not a copy. Yeah, 62% of them. So effectively 62% of all the formula had some kind of issue with it that we, we raised a comment on. So. And it was just. It wasn't a great model. We had lots of indirect sumifs over huge ranges and all these sorts of things. But the thing that really strikes me, or remember I remember about that project was the client's attitude to that was really what they wanted us, for us to sign it off. And they didn't really want to do any work to fix the model. They just wanted to do the bare minimum. Um. So yeah, we had, we had some fun and games with that one.

Yeah, I could imagine if they were like, no, just sign off. It's all good. We don't need to do anything.

Oh, yes, not really.

Yeah. Indirects. Yeah, I think everybody's used them some, but you just have to be careful when and how if you have nothing but indirects, it can be concerning.

Sure, yeah. I mean, it's like most things, you know, there's a time and a place and if you know what you're doing and you, you know what risks you're taking and you mitigate those. Yeah, that's fine.

Yeah, that's how I am with most things. It's like, yes, there's rules and there's almost always a case where you're going to violate those rules. But if you understand why they're in place, then, and you're, you know the risk you're taking and you're doing it appropriately. Okay, then I'm okay with that. I may not choose to do it the way you did, but I can at least understand it.

Yeah. Yeah, that's right. Yeah. No, I think so.

So what was the key learning or kind of your key takeaway from that model and that whole experience?

Yeah, I think the key learning from that was really about the people side of this, that the model is just part of it, but there's always people involved. And in that case, we had what we call a picnic problem, which is problem in chair, not in computer.

Yes, I've heard that one. As soon as you said it, I was chuckling.

Yeah. So it's very important to think about the human aspect of modeling and what goes around it as well, and the assumptions we make and the bias that can creep in and all these sorts of things.

I agree with you. There's a human component that just cannot be overlooked. It is so important to the overall model. The rest of it's kind of math and design.

Yeah, that's right. It is. Yeah. It's a dangerous generalization. But, you know, modeling attracts a lot of People who like working with computers more than they like working with people. And you know, really, you, you need to be able to work with people as well and, and understand how they're, how they're interacting with the model.

Totally agree. Well, you know, thank you for sharing that experience. Can you tell us a little bit about yourself? Just introduce yourself to the audience here?

Sure, yeah. So I've got old nails. I've got a lot of background to my career. I started out in engineering and did. I started with Excel actually my early engineering jobs, testing physical components and using Excel to do. To do the analysis on that and was writing what were then Excel 4 macros and you know, reading stuff in through CSV files and this kind of thing from, from transducers and all sorts of stuff with little programs to make that all work. And I just carried. I really enjoyed that and I carried on finding a way to use Excel in everything I did. Even for a while I was a salesman. I wasn't able to do much there with Excel but I was studying for an MBA there, so I was able to use Excel on all the assignments for the MBA as much as I could and that sort of thing. And I went to a sort of corporate management role where I was again using XRC. There's also Lotus 1, 2, 3 in those days, depending on which firm you were dealing with. And so I was doing a lot of analysis in. In sort of a corporate role. I got made redundant from that role and then found out that KPMG were advertising for what sounded just like what I've been doing and they were calling it financial modeling. I'd not heard the term before but, you know, I, I applied for that and got a job with them. I spent about six years there and, and in their financial modeling group and then about another year with Deloitte in their modeling group before joining a former colleague, Devora McCann, who'd, who left KPMG about the same time as I did and he'd started doing modelling as a contractor but he founded Numeritas. And yeah, we'd been talking and to cut a long story short, yeah, we joined forces and sort of launched Numerators as a firm rather than one person. And that's 20 years ago now, we've been going since then and sort of tried to grow the business and offer similar sort of standard and quality as you would get from one of the biggest firms, Big four firms or whoever, but with a more personal touch, of course.

Well, it sounds like quite the background, engineering cells and modeling in There a little bit of.

Yeah, a bit of an all rounder.

No, that's good. It's good to have a variety. I think it makes for a lot of fun versus doing the same thing the entire time.

Yeah. And actually, I mean having some sales experience is a useful skill if you're running a business as well.

Yes, I've had to learn a lot of the sell side. It's definitely a useful skill to have. It's now that I'm running my own business. Wasn't something you did as an FPA professional?

No, sure, sure. And you know, it's all important really, isn't it? Without that, nothing else happens.

So true. So I want to, you know, talk about something you and I chatted about beforehand. Before we recorded this. We discussed modeling design principles, you know, and how there's a lot of different standards out there. And you mentioned you worked on a project to help kind of create a framework for modeling. So can you talk about that experience, share what that was like?

Sure, yeah. So this goes back a few years now and you know, if you see government procurement or anything of that sort then you know they're trying to, they're often having to procure financial modeling and they were looking for a way to kind of set a minimum standard. And I started to see them specifying the fast standard. I'm not a huge fan of fast standard. It's not the way I like to build models. That's not to say it's terrible. I agree with quite a lot of what's in it, but I didn't want. So what this was effectively was people who are non experts telling people who are experts how they want them to build a model by specifying this standard. And I thought, well that's not a great situation. So I had a lot of contacts, well still at KPMG and Deloitte and some of those people have moved to young, some of them have moved to BDO and various other big accounting firms. So I basically just, you know, contacted. So I managed to get, get contacts in, I think the top seven accounting firms and a handful of independents and said, you know, do you think here's a case for putting together some kind of framework. Are you in? And most of them said yes. So we essentially. So it's been quite a long process really. We started to pull what we each thought was best practice. So we each had an in house style guide or an in house methodology. We essentially put those on the table and then argued points out and debated over which points we all agreed on. Which points were different, and tried to come to some kind of consensus about what we could all agree on as a framework that allowed the broad range of modeling approaches, but provided some kind of useful guidance. If you didn't know really where to start.

Got it. That makes a lot of sense. And I'm like, you, I've read the fast, and to me it just felt overwhelming. I'm like, really, you want me to follow this many pages of rules? Like, I'm going to spend six months just understanding all this?

Yeah, well, I mean, it's. I know how it originated because I know, I know the guy who, well, the guys who originally wrote it, and they did come talk to us at the time and said, would you. Will you adopt this? And we said, well, it's. It's a bit too prescriptive, a bit too down in the detail. If you take it up a level, then we will. But they, they went ahead with the way it was. And I think that was really because they were hiring. It was originally a methodology of a single firm, and they were hiring MBA graduates, teaching them from scratch how to build models. So they needed a set of rules that they would all stick to. So that's, you know, it's very much rules based, but it doesn't allow for a great deal of creativity, I think, in the way you set out your inputs and things like that. And I've got a few other problems with, with things like sign conventions and things like that. So I prefer something that's, you know, a little bit higher, higher level in terms of the sort of direction it gives.

So how did you, you know, you worked on that project and tried to come up with some kind of framework. How did you come to conclusion, what you thought was the right level? Because it feels like that's always kind of a challenge is, what is that right level? How descriptive do we want to be versus how general do we want to be?

Yeah, and that was one of the biggest challenges, really. And also when you've got like a dozen firms all. But that was one of the interesting things that I took away from that, is that these are all professional firms, all doing this as a specialism, but each had a slight different way of doing things, depending on their focus, you know, exactly what, who their clients were, or if they were doing mostly mergers and acquisitions, or if they were doing mostly project finance and so on. So in the end, and that was partly why it took so long, because trying to find a consensus was tricky. But what we ended up settling on was things that we Recommend or suggest is a good thing and things that we suggest you avoid. So we kind of left a fair amount of latitude, if you like, in exactly the approach you take. So we came up with things like you should have a sign convention. We didn't specify necessarily what it was, but, you know, that you should have a sign convention. I know I have a preferred sign convention, but, you know, not everybody agreed on that. So, you know, this, this was very much a work of a large number of people rather than. So it's not my standard.

Sure it was. It was a group of people where you all had to come together and.

Try to find and, and, you know, that ended up. I'm just, just to sort of finish the story. We, we then wondered what do we do with it? And you know, do we. Do we form an organization and publish it or. And you know, there was no appetite for doing that. So in the end, what we did was basically hand it over to the ICAW who, who kind of adopted it and they sort of redrafted it, so putting it into more layman's language and published it as the financial modeling code.

Yes. And I, I recently shared that on LinkedIn, you know, that the code, I thought it was good. I, you know, I browse through it. I didn't read everything, but the guidelines and the general rules all made sense to me. There are one or two areas where my. I might see it a little different, but in general, yeah, overall it's like, all right, this seems solid and not. It felt like it struck a good balance between being very rules based and, you know, not being so high level that you can't implement anything. I thought, I thought overall it was a pretty, pretty solid, solid document. So what was maybe your key takeaway or learning from that whole experience? What did you take away from that project?

Well, I think it was this, you know, the fact that there were so many slight differences in, in approach, all of which were valid. You know, these are all people who did this for, you know, as a group of people who developed what they considered to be best practice or something that worked for them. But there were nuances about how that were different between different firms. So that was really interesting, actually. It kind of says there's no definite right way to do these things. There's a number of things which you can argue are equally as good as each other.

What were the areas that you tended to see the most discussion, like divergent views? Was it around signs? Was it around using vba, you know, circular? Was there certain areas where there was really just a lot of discussion and it was hard to come to any kind of general consensus.

Yeah, that's a good question. Is it a while ago? So I remember. So hard coding, for example, I mean nobody likes hard coding, but you know, what, what do you consider hard coding? Is A12 a hard code? If it's obviously the number of months in a year, you know, there was some people saying yeah, that's fine if, or 7 if it stays in a week, whatever. But you know, and then I mean I'm a bit of a purist on that and I prefer to have it as an input that's labeled. Maybe, maybe it's a got a name range as well. If it's something you're going to use a lot and you know, then it's obvious what it is. But you know, there were differences in just lots of things. You know, there was very little that was unanimously agreed on. Absolutely. I think circular references was probably the one thing that we all agreed on actually. We didn't like them.

Yeah, I, I don't know that anyone likes circular references. A lot of people view them as kind of a necessary evil on, you know, a big debt model to at least get that calculation going and then maybe use a macro or whatever solution you have. But outside of that, yeah, there's some.

Some thing on project finance particularly where you know there's an inherently circular problem because you, you're forward looking, for example. So. Yeah, but I would have a macro or a goal seek to break that. So I don't consider that to be a circular reference. When I say circular reference, I mean that you switched on iterations in Excel and it's kind of trying to resolve that. And you can get divergent ones, which is scary. Each time you press F9 you get a different set of results. But the other reason I don't like circular references is that, and we have this. Sometimes we receive a model for auditing and I notice it's got iterations turned on. So switch them off and you find it's got a circular reference and there was one that was intended but if you break that one then you sometimes find there's a few others in there because as soon as you switch iterations on then it doesn't report any others and you can accidentally introduce other circulars that you didn't intend to. So that's the big reason I really don't like them.

Yes, I have a model that had that where person who had built this a long time, quite a while a while ago now. And five, 10 years ago, and he built it and I remember had some circular references, and I don't know that I ever found all of them. But, you know, we still use the model. I probably shouldn't admit that, but that is exactly the type of thing you're talking about. So I get it. I had one like that. I think I finally got rid of them all when I completely rebuilt the model. Why do you, I mean, why do you think having a standard is so important? I mean, what do you think the benefits are for having, you know, some kind of general standards out there for people?

So I suppose a few things within a firm, you probably want a house style at least, and an agreed approach so that if somebody else picks up the model, has to work on it, or somebody leaves, then, you know, you've got continuity. So, I mean, that's a big thing for us. So we have a more tightly defined standard in house than the financial modeling code. But I think in the wider world, having some kind of something that procurement people can point to and say, you know, you should use something that complies with this, I think that's helpful because like I say, you often get people who need somebody, they need a specialist to do financial modeling. How do you choose or how do you procure something that you're not an expert in when you're having to rely on experts to, you know, to, to do that work? So I think, I think it's useful from, particularly for that point of view.

I, I would agree. So how do you guys think about that at Emeritus? Are you using kind of the guidelines you put together the, the code? Is that generally what you guys follow for your style now, or how do you think about it there?

Well, we, we've, we sort of established our own methodology, if you like, that sort of fits within that. We call it skills, which is spelled with a C. So that's separation, consistency, integrity, linearity, and simplicity. And you can sort of drill down on each of those and there's a bit more within that. So separation means separating your inputs from your calculations from your outputs. But also that includes hard coding. You'd separate out assumptions from calculations at that level of detail. So that, that's kind of a high level and it's a nice little mnemonic that helps to remember it. We've got that broken down to further levels and there's, there's some videos on our website if anybody wants to, to drill into that. You can just, you can search for skills. Okay, Spell either spelling, and you should find it there's. A. There's a search on the website and.

So it's S, S, C I L.

L, F. Is that S, C I L, S. So separation.

Okay.

Yeah, yeah. And the last one being simplicity.

Got it.

A lot of people I think have been on the show agreed that simplicity is, is important.

And I think, yeah, that's another habit that's taken me a while to break. I used to. Everything I'd make is complex and the older I get, the more I realize just keep it simple.

Yeah, yeah, well, that's right. And so, I mean, we like to break things down and have flags, encounters and things like that to, you know, when you're trying to figure out when things happen on a timeline and that sort of thing, break those formulae out into small steps. So, yeah, I think there's a lot of agreement on that amongst most people.

What advice would you offer to firms, you know, companies as they're trying to implement a standard or, you know, guidelines to mention, like you mentioned skills that you guys use, you've helped with others. Any thoughts you have about going through that process? Because I think it's something, especially in corporate finance, when you get into more, you know, modeling and consulting firms, I think they tend to have standards. But what I've seen in corporate finance is it's often the wild, wild west. Any advice on kind of how companies should think about that or go about potentially implementing some guidelines and standards for models?

Yeah, so that in a way that's kind of what the financial modeling code is. Is about. It's. If you like, it's the. Here are the things that you should consider and that you should decide how you're going to approach those for your particular needs. If, if you're in a corporate and there is going to be a fair amount of financial modeling being done, then you probably need an expert to, to set that up. You maybe, you maybe have somebody to lead that and, and you know, they're naturally going to bring with them their own history and background to it. So, so, so, you know, it's going to probably look like what they're used to, whichever firm they came from. But yeah, I think about the particular type of modeling that your firm is doing or that you need to in your company. I think there's a few basics which pretty much everybody probably should stick to and that things like copying formally across and not using hard coding. I mean just some basic stuff like make sure everybody understands about absolute and relative referencing. That in itself helps considerably. But I'd also say use styles. I think Excel styles are kind of underused, but that helps keep everything looking consistent as well. And you can set up things like your input cells that have protection switched off so that those can still be accessed even if you activate protection. And so we've got our own set of house styles that we use, helps keep everything consistent and it has that sort of thing already set up. So yeah, so I think that's probably the sort of approach I would suggest start with something like the code as a Here are the things to consider and try and work through what you think you need for your own purposes.

In today's business world, financial modeling skills are more important than ever. With Financial Modeling Institute's Advanced Financial Modeler Accreditation program, you can become recognized as an expert in the field by validating your financial modeling skills. Join the Financial Modeling Institute's community of top financial modelers, gain access to extensive learning resources, and attain the prestigious Advanced Financial Modeler accreditation. Visit www.fminstitute.com podcast and use code podcast to save 15% when you register. I think that's good advice and I'll make sure to put a link to the code in the show notes for people so they can access that. Next question. I want to kind of switch gears a little bit. You know, I was reading a little bit about some of the stuff you have on your website and different things before we did this podcast. And one of the things I came across is just the importance of prototyping before you build a model that you're a big believer that we should spend some time prototyping. Can you talk about why you see that as such a big benefit? Why should we do that before we jump into Excel and just start building that model?

Yeah. Yeah. So I mean it's part, part of the process and you kind of alluded to it there that you need to be. There's a whole design part to building a model and that's about understanding the business, what the, what are the important things, what are the key drivers, and so on. So, so then there's also that human element. Again, there's that how are people going to interact with this? And that will depend on who the users are. It may be more than one person who deals with the different part of a different set of inputs and things like this, but you also want to make sure that it's easy for them to use. So I would say particularly around the input areas, we often mock those up so that they can see what that looks like. And, and also then you, you know what units it's going to be in. And should this be a percentage or should it be an absolute value? And those sorts of things, you, you easily test those if you, even if you just mock up the inputs. So, so I think it's, it's really helped. It helps, also helps the, the user to see, you know, what, what they like to get. And, and if they think, oh, no, this isn't, this isn't what I would imagine. What about these things? Then you're getting all that out in the open before you start coding. And it's much easier to do it at that stage if you've already started to build a whole bunch of calculations and then you have to reconfigure things. Because in our case, the client or the user is saying, this doesn't look right to me. I'd prefer it to be like this. Then it's a lot harder to do it later on.

Yeah, I mean, it's kind of like. I like to compare the modeling process a little bit to home building. No, no, nobody just starts building a home, right. You go to the architect, you get blueprints, you have them done by somebody who's qualified, you have an inspection process. And kind of step by step, there's a lot of similarities to the how a model should be built, unfortunately, and guilty of it. A lot of times you just jump into Excel and start building. And that's usually when you end up with what I like to call Franken models, you know, kind of that Frankenstein model that you get all done and you just like, what have I built? Yeah, yeah, I'm a big believer in that. There is some value in just stepping back and thinking about things.

There is. And we will sort of sketch, sometimes even sketch out schematics and show the client, you know, in a more complex model than, you know, you might have a portfolio. And so, you know, you would. You set things up perhaps with a sheet for each unit and, you know, some through those, or you may do it different, you may do it in blocks down or. Yeah, so you need to think about how you're going to lay these things out. And we're also thinking about future proofing. You know, we try and ask the client, where do you think this might go in the future? So that. Not necessarily that we build it now, but so that we don't kind of make that difficult in the future.

Yep.

And close the door there, I think.

Makes a lot of sense. Next question I want to ask you, as you look back over your career, what's the most enjoyable modeling project you ever worked on and what, what made it so fun? What did you love about that project?

Yeah, so there was, there was one project. There have been a few. I mean I've, I've enjoyed many projects and I, I, this is going back a little while because I don't do quite so much hands on stuff start to finish these days. But going back a while, I was the primary modeler for a big project with Electricity Northwest, which is a, in the uk, we're distribution network operator. So these are the guys that manage the, all the wires, all the grid in their local area. This company had been part of another company, United Utilities, and it spun out as a, as an independent firm. And so it didn't have, it didn't have lots of things. It was basically just a bunch of technical specialists and then a whole load of consultants really initially to get them off the ground. So I built them a model with some help from a colleague and this was the whole company. So it was all the regulatory stuff, it was all the statutory stuff. It was a whole bunch of holding companies with bonds being issued at different levels with different risk ratings and cash moving up and down. And then they wanted a macro to optimize it all. And so I built them a button and the button said show me the money on it and you click the button to optimize it. It got multiple different versions of finance. So what did I enjoy about it was just I really got under the skin of the company, really kind of got to know it thoroughly and this model had just about all the challenges you could imagine in it. So. Yeah, so it was really, really kind of fun to get stuck in with that.

Yeah, it sounds like that could be a challenging but fun model. And I love the button at the end. Show me the money. That's great. I'm sure they got a laugh out of that one when they saw it.

There was an investment banker there, one of the people who got one of the shareholder companies and, but he wanted that button that said show me the money.

Yeah, yeah, no, I could see that. You gotta have a little fun in the process for sure.

Yeah, yeah, absolutely.

Appreciate you sharing that. You know, Next question here is, I know you run your own podcast. You do the Forward Thinking CFO podcast. Can you tell us a little bit about the show, kind of how it came about and what is it all about?

Well, yeah, it was, it's really part of our marketing effort and we, we thought a podcast might be a good idea to supplement what we were doing. It's actually, I Went to a guy who, who I know does organized podcasts and so on and, and said, yeah, I was thinking about doing a podcast. He said, you want to get all your other marketing sorted out first. So, so we did that first for about six months and then we came back to the podcast idea and I mean, I thought about doing a podcast like yours, really, you know, a financial modeling podcast. But then we thought, well, actually the people we want to talk to really are more like our clients, you know, the CFOs. So, so hence we went for, we went for the, the forward thinking CFO and we, we, I, I try to, to find CFOs and people who deal with CFOs who, who might be interesting to CFOs to talk to. And I found it absolutely. I'm sure you are the same. I, I learned so much from that, from getting into those conversations. You can ask people questions that you would normally get to ask them. And, and there's some great lessons there as well from, you know, from what, what the CFOs have been through. And also we've had, you know, some funders on there, people who, you know, lend to, to companies so you get to hear a bit about what they're looking for. And every now and again I go a little bit off beast. So we just had one about hydrogen, you know, which if you're in the sort of renewable sector and so on, then you know, hydrogen is one of the next big things. So that's interesting to quite a lot of our audience as well. So. Yeah, but I thoroughly enjoy it. It's, we have some great conversations and, and I learned a huge amount from it.

Yeah, I'm, I am totally with you. I love, I love talking to people and learning from them. I mean, I've had the opportunity to talk to somebody from pretty much every continent in the world. You know, I haven't got Antarctica yet, probably won't, but you know what I mean? And it's just fascinating.

There aren't many penguins doing modeling.

Yeah, exactly. There's not a lot of penguins in modeling or FP&A, or finance in general. But it is, it's a lot of fun to just learn from others and hear their stories. Like, you know, just hearing you talk about show me the money or as you're telling about how you thought about modeling standards. And I know for me if I went back to being, you know, a day to day practitioner instead of running my own business, I'd be a better practitioner for what I've learned from Everybody. All those lessons I've absorbed because. Right. We. We all have our strengths and weaknesses, and if we're open, we can all learn from everybody out there at the end of the day.

Yeah, absolutely. Yeah. Yeah.

So this is. This is a fun question we like to ask. What is your favorite Excel shortcut?

Yeah. Okay. So there's. I'm a bit old. I know other people have had all TSV as theirs. I still use.

I do too. I'm a little old school with you as well there.

And I thought what they use the Most, that's probably F4. Yeah. To toggle between absolute and relatives. But I think my favorite. Actually, I've gone for control semicolon, which just puts today's date in, which I just think it's a great time saver. That's quite a neat. It's not one many people know as well.

So I had to think about it for a second. When you said it, I'm like, well, that's right. Because I just don't. It's not one I've used much. All the others I would call TSV, of course. F4. You know, control C Control. Like, because I, you know, I didn't start out. It wasn't until later in my career I started using shortcuts. It's something I was never taught. I didn't start kind of that investment banking route. I started not in finance. So it was a long time before I even really started. Started learning shortcuts. And I finally feel comfortable where I can do it most of the time. I still find myself sometimes being like, forget it. I'm just using my mouse.

Yeah, we use. We use them all the time. And in fact, we've got some of our own as well. We have a tool which has additional shortcuts in that make us more efficient, that does lots of other things. There's a free version that we give away as well, so that does mapping of workbooks and analysis and all sorts of things. Useful navigation.

I think I saw that online. Make sure to send me that link and we could put that in the show notes. And yeah, I definitely know shortcuts can save you time. And like I said, I'm kind of one of those that's in the middle. You have those people that are like the no Mouse club and you have others that have no idea there's shortcuts. And I'm one of those that's kind of a little. Probably here a little more toward the no Mouse club these days. But I definitely do my share of keyboard and sometimes I'm like, why am I doing this? I know this is really inefficient.

Yeah, yeah, well, it does. And when you're doing it day in, day out, you know, you can save quite a lot of time. And I even have the same keyboard. You know, I've got one at home and I've got one in the office because I have to have the exact same layout because it becomes muscle memory.

Yeah, no, I had a boss. You'll laugh at this. He used to, he told me he worked in modeling for a long time. He didn't do it anymore, but he had done like certain keys so much, he would be sitting there tapping them on the table like certain keystrokes, just like as a nervous kind of habit, like almost like a twitch. And he goes, I'd be like doing like F4, you know, different things just out of habit.

I thought you're going to say that some of the keys rubbed off. I'm sure some of the guy.

There was some of that too.

Yeah.

All right, so one more question, then we're going to move to our rapid fire section where we get to put you on the spot.

Okay.

So as you look back over your career, what's the one thing you've learned that's benefited you the most in your career, that's maybe, or saved you the most time or helped you the most throughout your career?

I think there was a job I did in my 30s, just before I joined KPMG actually. And there was a guy there who's, who was about my age now. So, you know, he was, he seemed really old to me at the time, but I was basically his right hand man. So doing this analysis work. So I was working with him day in, day out and I'd see other people come in and you know, because he was the, the big boss for the whole region and so on and you know, they were almost quaking in their boots sometimes. But, you know, so, but I, I was working with him closely. So I got to realize that, you know, he's just, you know, just the same as anybody else and you know, he doesn't have all the answers. And so it just gave me some lessons there about, you know, how people perceive you and also that not everybody has all the. Well, in fact, nobody has all the answers. You can get good ideas and get advice from everywhere. So that's really, I think the thing that I would say stuck with me, that you can get good ideas from anywhere and everybody can have good input. So nobody's got all the answers.

I really like that. It reminds me of the way somebody summarized it. I had podcast I was doing recently, and there's a guy by the name of Jim Cook, and he commented, I came to learn that the smartest person in the room is the room. And I really like that. He's like, it's not any individual. It's. How do you collectively come up with the best solution?

Yeah, that's right. Yeah. I mean, it's like the wisdom of crowds. You know, I wrote an article about that a little while ago, and it's quite a famous story about the. And I've got to remember all the names now, but it was. It was about a farmer's market, and they were trying to guess the weight of an ox. And, you know, each of you know, the crowd, actually, if you average it out, got it almost spot on. So. Whereas it was quite a big range. So, yeah, there is wisdom in crowds.

Yeah. And that's actually the example I shared when I was chatting with them. Not the ox, but just they've done a lot of studies where, you know, count the number of M M's or Skittles or whatever, and you get a lot of people high, a lot of people low. But generally, when you take the average of all those people, it's pretty close to the answer.

Yeah, that's right.

You know, it's that idea. There's a lot of wisdom in crowds. You just have to be able to contain them sometimes. But that's another story. That's probably a whole podcast, isn't it?

Yeah.

All right, so rapid fire. How this works is. I got to think about 10 questions. You get no more than 15 seconds to answer each of them. And you can't give me an. It depends. So you have to pick a side. And then at the end, you can elaborate on one or two where you're kind of like, yes, I can answer that. But there's this and this and this you need to think about, because I. All of these, you know, are nuanced. That's why we do this. So here we go. Circular or. No circular references.

No, no, circular.

Yeah, I knew the answer on that one. VBA or no vba?

Yes, I like vba, but there's a caveat to go with it. Yeah.

All right, well, we'll get to that here at the end. Horizontal or vertical?

If you mean time, timeline. Going across. Horizontal.

Not timeline, more. Do you like to put all your schedules on one sheet? Or you like to use a lot of sheets, a horizontal type model or kind of stacking it in one sheet. You have a preference?

Yeah, that really is a, it depends question. So I'm going to have to go for horizontal, I think.

All right, I get it. That is really one of those Excel dynamic arrays and models. Yes or no?

Not for financial models.

Okay. External workbook links, yes or no?

No, but yeah, we can talk about that one maybe as well.

Yeah. This is what makes it fun. Named ranges or no named ranges?

Yes, I like name ranges. Yeah, sparingly.

Sparingly. Yeah, I could buy that. I've had a few people say that. The next one, I think we spent about half the show talking about kind of the formal standard. So we'll, we'll move on past that one and just run to the next one here. Will Excel ever die?

Not before I do.

I've had a few people say that. I had one responded with yes, but just don't happen in my life. Will AI ever build the models for us?

Some would argue it already is, but I don't think it will in, in a useful way anytime soon.

Fair enough. Yeah, that's a question. There's a lot of nuance to, that's kind of a discussion in and of itself. Are you, are you a believer you should use like sheet cell protection in models? Yes or no?

Yeah, yeah, I'd say use protection, probably Generally wouldn't use a password, but it just helps avoid accidental damage.

Sure. So do you, the next question here. Do you believe financial models are the number one corporate decision making tool?

Yeah, I think so. Yep.

Okay, and then here's the last one. What is your lookup function of choice? You would choose vlookup, index, match, xlookup or something different that I didn't mention there.

Yeah, no, I'm old school. So it's index match and yeah, that's a common one. Yeah, I like that because you can separate the index and the match and sometimes you can use the match multiple times and save yourself some coding.

Yeah, no, I like that. I finally started using xmatch.

Yeah.

Because you get the extra arguments. It's just, I've never really, just hasn't been habit. We all kind of use match and I was doing something, I'm like, I really should use xmatch. That would have solved this problem I had.

Yeah. Yeah. I mean some of the new functions are really powerful. Yeah. But yeah, I, I, I like say it's to some extent it is habit.

Yep. So you wanted to elaborate on the VBA one a little bit. I think that's one you wanted to elaborate on.

Yeah, there's a couple. So vba. Yeah, I think so. I would generally not use it in the way of sort of custom functions or things like that. I think it's great for tools we've built, you know, loads of tools like say we, some, some we give away but those have really made us very efficient. And also when you're doing that sort of project finance circularity breaking stuff, then just a simple macro there typically to, to drive a goal seek. So you just click a button and drive goal. Sick. But yeah, I'd say avoid it for actually doing calculations.

Yeah, that's what I've heard a few people say, like use it for formatting. You're talking about tools, things like that. But don't be writing a bunch of custom functions with vba. We can do that with Lambda now if we want to be dangerous.

Well, that's right. And that's, you know, I think the same, I would apply the same there. I know, I know other people might disagree, but I would tend to avoid that if there's a simple way to do it using regular formatting.

And then I believe there is one other you wanted to elaborate on. You remember which one that was?

What did I say? I think, yeah, external workbooks. I mean generally you don't want to do links to Excel workbooks, but sometimes I know that people feel they need to. Or what I would say is if you do then have a kind of an airlock that's an identical sheet in both so that the links between those are, you know, sort of just, just one to one and you know, that's a way to reduce the risk of that. I wouldn't recommend it. I still, still say avoid it. But you know, just, just a. If you do have to then, then that's the way to do it.

Yeah, I, I try to avoid it. I've used it some and I've been bit a few times and so I really try to avoid it.

Yeah, yeah. No, I mean like I say, I think try to avoid it as much as possible.

Yeah, I agree. Well, I really appreciate you joining me. That kind of leads to the end of the show here. Just have a wrap up question for you. If you could offer one piece of advice to our audience to be a better modeler, what would that be?

I think it would be keep the user at the center of everything you do. Keep them at the center of your thinking and that way you'll produce a model that's much more, are much easier to use and like to have a longer life.

I like that. So keep. Keep the customer front and center. Yeah. And then if anyone wants to get a hold of you or learn more about you or your company, what's the best way for them to do that?

We're probably through LinkedIn and the. If you click on the button there that says view my portfolio, there's a whole bunch of links there to things like our YouTube channel, company page, the podcast, the blog, and all sorts of things that. That's probably the. The best way.

All right, great. Well, I appreciate you joining me, Stephen, and look forward to sharing this episode with our audience. So thanks for being with me today.

Thanks, Paul. It's been a pleasure. Yeah, thanks for taking the time to. To talk.

Yeah. Financial Modelers Corner was brought to you by Financial modeling institute. Visit fmi@www.fminstitute.com podcast and use code podcast to save 15% when you enroll in one of their accreditations today.