EasySend

The people who built the best AI skills last week weren't the engineers. We ran a company-wide Skills Day at EasySend. Not a training, not a demo day - a day of building. Marketing, CS, PS, Support, Delivery & engineering in one room, one rule: you leave with an AI skill you built yourself that works. R&D has been writing skills for months. But adoption that only lives in the technical teams isn't adoption - it's a pilot. We don't have the luxury of moving at the old pace anymore. The bet is simple: find the manual, repetitive work that quietly eats days, and turn it into something an agent runs in minutes. So this time, the whole company sat down to build. We mixed the teams on purpose - technical and non-technical people from different departments together. The customer-facing folks brought the real pain. The engineers cleared the blockers. And then something I didn't expect happened: in most teams, it was the non-technical people who wrote the skill. The people closest to the customer found the highest-value automations, not the people closest to the code. The part that's easy to miss - a Skills Day only works if it sits on infrastructure. Two kinds: 1. Human infrastructure - our AI Guild: a champion from every department, not just engineering. They're not a committee. Their job is to keep moving the needle on adoption inside their own teams - remove blockers, align the message so everyone hears the same thing, seed the next idea. All day, they floated between teams, brainstorming skills, opening technical doors, and ensuring each skill actually had an impact. Adoption turned out to be a staffing decision, not a tools decision. 2. Technical infrastructure - an internal marketplace. On the day we deliberately cut the dependency on it, so everyone could just build and actually finish a skill. Wiring it into the marketplace is the next step: contributed via PR, shipped through CI/CD, and from there available to every employee - it updates itself across Claude Code, Desktop, and Cursor the moment the skill changes. It's also where the guardrails live: how to write a good skill, how we keep it secure and compliant, how it gets shared. The day creates the spark. The marketplace keeps it from going out. By the end, the whole company felt like one team pointed at one goal, and the skeptics converted. Anyone who thought "skills" was hype watched a manual afternoon become a two-minute prompt. We're not scaling teams the way we used to. So every person becomes a builder, and engineering becomes the orchestrator that makes that possible. This isn't the finish line - the next phase is a company brain, agent-maintained, so the knowledge compounds instead of scattering. If you're trying to push AI past your engineering org, here's the rule I'd steal: stop teaching people about AI. Give them one day to build with it, and the infrastructure to keep what they build. One working skill someone built themselves beats ten workshops about someone else's.

The implementation gap is becoming one of the clearest themes in Enterprise technology. As Jon Garcia, Senior Partner at McKinsey, put it: “When 70 percent of transformations fail, management teams must avoid the common pitfalls that undermine success.” McKinsey – Jon Garcia on why transformations fail This was true during the No-Code / Low-Code wave. And it is becoming even more true in the AI era. The technology is incredible. The models are powerful. The demos look magical. But many organizations still believe the software itself is the transformation. It isn’t. In conversations I’ve had with CIOs over the past few months, the same pattern keeps coming up: Most AI projects do not fail because of the model. They fail because of everything around the model: Data Processes Compliance Security Integration Change Management Business Logic Ownership Operational Readiness And the market is starting to react accordingly. One of the hottest roles emerging in AI is not “Prompt Engineer.” It’s FDE ( Forward Deployed Engineer). A role that companies like helped bring into the mainstream. As Marty Cagan from Silicon Valley Product Group wrote about the rise of FDEs: “The real value is not in building the technology, but in deploying it successfully into the customer’s business.” Marty Cagan on Forward Deployed Engineers And that is exactly the shift happening right now across enterprise AI. The challenge is no longer just building technology. The challenge is making it work inside real enterprises. Good FDE teams understand: Product Business workflows Integrations Compliance UX Legacy systems Organizational dynamics And how to drive actual adoption They take AI and SaaS from demo → production → measurable ROI. I came back this week from a CEO summit with our investors in San Francisco, and one of the most interesting discussions was around the new cycle emerging in enterprise software: Service → SaaS → AI → Service Not because SaaS failed. And not because AI is hype. But because the market is rediscovering that technology alone does not create ROI. More enterprise buyers are beginning to realize that when they purchase AI or SaaS platforms, they are not only buying software. They are buying: Implementation capability Knowledge retention Domain expertise Execution And the people who know how to bridge the gap between technology and operational reality Without that layer, even great technology can fail. I’ve been fortunate to work with people like this since the first days of building EasySend. People who know how to take ambitious technology, navigate complexity, integrations, regulation, and enterprise constraints — and turn them into something customers can actually deploy, adopt, trust, and measure. Today it feels clearer than ever: In the AI era, the real competitive advantage may not be who builds the best model. It may be who builds the best teams at turning technology into real enterprise outcomes.

In insurance, every player owns the customer. Except one. The TPA takes the call. Opens the claim. Sends the forms. Chases signatures. Resolves the case. But the policyholder is not theirs. The brand on the form is not theirs. And the promise being kept -->or broken -->is not theirs either. That is the structural reality of being a TPA: You operate someone else’s brand, execute someone else’s policy, and often absorb someone else’s blame. Which is exactly why operations matter so much in this layer of the industry. Because for the policyholder, the entire carrier experience collapses into one deceptively simple object: The form. The form is where the carrier’s brand actually lives. The form is where the audit trail begins. The form is where data either reaches the system of record — or disappears into email threads, PDFs, and manual follow-ups. And most of the industry still treats it like a document problem. E-signature platforms digitized the signature not the workflow. Portals digitized storage — not intake. PDFs digitized paper — not data. None of them solved the operational gap between what carriers expect from TPAs and what TPAs are structurally equipped to deliver. At EasySend, we built around that gap. We turn the form into the workflow itself dynamically branded per carrier, routed across every participant, identity-verified, audit-trailed, and synced into the system of record before anyone has to ask where the file went. The TPAs already operating this way are no longer positioning themselves as an operational cost center. They are becoming the part of the carrier the customer actually experiences. Which, in reality, they always were.