Reclaiming Focus By Automating Financial Reporting | GLOW24

Hi everybody, welcome to this session of Jellyfish Glow. Thanks so much for joining us today. Today we're going to be talking about reclaiming focus by automating financial reporting and specifically going to be talking about Keller Williams experience implementing DevFinOps. One of our tools meant to support software capitalization and other critical R&D financial workflows. Richard, thank you so much for joining us today.

Yeah, absolutely. Happy to be here.

So before we get started, would love to just, you know, kick things off with, with some intros. To introduce myself in brief, I'm Taylor. I'm the product manager here, here at Jellyfish, focused on DevFinOps and supporting our customers like you. Richard would love to just ask you to do a quick intro of yourself.

Sure. I am currently the controller here at Keller Williams Realty Inc. I've been here for almost 3 years at this point. Prior to this, my entire career was Big 4 public accounting. I was at EY for 6 years, left that in 2021. And here I am specializing in all things US GAAP, one of those being, of course, capitalized software, for which we utilize Jellyfish and specifically DevFinOps, like Taylor mentioned, and it's been a huge help for our org. Awesome.

Thanks so much for the intro. And how long have you been with Jellyfish or using DevFinOps at this point?

Since 20— 2022, I believe we implemented it. And I remember we ran our old process, which I'll talk about more, in parallel with Jellyfish for about half the year. And then once we were good with the data output, we quit the old method and we've been on Jellyfish since then. Last year, 2023, was the first full year we had a full year of Jellyfish, got through audit without issue, and now we're on, I'd say, our third year. Things are going well. Awesome.

Really glad to hear it. And just, just to, you know, clarify for folks and, and level set. So you said you oversee a, you know, a bunch of different accounting workflows. What, what do you use Jellyfish for? What is your DevFinOps reporting focused on? What use case?

Use case would be capitalized software, right? So US GAAP, I believe it's a C 950, I hope that's right, requires obviously to, if you create, develop, or maintain internally developed software, you're required to capitalize that, right? And we have quite a bit of that. It is a material account for our financials. So we're utilizing Jellyfish, specifically DevFinOps, to quantify tech work, for lack of a better term. Tech, they do a ton of stuff. It's all in Jira, it's GitHub stuff I don't understand. But Jellyfish allows us to take that, flow it through the Jellyfish tool system, and then we have a result at the end which allows us financial users to say this is how much we capitalize, right? And that's a very important input to our consolidated US GAAP financials.

Awesome. Thanks for sharing that. And so to kick us off here, going to, you know, run through a bunch of questions and try to pick your brain a little bit more about your experience also here. A little bit about maybe any advice you would offer to folks in this domain. But I'd love to just start with like rewinding the tape a little bit. Tell me about your workflow here. But before DevFinOps, what were you working on? What was that like?

Yeah. Yeah. So before Jellyfish, our cap software process was manual is a huge understatement. It was, it was purely inquiry based. Very, very, very manual, tons of workbooks. And essentially what it boiled down to was we as finance would, we tried to do this monthly, it sometimes was quarterly. We had to inquire of engineering managers, right? To say, hey, we know you're working on this project, right? But we have to capitalize a certain amount of that work and we want to get as discrete as possible. So we were tracking and we still are tracking as an individual basis, whether that be full-time employee, contract what have you. And tech is very busy, right? So every time we inquired of these managers, be it monthly or quarterly, they had, well, number one, this was the last thing they wanted to respond to, right? So we pestered them for, hey, this past month, here's your roster, right? Like, John Doe, what would you say is the percentage he spent on new stuff, i.e., capitalizable work versus maintenance, bug fixes, business as usual, which is expensed, right? And the roster could be anywhere from like 5 to 50, depending on the project, depending on the manager. There's no way, there's no way the manager remembers specifically, discreetly, accurately what every person in his org was working on for that month, for that quarter, right? So 90% of the time, maybe more, the responses we got back were suspiciously round numbers, right? Everyone worked 70% on new stuff, right? Or everyone was at 65, or this guy was at 50%. Right. But, you know, back in pre-Jellyfish days, that's the best we had, right? Because we as finance, we don't understand Jira. I barely understand what GitHub is, right? I know the logo is a cat. That's pretty much all I know. So this was the best we had, right? Outside of pastoring tech weekly, which we tried that once, didn't work. So monthly or quarterly was the way to go. And with this we essentially had a huge spreadsheet which was individual names, projects they worked on. For full-time employees, it was their salary. For contractors, it was their bill rate. And then this vague, hard-to-support percentage, right, that we got from the tech managers, which I'm confident it was close enough, right? We got through audit. It was materially correct, but it was not traceable, right? Because if you said, hey, John Doe worked 70%, on new stuff in March on Project A, and all you have is that number, 70%. It's tough. It's tough to be like, hey, prove it, right? Because how, how, how could we, right? We pull up Jira, we wouldn't really understand it. Um, I don't even know if we have access. But that was the pre-Jellyfish days. The auditors hated it, um, of course, right? Because they're testing inquiry and they always test about a year later, right? Just due to the nature of financial audit. So it was, the testing was brutal. There was a ton of inquiry back and forth. A lot of prove this, prove that. We got through it at the end of the day, but it wasn't ideal, right? So Shelby Fisher was a huge improvement for that.

