Serious Insights: Managing Technical Debt

Serious Insights is back!

We took a short break for Thanksgiving, but now we’re here with two new episodes coming your way this December. In this episode, Salesforce MVP Kristi Campbell is joined by the Executive Director of RADWomen, Angela Mahoney.

Together the two discuss all things technical debt: what it is, what you should do about it, and why you should kill it dead with a checklist.

For more about Angela, and to hear her further elaborate on technical debt, you can catch a wonderful YouTube presentation she did from 2017 here. To read a transcribed version, click here.

Let's dive in!

Recognize, Minimize, and Optimize

If there’s one thing you can take to the bank, it’s that people are terrible at predicting the future. Like, hilariously bad. Even right now, somewhere, someone is making a prediction about the future that will be wrong.

Understanding this, when looking at the corporate world, particularly that involving software, you can easily understand what causes technical debt. We can’t predict the future, so we tend to make assumptions, and those assumptions lead to problems down the road that we have to solve.

Defined by the Salesforce Architects, "technical debt is a trade-off between the short-term advantage of meeting a release deadline and delivering quality, efficient, and optimal code. A little debt is acceptable; however, if left unchecked it can cost a great deal of time and money in the future.”

For the Admins, a few examples of technical debt created by short term decision making could include:

• Overlapping processes
• Redundant fields
• Abandoned business processes/remnants of proofs-of-concept and prototypes
• Relying on features or services that are being retired, such as Salesforce for Outlook
• Historic solutions no longer a fit for current volume/business needs

All of these problems, small as they may be at the start, can easily snowball into an avalanche of technical debt.

So, What Can You Do About Unforeseen Problems?

In three words: Recognize, Minimize, and Optimize

How do you do that?

1. By leveraging documentation & automation to ensure holistic knowledge within the organization, even when people leave.

A lot of great advice sounds obvious, doesn’t it? That’s because great advice can usually be described as “Stuff you already know, or think to yourself, but aren’t doing for one reason or another.” And this is an excellent example of that phenomenon.

Tools like Confluence are fantastic at creating a global repository of knowledge for everyone in your company. And, provided that someone is keeping an eye on managing it (to ensure everything is neat, tidy, and easy to find), this is one way to manage your technical debt.

By creating and referring to the documentation, you can have a better understanding of why things are working the way that they are. And the better you understand them, the more potential there is to automate tasks and decision making, which can further reduce the possibility of a mistake down the road that you need to fix.

An organization’s internal documentation can help you understand why that process was implemented in the first place, and what future plans for the process may be. For example, if you know something is being sunsetted that you use, you’d have a plan for it in your Confluence documentation for the administrators to stay on top of things for when that thing is retired.

2. Prioritize time for both tech debt cleanup and new functionality with each release

Just imagine Steve Balmer, former head of Microsoft, standing here and clapping his hands like some kind of wild animal just saying “Planning. Planning. Planning”

Steve if the person you should be listening to.

If you’re not planning, you’re creating opportunities for failure to occur. The more you plan, the less technical debt you will create. It really is that simple.

If you make time to manage your technical debt throughout whatever process you’re going through, you’re going to be fine. I mean, as fine as fine can be for an Admin. Which could be like, fine for the day, and then something else catches on fire, but you get what I mean.

If you plan properly and have time to work specifically on the technical debt as things progress, you are (less) likely to have a major problem down the road where you and your team have to race around the clock, and probably on the weekend, to solve an issue that could have been solved if you had taken the time to resolve it. Plan before you do anything, and then plan time in the future to alleviate issues so that you don’t need to cut into your actual production time to fix them.

Planning. Planning. Planning.

3. Recognize. Minimize. Optimize.

I’m going to tell you a secret. If you want to get really good at recognizing potential problems involving technical debt (or really, anything in life), minimizing those potential problems as they come up, and optimizing to solve for those problems when you encounter them, study the cooking philosophy of Mise-En-Place.

What’s that? The really condensed version is that Mise-En-Place in French means, “put in place.” It’s a phrase every chef around the world knows, understands intimately, and follows. You will not find an example of a successful chef who does not follow some form of Mise-En-Place.

