Earlier this month in my post about the future of AI pricing, Intelligence Too Cheap to Meter, I ended with a story about being blown away by a demo of an internal tool built by an ops team:
I got a demo of an awesome SaaS product for CS teams. It integrated account scores, task management, calendaring and customer communication into a single streamlined workflow. There was AI chat for getting quick answers across all that data. Everything synced back to Salesforce. It even had a nice dark mode and achievement badges.
Except it wasn’t a SaaS product. It was a bespoke internal app built by their ops team. And they built it in under two weeks. Now it’s in production.
I suggested part of the reason an internal team would even attempt such a thing is due to the ever-increasing availability of powerful AI. That, however, grossly undersells the organizational transformation and team effort that makes it possible to not just consider it, but to actually succeed at it.
This week, I asked the leader of that ops team—Andrew de Geofroy, VP of GTM Strategy and Operations at Luxury Presence—to join me for a conversation about how they’ve rebuilt their team from one that was drowning in support tickets to one that’s capable of shipping a SaaS product (aka Scout) in two weeks.
In our conversation, he explains his “squad” model with a matrix reporting structure, his process for hiring builders, and the surprising (to both of us) role rap battles play in change management.
You should definitely give it a watch or a listen. Alternatively, if you still have a hankering for old-fashioned words on a screen, you can read my 100% human-written (Pangram approved!) takeaways below.
1. Removing rate limits with squads
We didn’t want the org structure that we had to get in the way of that and sort of rate limit us on how quickly we could bring new solutions to bear. (06:00)
Luxury Presence has a 22-person ops team that was originally organized around functions (e.g. Sales, CS, Launch) and platforms (e.g. RevTech, Analytics, Enablement). This split made it hard to deliver for specific functional stakeholders. When CS needed something, the functional ops leader didn’t always have all the resources necessary to deliver.
The functional ops business partner would often be blocked waiting on the platform team, while the platform team struggled to prioritize their backlog to ensure functional stakeholders got what they needed. Overall throughput suffered and the team spent most of its time reactively keeping up with tickets.
To combat this, Andrew reorganized the team into a matrix structure. Each ops leader became responsible for a “squad” dedicated to a specific functional area. That squad includes platform team members. This ensures the squad leader has all the resources at their disposal to deliver entire solutions.
They’ve adopted a matrix reporting structure where the platform team members report directly to the platform team leader but have a dotted line to the squad leader. Platform folks devote 70-80% of their time to the squad roadmap and the remainder to base platform work.
This new team structure has led to faster decisions, fewer tickets, happier stakeholders, and—as we’ll see—more ambitious roadmaps.
2. Hiring ops leaders who build
They almost resemble a little bit more like product managers or product leaders than we ever have in the past. (15:05)
The squad leaders increasingly need to act like product managers, which means hiring for a builder persona. Andrew used to be a journalist. He sees some surprising parallels between journalists and the persona he’s looking for: both share an innate curiosity that makes them ask questions and seek out on-the-ground facts.
He gives a shoutout to his CS ops leader who, soon after starting, jumped in with the CS team to observe their day-to-day activities and even take support calls herself.
He offers some practical recommendations for a hiring process that identifies builders:
Have everyone build something using AI - Give them a short brief and 48-72 hours to come back with a working prototype.
Pay attention to how they approach the exercise - Andrew keeps the brief consistent across all candidates but keeps it intentionally vague. If a candidate asks clarifying questions, it’s a good sign.
Have them demo to a panel - They should be able to demo their prototype to a cross-section of stakeholders. A good builder will be able to connect product capabilities to different people’s needs, not just list out features.
Obviously, the classic ops hiring move of “build a presentation about X” doesn’t cut it anymore. That’s a different skillset that’s less relevant in this model.
3. Balancing squads and platform teams
We could have […] eliminated the platform teams entirely. But I think that would have been a mistake, because then they would have been fully siloed and really wouldn’t have those opportunities to work together and share. (37:08)
Every org design has tradeoffs—this squad model is no different. The matrix reporting structure can sometimes leave the platform team starved for time. “In practice,” Andrew says, “the reality is the squads tend to consume the vast majority of the time.”
He’s developed a few counters to this:
Maintaining the direct line reporting structure with the platform leader ensures that platform specialists deliver their work using the same standards.
Frequently meeting with the platform and squad team leaders helps identify issues with time allocation.
Implementing a support rotation so that different platform team members are “on call” for any platform issues. This acts as a forcing function to ensure that nothing gets too siloed.
Giving platform leaders one focused sprint a quarter to devote 100% of their team’s time to platform work.
Andrew also called out one big thing about Luxury Presence’s culture here. One of their core values is “egoless collaboration”. If your org is not well-prepared to collaborate across teams, this will be hard for you.
4. Set the tickets aside (briefly) and ship
Even if we had these tools available, if we didn’t really get all the right resources aligned and structure it that way... I think two months later we’d still be trying to build this and wouldn’t get it there. (23:53)
No amount of AI matters if the team doesn’t have the breathing room from “keep the lights on” (KTLO) work to focus on delivery.
Generally speaking, Andrew’s teams work in a cadence of two-week sprints. Each team gets to dedicate one or two sprints a quarter to shipping something new. This allows them to set aside the KTLO work for a brief period of intense focus. Two weeks is short enough that stakeholders don’t feel like important support issues are being ignored, but it’s long enough to make extraordinary progress.
In a pre-AI world, you would have had to ask for a few months of focus to ship something ambitious, which just isn’t tenable—time doesn’t just kill deals in sales, it kills all initiatives. The resource alignment from the squad model plus the impact of AI tools dramatically reduces delivery time, which in turn expands what kinds of projects can even be considered.
5. Momentum makes change management easier
If you are promising something for months, you lose that momentum, you sort of lose trust. (29:28)
Before introducing the squad model at Luxury Presence, the ops team had been promising the CSMs better tooling for many months without delivering. That was hurting their credibility. The squad model turned all that around during the Scout sprint.
Because they can iterate quickly, they can incorporate stakeholders into the build process in a way that wasn’t possible before—and which helps build momentum. While developing Scout, they seconded a CSM as a tester. The CSM had the same reduced KTLO workload as the squad itself. As soon as their engineer shipped a change (which happened frequently), the CSM could try it out and provide real-time feedback.
Now that they’ve delivered the first version of the software, they’ve deliberately made adoption fun. They built leaderboards and gamification directly into Scout. “I have never seen CSMs act this competitively,” says Andrew. They’ve also encouraged adoption through team activities including karaoke, something called “laughing yoga”,1 and—I kid you not—Scout-themed rap battles. Frankly, it’s an impressive level of cringe that speaks to how excited the CSMs are.
Iterating fast creates momentum that builds on itself and, ultimately, makes change management less difficult. The only issue Andrew faces now is how to keep the momentum going as the CS squad transitions into a few more normal sprints before the next big build sprint.
And that’s a wrap! I hope this gives you some ideas for how to rearchitect your team to move faster and take more advantage of AI.
“Just Google it,” suggests Andrew. “I can’t promise the results will all be super safe.”