Mm-hmm, absolutely. And before we move past this, just want to make sure for those in the audience who might not know some of the accounting jargon, can you explain what inquiry is And I think, yeah, I can kind of infer from context, but would love to hear it in your words.

Yeah, yeah. So I mean, when we were discussing like accounting support, especially in terms of audit, right, you could have inspectable evidence, you could observe stuff, and the weakest level of support is typically inquiry, right? Because it's based purely on discussion. It's, you can't really inspect anything, or at least not readily available. Inspection. Inquiry really, really, really is just, hey, let's chat, and then what do you think the answer is here, right? With no tangible support, for lack of a better term. It works. It does work, and it has worked for us. I mean, we passed the audit in prior years, right? It was just a bit more headache, right? Because inquiry is tough to support by definition because it's just discussion. So that's essentially what inquiry is in terms of this. It's supportable, but it's tough to support.

Yeah, no, that makes sense. And just to give for a sense of scale, I mean, how many engineering managers were you doing this inquiry with? And you said it was on a monthly basis, right?

Yeah, we tried to do monthly and it was, geez, it was at least probably I'd say at least like 20, 25, right? And each of those have their own teams and sub-teams. So hundreds of individuals that we were, you know, putting in our schedule and inquiring of at least 20, 25. Yeah. So it was quite a bit of work just to get time on their calendars. And if they couldn't do that, they would send an email with just a bunch of numbers and percentages and it's just like, all right, that's fine.

And why did you consider shifting to weekly? What made you decide to go the other direction ultimately? I'd love to—

When we tried the weekly, like I said, it didn't really work because of feedback from the auditors where it was like, hey, if you do this monthly or quarterly, the chances of the engineering managers remembering specifically what their teams worked on one month ago, three months ago is low or lower, right? So we tried to do weekly check-ins. It worked for not many, right? Like I said, tech is very busy. No one really has time to sit down with us every week to say, okay, this week my team of 20 people worked on this scope of work and we think this much of it was new development that's capitalizable, right? So we tried it in order to try to get a bit more specific. And then it just, with timing and schedules and workload, it just, it just didn't work out.

Yeah, no, that makes sense. I mean, that's, that's a lot. 20, 20 to 25 essentially interviews or surveys every single week of the year. Yeah. Yeah. Um, but before I have, have more questions for you, but before we move on, any, any other just reflections on your experience before? I mean, was there anything else about your process that was manual or that sort of thing?

The inquiry itself was time-consuming and then our schedule was kind of a mess, right? Because I would split the inquiry with myself and the accounting senior and we would just, because there was 20-something people we'd have to inquire of and our formatting was always close but not really. So we'd have to combine reports and then like pivot that and then pivot that again to get data by person. And just on a more broad scope, the relationship we had with tech because we kept pestering them with stuff like this was very— it wasn't negative, but it was like, oh, this again, right? Or it was very reactive instead of proactive. It's always looking backwards, always like, hey, 1 month ago, 3 months ago, hey, what about that? So it was both manual and reactive and we didn't have as close of a relationship as we do with tech today, which I can speak to further later on.

Yeah, yeah, absolutely. So that's a great segue into— I'd love to, you know, learn more about your experience with DevFinOps. I'm curious, you know, how did you first learn about DevFinOps and what were your objectives when you were kind of setting out? What were you trying to solve for?