As explained in Dan Charnas’s book, “Everything In Its Place: The Power of Mise-en-Place to Organize Your Life, Work, and Mind”, Mise-en-Place in a more practical sense means to break down the task you’re looking to do into the smallest possible unit, memorizing each step of the process to do that thing, and then acting on that process with repetition until the movements and thought becomes automatic. (I’m heavily distilling this down. The book is a little bit of a slog to read, but recommended for those of you who are interested in learning more about this.)

How might this work for admins? Well, master chefs will also draw out on a napkin or piece of paper what their finished plate will look like when it reaches the customer. And then from there, they work backward in thinking about what they’ll need to set the plate properly, what ingredients they need for the meal, what prep work they need to do to get those ingredients ready, and virtually every other detail, right down to the smallest, including the positioning of your silverware and kind of plate your food appears on.

Doing this allows the chef to recognize what it is they are trying to accomplish, minimize the amount of time wasted during the process of creating the dish, and optimize for flow by eliminating all possible sources of trouble and distraction. The less you’re distracted, the better you work. Again, pretty obvious sounding, but it needs to be said.

You can see where I’m going with this, right, Admins? You want to do the same when embarking on a big project. Think as the Chefs do. Make a checklist once you have visualized what the finished product looks like that you are changing and implementing, and then evaluate that list to make sure no stone is left unturned.

Will there still be technical debt created? Of course. You can’t eliminate it entirely, but you can minimize it by having you as the Admin and the team handling the implementation make a checklist, look to see how they can maximize the efficiency of completing each task (in other words, putting them in an order that allows for minimal mistakes and for performative flow), and then acting on it.

As Kristi says in today’s episode, you wouldn’t want to leave a dirty cup in the sink of a clean kitchen. Everything has its place and order, and if you keep things neat and organized, you can reduce (but not eliminate) future problems like technical debt. Cleaning the kitchen removes all the potential distractions which will sap your time and energy away from the thing you need to be doing: Cooking.

So, the next time someone says, “Ah. We’ll worry about that problem later”, think about how you can recognize, minimize, and optimize the task at hand by creating a check list and breaking that task down into the smallest possible steps for you to then act on.

The AdMinute

At the conclusion of each episode, our fearless host asks her guests to share media and resources that they recently found!

On brand, Angela shared a slew of Salesforce related podcasts. To her, Smartless, Salesforce Way, and the Salesforce Developer Podcast are must listens for any serious admin – okay, Smartless is more just fun to listen to. She of course plugged her own podcast, RAD Women, too.

Transcript For Episode 3 of Serious Insights

Kristi Campbell: Welcome to Serious Insights, our video series. I'm your host, Kristi Campbell. And I have with me today, the lovely and talented Angela Mahoney, who is the co-founder, executive director, coach lead for RADWomen and Forcelandia, represent and welcome.

Angela Mahoney: Hi, nice to be here.

Kristi Campbell: That's a whole lot of things that you do. You did a great session that I had seen about Technical Debt and so I asked you to come and talk to me about it today. Do you want to give me a little background about you and how that became a thing you were interested in talking about?

Angela Mahoney: Sure. Well, I'll start off as a creator of Technical Debt. I think we all are as much as we hate to admit it. But, I was a platform manager in my youth. It feels like many moons ago. And sometimes as a project manager, as a platform manager, as an admin, as a developer, as almost anybody working in the system, you're generally squeezed between what your users want and maybe what you have budget for or what your managers tell you, you can do or what the visions of the company are.

Kristi Campbell: And which time.

Angela Mahoney: And you have to make those decisions of what you can do to meet the deadline, can you come back and fix it? In many cases it's not, or it's like, let's just get it into product we'll take care of it later.

Kristi Campbell: Yeah, sure.

Angela Mahoney: We all know that, is that going to happen? Maybe not, in my experience. So I got passionate about it because I had to talk with my dev team back in the day or consultants on the projects I was PMing on, or even with a client of, here's a best practice, here's what you should do for long-term success. And like, "Yeah, we don't have the budget for that." Or sure, "We'll do it in the infamous phase two." But you know it's out there. And I've been in scenarios where I would ask our developers, "Just comment this in the code." This is not a best practice. We know this because somebody else will be looking at it someday. I don't want them to know that that work was not our choice. We know this, don't judge us, but it's tricky sometimes to get those...

