Skip to content

The Rise of the Capability Engineer

Brian Lambert, PhD
· 23 min read
The Rise of the Capability Engineer

A Capability Engineer is the person accountable for how humans and AI agents work together to get a job done, and for making sure training for people and instructions for agents both serve that result. It is a new role because the old unit of work, the individual employee, no longer describes how work gets done. Before you build that next course, ask a different question: what capability does this work require, and is learning even the right enablement play.

TL;DR

  • Capability Engineering is not a new name for Learning & Development. It widens the unit of capability from the individual to the combined human-and-AI system through which work gets done.
  • The operating principle fits in one line: develop humans, train agents, engineer collective intelligence.
  • A Capability Engineer does not own the people or the agents. They own what happens between them.
  • The work starts with diagnosis: what the work requires, where the friction sits, and whether learning is the right response at all.
  • Measurement is the weak point in most organizations today, which is why the role is emerging now.

Table of Contents

 

Cognistry
cognistry.co
Engineer Capability From Evidence
 
Cognistry helps enterprises diagnose what work requires, decide whether learning fits, and ground capability design in business evidence.
Explore Cognistry

Why this role is appearing now

For decades, enablement had a simple shape. A business need appeared, someone requested training, a team built a course, and completion rates came back as the proof. That shape assumed one thing: people do the work, and people are what you develop.

That assumption is breaking. Agents now draft, route, classify, recommend and sometimes act. The work is done by a combination of people, software and AI, and performance depends on how well those parts hand off to each other. A flawless course for the human half does nothing for a handoff that nobody designed.

The labor market is already reacting to this shift. The World Economic Forum’s Future of Jobs Report 2025, as charted by Visual Capitalist, puts Big Data Specialists (110% growth), FinTech Engineers (95%) and AI and Machine Learning Specialists (85%) at the top of the fastest-growing jobs for 2025 to 2030. Those figures come from a survey of more than 1,000 employers representing 14.1 million employees. They describe demand for people who build the technical layer. Someone also has to be accountable for the layer that makes it perform in real operations.

Growth rates for three fast-growing job categories

That someone is the Capability Engineer.

What a Capability Engineer actually does

The title borrows from engineering for a reason. Engineering means designing a system against requirements, testing it, and being accountable when it fails. Applied to capability, the job looks like this:

  1. Diagnose. Establish what the work requires to be done well, in the organization’s own terms.
  2. Decide. Determine whether learning is the right response, or whether the gap sits in tools, process, incentives, data or the way work is handed between people and AI.
  3. Structure. Design the response: courses where knowledge is the gap, practice simulations and decision environments where judgment is the gap, and clear specifications where an agent is involved.
  4. Assure. Put quality gates in place before anything reaches the workforce.
  5. Measure. Tie outcomes back to business results, not to completion.

Notice the order. Building comes third. Most organizations start there, and that is where money disappears.

The one contrast that defines the role

A Capability Engineer does not own the people. HR, managers and business units do. A Capability Engineer does not own the agents. Technology and product teams do. They own what happens between them: the handoffs, the decision points, the places where a person must judge what an agent produced, and where an agent must be constrained by what a person knows.

Human and agent work meeting at decision points

That is the third layer in the operating principle. Develop humans. Train agents. Engineer collective intelligence. The first two layers are familiar. The third is the one almost nobody is accountable for, and it is where performance is won or lost. We explore this further in Capability Engineering in the Age of Collective Intelligence.

Where the idea comes from

The phrase is not new in engineering. Software and defense communities have long asked how an organization reliably produces a result. The Capability Maturity Model was developed in the 1980s at the Software Engineering Institute at Carnegie Mellon University, as the SEI describes in its 40th anniversary material, to address software development challenges for the U.S. Department of Defense. It defined five levels of process maturity: Initial, Repeatable, Defined, Managed and Optimized. It later became the foundation for CMMI, released in 2002.

The lesson that carries over is simple. Outcomes come from systems, not heroics. Organizations that depend on individual effort get inconsistent results, and organizations that define, measure and govern how work gets done get repeatable ones.

The new part is what the system contains. It used to be people following processes. Now it is people and AI agents sharing the work. The question moves from “how mature is our process?” to “how well does our human-and-AI system decide, act and learn?”

The measurement gap is the opening