That's a good question. That was years ago. So Jellyfish was brought to our attention by a tech, I believe he was a director, who unfortunately is no longer with the firm, but he was using it in terms of on the tech side for it to track his team's progress, right? I know, I don't know all the details of Jellyfish. I believe primarily in DevFinOps, but I've seen the screens that tech uses and it seems very, It seems like a good project management tool, right? It allows you to drill down into the specific epics or specific subsets of work by person, by allocation. So he was using it for that. And then at some point down the line, I forget when it was or who it was, someone brought up to me that, hey, we could use this to make the cap software process a bit easier, right? Because the same data that tech is using, we could use it too on the finance side. We would just have to tag stuff as capitalizable work, non-capitalizable work within Jira and set up in Jellyfish. Of course, we'd have to do a bit of coaching up for the tech team to get that done, which we did. It was very, very productive. We still do that, by the way, quarterly. We do little lunch and learns with the tech team. And to my previous point of being reactive, this is a lot more proactive, right? Because we were, we were involved during the setup of Jellyfish. Maybe not the entire setup, I don't want to take too much credit here. The setup for the finance piece where we worked pretty closely with Scrum Masters, engineering managers to define and kind of translate the accounting guidance into more understandable, more relatable terms that engineers would understand, right? So we would take the guidance, distill it down into something understandable, and then we would configure Jira Jellyfish to kind of flow that through correctly. So the number we got at the end, the capitalizable number, was traceable all the way back to setup, right? So that was 2022, and like I said, we do that refresher course pretty much quarterly here to make sure everyone's still doing things correctly, tagging epics correctly, especially for new hires, right? So if they're unfamiliar with the tool, we can kind of level set like, hey, by the way, this engineering data finance needs it too. Let's make sure to get it right.

Awesome. Yeah, no, I love that you all have done that. So, and just, you know, maybe to belabor this a little bit, but why the need for those lunch and learns? You all were just, again, trying to kind of create more of a dialogue? Is it, was it mostly to focus on, you know, the capitalization eligibility requirements and that sort of thing? Or is there anything else that you cover in those sessions?

Yeah, so collaboration I think is pretty key here between finance and tech. The lunch and learns essentially are, well, the first one was quite long, right? It was, why does this matter, right? So it's required for US GAAP. US GAAP is, you know, a key input into our internal KPIs on the finance side. And of course, those KPIs drive stuff like next year hiring or annual bonus, right? Or stuff like that. So that always perks people's ears up a bit as to why you should care. And then for the legacy folks who've been here for a while, I would always say, hey, remember we used to do these inquiries monthly, quarterly? Everyone loved that. Jellyfish essentially gets rid of that, right? So I always highlight the way we used to do things. Which, like I said, is outdated, it's manual, it's unsupportable, it's inquiry-based, to this data-driven traceable methodology that Jellyfish enables us to do. And the accounting guidance is, it's kind of jargon, right? It's, I don't have it up right now, but you can read it 5 times and be like, I don't know what the hell this is saying. So we would take it upon ourselves to say, okay, we understand this language, let's flow it through and make it understandable, right? So if, if you're working on something that's a new feature, right, feature work usually tagged to an epic, that is usually capitalizable. And these are terms— I hope I'm not butchering these terms— these are terms I believe the engineers understand, whereas maintenance, business as usual, bug fixes, those typically are expensible, right? So, so we're taking a huge breadth of accounting guidance, distilling it down into something very understandable and communicating it to the team so they understand what is capitalizable, what is, what should they be tagging as capitalizable in the system, in the tool. So, and we, again, we do that refresh, of course, about once a quarter so people get accustomed to it, get used to it. And one of the issues we noticed when we first implemented Jellyfish was there's in Jellyfish, you can see these bar charts. I don't have it up right now, but part of it is gray, and that gray bit is like work that has not been assigned to an epic or something. I believe that's what it is. And that stuff, it was, it was a pretty big chunk of the bar chart when we first started, and that essentially is stuff that hasn't been tagged correctly. And from a finance perspective, we, we just take that and to be conservative, we just say that's expense, right? So one of the pushes this past year, which we had support from the CTO, Chris, as well as the VP Finance, also Chris— sorry, VP Tech, also Chris— was to have the tech team reduce that gray bar down, right? So whenever they do their scope of work, they need to be sure to tag their work to an epic or tag their work to a— I believe it's called a key or something. That way we don't have that chunk of uncategorized work. So everything is properly categorized and we don't have to make that assumption that says oh, this entire great chunk, just take it to expense, right? While that is technically appropriate, it's not as precise as we'd like. So these lunch and learns really, really help drive that point home. They're like, hey, whenever you're doing work in Jira, in GitHub, and any tech-related work at all, you should tag it correctly. That way tech can track it correctly and finance can take that and track it correctly as well. So those lunch and learns are really helpful to one, teach new people, And we emphasize points that we want to nail home.

Yeah, absolutely. And so now, you all have been using DevOps for a little bit now. You've been in kind of a rhythm of it. How are those going? Are you still seeing a lot of engagement at those Lunch and Learns? Would you advise them to others as kind of best practice?