Angela Mahoney: Sometimes, I think the technical definition is, short-term fixes, things that you know they're wrong, that you not necessarily cut corners on, but it's the shortest best, easiest way to get there. And now I think it's morphing into, we'll write a workflow right now in our Salesforce world. We know that, don't do that. We need to start thinking a little bit along the flow lines, or when you're writing your unit testing, how are you doing your test data, for example? I think for me in our particular ecosystem, it's expanding out into other things and ultimately we all want systems that won't break, that will be sustainable. So when you add more business processes in, or you change them, or you take what Salesforce has produced, you want to be in a healthy spot to do that. But it takes everybody to do that. It's not just a single person thing.

Kristi Campbell: Right. And I think that's what I really liked about your take on it. So, coming in as an Accidental Admin, I think when I first started hearing about the concept of Technical Debt, it felt very developeree Like our code isn't efficient or our code is whatever it might be. And I think not knowing much about it, it feels like something like, "Oh, well, you should go fix that right now." But then as you evolve and you learn about the different priorities, like you said, the different projects, the new and shiny things are always going to be the things that people want and that people see, but in reading more about it, it was really interesting to learn about that... I mean, there's charts all over the place. Right?

Angela Mahoney: Right.

Kristi Campbell: But that exponential, as things get more and more brittle, as you build more and more on top of something that's already maybe not as tight as it could be, then you are potentially setting yourself up, then everything takes longer. Right?

Angela Mahoney: Right.

Kristi Campbell: So, I can see that it can be tough to make the time to do it or the budget or there's not going to be a Technical Debt project probably, but-

Angela Mahoney: There should be.

Kristi Campbell: Well, right.

Angela Mahoney: But yes, there's most likely not.

Kristi Campbell: Right. But I think conversely, one thing I found interesting, and I don't know if you've seen as well, is the idea isn't necessarily to get to zero, especially with something like Salesforce, where things are changing all the time. Maybe it made sense at the time, have a little grace for three years ago, you where Flows didn't have Before-save Flows. Right? And that's just one current example. But maybe the fields and the page layouts and all of it made sense at the time, and it's really just making sure that you don't get too far. If you have a little bit and you kind of live vastly in this space that then once you hit a threshold that you can kind of jump back down and reprioritize and finding that sweet spot.

Angela Mahoney: Yeah, because it's almost like in my... This is going to be my very unprofessionally sounding opinion. It's like dust in a corner. I have plenty of experience with that in my house, but if you don't handle it every now and then it just kind of all keeps collecting there. So periodically, you do need to go vacuum it out and just be aware of it. Know what your limits are so that when you start reaching those, you can either do a Technical Debt project or I prefer in Sprints or as part of your larger projects, you know what some of your big key pieces are so that you can tackle those. We're going to do awesome feature one, or we're going to do sexy feature two, and we're going to do this purchased feature three. And then number four is, right we have this piece of Technical Debt that we need to tackle so that you're constantly working on it.

Kristi Campbell: Right. And I think a good example for Admins, like you mentioned right now, especially is, we know that Process Builder and Workflow rules are getting sunset. So if I'm creating something today, I know that Flow should be the way, but it's not my comfort zone yet. So I know there's a part of me that wants to build it in the way I know how. And then that future you is... I think it's okay for certain scenarios, but you do have to build in and fight for that time to go back and tighten things up and resolve and look for ways and places you can make things reusable.

Angela Mahoney: Yes. Because there's the philosophy, especially the higher you go in management, in many cases, that's somewhat equivalent to the less hands on you are, the less aware you are, the more, "Hey, if it's not broken, don't fix it." Sorry. If it's not... What does it say? If it's not broken, you don't have to fix it, I guess that's it.

Kristi Campbell: Yeah.