If enablement were already proving its value, nobody would need a new role. The data says otherwise. According to the Association for Talent Development’s Organizational Use of AI for Talent Development report, fewer than half of talent development professionals measure AI’s effect on key metrics such as knowledge retention or employee engagement. Only 26% of organizations measure how AI in talent development helps meet revenue goals, and 22% measure its effect on customer retention.

Read that carefully. The tools are arriving faster than the evidence that they work. Leaders are buying AI, adopting it, and training around it, without a clear line from the activity to the business result.

This is what we call data drag: the performance-draining gap between what people learn and what they do on Monday morning. It shows up as AI licenses that sit idle, managers who cannot tell good AI output from bad, and training that scores well on completion and changes nothing in the work. If you recognize the pattern, our piece on AI bought, outcomes flat walks through how leaders diagnose it first.

What good measurement looks like

A Capability Engineer starts with the business metric the work is supposed to move, then works backward. Which decisions drive that metric? Who makes them? What do they rely on? What does the AI contribute, and where does it go wrong?

Operational data matters here. Organizations that already track productivity at the team level can borrow methods from adjacent fields. For example, this analysis of time tracking payback for billable teams and field crews shows how a workforce-data discipline frames return in weeks rather than abstractions. The same habit applies to enablement: pick the operational signal first, then decide what to build.

Two cautions keep the measurement honest:

  • Completion is activity, not capability. Treat it as a delivery metric only.
  • Outcome claims need your own data. Be wary of any vendor, including us, quoting improvement percentages that you cannot trace to a verifiable customer study.

Diagnosis before design

The most expensive sentence in enterprise enablement is “we need a course on that.” It skips the question of cause.

Before anyone builds, a Capability Engineer separates two kinds of gap:

  • Person gaps. The employee lacks knowledge, practice or judgment the work requires. Learning can help.
  • Environment gaps. The tools are clumsy, the process contradicts the policy, the incentives reward the wrong behavior, the data arrives late, or the AI output cannot be trusted. Training people to cope with these gaps is waste.

Most organizations find a mix, and the environment share is usually larger than expected. That is not a criticism of learning teams. It is a reason to put diagnosis ahead of design.

The evidence a diagnosis draws on

In our usage, evidence means the organization’s own source material that grounds a design decision. Four sources do most of the work:

  • Strategy. What the business is trying to achieve, and which capabilities that depends on.
  • Frontline friction. Where work stalls, gets reworked or gets escalated, as described by the people doing it.
  • Quality findings. Audits, defects, errors, complaints and exceptions.
  • Subject-matter expertise. How the best people actually decide, captured before it walks out the door.

A design built on those four sources is defensible. A design built on a template, or on what a generic AI model guessed a course should contain, is not. If you want the 6 to 8 week version of this process for AI programs specifically, see our diagnosis approach before AI training.

Judgment, not recall

Once diagnosis says learning is part of the answer, the next question is what kind. Recall is easy to teach and easy to test. It is also rarely the problem. A claims adjuster, a nurse manager, a service lead or a plant supervisor usually knows the policy. What they struggle with is the call in a messy situation with incomplete information and a fast-talking AI assistant offering an answer.

That is operational judgment, and it develops through practice:

Gap What it needs Poor fit
Missing knowledge Short, focused learning content Long simulations
Weak judgment under pressure Practice simulations with realistic consequences Slide decks and quizzes
Unclear decision rights between people and AI Redesigned workflow and a decision environment to rehearse it Awareness training
Broken tools or process Fix the environment Any training at all

The fourth row is the uncomfortable one. Sometimes the right enablement play is no training. A Capability Engineer says so, and shows the evidence.

Governance belongs in the job

As AI moves into higher-stakes work, someone has to be accountable for how people oversee it. Researchers studying regulation have noted that management-based approaches to AI governance are spreading, and that for high-stakes uses, relying on data-only training is becoming insufficient. Organizations are increasingly expected to include explicit human guidance and oversight to support safety and explainability.

That has a direct enablement consequence. If a regulator, auditor or customer asks how your people oversee an AI system, “they took a course” is a weak answer. A stronger one shows what decisions the person owns, what they were prepared for, and how you checked the preparation held up. For U.S. organizations building that foundation, we have a practical guide to AI governance and a companion on building team capability around governance strategy.

How the work itself is being redesigned