I really would, especially when you're setting this up, you cannot set the CILA up in a silo. All right, so when you're configuring DevFinOps, I highly recommend that you work with the tech team. You have to, you have to, right? Because certain things that we as accountants and finance folk understand, it's not easy for tech to understand and vice versa. A lot of, most of the stuff tech does, I have no idea what's going on, right? I care about the numbers at the end of the day. So collaboration is key. To kind of bridge that gap, right? Like, what is the outcome we're looking for? What is the work tech is doing? And how can we make that meet in the middle and make sure everyone understands that appropriately? So configuration, I would recommend heavy involvement from tech and finance together to make it work, at least to understand how tech is doing things and for tech to understand why we care. And to make it clear, okay, you guys are working on this, this chunk of it is capitalizable, this chunk is not. I made myself available to the tech team pretty much day in, day out as we were setting it up because I had questions all the time like, hey, we're working on this, is this cap or not cap? Like, okay, that's cap. Is this cap or not cap? Okay, that one's not cap, right? And those questions were significant upfront, but as we went through the process, now I get maybe one question a week, every two weeks for this. One-off thing, and I can easily say, okay, that's non-CAP, just do it like everything else. But if we hadn't had those discussions upfront, it would kind of be a mess because then it's, it's essentially garbage in, garbage out. If tech doesn't know how to tag things appropriately and we get the output, it's not going to be correct, right? And, and the quarterly updates primarily, well, Jellyfish hasn't changed too much. And I mean, it's, we've only used it for 3 years, going on 3 years. So it's, it's more so for the new folks. Tech, tech hires quite a bit. And for the new engineers who may not be familiar with Jellyfish, with the collaboration with finance, it's primarily for them. But I do recommend collaboration between tech and finance.

Yeah, absolutely. And it's just so important to build that foundation at the, you know, front side of things. And then like you said, you can kind of optimize over time. I have a question for you following up on what we were talking about earlier. So before you had to do a lot of inquiry, what's the role of inquiry in your process today? Do you still have to do that? To what level?

We do still do inquiry, although now it's at a much higher level, right? So quarterly we meet with the CTO, Chris, and the VP of Engineering, also Chris, and we essentially review the past quarter's capitalization, right? Because I mean, capitalizable work and new features are essentially synonymous. There might be slight nuances here and there, but broad strokes are the same thing. So tech has a— especially tech leadership has a pretty damn clear idea of what they want their results to look like. We, for example, they would say, we believe our team should be focusing 60% on new stuff this quarter, right? So when we get the data from the finance side, because they're synonymous, We get our data output, we capitalize around 60% of the work, and then we meet quarterly. We can say, hey, so we capitalized 58.4% of the work this past quarter. Does that align with your expectations? And usually it's yes, right? But if in any case it's no, if Tex says, oh, I thought we would have capitalized more, or, oh, I thought we did more new stuff, that would be a really, really good point to like for both our sides to drill in and be like, okay, okay, so What's the disconnect? Did we miss something? Did we fat finger something here on our end, or did some engineers not tag that work correctly? Let's dig in a bit deeper here. Let's drill into the non-capitalizable piece here. Spot check a couple. Does that look right? Oh, that's not— we should reclassify that to cap work. Oh yeah, that's right. Maybe our expectations were a bit wrong, or we really did just come in under, right? Because that does happen. So, so Yeah, so we do still have inquiry, but this inquiry is not so much as it used to be, wherein we inquired in order to develop our conclusion. This inquiry under the new approach is more so to confirm our conclusion, which we already have from jellyfish, from that data. So we now have another independent source, which is tacti, to essentially corroborate the result we have from jellyfish, wherein before it was It was just, Tech said it, I believe it, we're good. But now we have Jellyfish as like a discrete data source that's traceable, auditable. And the inquiry right now is much more, hey, is this, does this look right? Rather than, oh man, you got to give us a number, right? Yeah.

Much different from coming up with a number out of a vacuum off of recall and—

Yeah, absolutely.

And, and, you know, one, one thing I wanted to ask you about touching on something you said earlier was, so you said for, for a time you ran your prior method and Jellyfish in parallel. And I'm curious to just hear a little bit more about why, what was kind of the purpose of that? How did you just, you know, navigate some of the transition and that sort of thing?

Yeah. So we— I don't think we technically had to. So KW is not a public company. But I come from a background of auditing a ton of public companies. So I knew a question would come up from the auditors, right? Like, hey, you implemented a new system. That always raises some alarm bells. How do you know the data is right?