Angela Mahoney: Don't touch it. Which sure, that makes sense. However, what you build yourself into, or you back yourself into a corner where suddenly it's going to snap, it's going to break, your reports might run really slow. You're going to time out on executing whatever you happen to be doing. And then you're doing a hotfix. You've potentially got users locked out of the system because you didn't make time for it before. And in the back of your mind, I think most people know it. And in many cases, it's Technical Debt that needs to be dealt with instead of, "Well, shoot, let's toss off the system and start a new one because clearly the system doesn't work." Well, let's dive a little deeper into that.

Kristi Campbell: I was reading something that was talking about, you're less likely to set your cup in the sink in a clean kitchen. Once things have started to accumulate, once you've kind of started doing things a certain way, it's easier to just add to the top of the pile.

Angela Mahoney: Yes. Just one more.

Kristi Campbell: Even though you know that creates problems for you in the future. I think it feels like kind of an ingrained habit that we have to make efforts to work against.

Angela Mahoney: Yes. It's a discipline I think. I'm a big fan of whether you use, JIRA or something homegrown or Excel, whatever works for your company, but make notes of these things, treat them as tickets. So when you recognize, for example, with the big one, Flow coming out, well, we need to go in and identify our Workflows. Which ones are we using? Which ones are we not? And then create a ticket, create a placeholder for those pieces that you can start quantifying it. And that it also helps with your arguments if you're trying to get something signed off from he or she who controls the purse strings or the timelines.

Angela Mahoney: So you can say like, "Look, we've got all these cool things in our Sprint, but we know that we've got these many things waiting and we've got to estimate 30 hours," who knows what it is. But people like numbers. It helps them make decisions. So being able to quantify what you've got, even though you might think this will never get done. Maybe it won't. We all know that. But being able to just say, "We've got 14 tickets, or we've got 186," or whatever it happens to be, it's good to have those numbers there when you're making those arguments to get time dedicated to dealing with Technical Debt.

Kristi Campbell: That's a really great point. Do you have any recommendations around, so if we've bought in this nebulous concept, that there is page layouts, there is fields that I don't use anymore, there's too many profiles that are confusing, there's of course code, there's automations or rules that are referring to things that don't exist anymore. We know there's those kind of dead ends. How do you start to tackle that?

Angela Mahoney: I like to write it down first and sometimes it might make me cry. So I still do work in volunteer orgs, because I don't want to lose my technical skills. And when we talk about those things, the wouldn't it be nice ifs, to me that it's not necessarily Technical Debt, but it's something you want to put there because they might ask for it someday so it can influence a decision. But when I know sometimes maybe I haven't done it, but let's say hypothetically, you've done some filters on a year. This is something that might seem easy. However, it is going to break when the new year starts. So little things like that, "Sure, I'll go back in and fix it. I'm the Admin why wouldn't I?" Well, because I forgot probably. So I'll make tickets and things [crosstalk 00:10:37].

Kristi Campbell: Until it breaks.

Angela Mahoney: Right. Yes, exactly. Why did it break? Well, we knew that when we did it before. We knew this was going to happen, but you get busy and you forget, which is another reason why I'm a huge proponent of writing it down when I think about it. It might be low priority. It might be a low level of impact, but it still exists because those little tinny things add up. Probably we've all dealt with that. They add up. Or making notes, for example, years and years and years ago we developed a process in our business line that had a relatively small in the grand scheme of things, quantity of transactions that we were having to deal with, which was fine, our system work. When another business line came in and they spun up another team, they were very high volume of transactions, just line of business, energy efficiency.

Angela Mahoney: And when they... So we had a process that worked just low volume transactions. When they spun up the high volume transaction model, it broke, it broke everything. We didn't know because they had a different team. And when you get into DevOps, which has come a long way since then, passing things by, so you can take a look at those and testing that kind of stuff thoroughly is a good thing. Slowing things down at the beginning is a good thing. So that you don't have it and take your system down in the first week when everything's supposed to be great. I mean, hypothetically of course, we've never done that.

Kristi Campbell: Yeah. That never would've happened obviously.

Angela Mahoney: No.

