# Operator-Led > Analysis and frameworks on AI adoption, software operations, and value creation in PE-backed technology companies. Operator-Led is a publication by Mo Battah. It covers how AI is changing product execution, technical team design, and software economics inside PE-backed businesses. --- ## The AI Readiness Ladder ### A Practical Sequence for AI Adoption In portfolio companies, AI work breaks at the handoff from demo to production. The problem is not model access. The problem is production readiness: release process, test coverage, data access, and the people directing the tools. A recurring boardroom sequence looks like this: a competitor launches a feature, directors ask for an AI plan, a prototype appears quickly, and the work then slows once it reaches release controls, environment parity, or data preparation. The delay begins when the feature has to meet production requirements. The ladder is a production checklist more than a maturity model. The five steps run from ad hoc tool use to customer-facing AI features. ### Step 0: Basic AI Adoption Individuals use ChatGPT, Claude, or copilots for ad hoc work. That matters, but it is not yet an organizational capability. Every company can buy the same tools. There is little advantage unless usage is systematic and tied to measurable output. A board slide that says "the team uses AI" can describe nothing more than a few engineers with separate subscriptions and informal habits. When those habits are personal rather than institutional, the capability does not persist. Treat Step 0 as a baseline. Useful, but insufficient. ### Step 1: Agentic Tooling + High-Agency Talent The company has moved beyond ad hoc prompts. Engineers use agentic tools to draft code, tests, scripts, and operational work, and they can independently accept, revise, or reject the output. Tooling matters, but the limiting factor is high-agency talent. This is where agency shows up. Strong engineers use AI the way a good manager uses a junior team: clear scoping, fast review cycles, and high standards. The tool expands the reach of an already capable person; it does not substitute for one. A company can buy licenses in a week. It takes longer to identify who can use them well. That is why Step 1 is partly a staffing question. ### Step 1.5: Fix the Fundamentals — Using Agentic Velocity This is the step many companies skip. Before shipping AI into the product, fix the operating basics: CI/CD, automated testing, security controls, environment parity, and release discipline. AI features do not remove the need for good software operations; they make the cost of weak operations more obvious. Agentic tooling changes the economics of this work. In a recent engagement with a PE-backed SaaS company, we deployed a complete network re-architecture to production — replacing an insecure network with a secure one — within 30 days. A web application firewall that would have taken months to plan and deploy was operational in weeks. These timelines would not have been realistic two years ago with the same team size. That does not make the work optional. It removes the old excuse that the foundation will take too long to fix. Step 1.5 is where a company becomes able to ship reliably. Without it, every AI initiative becomes a custom project with avoidable production risk. ### Step 2: Data Readiness AI capability depends on clean, accessible data. The question is not whether the company has data in the abstract. The question is whether the underlying systems produce data that can be queried, joined, and audited without a side project. Data readiness is not only a data science concern. It is also a product and engineering discipline concern: event instrumentation, stable identifiers, coherent schemas, and sane pipelines. Many portfolio companies have years of accumulated data debt. Until that is addressed, the output quality of AI features will be uneven and hard to trust. ### Step 3: AI Features That Deliver Outcomes Only at this stage does it make sense to build AI directly into the product or operating workflow. The supporting conditions are in place: the team can ship, the data is usable, and the organization knows how to measure whether the feature is working. The distinction is not between "AI" and "non-AI." It is between features that are lightly wrapped around an API and features that are integrated into the product's economics, data, and customer workflow. Step 3 should show up in operating metrics: faster resolution times, higher throughput, better prediction quality, or lower cost to deliver a specific result. > AI features usually fail at the production layer, not at the model layer. Steps 1 and 2 do not produce flashy board slides. They do determine whether a feature survives contact with production. ### How to Assess Where You Are If you are trying to place a company on this ladder, the useful questions are operational. They are less about vision and more about what the engineering organization can already do on a normal Tuesday. **Step 0 — Diagnosing Basic AI Adoption** Questions to ask the CTO: - "How are your engineers using AI tools day-to-day?" - "What's your policy on AI-assisted development?" - "If I asked three random engineers on the team what AI tools they use, would they all give me the same answer?" If the answers are informal, inconsistent, or based on a few enthusiasts, the company is still at Step 0. That is normal. The mistake is describing it as a mature AI program. **Step 1 — Diagnosing Agentic Readiness** Questions to ask the CTO: - "How many of your team members could build an internal tool using AI in a weekend?" - "Who on your team is pushing AI adoption without being asked?" - "Show me the last thing an engineer built in a day that would have taken a week two years ago." Step 1 shows up when the CTO can point to specific people and concrete output changes: internal tools built quickly, repetitive work automated, release cycles shortened. If the story is only about licenses purchased, the company is not there yet. **Step 1.5 — Diagnosing the Fundamentals** Questions to ask the CTO: - "How long does it take to deploy a code change to production?" - "Can you roll back a deployment in under 5 minutes?" - "Do you have staging environments that mirror production?" - "What percentage of your codebase has automated test coverage?" These questions have concrete answers. Slow or fragile deployment, missing staging parity, and minimal automated testing all signal the same thing: the organization is not ready to scale AI work into production. **Step 2 — Diagnosing Data Readiness** Questions to ask the CTO: - "Where does your customer data live? Can you query it without engineering help?" - "How clean is your data pipeline? When was the last time you found a data quality issue in production?" - "If I gave you an AI model that needed your last 12 months of customer interactions, how long would it take to prepare that dataset?" The key issue is how quickly the company can assemble a usable dataset for a live problem. If the answer involves manual exports, inconsistent IDs, or multiple teams, Step 2 is unfinished. **Step 3 — Diagnosing AI Feature Maturity** Questions to ask the CTO: - "Which product features currently use AI or ML?" - "Are those features driving measurable customer outcomes or just checking a box?" - "What's the feedback loop? How do you know if an AI feature is actually working?" A genuine Step 3 company can explain impact in customer or operating terms. A weaker company talks mainly about the model choice or the demo. --- ## Tools to Outcomes ### How AI Changes the Economics of Software Most software products help the customer do work. They rarely own the result. The interface organizes a workflow, but the customer still provides the labor, judgment, and follow-through. That model supported a large SaaS market. Vendors sold seats, features, and administrative control. Customers bought software and then staffed teams to operate it. The software improved the process, but the customer still owned most of the execution risk. AI changes the boundary. In more categories, the vendor can take responsibility for part of the work itself. The product is not only a system of record or a dashboard. It becomes part of the execution layer. > As software takes on more of the workflow, the interface matters less than the result. That matters for PE-backed software companies because the competitive threat is straightforward: if your software only provides a tool, a competitor will provide the outcome — and take your customers. Your product has to automate part of your customer's job. If it does not, someone else's product will. The strategic question is whether a company is still selling access to a workflow or moving toward ownership of the result. The change is clearest in workflows that are repetitive, measurable, and built on structured data. ### The Diagnostic These four questions reveal more than a roadmap deck. They separate products that assist a workflow from products that are starting to absorb it. Evaluation rubric: - **Does the product measure success in customer business terms, or mainly in product usage terms?** If the company talks mostly about feature adoption, seats, and engagement, it is still oriented around the tool. If it talks about throughput, resolution rates, or dollars saved, it is closer to an outcome model. - **Could an AI agent complete major parts of the workflow with limited user involvement?** If yes, the defensible value is more likely to sit in the workflow, data, and distribution than in the interface alone. - **Does pricing improve when the customer achieves a result, or simply when more employees log in?** Pricing reveals the economic model. Per-seat pricing ties value to labor usage. Outcome-linked pricing ties value to the result. - **If a competitor wrapped the same workflow in AI, what would still be hard to copy?** Proprietary data, domain-specific logic, embedded distribution, and trusted workflows are stronger answers than "we have a good UI." If management answers these questions in usage metrics rather than customer results, the business is still selling a tool. The more interesting cases sit in the middle: enough workflow control and data to move, not enough to claim the shift is complete. ### Where This Is Happening First This transition is moving fastest in categories where the workflow is rules-based, the data is structured, and the output is measurable. **Compliance & Document Processing.** The traditional product gave compliance teams a better review interface. The newer model takes on the document flow itself: extraction, classification, validation, and routing. In a recent engagement with a PE-backed SaaS company, an AI-powered document ingestion system compressed enterprise customer onboarding from over a month to one business day. Because the system parses every document programmatically rather than relying on human reviewers, it captures data that manual processes routinely miss. That richer data now powers new product features the company sells to its customers — more value delivered, not just faster processing. **Customer Support.** Support vendors used to sell better ticket handling. The market is moving toward first-pass resolution. Klarna deployed an AI assistant in 2024 that handled two-thirds of all customer service interactions — 2.3 million conversations — and cut average resolution time from 11 minutes to 2 minutes. The commercial question shifted from how many agents a company staffs to how many issues the system resolves without human involvement. (Klarna later rehired some human staff after quality issues surfaced, which reinforces the point: the outcome has to hold, not just arrive quickly.) **Financial Reporting.** Finance software has long helped teams assemble dashboards and reports. AI is starting to take on more of the analysis itself: identifying variances, generating commentary, and reducing the manual work between raw data and a board-ready narrative. **Content & Marketing Automation.** Marketing tools historically improved coordination around campaign execution. AI pushes those platforms toward content generation, targeting, testing, and optimization. Duolingo made this shift explicitly: in 2024, the company replaced contract translators and writers with AI-generated content, framing it as the only way to produce the volume of material needed to scale across languages. The customer cares less about the authoring tool and more about pipeline produced per dollar spent. The pattern is clearest where the workflow is repetitive and easy to measure. Those categories move first because the path from software assistance to partial automation is shortest. ### Implications for PE Deal Thesis This changes how a deal team should evaluate a software target, both as a risk and as an opportunity. **On the risk side:** a company whose product only assists a workflow — without automating any part of the customer's job — is exposed. If a competitor builds AI that delivers the result directly, the tool-only company loses customers regardless of feature quality or brand loyalty. The question is not whether management mentions AI on the roadmap. It is whether the business can deliver outcomes before a competitor does it for them. **On the opportunity side:** the best candidates already control the data, domain workflow, and engineering execution needed to move closer to the result. But that transition requires product changes, operating discipline, and a different way of measuring success. Adding an AI feature to the roadmap is not the same as restructuring the product around the customer's outcome. The hold-period question is concrete: can this company move from tool orientation toward outcome delivery before exit, and what would that require in product, data, and management capability? Deal teams that can answer that question with a realistic execution plan will underwrite software assets more accurately. --- ## The Intensification Thesis ### Why AI Raises the Value of High-Agency Employees Market commentary treats AI as a labor-saving tool. The evidence points in a different direction. An eight-month ethnographic study by researchers at Berkeley Haas, published in Harvard Business Review in February 2026, found that AI tools did not reduce work at the company they studied — they intensified it. Employees worked at a faster pace, took on broader scope, and extended work into more hours. The self-reinforcing cycle was clear: AI accelerated tasks, which raised speed expectations, which increased AI reliance, which widened scope further. Inside software teams, the more important effect is uneven. AI increases the output of employees who already know how to frame problems, review work, and keep moving. The same logic extends beyond engineering. A high-agency engineer ships more. A high-agency support employee can resolve more issues at a higher standard. A high-agency customer success manager can cover more accounts without lowering the level of service. A high-agency employee in sales or operations can prepare faster, follow through faster, and move with less administrative drag. The productivity data supports this. Microsoft Research found that developers using GitHub Copilot completed tasks 55.8% faster in a controlled experiment, with measurable improvements in code quality. But the gains are not automatic — the same research shows it takes roughly 11 weeks for developers to fully realize the productivity benefits, which means the return depends on the person, not just the tool. For management teams and investors, the implication is straightforward. AI does not simply reduce labor demand across the board. It increases the return on employees who can use the tools with speed and independence. One well-paid, high-agency employee can now do work that previously required several average employees. > Same tools, different workforce, different output. The hiring variable that matters most is orientation. A high-agency employee is not thinking about job security. They are thinking about financial impact on the company, about improving operations, about doing more with less, about raising the bar for customers. That orientation — toward impact rather than self-preservation — is what determines whether AI tooling produces outsized returns or sits unused. The operating model that follows is smaller teams, higher-agency employees, and higher compensation for employees who can carry more scope. "Fewer, better, higher paid" is the shorthand, but the real point is leverage: moving from average-paid employees who protect their position to higher-paid employees who raise the standard. The result is a more efficient company with a higher internal bar. Quality standards rise because fewer people are carrying more responsibility. Productivity standards rise because the weaker forms of coordination work become harder to justify. Operating standards rise because a smaller, better-paid team has to ship cleanly and consistently. ### Fewer, Better, Higher Paid **What remains valuable:** senior engineers who can design systems and review AI-generated work, product leaders with strong domain expertise, support and success employees who can use AI to handle more customer volume without lowering service quality, and infrastructure people who make release processes reliable. **What compresses first:** routine implementation, manual QA, repetitive support work, low-value follow-up work, and documentation or reporting tasks that can be drafted or automated once standards are clear. **How compensation shifts:** a smaller team may cost less in aggregate even while paying far more for the remaining seats. The relevant measure is output per experienced employee, not salary bands in isolation. The argument is not to underpay fewer people. It is to pay more for employees who can carry far more productive scope. Headcount reduction alone does not work. Klarna automated two-thirds of its customer service interactions with AI in 2024, handling 2.3 million conversations and reducing resolution time from 11 minutes to 2 minutes. But the company's CEO later admitted that quality suffered, and Klarna began rehiring human staff. The lesson is not that AI cannot handle the volume. It is that removing people without raising the bar for the people who remain produces a worse outcome, not a cheaper one. In PE settings, headcount is treated mainly as a cost lever. In an AI-accelerated organization, it is also a leverage decision. ### Implications for PE Operating Models If this dynamic holds, it changes several parts of the post-close playbook. **The 100-Day Talent Plan Looks Different.** The traditional 100-day plan asks which open roles need to be backfilled. A higher-leverage model changes the question. Which roles should actually remain open? Where should savings be redeployed into higher-agency employees, better tooling, and stronger retention across engineering, support, success, sales, and operations? This is not simply a headcount reduction exercise. It is a redesign of how the team operates, with fewer roles, clearer standards, and more investment in the people who can carry broader scope. **Management Assessment Changes.** Traditional CTO assessment focuses on recruiting, team management, and technical credibility. Those still matter. The additional question now is whether this person can run a smaller, faster, AI-augmented organization without losing quality. Managing a 15-person high-leverage team is different from managing a 45-person conventional one. Communication is tighter, expectations are higher, and weak performers are more expensive. Not every CTO who worked well in the older model will work equally well in this one. **The GP-Level Capability Gap.** Many PE operating teams are still benchmarking against pre-AI org charts. That makes it harder to judge whether a smaller team is under-resourced or simply better tooled, and whether a higher compensation band reflects inefficiency or leverage. The larger firms are moving. Vista Equity Partners reported that by January 2026, 30 portfolio companies were already generating revenue through agentic AI, with another 30 to 40 expected by mid-2026. Thoma Bravo now deploys dedicated AI transformation teams into portfolio companies to modernize sales, marketing, and R&D. But evaluating AI-augmented team structures requires different judgment than evaluating traditional org charts — and that capability gap at the GP level is real. > The central operating question is not how many engineers a company employs. It is how much reliable output the organization gets from each experienced employee. The point is not to predict a single future org chart. It is to recognize that AI is already changing the economics of technical leverage. Firms that evaluate teams on that basis will make better staffing and underwriting decisions. --- ## About Operator-Led is a publication by Mo Battah. - Blackmere: https://blackmere.ai - Mo Battah: https://mobattah.com