How Flare's ops team went AI-first in three weeks

About Flare

Flare (Themis-Tech Inc) is a legaltech company founded in 2020, with offices in New York, Arizona, and Tel Aviv. They've built an AI-powered platform for delivering legal services to consumers, covering areas like divorce and immigration. The model works two ways: a direct-to-consumer offering providing AI-assisted legal services with lawyer supervision, and AI-powered tools for attorneys handling cases that require in-person court appearances. The company has about 225 employees and has raised multiple rounds of venture funding.

Rachel Horowitz joined Flare in 2021 when there were only 12 employees, initially as General Manager overseeing product and business functions during the company's early growth. She became COO in 2024 and now runs all of Flare's non-technical teams, including operations, customer success, sales and people. Before Flare, she spent years scaling consumer marketplace companies including Zola, M.Gemi and Plated, building distribution and partnerships across each. She's a Harvard Business School graduate and a First Round Fast Track mentor.

Where Flare was with AI

Flare wasn't starting from scratch with AI when they began working with OneTwo Growth Studio; if anything, they were more sophisticated than most companies their size.

Their engineering team was already running on Claude Code and other teams had built custom GPTs and Gemini Gems. More were experimenting with Zapier for agentic workflows and operational tasks and their data team had already seen strong results from running its own internal AI workshop earlier in the year.

So when Rachel started thinking about AI enablement for her ops leaders, she wasn't dealing with a team that was resistant or unaware. Instead, she saw a team that had been experimenting independently for months but had yet to reach their full potential. Everyone had tools, but none of it connected to how the team actually worked day to day. The experimentation was real but scattered, and it wasn't resulting in a different way of operating.

A structural issue at Flare also made this feel urgent: Rachel's teams didn't have dedicated product or engineering resources to build internal tools for operations. The kinds of things that would make a real difference - e.g., performance dashboards, automated reporting, data analysis that normally requires an analyst - were never going to make it to the top of the engineering backlog. Though they mattered to the team's day-to-day, they were permanently behind higher-priority customer-facing work.

"It's not going to ever stack rank in the top 10 things in the OKRs," Rachel said, "but it is pretty impactful in terms of the team's day to day and their ability to move metrics."

She wanted to find out whether her team could build these things for themselves.

Why they engaged OneTwo Growth Studio

Rachel didn't pick a vendor and schedule a training. She tested the approach first.

In January, she spent time one-on-one with me going through the tools, setting up a personal workspace in Claude Code, and getting a feel for what it could do for someone who isn't writing code. That session gave her a clear sense of the potential as well as the constraints. She shaped how the broader workshop should be structured, flagging things like the importance of not jumping straight into the terminal and building in more foundational context at the start. She came away sure that this was worth the investment for her broader team, and she came with specific opinions about how to make it work for people at different comfort levels.

As Rachel put it, "I thought it was important to (1) have everyone just carve out some time where this is all we were doing. And then (2) bring in someone that could give us some training wheels to get off the ground."

She assembled a cross-functional group of about 15 employees spanning ops, finance, sales, marketing, business operations and compliance. The intent was to build a shared foundation across teams so that people weren't just learning in isolation but rather developing a common language and a set of shared reference points they could build on together.

How we designed the engagement

We ran two two-hour workshops, a week apart, in late February and early March 2026. The approach centered on one principle: everyone works on their actual problems.

The first session built a shared foundation. Everyone got set up with Claude Code, worked through the core concepts, and had a working project by the end of the two hour session. I focused on making the technical concepts accessible without dumbing them down. Most people in the room had never touched a terminal before. They didn't need to understand the architecture behind an MCP server to use one. They needed to feel confident enough to connect Claude to their Google Sheets or Slack and see what happened when they did. That's a different kind of teaching. It's more about lowering intimidation than transferring technical knowledge, and it means explaining things in terms of each person's actual context rather than abstract concepts.

Then there was a deliberate week of space between the two sessions.

That gap was one of the most important design choices. The first session gave people a spark. For some it was seeing Claude analyze a dataset and produce insights they'd normally wait days for an analyst to deliver, while for others it was more conceptual, a shift in understanding about what this kind of tool could do for the work they were already doing. Whatever the specific moment was, people needed time to sit with it -to take it back to their own desk and try things on their own terms, explore without someone guiding every step, maybe break something and figure out why.

The second session built on the progress employees made during the gap. People came back and shared what they'd been working on, and those peer demos ended up being just as valuable as anything I presented. Seeing what a colleague had built for their own workflow made the possibilities feel closer than any polished example could.