Kristi Campbell: I think it's an interesting piece too. I think growth is a lot of what causes these things to break. And so like you said, even when you're not at a large organization or you don't have a large org, thinking about those possibilities again, can be tough to prioritize in your mind. For me, I think my current struggle, I'm an admin team of me. Obviously, I work at a partner company so I've got Salesforce knowledgeable resources. But I don't have a DevOps formal structure. I mean, obviously I would never do anything directly in production of course, but I don't have a Sprint schedule. And so could it be helpful for me to put something in place for myself to... What I've been thinking of about is object by object as kind of a way to make it a little more bite size and think about the key objects, but also balancing the new shiny things like, actually rolling out lightning pages instead of just turning lightning on.

Kristi Campbell: So those new shiny things, even as I'm thinking about it already start to build up as opposed to just looking at the rules and the fields and all of those things. I think-

Angela Mahoney: Yeah. That's a good point. If you're like me, you get all these paper scraps on your desk. I still do that sometimes if I'll write it down to deal with later. And I love a good report. I don't know who doesn't. So I like to be able to go in and create my report of all my low priorities or all the smaller ones or something like that, whatever filters work for me so that I don't forget. And I can say, let's say we have 30 hours of work allocated to the next Sprint. Can I stick in another six with a different resource or myself? It just really depends on what your environment is, but then you can also take it off. And as you hopefully introduce this concept, if it's not introduced, you can also say like, "Hey, and we rolled out sexy new feature A, but we also cleaned up this that you didn't know, here's the benefit of it," for example. So when the new thing rolls out, we're already ready for it. We're good. We won't be scrambling at the last minute.

Kristi Campbell: What's in it for you angle?

Angela Mahoney: Right. Because you have to sell it. Sometimes you have to sell it to the decision makers. That's to be expected.

Kristi Campbell: Well, and I think hopefully you kind of get to a cadence of understanding. You may be delivering here and especially in the short-term, that may go down a bit with new feature wise while you're adding in those kind of pieces. But then as there's less and less and you're being more aware of it, by the time I cycle through all my objects and come back to opportunities, hopefully there's less weight there. There's less to have to do. And you've got some monitoring in place, you kind of got a little bit of a guardrail so that you can get back to a larger trajectory of new futures.

Angela Mahoney: Yeah. The fun stuff, right? The cool stuff that people really want to see.

Kristi Campbell: Yeah. It's interesting... I mean, we're such nerds. But it's interesting because I almost think that looking at your existing Workflows and Process Builders and how you might move them into Flow, I think that's interesting to me to think about, what made sense at the time. I found the same things, updating things and just getting back into best practices and naming conventions. And I don't know, that seems fun to me maybe.

Angela Mahoney: It is. And how often do we get to do that? How often do I get to stare at that page and like, oh? Can these be combined? Are they so similar? Because sometimes that happens where a new Admin might come in and not really know or be given the time to learn the org. So they just write something new and either deactivate it or they run concurrently. It just depends. Because I think we all know that it's very rare that you're going to get a totally green org that's fresh and pristine. That doesn't happen very often. You're going to be taking over somebody else's work. And it's hard sometimes to quickly got to ramp up and learn the little one offs and things like that. So it's also natural that we make mistakes. I know we want to kick ourselves over it, but we can't, we just can't do that. We're going to create our own debt. We're going to inherit somebody else's. We just have to accept it and like, all right, there it is. We know what our playing field is.

Kristi Campbell: Well, and your business process may be different from when you started there too. Right? So what made sense at the time there may not apply anymore. So I think that can be another way to kind of sell a little bit some of the, seeing what your users are doing, what they're actually doing right, what's hard for them. And maybe those pieces that could make their lives a little bit easier kind of tie into something that you can optimize or build to pull forward and get rid of some of that.

Angela Mahoney: Yeah. And when you talk about optimizing, I want to spin this over to a people standpoint, because never have I seen this included in Technical Debt or some of the dangers of Technical Debt. It's usually tied to downtime or it's tied to, there's some pretty complex formulas out there of how to quantify it. Don't know if I necessarily subscribe to those. I'm more interested in when your systems get frustrating and you keep saying no to your experts, your developers and admins that are the experts on the systems. At some point you run the risk of forcing them to leave because they know what's best and you don't listen to them. And I think we all know that it's difficult to hire great people right now. So you also have to listen to your experts on your system and if they are highly recommending something, do that to make them happier at work, which sounds, I think cheesy and that's hard to quantify, but it's really important that you've got happy software development teams.

