I recently had the privilege of sitting down with Pam Jordan for an episode of Pivot to Profit, where we dove into my journey from architecture student to CEO of Macktez, and explored the practical foundations every organization needs to build resilient, secure technology infrastructure.
We covered everything from how I accidentally stumbled into technology consulting to the three core security practices that even small organizations should implement from day one.
This article includes the key themes we discussed, links to watch the full conversation, and the complete transcript below.
Topics Covered
- The unexpected path: How a favor to set up servers turned into 29 years building an IT consulting firm, and why my architecture background actually shaped how I approach technology problems.
- Security foundations that matter: The three non-negotiable practices every organization should implement early—password managers, multi-factor authentication, and secure domain registration—regardless of size.
- Trust as the competitive advantage: Why the real success of Macktez comes down to building and maintaining trust with clients, and how that shapes everything we do operationally.
- Scaling intelligently: The metrics we track, the challenge of growing a professional services firm, and how we think about the role of automation and AI in our work.
Watch Now
Watch the full conversation below, or click here to watch on YouTube.
Full Transcript
Noah Landow: I think it's the kind of area that many organizations are fine, but just like insurance, if you sort of take a little extra time and spend a little bit of extra money early on, you're protecting yourself. It's the kind of thing that most organizations don't have that problem twice because it's so horrifying when it happens. But many have it once because they don't realize until after something happens that it isn't that hard to protect yourself, but it does require a certain kind of diligence and a certain kind of organizational consistency.
Pam Jordan: Hello and welcome to today's episode of Pivot to Profit. We have the amazing Noah Landow here. He has extensive IT knowledge, cybersecurity—but this is going to be a fun conversation. We're going to learn all about his journey. Noah, how are you?
Noah Landow: I am good. It is a beautiful day in the autumn today. I'm just—I am loving the weather, so doing very well.
Pam Jordan: And Noah is chilling in New York City, like New York, New York proper. So, super jealous, I love the city. So let me officially introduce you. Noah is the founder and CEO of Macktez, an IT consulting firm that has partnered with innovative organizations to solve complex technology challenges for more than 25 years. Noah also serves as board president of UnionDocs, a center for documentary art, and sits on the board for the Victorian Web, a pioneering digital resource for Victorian art and culture. He's a long-time advocate for creative communities and education with a career that bridges technology, design, and cultural engagement. Noah divides his time between Providence and New York City, continuing to bring thoughtful insight and creativity to everything he does. Amazing, Noah! I'm so excited. We've watched other conversations that you've had, so I'm just going to dive right in. Are you ready?
Noah Landow: Absolutely.
Pam Jordan: What did Noah want to be when he grew up?
Noah Landow: Well, depending on what age, I definitely wanted to be a fireman for a very long time. There was a long period there where I decided I drove around in a little tiny fire truck. And then I switched at some point to wanting to be a knight. And I have vivid memories of probably in middle school where I decided I was going to be a vampire knight. So, good indication that these desires change as you grow and, you know, being aware of the ever-evolving complexities of the world affects your ambitions for the future.
Pam Jordan: Well, I'm sorry to hear you did not turn into a vampire knight when you grew up.
Noah Landow: I'm happier, I think, with life than I would be if I was a vampire knight. So, thank goodness.
Pam Jordan: So what was little Noah, who wanted to be a firefighter and a vampire knight, taught about money? What was family taught, society, school? Money good? Money bad? Should you have it? Should you not? All of those things.
Noah Landow: My parents were academics. And interestingly, I mentioned at one point that the company that I run, Macktez, was my mother's maiden name. Part of the story behind that is my father's side was more academic—his father was a doctor—and my mother's side, her father and brother had started a company named after their grandfather. And so as children, it felt a little bit like the business side was on my mother's side and the academic was on my father's side. That wasn't quite black and white because my mother was also an academic. As a child, I felt like we had modest means. Academia certainly didn't equip us with wild, decadent lives. I certainly grew up comfortable and in Providence, Rhode Island—a wonderful town to grow up in.
And over the years, I think I've been fortunate enough to not have a shortage of money being a driving challenge in my life. I've been very lucky, and I think luck is an important thing to highlight in that. Some of it is family, some of it is circumstance, some of it is just the dumb luck of buying a bunch of Apple stock a long time ago back when it was very cheap and holding onto it for a very long time. So that did make a huge difference, and frankly, it's a substantial portion of our portfolio now. And so yeah, as a child, I think finance and business and all those were things that were kind of like a little bit secondary. I was most drawn to and excited about these ideas of creativity and explorations and design. My aspiration in college was to become an architect, which I did pivot out of relatively quickly. But I think in a lot of ways that love of what are the practical constraints… but over time, I think one of the great journeys of Macktez has been kind of realizing early on that I needed to learn how to balance books, I needed to learn basic operational things, I needed to run a board meeting. So there are evolving necessities of learning and knowledge to gain as you progress. Somebody once told me recently in the last 10 years that the primary job of a CEO, particularly an organization that's trying to grow, is to basically learn something new and then hand it off to somebody else continuously. I don't think I do that perfectly, but I certainly aspire to that and I try to maintain that as sort of, at least in broad strokes, a part of my job.
Pam Jordan: I love it. So let's talk early career. You did go to Yale for architecture, and then now that's not at all where you're at. So what was the driving force of that? Like where were you like, "Yes, this is what I want"?
Noah Landow: The pre-driving force to even before that is before I went to college, I did a bunch of arts and creative projects. I actually worked as a silversmithing counselor at an amazing summer camp called Buck’s Rock that is part of my resume. I ran a, or was part of a non-profit for about 25 years that did essentially scholarships to the camp. The camp has now become a non-profit in a wonderful journey of its own and I'm still tangentially involved there. But those early days as a silversmith for about 10 years, culminating in this summer camp, were sort of my pre-college years. And then architecture, I think as a field, was something I was drawn to. I did a lot of theater, a lot of theatrical design, and a lot of sort of like trying to shape the human environment. And so architecture for me was an opportunity to kind of learn about volume and space and construction and materiality and lighting and sound. Architecture as a career and architecture as an education are very, very different. I actually had a tech talk in our office just a few weeks ago specifically on this called "After Architecture," in which everybody in the room was somebody who had done an architecture undergraduate or graduate or some sort of degree and then did something else as their job. So it was 20 people filling the room specifically on this topic. But I think architecture is an amazing educational experience, but it's very different as a profession. As a profession, it is much more constrained by regulation and by contracts and by construction schedules, and I did not find that anywhere near as exciting. So after a couple of internships, I kind of veered off in a different direction and started working for a graphic designer and then a funny experience working as a graphic designer for a German design firm called MetaDesign in San Francisco in the mid-1990s resulted in me switching gears. And instead of doing design work for Hewlett-Packard, which is what I'd spent a couple of months doing, I was like, "I'd much rather have my clients be the creatives and do the technical work." It meant that I spent all of my time working with designers as opposed to all of my time working with Hewlett-Packard engineers. So I kind of jumped to the other side of the fence there a little bit, and then one thing led to another.
Pam Jordan: I love it. So when one thing led to another and you were like, "I'm going to start my own business," did you have in your mind that "I'm going to be an entrepreneur" or "I just want to be my own boss"? What was the motivation there for you?
Noah Landow: That's a great question. I actually started as a favor. One of my thesis advisors in undergraduate architecture was a partner in a design firm—a great design firm called 212 Associates that was based in lower Manhattan. And I had thought I was going to do design work for them and ended up in a sort of like weird series of coincidences. They had a member of the team who had bought a bunch of server physical stuff and had never gotten around to setting it up. This thesis advisor of mine was like, "Hey, would you mind basically doing us a favor for a couple of months and like taking on this project?" And I was like, "I don't actually know that I'm the right person for that, but if you'll pay me, I'll do it." And I did, and I turned out I was okay at it. And also, probably equally importantly, I identified other people who I could bring in for help, including my current business partner now. And over the years, I have found some wonderful people to collaborate with. So the long arc of that was I sort of almost fell accidentally into technology in New York City thinking I was only doing it for a few months, and then one thing led to another, of course. So I didn't intend to start off as an entrepreneur, although I did in my very early days of Macktez remember talking to a friend and saying, "Okay, so the one thing I don't want to be is bored, and I don't want to be doing the same thing over and over again. So I think what I want to do is like pick some new area to explore for the business every six months or every 18 months." And so the first year it was like, "What's an LLC? and what's an S Corp? and what's taxes?" So I spent a bunch of time learning some very basic things, and then over the years, that window has shifted obviously. After 29 years—which is what we're up to now, crazy—that is a very different set of topics that I focus on than I did 27 years ago.
Pam Jordan: You stumbled into entrepreneurship as a favor to help somebody and then all of a sudden, now we have a business. So in those early years, I'm sure there were good times and bad times, but tell me about one of the bigger financial wins that you remember where you were like, "Hey, wait, I can do this and maybe pay bills and still enjoy what I'm doing." What was one of those early financial wins for you?
Noah Landow: I think one of the early moments, probably in the first decade, was realizing that we had reached a point where we needed to hire a staff person. The early years were kind of a collective of three to five freelance consultants who were all collaborating on projects. And we reached a point where it occurred to myself and a few others that it would really make a big difference if we had somebody sitting at a desk who was actually like answering the phone and able to accept deliveries and to sort of coordinate. And I think that was a convoluted process—I think we, looking back, I would have handled that differently now than I handled it then—but we hired somebody who worked out fine for a while, and it was a very interesting kind of moment. It felt like, "Oh, we suddenly have an employee." And then of course that creates a significant number of ramifications as a business in terms of like you need to put them somewhere and you need to understand how payroll and all that other stuff works. So that was a 10-year process of education and exploration for sure.
Pam Jordan: I love it. Yeah, growing a team is a new stage in scaling. Because if it's just you and some contractors or some buddies making things happen, once you admit that there's enough going on that I can't do it by myself and I need help, it really makes you feel that "Oh, this is a business now. Like, I'm not playing." So it makes total sense that that first hire was like, "This is real, this is how we're going to go."
Noah Landow: I think it's also fascinating now, a quarter century later, because the line of what kind of work we would hire a full-time person to do versus hire a company to do, particularly an outsourced company or a SaaS offering, is very, very different. Obviously, the role of AI is a factor here, but also international factors, telecommunications—there are so many variables now that are quite different from 25 years ago. In some ways, I don't know that we would have hired a person if I was encountering the problems we encountered then today. I don't think hiring a staff person would have been the way I solved the problem. And I think that's interesting—it's sort of like as the landscape has shifted over those years, the kinds of tools available to solve problems have also changed dramatically.
Pam Jordan: Because the reach and access to talented team members, they don't have to be W-2s coming into an office in New York. They could be sitting in Central America, Europe, wherever. I love it.
Noah Landow: I mean, our last—probably half of our last five hires were not in New York, even though we're New York-based.
Pam Jordan: Yeah, well, and also New York labor laws are not fun and taxes are not funny either. So, I have a team member in New York and it was not a nice awakening to realize all the crap that came with that. So let's talk about Macktez. What is it doing now? How do you describe—like, what's the elevator pitch for it?
Noah Landow: The elevator pitch for Macktez is we are a combination of two things in the technology world. There are essentially two very similar kinds of things that happen when companies want to manage technology. There's something called a Managed Service Provider, or typically an MSP, and there's something called a technology consultant. A technology consultant typically comes in and tries to understand all the peculiarities and idiosyncrasies of your organization and then helps you design, find, figure out solutions that sort of fit within your mixture of needs and capabilities. Those are typically much larger companies—management consulting is often a big part of that, so Deloittes and Accentures do a lot of this kind of work, but there's also groups like ours that are at the smaller end of the scale. Managed Service Providers tend to be organizations that take responsibility for managing the technology in a number of different ways. Typically that's managing the computers and the networks and the identities and the credentials—all these different pieces that sort of in the modern world allow companies to function, to share information, and to do business. Most organizations have some element of that, but most tend to be strongly in one area or the other. And we're a little unusual in that the way that we approach both of these are kind of multivariate and exploratory. In other words, most of the times we get involved with a client, it's because things are not working the way that they want them to. And so a big part of us coming in is sort of like untangling a mess or kind of figuring out some sort of beastly, terrible tech debt—something or other that doesn't kind of work the way people wanted it to. We actually have a book coming out, hopefully in the next month or so, called Tame the Tech Beast, which talks more granularly about this process. But we essentially come into organizations and then try to understand, in a co-managed collaborative way, what their in-house IT departments are doing, what their operations in HR and other groups are doing, and try to solve the problems that they're actually having. What that means varies significantly from client to client. We deal with clients that are 1,000 people and clients that are 20 people. Most of our clients, of course, are at the larger end of the spectrum—probably in the 50 to 150 range is most common—but we do have clients at both sides of that range. And a big part of what we do in that space, I think, is ultimately trying to help these organizations navigate where the world is now technologically, which is often very different from where they were when some component of their infrastructure was designed or bought or implemented.
Pam Jordan: This leads great into my next question because as a small business owner, we've got hundreds of clients that we work with—at what point does someone need to raise their hand and be like, "I need a managed service provider"? Because is it headcount? Is it revenue? Is it tech stack? Because there's so many stuck points within technology, and cybersecurity is a whole another beast. But like, at what point does someone need to raise their hand and be like, "Noah, I need help"?
Noah Landow: That is an incredible question. The answer is a little complicated. We actually finally, grudgingly realized we had to write a book because that answer had so many different variables. The book is an attempt to answer that comprehensively, but to answer that in a little bit of a flippant way, I think it depends on the culture. The culture of the organization determines often who within the organization wants to deal with what aspects of growth and preparation. If, for example, you have a CTO in a five-person organization, a co-founder, they might be extremely happy to just deal with this stuff on the side. But there are also CTOs that are like, "I'm not going to deal with that stuff. I want to stay focused on product." So obviously for like a SaaS or more technical organization. For a company in a more regulated industry, you'll often find yourself in finance or fintech or in health, you'll often find yourself with a founder who is sort of adjacent and having done some of these before says, "Hey, we really need to bring somebody in to handle this piece so we don't screw it up at the beginning and use a bunch of incorrect data storage models." So different industries, different businesses, of course, have different variables. But the more useful, less wishy-washy answer would be that by a time an organization hits about 50 people, in the current technology landscape, you probably want to have fixed a bunch of things that you didn't necessarily need to care that much about when you were five. And there's a few very simple things most organizations can do at the very, very beginning when they're only one or two people that make a big difference for scale. The two or three things that we talk a lot about are one: recognizing—and hopefully this isn't too specific, but to be super specific—number one would be taking a little bit of time to establish a safe and secure place to store credentials. The classic example of this is some sort of password manager. Something like 1Password or another company is great—doesn't really matter what company it is—but to have a product that allows you to store in an encrypted way, properly manage a set of shared credentials. That's number one. Number two would be whatever your organization is doing for email, web, collaborative service—typically it's Google Workspace or Office 365, but it could be others—to ensure that you've set that up by taking a little bit of time to read some of the best practices, watch some videos. Google and Microsoft are both quite good at pushing you to make a lot of good decisions now. Google is frankly probably a little bit easier for a beginner who's non-technical, but both have strengths and weaknesses. But in both cases, we would really encourage people to turn on multi-factor and to make sure that is correctly and properly stored for everybody in your organization. And then the third, something that comes up relatively infrequently but I think is sort of the Achilles' heel of a lot of security approaches, is to make sure that you have registered the domain names that you're using for your business in a way that the business owns them and that are securely protected—usually with credentials that live in one of these password managers. So that's sort of like the core foundation that even an organization of two or three people can do. You don't require an outside organization to do that. If you've done that, then that's sort of a good base foundation layer. As organizations grow, one of the great challenges often becomes procuring new hardware, not losing track of the hardware that you already procured, also kind of like maintaining and managing access to the correct bodies of information and beginning to bind the different pools of information that you have together. Often the point in a conversation where we get involved is either an organization has already implemented or intends to implement something called an identity platform. And an identity platform in the bigger Microsoft enterprise world is often called Azure or Azure AD or Active Directory, and a lot of our clients use different mixed—but JumpCloud is also a common competitor there. If you're somebody who's hearing those terms in your boardroom, then I would encourage you to reach out to a company like us because those are the kind of things where if they're implemented poorly, it can be extremely frustrating down the road. But if you're implementing them at the smaller end of the scale, the cost is reasonable. Those do, on the business side, incur some significant additional monthly recurring expenditure requirements, so there is a sort of an OpEx problem there. So one of the balancing acts is how to delay some of these investments until you actually need to spend the money. But this is one of those areas that's usually the first moment when somebody is like, "Hey, we really want to make sure that our Slack and our Google and our Microsoft and our Harvest and our Zero—that all these things are sort of connected to each other." And that's usually beyond most non—unless you're a very technical founder in the organization—it's usually beyond most people. So that's an area if you find that that's being talked about, that's a good like, "Hold on a second." The other is if you're looking around and you're like, "My team just doesn't have time to deal with this stuff," that I think is also a great opportunity. Sometimes that's five people and sometimes that's 50. It depends a little bit on your expectations of complexity and also how complicated your industry and business are.
Pam Jordan: I love the call out about passwords. Because we deal with people's financial information, right? And every now and then we'll get a client that'll want to give us their login to their bank. And I'm like, "Oh, please stop. Like, please, please stop. No, don't do it!" It's like, "Pause the recording right now! Don't say it! Don't—" you know, like, oh my gosh. And it seems silly, but there's so many nightmare stories, I'm sure that you could tell, of people just not having a tight lid on that and just being taken advantage of. Especially when employees leave—I've seen it get really ugly for some of our clients when key employees leave and they had access to things that people didn't know they had access to, and it just gets messy. So I love that that was your first call out, because as an entrepreneur, it does come—like, as the founder, it comes back to you even if someone on your team screws up like that.
Noah Landow: I think it's the kind of area that many organizations are fine, but just like insurance, if you sort of take a little extra time and spend a little bit of extra money early on, you're protecting yourself. It's the kind of thing that most organizations don't have that problem twice because it's so horrifying when it happens. But many have it once because they don't realize until after something happens that it isn't that hard to protect yourself, but it does require a certain kind of diligence and a certain kind of organizational consistency.
Pam Jordan: I love it, I love it. All right, so in the past you've talked about how Macktez success isn't about a secret recipe, but about relationships. Help us understand what that philosophy means and what does it mean on a day-to-day basis for you and your clients?
Noah Landow: So organizations like ours—and I mean that in a very broad sense—only really work if there's a trusting relationship between us and the stakeholders and the clients that we're working with. Almost by definition, the work we're doing requires us to trust them and them to trust us. That's sort of a complicated, intimate, kind of intertwined element to technology. And examples of that are somebody generally needs to have the ability to lock out people from accessing key resources. Typically that's the IT department, but of course, if it's like a junior IT person, you want to make sure that junior IT person isn't either accidentally or intentionally locking out the CEO or the ED. So there are some complicated things that—particularly for a non-technical founder—it might not be obvious how complicated some of those can quickly become. So I think recognizing that on some level actually trusting each other is sort of a fundamental requirement. You need to trust that the people who have been tasked with managing this stuff are actually trustworthy and capable of being trusted. So I think if there's a special sauce, it's something we talk about every time we have a leadership briefing—it's just this idea of trust. You know, you have to earn it, you maintain it. It's something that consistency helps build, but it's also easy to lose it. Little small things can happen that can undermine trust even sometimes things that seem silly at the time. That's, I think, special sauce is—there's nothing terribly magic about wanting to build trust, but I think that is an area that we do put no small amount of time and attention. The other thing is that, you know, we are a little unusual in that we sit in this sort of space where we're not exactly kind of a hardcore MSP. There are lots of organizations that are like, "We're an MSP for finance" or "We're an MSP for architecture," and there are lots of great, very effective, successful organizations that do that. I think a big part of us has been recognizing that our strength is not in these industry verticals or in a particular unit size, but it tends to be cultural. We're really looking for organizations that are dynamic, that are changing a lot. And changing doesn't necessarily mean growing in headcount; changing could mean the industry they're in is sort of going topsy-turvy underneath them. It could be an organization that's actually shrinking, it could be an organization that's building a new facility—but these organizations that are sort of navigating some sort of significant change are the ones where our team is particularly well-optimized to sort of help them navigate that path and kind of come out the other side. The other thing is that we often think about these relationships not in terms of like "Hire us and then we'll take care of it forever," but we often think of these as co-managed relationships where what we do and what the people inside the organization do ebbs and flows over time. Maybe we'll take on a bunch of responsibility during a very dynamic period, and then as things get calmer, maybe more of that responsibility and frankly expenditure shifts back to the client. Other times we'll bring in somebody at a higher level who will do a bunch of complicated conversations, and then that will also drop back down again and then raise even higher. So I think that variability is something we take a lot of pride in.
Pam Jordan: So as the CEO-founder of your business for 29 years, obviously you can't ignore your numbers and still be in business that long. So what are some key metrics that you and your leadership are tracking on a weekly or monthly basis—financial numbers, conversion rates, whatever—that really let you know "Are we good or are we not?" Like, what are some metrics that you yourself are putting eyeballs on?
Noah Landow: It's tricky. I think we're probably closer to a professional services business than probably any other super-oversimplified vision. I heard a COO at a professional services design firm many years ago make a comment of like, "You can have like seven great quarters and then one terrible quarter and suddenly like the projections are sort of all skewed." And I think we have a mixture of recurring revenue—our MSP work is typically recurring—and some of the technology consulting we do kind of falls under recurring infrastructure development project. But we also just do a lot of projects, and the projects of course are very difficult to predict; the pipeline is filled with a lot of uncertainty. So I think ultimately the numbers we look at are basically what we're billing, and what do we think we're going to be billing over the next quarter, and what is the size of the opportunities that are in front of us. Are any of them large enough? Many of our client relationships, many of our new opportunities are quite large. We don't tend to have many small clients. When we were much younger—when we were in our first 10 or 15 years—you know, a client might have been $10,000 or $20,000 a year, but that's probably below where most of our clients are now. I mean, we have a legacy of clients of course and we have some that ebb and flow, but typically I think the kind of relationships that we're often engaging are larger than that. That having been said, we will take a smaller client and a smaller project if it's really compelling and exciting, and particularly for an organization that has some sort of really compelling quality to them. But typically the numbers we look at are projecting what our plausible revenue, what our invoicing will be. We kind of want to keep an eye on what our workload is. I think we're lucky to have a really amazing team. One of the very interesting things to kind of struggle with in this moment in time is sort of what the interplay is between various forms of AI and staffing. So that's an area where automation—which is maybe what I would use as the more unambiguously positive side of AI—is a little more complicated, but using automation to sort of say, "Hey, we're doing this process a lot. Can we do this process in a way that it doesn't require quite so much time or labor from individual members of our technology services team? Can we find a way to streamline it? Can we find a way to help the client to do some of these tasks themselves when they want to do them, not to submit a ticket?" That's one of our big kind of goals for this year is sort of getting our head around those possibilities. It's difficult to quantify some of those; some of the KPIs are misleading in the sort of help desk and other areas. But there is sort of an anecdotal quality to like, "Hey, this is something that people keep being frustrated by, maybe that's something we should take a closer look at."
Pam Jordan: Maybe we should focus on that. I love it. And you have a book coming out, so what's the name of it again?
Noah Landow: Called Tame the Tech Beast.
Pam Jordan: Love it. And so who is the book for? Who's going to get benefits from it?
Noah Landow: Great question. It is intended primarily for sort of COO, CFO, maybe CEO, and then perhaps a CTO that is more product-facing, meaning a CTO that doesn't want to talk about the internal technology operations too much. And our hope is that people will read this kind of before there is a situation they want to fix or in the early stages of figuring out how to approach solving kind of a tangled messy situation. I think it's also relevant for an organization that's on the smaller side as well, an organization more like some of your viewership. And I think it's helpful to think a little bit about "What are the things I'm going to have to think about down the road?" One of the things we talk about a lot in our prospective client conversations is "This is a thing that you should think about, but not something you probably should do now, but you should think about reserving funds or time or attention to do this in 18 months or in 24 months. Where you are right now, this isn't a priority, but this will become a priority in some time frame." We also work with a lot of nonprofits where you sometimes need a couple of years of lead time to get a large expenditure into a budget. And so in those cases, it can be helpful to be like, "Hey, this piece of equipment is going to be nearing its end of life in two years, so next year is your last chance to do another project before that project comes due."
Pam Jordan: Got you, I love it. Well, amazing, I can't wait to see the book because it's definitely—IT and managed services is something that as you grow, you're not even—in my mind, it's not even on my horizon that it's something I'm going to deal with, and it's coming a lot faster than I realize. So I appreciate that. Noah, thank you so much for sharing your profit story with us. Where can people connect with you?
Noah Landow: Simplest place is just our website, Macktez.com—M-A-C-K-T-E-Z dot com. My email address is on there; you can also find me on LinkedIn. That works for people, happy to take communication either way.
Pam Jordan: Awesome, Noah, this has been amazing. Thank you so much. And that's all for today's episode of Pivot to Profit. If you need help understanding your numbers and knowing "Are you profitable? Can I make payroll?", just go to PamJordan.com and schedule a call with my team. Remember, it's not what you make that matters; it's what you keep. Thank you, Noah!