OPT   Operator's Take

One of the brands we work with runs a lifecycle program far more complex than a typical e-commerce brand's, with high send volume, offers that shift constantly, and journeys that react to customer behavior in real time. Its lifecycle team recently connected the CRM to AI through an MCP server. Agents could now read customer data, build segments, write journey logic, and set up campaigns with all their rules in place. For a program that complex, it was a step change in what the team could do. It started producing campaigns at a pace and volume it had never reached before.

The same change that freed up the lifecycle team handed the design team a hard problem. Each campaign still needed creative, whether an email, a pop-up or an in-app promotion. The design team was using AI too, working from an encoded design system, and it still struggled to deliver assets at a rate that wouldn't slow the lifecycle team down. The lifecycle team had finished work it couldn't launch, and the results and reporting it needed to plan the next round were stuck behind the same assets. For the workflow as a whole to keep moving, both teams had to rise to the occasion.

We've argued that building got cheap, so the hard part is choosing what's worth building, and that teams should encode their design system so quality keeps up with the speed. This team had done both, and the work still waited, because AI had sped up two parts of a single process, but at vastly different rates.

Most talk about AI and speed focuses on individuals getting faster. Inside a team, the more useful question is how much faster each function got relative to the ones it collaborates with. Campaign logic is mostly reasoning over data, which AI handles very well. Design asks for taste and judgment. A strong design system that leverages AI only narrows the gap, but doesn't close it. This type of gap shows up regularly between departments and at different scales.

Any pair of functions can show this. Research can now outrun the marketers who turn it into positioning and campaigns, campaign builders can outrun creative, and designers can outrun the engineers doing complex integrations. Each person clears their part sooner, and the finished work joins a queue at whichever function is sped up the least.

Others are seeing the same pattern. Claire Vo wrote on X this week that once teams figure out building with AI, the constraints move upstream to ideas and org structure and downstream to review and go-to-market, and that fixing it takes a leader willing to force the changes. One reply pointed out that most downstream fixes are tools a team can buy this quarter, while the upstream ones live in the org chart, which always moves slower.

Every team we talk to is being asked to move faster, and much of that pressure comes from executives and owners who know these tools exist and assume everyone should be faster by now.

Some leaders see a lifecycle team waiting on design and decide the design team is slow. The real picture is harder to read. Teams are made of people with different skills, tools and workloads, and AI has changed each of those unevenly. There's no quick fix for making a whole team move faster and better. The leaders who understand that roll up their sleeves, learn what each team is dealing with day to day, and work out the fixes alongside them, whether that means setting timelines by function, starting the slower function earlier, or putting effort into the handoffs where finished work sits.

For the lifecycle team above, that meant two changes. The first was tightening the design system so creative could move closer to the campaign team's pace. The second changes who does what. We're building a workflow where marketers with a good eye can request routine assets from an agent inside Slack. The agent builds each asset on an artboard from the design system, and the marketer can take over for small fixes. The goal is an asset ready to ship within two or three rounds of feedback, which can take a matter of minutes, with no designer involved, so designers can spend their time on the bigger work that needs taste and judgment. The workflow isn't live yet. Every piece of it already runs in our other systems, including a design system that produces emails and web banners at scale, and we expect the first version within a few weeks.

Moving routine assets from designers to marketers changes two jobs at once, and the people in both roles want to know where the change is heading. In our experience, the first thing they ask about is the end goal and the reason behind the change. When we've asked designers to learn some code basics, the answer they needed was specific. We make it clear we don't want them to become engineers. The reason is the handoff to engineering. Motion built with code-based AI tools reaches engineers as working code, while motion mocked up in Figma leaves an engineer guessing how to translate it, and each guess can dilute what the designer intended. Framed that way, learning some code protects the quality of their own work.

People also need clarity on what success looks like now, what the job is becoming, what it should stop including, and where to stop spending time. Leaders tend to talk about what else people should take on, and rarely have a reasonable conversation about what comes off their plate to make room. Explaining the change as a long-term efficiency story leaves people without answers to any of it.

Some people need the change in smaller pieces. One person on a team we work with found AI overwhelming at first. We started her on a single task, connecting her AI assistant to her email so it could find the material she needed for a project, and it took away a chore she disliked. After three or four months of adding one use case at a time, she uses it freely.

The hardest part for us is time. People need room to stumble through new tools, iterate and make mistakes before they feel confident in what they put out. They're also being asked to build more and build it faster. Those two demands pull against each other, and we're still working out how to balance them.

What we do now is informal. We take the strongest people on part of the team and point them at frontier work, such as a new model, a new platform, or a moonshot systems project we've been holding, and see how far they can push it. Their regular work goes to teammates who pick up the slack.

That points at a bigger structural question. Say a team runs well on a set of tools and a new product replaces one of them. Swapping it out for everyone at once sends every person into experimentation mode while the work still has to ship. A small group can rebuild the system with the new tool, pressure-test it, and roll it out once it covers what the team needs.

Others are building this into their structure. Josh Woodward of Google Labs argues that every company now needs to operate more like a lab. In his framing, a lab is a small team of two or three people that tries what new models make possible, moves fast, and expects most experiments to fail. Dan Shipper runs a labs function at Every along the same lines. An idea starts in the lab, gets proven in real work, spreads across the company, goes to early customers, and only then moves to the product team. He pairs someone who runs the messy experiments with someone who makes the result hold up. Our point is narrower: exploration and delivery can't share one job description without one of them starving.

How formal that gets depends on size. In a large organization, the change moves slowly and needs real structure. In a small team, the lab might be one person with protected time and a plain way to hand what works to everyone else.

Most teams have bought the tools by now, and the better ones have started encoding their systems. What's left is how the team itself is organized, and only the people who lead it can change that.

Ghost Brief helps the brands we work with redesign how their teams work as AI speeds parts of it up. If your team is moving faster in some places and stuck in others, we'd like to hear about it.