Kristi Campbell: Well and people that care about the end user experience and that it's not just about your system going down and what financially that could cause you for your customers, for your users, et cetera, but just the general health of your org and the users that use it and having a sense of purpose around that.

Angela Mahoney: Right, yes. So that they don't have to configure around or develop around some of the scenarios that you know you have to take care of. Don't force them to do that is my take.

Kristi Campbell: Interesting. Any other experiences with maybe recommendations about helping other people understand the implications or that it's not just a developer problem?

Angela Mahoney: I think a lot of it, in my opinion is communication and that's in, I guess, two ways. One is word choices, which leads to the other way, the people in it because we tend to speak... And we were talking about this a little bit earlier, acronyms, we're very good at that in IT. We're very good on the developer side as well. So it can make it really hard for people to understand each other. And we have to be able to do that. In my experience, a lot of people lack confidence for example, when they're talking with dev teams, because sometimes we tend to... We shouldn't, but we tend to put developers on a pedestal. They're solving the same problems we are. They just use a different tool for it. But developers will speak in a different language sometimes than Admins.

Angela Mahoney: So it can be hard to have the confidence to go say, "This is wrong. It's not working. I'm going to make this change." It could be a Picklist change. I recently irritated a developer on my team. I didn't think this through, by making it feel mandatory in production because the user asked for it. I'm like, "It's just making it mandatory." Not thinking down that, well, the test data that we had in there didn't have that field. So I'm like, "Blah, blah, blah, let's get this all done." I tossed it over the fence, is how we work on this team. And it kept failing when he was running the test because he's like, "There's no data there." And that's something that's so easy, but it's just lack of communication of... Because I had assessed it to be like, it's fine. It's just an easy change. It's not going to do anything. Well, yeah-

Kristi Campbell: Is a for the user. Right? Maybe that.

Angela Mahoney: Yeah. Well, I'm just here to please. So, because I lacked the communication, that's just a total newbie error because I incorrectly said, "Oh no, this is going to be easy." And the way that we had written the testing for that particular scenario is, it's not just individual and run it like that way. And it broke. And then there was some anger, some hurt feelings a battle line to fix it, to do that. So little tiny things like that, that you don't think are going to cause problems because you're not communicating or you're not understanding what the other person is saying and clarifying what's going on. If you don't understand it, it's your job to say, "Wait, stop. I don't understand it." You don't look stupid. You look like you want to understand what's going on.

Kristi Campbell: Right. Well, and the key too, to me in that scenario is also taking those examples that are fresh and translating that into some of potentially the work you want to do. Is this the point where we need to make a more flexible test factory? Is this the point where that it's something, for example, that at my past role, that the developers built into custom metadata types? So I had a certain amount of power to make changes without needing to recode the things. Are there different, smaller levers that you can pull to enhance that functionality? Which again is going toward just a little bit less brittle, a little bit less involved changes that if you want to make a "simple change" in the future, can we actually help make it a simple change? Or is it not the tipping point for that yet? Is this something we're going to do once and we're never going to do again? And that certainly is a tough balance I think, like you said, of getting to quantify those things of whether that's a big ask or it's reusable or it's actually the scenario's a one off.

Angela Mahoney: Yeah. That's very true because I think there's a certain element of Admins to the admin work, devs do dev work, QA does QA work and you kind of open the door when you're done, throw it through the other side, slam the door and move onto the next thing. And then on the other side of the door, they're pulling their hair out, "What is this? What the heck?" And I go back to what Dan Appleman said, years ago, years and years ago, we all work in the same metadata, regardless of what we're doing, we're all in the same metadata. We're all responsible for the system, we just play different roles, but fundamentally, we are all a team. And that's where I think it's super important that even if it seems dumb, like what I did, I used to, when I managed a team, I would have the lead developer look at all the... You sign off on every single change we're going to make, because there might be something like that where we added a Picklist value, that code was referencing.

Angela Mahoney: So to us, we're just adding on the admin side, we're just adding a Picklist. And the development side is like, "We didn't write it to [inaudible 00:23:12]."

Kristi Campbell: Or a validation rule.