Capability Engineers do not operate in a static organization. McKinsey’s Martin Harrysson and Natasha Maniar argue in a talk on moving away from Agile that AI-assisted software development requires redesigning operating models, not just adding coding tools to established teams. They describe small, multidisciplinary pods of three to five people who consolidate roles such as front-end, back-end and QA into product builders who orchestrate agents. They also describe a shift from long requirement documents to continuous, specification-driven work with agents.

That talk is about software teams, but the implication travels. When roles consolidate and agents take on pieces of the work, the questions multiply. Who decides what? Who checks what? What does a person need to know to supervise an agent well? Those are capability questions, and no job description answers them by itself.

Who needs this role first

You do not need a department. You need accountability. In practice the role lands first in four places:

  • Transformation teams that must prove workforce readiness before go-live, not after.
  • Learning and enablement leaders who are asked to show business results and have only completion data.
  • Business unit leaders who are accountable for team performance, not training attendance.
  • Executives deciding whether training is the right response to a performance problem at all.

Managers deserve special mention. They sit at the point where AI output meets human judgment, and they are often the least prepared. Our article on AI manager enablement explains why that gap stalls transformation.

Our perspective

We built Cognistry because we kept watching the same sequence. A problem surfaces. Training is commissioned. A course ships. Completion looks fine. The problem stays.

The issue was never effort or talent. It was order. Organizations build before they diagnose, and they measure activity because outcomes are harder to trace. We think that order should flip, and we think the person who flips it needs a name and a mandate.

So here is where we stand:

  • Capability Engineering is not L&D with a fresh label. It changes the unit from the individual employee to the human-and-AI system.
  • Diagnosis is the product. Courses and simulations are downstream results, and sometimes the diagnosis says to build neither.
  • Evidence must be the organization’s own. Strategy, frontline friction, quality findings and expert knowledge. Not templates, not guesses.
  • AI should be governed, not trusted by default. Any AI-assisted design needs quality gates before it reaches your people.
  • Proof matters more than polish. If you cannot connect the work to a business result, you have not finished.

We are not a slide authoring tool, an LMS or a generic AI course generator, and we do not want to be. We are the system organizations use to decide what capability to build, prove why, and show that it worked.

— Brian

Becoming a Capability Engineer: a starting checklist

You may already be doing part of this job under another title. Here is a practical way to begin without waiting for a reorganization.

  1. Pick one business metric. Choose a result a business unit leader already cares about, such as resolution quality, cycle time or error rates.
  2. Map the decisions behind it. List the five to ten decisions that most affect that metric, and who makes each one.
  3. Mark where AI touches those decisions. Note where an agent drafts, recommends or acts, and where a person must judge the output.
  4. Collect your own evidence. Pull quality findings, interview frontline staff, and capture how your best performers decide.
  5. Sort the gaps. Label each as person or environment. Resist building anything until this is done.
  6. Choose the smallest enablement play that closes the gap. It may be a process fix, a short learning asset or a practice simulation.
  7. Set the measure before launch. Decide which operational signal should move, and by when you will look.

This is also a fair way to test any vendor, ours included. Ask whether they start with your evidence or with their content library.

Where Cognistry fits

If you want this discipline in a system rather than a spreadsheet, the Cognistry Platform brings it together. Signal maps the capability the work requires from your own evidence, Forge structures the response, Sim builds practice and decision environments for operational judgment, and Edge supports adoption and change. Teams in operations and product and delivery are good places to start. If you are weighing a first project, start with a conversation on the Cognistry site.

Frequently asked questions

Is a Capability Engineer the same as an instructional designer?

No. Instructional designers build learning experiences, and that skill stays valuable. A Capability Engineer is accountable one step earlier and wider: what capability the work requires, whether learning is the right response, and how people and AI agents perform together. Many instructional designers and learning experience architects grow into the role.

Does this role replace L&D teams?

No. It changes what they are asked to own. Learning teams keep developing people, but they work from business evidence and answer to business outcomes. The Capability Engineer role connects that work to the agents and workflows around it.

Is capability engineering the same as the Capability Maturity Model?

They share a premise that results come from governed systems rather than individual heroics. The Capability Maturity Model was created for software processes. Capability engineering, as we use the term, applies the idea to the combined human-and-AI system that does the work.

Where should an organization begin?

Begin with one business metric and one team. Diagnose the decisions behind that metric, sort person gaps from environment gaps, and only then choose what to build. For AI programs, our 6 to 8 week diagnosis follows exactly this sequence.

Sources

Continue Reading