What the team built

Rachel asked everyone to document their use cases in the Slack channel after the workshops. The range caught me off guard.

Someone in finance completely rethought his reporting workflow. He took the quarterly investor reporting process that previously took two hours down to about 15 minutes by automating the data assembly that he'd been doing manually. He also automated a monthly review deck, which had previously required hours of pulling data and formatting slides.

On the ops side, one team member built an app to handle a problem the whole team had been living with. In that example, routine case inquiries were each requiring about 20 minutes of digging through multiple systems, piecing together history, and coming up with a recommendation. Her new workflow pulls all the relevant information together, runs the analysis, and drops a recommendation into Slack. She estimated it was saving an hour a day across multiple people on her team.

Before the workshop, one team member had been pretty clear about where he stood on all of this: he told the group he was never getting rid of Excel. Just a few weeks later, he was regularly timing out his Claude credits and he hadn't worked in Excel that week. Claude was going into Excel for him.

The deepest adoption story came from the head of marketing. She went from the workshop into ongoing 1:1 coaching with me, building Claude into her daily workflow piece by piece. She started with brand compliance auditing, making sure marketing materials consistently meet internal standards. Her work culminated in a full product marketing agent setup in Claude Code. She had trained it on how their product marketer thinks, the documentation they produce, the way they give feedback on product specs. In Rachel's words, "She basically built a product marketer agent. A full person. A supplemental person."

That one resonated because it was exactly the constraint Rachel had been describing from the beginning. There were no spare product marketing resources available and the engineering roadmap wasn't going to make room for it. So the head of marketing built what the team needed, and now it's part of how they work.

How the team works now

The individual use cases were impressive on their own, but what Rachel kept coming back to in our conversations was the broader shift in how the team operates.

One of the ops leaders audited how her team actually spent their time. What she found was revealing. About 30% of their work was legacy tasks that probably shouldn't exist anymore, things that had accumulated over time and nobody had stopped to question. Another 30% was necessary but low-value, the kind of repetitive work that keeps operations running but doesn't move any metrics. The remaining 40% was the high-value work that everyone wished they could spend all their time on. The day after that audit, she built an app to automate a chunk of that middle 30% so the team could spend more time on the 40% that mattered.

That same pattern started repeating across other teams. People weren't just automating individual tasks that annoyed them. They were looking at how their teams spent time overall and building tools to shift more of it toward the work that actually matters to the business.

The team also created their own internal Slack channel for sharing what they're building. Nobody asked them to do this. Product leaders, data leads, and other leaders are all active in the channel, reacting to what people post.

Rachel's observation about adoption speed was the one that stuck with me most. She said that once people get past the initial learning curve, the frustration flips entirely. It goes from "I don't know how to use this" to "why can't it do more?" That shift happened across her team in weeks, and it's still going.

Rachel's advice for leaders considering this

I asked Rachel what she'd tell someone in a similar position who was thinking about doing something like this for their team. She came back to three things.

The first was about time. You have to carve out dedicated space for your team to learn and experiment. The tools are already available, but without protected time, people feel overwhelmed and don't know where to start. A structured workshop with a shared experience breaks through the intimidation in a way that sending people a login and hoping they figure it out on their own rarely does.

The second was about facilitation. Having someone who understands the types of problems that ops teams face made a real difference in how the workshop landed. Connecting AI capabilities to actual work that people recognized from their own week, rather than running through abstract demos or generic examples, meant people walked out with something they'd keep using.

The third was the one Rachel felt most strongly about, and it's the one I'd encourage any leader reading this to think about carefully. You need someone internally driving adoption after the workshop ends. At Flare, that person is Rachel. She shares articles with her direct reports. She posts use cases and asks teams to document what they've built. She keeps bringing new ideas and nudging people to try things they haven't considered.

"I'm instigating everyone all the time," Rachel said. "I'm always pushing them to do more here."

That ongoing energy matters more than people expect. Without it, teams tend to settle into one or two ways of using AI and stop exploring. Rachel pointed out that people get inspired by seeing what other teams have done, and each use case that gets shared sparks ideas on a different team. The internal channel they created became the mechanism for that, and the adoption keeps building on itself.

Three weeks from the first session, the team had changed how they thought about their work. What they expected from their own capabilities. Where they turned when they hit a problem that used to require an engineer, an analyst, or a headcount they didn't have.