Angela Mahoney: Looking at that extra value. So it's going to get caught in the wrong spot, probably. So being aware that even if it's a small change, we're all responsible for the system. We can't just like pitch it over the fence. And "Hey, let's see what happens."

Kristi Campbell: That's a really interesting piece too, because thinking about some of the admin tools, feel easy but you have great power there too right? If creating a validation rule can take down your integration, having an awareness of the things that are going on on the object that you're modifying and what those implications might be and an avenue to ask those questions and potentially track those changes of, "Okay, yes. It's hard now, but how can we build for a future where it's not as hard?" Definitely it'll take-

Angela Mahoney: And I think, we all want to future proof and you do it to the best of your abilities at that time. But it's on all of our plates, regardless of whether, are we at the PM level? Are we at the B level? VA level? We are all responsible for Technical Debt, even though it's traditionally defined as programming. It's all of us.

Kristi Campbell: I like it. We're all in it together.

Angela Mahoney: We are. We are on it together. Because when that system goes down, we're all in it together.

Kristi Campbell: Yeah. We're all going to get in the weeds and get on the calls in the middle of the night.

Angela Mahoney: "Sorry." Nobody wants to do that. Nobody wants to do that. And I'm of the belief that really your project's going to take this long, whether you do... So I can get this right. Whether you put the work in at the end or you put the work in at the beginning, it's going to be the same amount. So just build it right the first time, slow down at the beginning so that you have a successful deployment at the end, you have a successful user experience. Don't cut corners at the beginning.

Kristi Campbell: I like it. Well, thank you so much for joining us, Angela.

Angela Mahoney: I could talk forever on this.

Kristi Campbell: I know, clearly. Considering my last episode went into two, because we talked for so long, maybe that's why they asked me to host the show. Before I let you go, I do want to ask, when you take an Adminute for yourself, and stay aware of what's going on, see in the mix, has anything caught your eye recently that you want to share with our listeners, watchers, viewers?

Angela Mahoney: No. Caught my eye, no. I'm going to say what's caught my ear lately. I complain all the time about my husband always having his EarPods in and my teenagers always having them. So, if you can't beat them, join them. So I've really been carving out time when I'm doing stuff around the house to catch up. I'm way behind on Josh Burke's, Developer Podcast, but he has such a wide variety of topics and great, great guests. And then I also got into... I'm going to mispronounce this, the SalesforceWay, but I think, Xi Xiao, also has fascinating topics. So I've been going back and forth between that. There's plenty of content because I just recently discovered the SalesforceWay, but podcasts are what I've been doing. And then when I really want to break, I listen to SmartLess, which I think is the best use of air time out there.

Kristi Campbell: SmartLess?

Angela Mahoney: Jason Bateman, Sean Hayes, Will Arnett. If you really just want to learn something that's never going to help you out not even in trivial pursuit, it's an excellent use of time.

Kristi Campbell: Just to learn something. I like it. In a completely unplanned fortuitous moment, my Adminute this week was also Josh Burke. It's funny because I watched it on YouTube. So they cross post the podcast. There's no video, which took me a second to like, I'm watching, but I'm just hearing. But Jeffrey, the founder of the Salesforce XD discord group, that I'm a part of was a guest for Josh on the latest episode from November 8th. And it was great just hearing him talk about architecture and the beginning of a community and kind of how that grew. And yes. So [crosstalk 00:27:04].

Angela Mahoney: I saw that out there. And can I give a plug?

Kristi Campbell: Of course.

Angela Mahoney: I want to give [inaudible 00:27:06] RAD Women podcast. I think we're getting some out there. We haven't had some fresh content a little bit, but I really love listening to what our coaches say, for example, or just hearing different takes on learning on the platform. It's all interesting. Everybody has their own career or their own career path and their own journey. And I just love taking little tidbits from different people if they're not linear path to where they are.

Kristi Campbell: And finding the things that stick in your head that you then quote when you're a guest in a video series months or years later.

Angela Mahoney: There we go. There's a posting on my desk more about that.

Kristi Campbell: Thank you so much for joining us. And I hope everyone has a wonderful day.

Angela Mahoney: Thank you. Pleasure.