AI Teams, Adoption, and the Power of Public Learning

AI Teams, Adoption, and Public Reading

TLDR: Building effective AI teams doesn't require PhDs or AI specialists—it requires strong prompt engineering, good product intuition, and removing barriers to adoption. The biggest challenge isn't technical, it's cultural.

Summary:

The composition of high-performing applied AI teams has shifted dramatically. Contrary to conventional wisdom, many of the fastest-moving AI companies aren't staffed with PhDs or researchers. Instead, they're built like modern software organizations with strong product intuition, excellent prompt engineering skills, and solid MLOps fundamentals. This insight comes from founders and investors who've observed that nearly every successful applied AI initiative started small—often as a hackathon project, a curious engineer exploring a new model, or an executive tinkering with an AI tool. The key pattern: start with a prototype that proves utility, then scale with a small core team.

As organizations mature, a platform-plus-product model often emerges. The AI platform team handles the infrastructure—evaluations, inference optimization, data pipelines—while product engineers ship features responsibly. This structure mirrors how successful technical teams have always worked: separation of concerns between platform and product, with each playing to its strengths. The implication here is significant: you don't need to hire specialists; you need to empower your existing engineers to learn and experiment.

This connects directly to one of the most underrated aspects of software development: the working conditions that enable good thinking. Darragh Curran, CTO at Intercom, has been driving AI adoption through a deliberate four-step framework. First, set ambitious public targets and make it clear this isn't optional—it's essential to future productivity. Second, actively remove barriers by being permissive about tool choices. Engineers should reach for Cursor, Claude, Copilot, or whatever suits their workflow. Third, leaders must use these tools themselves to understand the developer experience firsthand. You can't evangelize what you don't understand. Fourth, and this is critical, explicitly protect learning time. Many engineers cite lack of time as the primary barrier to adoption, which creates tension between shipping pressure and the investment required for long-term gains.

For teams implementing AI adoption: start by having honest conversations with your engineers about their concerns and barriers. Then systematically remove each one. Make tool choice permissive, not prescriptive. Use the tools yourself so you can discuss them authentically. Most importantly, signal that learning time is legitimate work. Without this, you'll create a false choice between velocity and capability.

A parallel insight emerges from Luca's experiment with public learning. When he made his reading list public and subscribed on Mailbrew, something powerful happened: the accountability of an audience created a feedback loop that made his underlying habits stick. This isn't about vanity metrics—it's about how humans are motivated. Public commitment changes behavior. When you know people depend on your recommendations, you read more carefully and stay more rigorous. For teams, this suggests an interesting pattern: building shared learning practices and making them visible might be more effective than top-down training programs.

Key takeaways:

Applied AI products succeed with strong product engineers and prompt engineers, not necessarily PhDs
AI adoption is primarily a cultural challenge, not a technical one
Remove barriers deliberately: allow tool choice, model use yourself, protect learning time explicitly
Public commitment and shared responsibility drive better habits and sustained learning
Start small with AI initiatives—let early wins justify the team investment

Tradeoffs:

Prioritize learning time but sacrifice short-term delivery pace to achieve long-term productivity gains
Enable tool flexibility but accept reduced standardization across the team
Build platform infrastructure early, which costs upfront engineering resources, but gains reusable capabilities and team autonomy at scale

AI teams, adoption, and public reading