episode 148
Growth Eras, Mea Culpas, and Non-Competes
episode 148
Growth Eras, Mea Culpas, and Non-Competes
On today’s episode, join Rob as he navigates two significant topics that are shaping the landscape of modern business. In this solo episode, Rob reflects on the dynamic journey of P3 Adaptive, discussing our recent transition into a new growth era propelled by evolving market conditions and internal strategies. He delves into the intricacies of sustaining and fostering this growth, sharing the challenges and strategic decisions that define our path forward. Additionally, Rob has a bit of a Mea Culpa to share about his previous understanding of the Parquet file format and the comparison between Direct Lake and Import Mode in Power BI.
The conversation then shifts to a critical development in employment law. Rob unpacks the recent FTC ruling that renders non-compete agreements illegal, exploring its broad implications across various industries, from tech to professional services. He sheds light on how P3 Adaptive uses non-solicitation agreements to safeguard client relationships, emphasizing the balance between competitive edge and ethical practices.
Love what you’re hearing? Make sure you don’t miss an episode by subscribing to The Raw Data Podcast on your favorite podcast platform!
Also in this episode:
Episode Transcript
Rob Collie (00:00): Hello friends. This week's episode is one of those Rob flies solo episodes, and the reason for that is ironically that I spent a big chunk of the previous week, last week in person with Justin. It wasn't just Justin that I was with. We actually had a bit of a sea level off-site this past week. So it was myself, Justin Mannhardt and Kellan Danielson, and we had a super productive week, just figured out a bunch of things, got on the same page about a bunch of things, things that are just so valuable getting together in person, like sitting in a conference room, even if it's informal. We're a fully remote company and that includes the C-suite at our company. We live in three different cities and in fact in three different time zones, and it's really, really valuable and nice to punctuate all of that remote work and remote coordination with an occasional actual face-to-face.
(00:54): When I talk about our growth as a company, I tend to talk about it in eras. We've had essentially three distinct eras of growth at P3 and in each era our growth was driven by different factors and characterized by different market conditions and actually even just characterized by the way our company was organized. Maybe we'll do an episode someday on what those three eras were, but late last year and certainly early this year, I think we've entered a fourth era of growth driven by at least slightly different forces than in the past, definitely characterized by different market conditions and we've also made significant changes to the way we're organized. And if it were just changes that we'd made to the company and or changes that have been happening in the outside marketplace, just based on optimism and leading indicator type of thinking, I wouldn't call that a new era of growth if it weren't for the fact that we were already experiencing the growth.
(01:58): When you look at sort of an abstract demand curve for our services, you can absolutely see the inflection point. Similarly, we've been hiring very aggressively lately, hiring into demand that we already have. So there's something already retrospective and true about this new era of growth for us. And so obviously some of the things we were talking about and figuring out this past week were things like, how do we sustain this new era of growth? How do we really lean into it, also accelerate it? And frankly also, how do we accommodate it? Because while growth is a good thing, if you're not prepared for it can dilute the way that you interact with your customers. It can dilute the way that you interact with your own employees. And that sort of dilution, folks, is not going to happen here. I look at this organization today just absolutely top to bottom and I can tell you that it is just so much stronger, so much more robust and well organized than we were even a year ago.
(03:03): And I'm not saying we weren't in a bad place a year ago either. I'm just legitimately really proud and impressed, frankly by how much clearer things are today, how much cleaner and more unified, organized, integrated. So I'm super, super grateful for the team that we've assembled here and watching this organization that I started, watching it grow well beyond the capabilities of things that I myself could have done with it is just so, so, so cool. Now, of course, a side effect of this get together is that we didn't want to interrupt those meetings with podcast recordings. So dear listener, I'm sitting down to record this for you on a weekend. And what is it that we're going to talk about? I want to talk about two things today. One technical and one non-technical.
(03:51): Okay, first up, let's talk about Parquet, Fabric and the Vertipaq engine. And there's a little bit of a, well, not a little bit, there's an actual mea culpa here. For a number of episodes now, I have been repeating kind of the same message over and over, which is that one lake, the data lake format in the Fabric universe, the Fabric world, has adopted the Power BI storage format as its storage format. And even as I've said that multiple times, in the back of my head, there's been sort of an itch, like a bit of an unsettled spider sense thought. How is that possible? How could they actually have done that? I mean, there is so much magic, software, technical engineering magic in the Vertipaq engine that represents what I have been calling the Power BI storage engine. And for that to kind of be meshed with everything that people would expect from Data Lakes with its really granular read and write updates and sort of openness, something about that seemed a little weird to me.
(04:56): But given all of the things that Microsoft has been promising about the Fabric platform and about in particular this direct lake mode for Power BI in which there is no separate Power BI storage, it's just storing the data in columnar compressed format in one lake, that message essentially decomposes to, it checks all the data lake check boxes, and it also delivers all the things that Power BI needs, like the DAX engine needs for instance, and the visuals layer needs to give you the Power BI report experience that you're used to. So I've been just basically kind of writing off that spider sense skepticism as essentially Microsoft went and invested a tremendous amount of engineering resources to bring these two worlds together.
(05:43): Well, it turns out they kind of did and they kind of didn't. It all starts with on the last episode me talking with Justin and saying something to the effect of, "Oh, in Parquet, this storage format, this columnar storage format that we're always talking about that lake uses," I was connecting the dots like, "that's a Microsoft thing, right?" And it turns out, no, it's not a Microsoft thing. On our steering committee, I got to give Alex Dupler a shout out here. Thank you for pointing out after that episode that Parquet is actually an open source Apache standard. It's not a Microsoft thing. And as soon as I saw that it was kind of like a lightning bolt. There's no way that the proprietary just absolutely crazy, super optimized, genius level optimization, both for compression and for query speed that was pulled off in the Vertipaq engine even as far back as 2010, but increasingly improving ever since the, there's really no way that all of that magic could or would be representable in an open source format like Parquet.
(06:48): Now, fundamentally speaking, the Parquet format and the Vertipaq format, they have a lot in common. At a high level, they might be very, very similar. They're both column oriented data stores, hence the Parquet visual pattern that the stripes form. And you can think of this Parquet storage format as probably delivering some percentage of the compression and query speed benefits that Vertipaq has delivered over the years, but definitely not 100% of them. So what's really happened, instead of Microsoft teaching their data lake to store things in Power BI format, as I've been assuming and saying for a while, what's actually happened is they've taught the Power BI engine how to use the Parquet storage format as its underlying storage format, as one mode of operation. So the import mode that we've been using for years and the original direct query mode, both of those are still there, but now there's like a third mode, there's not kind of, it is a third mode. It's not even really like one in the middle. This direct lake mode does use Parquet as a storage format.
(07:49): So what does that mean? Well, one thing that definitely means is that a Power BI model that's implemented in direct lake mode with Parquet won't be quite as fast as the same model implemented in import mode. Now, how much less fast? In many cases it might not be noticeable. In other cases, it absolutely will be noticeable. Now, in order to get all of those shared common format benefits that we've been talking about with Fabric, the accessibility to, let's say, your data engineering pipelines and toolkits, that data engineers and the PySpark stuff and all that kind of stuff, you're going to get those benefits when you're using direct lake mode. When you're using import mode, you're not going to gain all of those data lake benefits. That whole wave particle duality that Microsoft is aiming for where you get all the benefits of Power BI and all the benefits of a data lake, you're going to get that overlap in direct lake mode.
(08:48): Now, what are you going to have to sacrifice from a Power BI perspective, what are you going to have to sacrifice to be in direct lake mode?
(08:55): Well, our good friends at SQLBI have been doing some research on this, and this of course is a developing story. The news is early on all of this, plus Microsoft obviously reserves the right to continually improve things, but as of right now, and to some extent, forever, direct lake mode will not be as fast as import mode. Like when you click a slicer for example, you're going to wait a little bit longer for the visuals to update. Now, depending upon your particular circumstance, your particular data model, the extra delay may or may not be noticeable. This might not in some cases any way, might not inconvenience your users in any way that they notice. And so in those cases, the reason to use direct lake is not to gain some sort of performance improvement, but to gain all of those open to everything else data lake benefits that we've been talking about, that's sort of the central tenet of Fabric. Your Power BI model can then be open as a source of intelligence to many, many, many other processes.
(09:51): So there's some amount of performance penalty, and again, whether or not that's noticeable or that actually causes any real impact is going to be something to plan and evaluate and even just test sometimes on a case by case basis. My view on it is as long as that performance degradation isn't noticeable or isn't significant, it hardly matters. The openness benefits you're going to gain here are completely worth it. And even there the performance is something that you can tune and get closer and closer to Vertipaq level import mode performance, kind of like asymptotically, you're never going to match millisecond for millisecond the performance of the Vertipaq engine. It is and remains the apex predator of query speed.
(10:33): So you can tune your Parquet storage to get closer and closer, but that requires technical expertise that the Vertipaq engine just kind of magically handled for us, just automagically handled for us. All that optimization, when you import data, it's analyzing your data set and doing the right thing with it. And you're going to have to perform some level of that on your own if the performance you're getting from direct lake is insufficient.
(10:57): Now, a couple of things I didn't expect, but that make complete sense, is that you cannot implement DAX calculated columns or DAX calculated tables in your models in direct lake mode. Those are actually going to have to exist in the data lakes. You're going to have to create them with pipelines, with Power Query, whatever. They're going to have to be physically created at the data lake layer. So it's a little bit less agile, a little bit less nimble.
(11:22): We like calculated columns. So it is painting a picture of direct Query mode of this Fabric, unite the clans, unite everything in one place picture that is definitely a little bit more technical, a little bit more deliberate than the completely kind of like ad hoc, agile, nimble environment that we're used to in Power BI in import mode.
(11:46): So in fairness, to me, the things I've been saying about Fabric in terms of the overall ecosystem are very much 100% still true. It's just that they come with some asterisks like this that are a little bit more than just asterisks. There is some thinking, some planning, some deliberate nature that needs to go into this. But you're not going to be really looking into this unless you believe the benefits, ecosystem wide benefit, of access to things like AI and things like that, you're not going to be looking into this unless those benefits are compelling. And if those benefits are compelling, the extra thinking and a little bit of the extra work that's required to get there is not out of reach for anyone that's listening to this. Whether you're a business leader, whether you're a practitioner or implementer, these things are within reach.
(12:29): So the way I've been describing things that one lake has adopted the Power BI storage format, that remains still a very useful metaphor in terms of how we understand how all the Fabric ties together and what the whole point of Fabric is. But as a literal interpretation, it misses the mark and therefore obscures a few details that I think are important once you get into it. And I definitely wanted to circle back and clarify that point.
(12:58): Okay, changing gears. The non-technical thing I want to talk about is that this past week, the FTC announced, the Federal Trade Commission here in the United States, announced a ruling that non-compete agreements in employment contracts are going to be essentially declared illegal. Now, I kind of enjoyed that ruling. I thought that was one for the good team. I tend to think of these things primarily, the non-compete agreement space, I've always thought of that primarily as a big tech thing, maybe also a little bit of a Wall Street thing. I did not think of non-competes as being something that would become a topic of conversation in my everyday life. And it turns out I was wrong, came up multiple places this week, places that I wouldn't necessarily expect.
(13:44): One of them was I was getting my haircut. At the place where I was getting my haircut, the employees there at the salon were talking about this ruling. It kind of blew me away. It turns out that one of the people who works there has had this fear of being sued by the salon where she used to work. She had a non-compete at a hair salon.
(14:06): The other place that it came up was here at P3. Why wouldn't I expect it to come up at P3? Well, we've never had non-competes in our employment contracts. Never believed in it. When we were first having employment agreements drawn up by our attorneys, well, being attorneys, they put non-competes in there 'cause apparently that's what you do. And we asked them to take them out and they forgot to take them out. And the first few people here ended up with non-competes in their employment agreements. We're like, no, no, no. We're going back and taking those out. So we redid them. And since then, since we caught that mistake, there haven't been non-competes in any P3 Adaptive employment contracts. So why does anyone at P3 then approach me and ask, "Hey, what does the FTC ruling have to do with us?" So we don't have non-competes, but we do have something called non-solicitation, and this is something that is, I think relatively vital in the professional services industry.
(14:59): Ignore just for a moment, the employees of a consulting firm, just think about the consulting firm and their customers. Any consulting firm who attracts and organizes talent in a way that they can provide a service in kind of an on-demand capacity for their clients has done a lot of work to get to that point and has taken on a lot of the risk. Think about it. If you do a really good job for your customer and the customer says, "Oh, this is great," if the customer is able to raid the consulting firm for its talent, well, that's a huge business risk and threat to the consulting company. Consulting companies can't exist, they can't be an ongoing stable enterprise if their customers are free to raid them for talent on a whim. And so our contracts with our customers contain a non-solicitation clause in which the client agrees not to basically poach, right? It's a non-poaching clause.
(15:58): Now, on the flip side of that, our employment agreements do have the employee's version of non-solicitation, which basically says, if you leave the company, don't steal our customers. And it's the same sort of thing. A lot of marketing, sales, communication, just a lot of effort went into developing a customer relationship. And if employees are free to leave and just take those relationships with them, they might've helped build over time, but they were certainly not the only effort involved, that again, would be just across the board, nothing specific to P3 Adaptive, this is another one of those things where you really can't run a consulting business with that threat hanging over your head at all times. If you want to run a headhunting business, fine. If you want to run like a temp agency, also fine. But if you want to be an ongoing consulting company and provide salaries and ongoing benefits and things like that, you can't do it as a business with these risks hanging over your head. Which is very different from the notion of non-compete.
(17:01): If you're really good at let's say, Power BI and you decide that you want to leave a company, well, what are you going to be doing for another company? You're probably going to be doing Power BI, right? The idea of a non-compete almost says you're not allowed to ply your trade elsewhere, and that is gross.
(17:19): So back to the tech giants for a moment. Imagine you're like a professional developer and you go to work from one of the big, big, big tech companies like Google or Microsoft, and you sign an employment agreement that it contains one of these non-competes. If you decide to leave for any reason, almost by definition, the people who would hire you are going to be competitors. You're going to go to another software vendor, 99% of the jobs out there are going to be with another software vendor. 99% of the jobs out there are going to be, for you, are going to be with a competitor to your original employer. This is insane. And yet, this has been the law.
(17:57): I've told this to the P3 team. It's actually kind of depressing to me how long it's taken for these rules to be rewritten. And the cynic in me actually thinks that the reason the FTC has now stepped up and all of a sudden declared these things invalid is that behind the scenes, and again, this is just my theory, is that those same big tech companies have approached the FTC and asked the FTC to make them illegal. Now, why would they do that? If they're the primary organizations that are wielding these things today, why would they be the ones to encourage their removal? And again, my theory here is that these non-competes have now become more trouble than benefit for those same companies. These things have always been difficult to enforce. 15 years ago when I was at Microsoft, one of the big members of the leadership team on Bing left and went to Google.
(18:59): Now, if there's ever a situation in which a non-compete would have some validity, and again, I don't think that it really does, but if there ever were such a case, this would've been one of them. It's one of the most prominent examples because this person would've been taking with them and actually was taking with them just a tremendous amount of Microsoft internal secrets, technical and otherwise that it's not like they can forget. They can't erase their brains or whatever. And there was a big blow up about this, and in the end, nothing came of it. The person went to Google and stayed at Google, and even though technically they were in violation of the rule, also like Donald Farmer, and I think 2010, Donald Farmer was like the primary evangelist for Power Pivot, the precursor to Power BI. He was like the face of Microsoft BI outside of the company, left Microsoft and went to a competitor ClickTech. And Microsoft chose to let him go. They chose not to pursue the non-compete.
(20:00): The PR impact, the human impact, the legal trouble of going after these things more often than not wasn't worth it. And it leads to all kinds of uncertainty. It also hurts the company that's trying to poach an employee from someone else. Like if Microsoft wants to go get someone from Google, for instance, and they really think that that person at Google will be more valuable at Microsoft, and that might be true, the market might benefit quite a bit from having someone undervalued at Google coming over and doing something that Microsoft will support them on, that Google wouldn't or vice versa. In the end, there's consumer benefit to this kind of mobility. But if Microsoft being the hirer in this case, the poacher in this case is concerned about what Google might do, it might kind of freeze them, right?
(20:45): But Microsoft can't or Google as an individual tech company, you can't just unilaterally lower your shields and say, "Hey, we're going to be the one voice in this ecosystem that stands up and says, we're not going to do non-competes." Because if you're the only one without non-competes, the others now have an advantage over you. So the only way to end this morass is if the government steps in and puts an end to it. And if the FTC were simply acting on sort of doing the right thing, they could have done that a long time ago, but I'm pretty sure that back then they wouldn't have had any support for this.
(21:22): Circling back to the hair salon example, just absolutely jaw-dropping that non-competes would be used there. But once I thought about it a little bit, it started to make sense. Whereas in our case with P3, we sign contracts with our clients that are basically non-poaching agreements. It's part of our working agreement with our client. That has nothing to do with the employment agreement. Whereas no one walks into a barber shop and signs a non-poaching agreement. You'd never sign an agreement in a hair salon that says, "If one of your employees go somewhere else or go solo, I won't have my hair cut by them." That's just not part of the deal.
(22:01): And so the non-competes that this person at the hair salon signed was a 10-mile radius. She apparently wasn't going to be allowed to ply her trade within 10 miles of the salon where she was previously employed. What does this tell you? Frankly, what this tells me is boy hair salons are a tough business. When I moved to Indianapolis, I went to a hair salon. I got my hair cut one time by one person, and before I could get my hair cut again, that person messaged me on Facebook two or three weeks later and said, "Hey, I'm going solo. I'm going to be over here now at this place where I rent my own salon space," and she'd done a great job of my hair. So I'm like, fine. Yeah, I'll go there. Right?
(22:46): Think about that from the perspective of the owners, the people who'd built up the original hair salon that I walked into that time, all the effort that they put into customer acquisition that led to me walking in the door was essentially just kind of leaked right out the back, and there was nothing they could do about it. But at the same time, someone who's entering that workforce for the first time, if you're a brand new hairstylist for instance, you're going to need to work in a salon to gain experience. No one's going to want to be your customer unless you are sort of working under someone else's banner.
(23:22): My two takeaways from that are, number one, that I'm glad that's not my industry. That sounds really surprisingly difficult and cutthroat. I would never have expected it. And secondly, employment agreements aren't things that get talked about a lot. So it might be that non-competes are just a lot more widespread than I would've ever thought they were. I started wondering, how many consulting companies in our space have non-competes for their employees? I was assuming it was zero, but after the hair salon example, I've got to assume that it's non-zero. I'm very interested to hear.
(23:54): Hit me up on LinkedIn or whatever. Let me know. Are you aware of, are you hearing from lots of people or anyone for that matter that they're excited about this FTC non-compete ruling? Which by the way, I hear it's four months before it even goes into effect. There's a possibility it'll get challenged and it might not get past the Supreme Court. So who knows where this actually goes in practice, but are you hearing lots of people sort of coming out of the woodwork talking about how exciting this is? 'Cause again, I have been assuming that it's only basically like a software industry thing or a Wall Street thing, and my eyes are opening up that it might have been a lot more rampant than I ever would've suspected. So very curious. Let me know.
(24:34): Okay, so let's call it an episode. Thanks for listening. We'll catch you next week.
Sign up to receive email updates
Enter your name and email address below and I'll send you periodic updates about the podcast.
Subscribe on your favorite platform.