Right?

That's always the first thing that anyone asks. Well, it's right because we did the same process parallel. It wasn't the easiest because we had to inquire of tech monthly again. And this time we had to really push for it because we were checking Jellyfish monthly in 2022. So we run Jellyfish after we set it up with tech, get their output, and then we would inquire of tech using the same old methodology. And we didn't really tell them that we were using DevFinOps yet, just to be a little sneaky to make sure they weren't like looking at the data and just giving the same number. But we, we did that for 6 months and it was very important because that gave us comfort in that number one, in that we set up Jellyfish correctly, right? If, because if we, if our numbers were way off, then we, we probably configured something wrong or tech wasn't understanding what we told them. But we were pretty darn close. We weren't spot on obviously because Jellyfish is just so much more precise. But broad strokes, we were pretty, pretty close. I think like for one month, I believe Inquiry resulted in capitalizing like 60%, again, a round number. And then Jellyfish was like 63.4% or something, right? I think there was one month where it was a bit off and it turns out that someone, someone here was on their way out, so they just kind of gave us some numbers and then left. But once we kind of took that out, that was, that was obviously an outlier. It was, it was pretty close again. So 6 months of that, I do again, I highly recommend that whatever your old process may be, whoever is listening to this or watching this considering implementing DevFinOps, whatever your old process was, I highly recommend doing it in parallel. That way you get comfort over Jellyfish configuration, setup, usage, and it'll save you a ton of heartburn when and if you get audited down the line, right? Because then you can point to something very clearly and say, hey, look, it works.

Absolutely. That way you can, yeah, just build trust, build comfort, not only with, with your team but with the auditors as well, which are obviously an important stakeholder in all of this. Absolutely. Um, awesome. Well, we're, we're coming down the home stretch here, uh, you know, to, to close us out, would love to just ask a question that's maybe a little bit of a recap of some of what we've talked about today. But I'm curious, just, you know, what would be your bits of advice for anybody, you know, trying to optimize their software cap process with DevFinOps in general? I'm sure folks in the audience would be, you know, kind of keen to hear what you have to say about that.

Yeah, don't be afraid of change. It's going to suck, right? Implementing it was very rewarding, but it was tough, right? But, you know, it's grown pains and now our process is 10 times easier, maybe more, right? Just because we don't have to really think about it. DevFinOps, Jellyfish is linked to Jira, linked to GitHub. We don't have to inquire of anyone. It just happens. We run the report monthly. We do our process. It's quick. It's easy. It's painless. That said, I want to reemphasize collaboration. With tech, especially when you're configuring DevFinOps, right? Especially when you have to set up the initial, okay, what is CAP, what is not CAP? Have patience, especially because we as finance have pretty much no idea what anyone in tech is saying most of the time when they come up, come to us with technical terms. But on the flip side, tech may not understand what finance is saying all the time, right? So have patience. Make sure every time we have a meeting to configure something, I always like to make sure at the end to say, okay, this is what we decided on. Are we aligned? Because sometimes even that simple question will spark like, oh no, no, no, that's, that's not what I meant, right? I meant this, I meant that. And have those conversations, be patient, be proactive, be open. And the better you set it up on the front end, the less heartburn you'll have later on, right? Because then the questions you'll get down the line are very simple, like, hey, this is a new thing. Is this capped or not capped? Easy question. It's not, oh shit, I think we set this up wrong, right? Like, why are our numbers not what we expected, right? So be open to change, be collaborative. I do recommend quarterly updates or maybe more frequent, maybe less frequent depending on the nature of your org. If there's a ton of turnover, Doesn't do much good if we have new engineers or new finance folk that don't even know what Jellyfish is. So it's good to have a little refresher course every now and then. And honestly, it's just, it's a great way to broaden your horizons, right? So I now know more about tech than I did 2 years ago, right? And I like to think that some people in tech know more about accounting than they did 2 years ago. So collaboration, open to change, and patience, right? It's, it's, we did Parallel in 6 months and I think it was very worth it. But again, it was, it was kind of a tough 6 months. But no, like I said, this was a huge improvement from our prior process. So I highly recommend this.

Awesome. Well, thank you so much, Richard. Really appreciate the time to share your experience and your advice. You know, definitely understand this is not a straightforward thing. And so I think it's really helpful to hear stories of how orgs like yours have, have handled it. Um, so, um, thanks so much for your time today, and thanks everybody else for, for the time today, uh, for attending this session. Um, reach out to, to anyone here at Jellyfish if you have any questions on DevFinOps. All right, thanks so much.

Thanks.