EAT Office
The business transformation profile for the age of AI

Those who know the work design its future

A Business Technologist combines knowledge of their own field with AI and technology, not just to speed up tasks but to redesign how the work should be done.

They find the right problem. They set up the way people and AI will work together. They own whether the solution gets used and delivers measured value.

Domain knowledgeAI fluencySystems thinkingValue ownership

Business Technologist knows the work and owns the solution.

Forward Deployed Engineer embeds the solution in the organization’s real-world environment and hands it over.
Explore the role →

Why now?

AI is not only speeding up work; it is shifting where valuable human contribution lies.

AI is rapidly lowering the cost of finding information, research, content creation, analysis and first prototypes. But a model does not know the organization’s customers on its own. It does not know a sector’s unwritten rules, its exceptions or its past decisions. It cannot decide by itself which problem is worth solving or which decision should stay with a person.

So human value now concentrates less in doing the work and more in setting the purpose, building the context, designing the way of working and owning the result.

An idea Jensen Huang often returns to: in every industry, people who know how to use AI will take the place of those who do not. This holds for organizations as much as for individuals. Organizations that can combine AI with their employees’ domain knowledge and real workflows will move ahead of those that cannot.

From an independent source
  • 41%Share of employees who work outside IT yet build technology or analytics capabilities
  • 2.6×How much more likely organizations that empower these people are to accelerate digital business outcomes

Gartner, Reimagining Technology Work research series · 2021–2022.

The new competitive question: who will turn your organization’s domain knowledge into new ways of working with AI?
From literacy to ownership

Using AI is the start. Redesigning the work is the transformation.

The AI-literate employee

  • Uses the right tools for their own tasks.
  • Researches, analyzes and drafts faster.
  • Questions and verifies the output.
  • Knows the limits of security and privacy.
  • Raises their own productivity.

Business Technologist

  • Sees the end-to-end workflow rather than the single task.
  • Uncovers the real problem and its root cause.
  • Redesigns the tasks of people, AI, data and systems.
  • Doesn’t just describe it; builds a working example themselves.
  • Builds the solution and its controls together with technical teams.
  • Owns user adoption and the business outcome.
  • Turns what was learned into a method the organization can reuse.
The AI-literate employee uses AI to do their current work better.The Business Technologist uses AI to redesign how the work should be done.
Who are they?

Not a domain expert drifting into tech, but the owner of transformation from inside the business

A Business Technologist is a professional who brings together domain knowledge, problem and systems thinking, and fluency in AI and technology to uncover real business problems, design human–AI workflows, produce a working example, and own whether the solution is adopted and delivers measured value.

In most organizations this profile does not begin as a new position or title on day one. It emerges as employees grow into it: people who know operations, customers, products, finance, people or risk well, are open to digital tools and can take responsibility for results.

  • Passes on the requestUncovers the problem
  • Writes requirementsDesigns the workflow
  • Waits for a solutionBuilds a working example
  • Tracks the projectOwns the value
  • Uses the toolBuilds the human–AI way of working
What they are not

How the role differs from adjacent roles

RoleWhat it doesHow the Business Technologist differs
Business analystDescribes the need, hands it over.Doesn’t stop at describing; builds a working example themselves.
Key userGives input on the process.Turns the input into an application and owns it.
Software developerBuilds the code and the platform.The goal is a business outcome, not code; relies on the technology team at enterprise scale.
Product ownerRepresents the solution.Works inside the solution: “I built it, and I own it.”
A Business Technologist’s value comes not from the tools they use but from the quality of the decisions they make.
Why domain knowledge is central

Learning technology has become faster. Truly learning a business still takes time.

Learning an AI tool takes days or weeks. Understanding a sector’s value chain, the need a customer never voices, the exceptions in operations, the side effects of decisions and the limits of risk takes years. That is why the role is built not by teaching the work to a technology specialist, but by giving the tool to the person who knows the work.

Here is the paradox: as technology becomes more accessible, domain knowledge does not lose value, it gains it. Because that knowledge no longer ends up in reports; it becomes the context, rules and evaluation criteria of working systems.

  1. 01Sector economics and value chain
  2. 02Actors, roles and incentives
  3. 03End-to-end processes and exceptions
  4. 04KPIs and value drivers
  5. 05The reality of data, systems and integration
  6. 06Regulatory, security and ethical limits
  7. 07AI opportunities and known failure modes
The model brings general capability. Domain knowledge decides where and how that capability creates value.
Capabilities and maturity

The difference lies not in one technical skill but in a combination of capabilities.

Seven capabilities, read across three levels. The Business Technologist framework written in the Embed stage is built on this table.

  1. Problem selectionWhich work?

    Solves the problem they are shown.

    Finds the repetitive, costly work on their own.

    Also names the problems not worth solving.

  2. Tool selectionPersonal or enterprise?

    Uses the tool at hand.

    Separates what stays personal from what enters an enterprise system.

    Anticipates a tool’s limits; stops on their own when enterprise controls are needed.

  3. Build and showThe heart of the role

    Explains the idea.

    Builds a working example within days.

    Spreads the example across the team; gets others to build.

  4. Data literacyWhat does the number measure?

    Reads the number.

    Sees what the number does not measure.

    Makes the value case in numbers; wins over leadership with data.

  5. Automation economicsIs it worth it?

    Automates whatever can be automated.

    Weighs return against cost.

    Also argues for not automating.

  6. Shared governanceWith the technology team

    Asks the technology team for permission.

    Applies the rules together.

    Writes and defends the framework together.

  7. Process designSimplify first

    Speeds up the existing process.

    Maps first, then simplifies.

    Knows that automating a bad process means failing faster; redesigns it.

Beneath these seven areas lie four general capabilities: critical thinking (telling convincing from correct), systems thinking (the effect of a change in one task on process, people, data, risk and customers), learning agility (not being tied to a single tool) and ethical judgment (asking what should be done before what can be done; human oversight, privacy, accountability).

Human capabilities are not an alternative to technology. They are the layer that lets technology create value.
How do they work?

How a Business Technologist thinks

Eight moves, end to end. The order matters: each move builds on the output of the one before.

  1. 01

    Notices

    Makes repetitive work, customer loss, delays, quality issues or decision bottlenecks visible.

  2. 02

    Explores

    Talks to users; draws out the current process, exceptions, data sources and root cause.

  3. 03

    Frames

    Writes down the problem, target user, baseline, success measure and scope limit.

  4. 04

    Redesigns

    Decides which task people, AI and existing systems each take on, and where approval and human handoff sit.

  5. 05

    Co-creates

    Builds the solution, user experience, evaluation criteria and pilot design with the Forward Deployed Engineer and relevant experts.

  6. 06

    Validates in the field

    Tests with real users; measures usability, trust and behavior change as much as output quality.

  7. 07

    Owns the value

    Compares usage, cycle time, quality, cost, revenue or risk impact with the baseline, and brings it to the EAT Office.

  8. 08

    Codifies it

    Turns what works into a guide, a decision record and an evaluation set, so the next application does not start from zero.

An example

From idea to measured value

Choose a department and see how the same approach plays out in different kinds of work. Each time, the request is for automation; the Business Technologist does not take it at face value.

Management’s first request

“Let’s automate the weekly defect report with AI.”

Explores the current state

  • Establishes who uses the report and for which decision.
  • Sees that defect records are kept in different formats.
  • Finds that the real delay is not in writing the report but in classifying similar defects.
  • Notices that critical exceptions live in the heads of experienced specialists.

Designs the new workflow

  • AI pre-classifies the records and brings up similar cases.
  • Low-confidence results go to a quality specialist.
  • Human approval remains mandatory for critical defect types.
  • The specialist’s corrections feed back into the evaluation set and organizational knowledge.

Builds the value hypothesis

  • Review cycle time
  • Detection rate for recurring defects
  • Rate of missed critical defects
  • User adoption
  • Time to corrective action

This was never about automating a report. What changed is how quality decisions get made.

The role across the Transformation System

Where the role sits across the five stages

  1. 01

    The Briefing stage

    The role does not yet appear in this stage.

  2. 02

    The Diagnostic stage

    Business-unit people who know the work, are open to new tools and are ready to take responsibility are identified. What emerges is a profile, not a list of names.

    Go to the stage →
  3. 03

    The Proof stage

    Works alongside the business owner of the Lighthouse Application; drives user learning and the first value measurement. At handover, becomes one of the application’s owners on the organization’s side.

    Go to the stage →
  4. 04

    The Embed stage

    The Business Technologist framework is written: capability definition, scope of responsibility, zones of work with the technology team. Candidates join the EAT Office; the role is tested on real work in the second application.

    Go to the stage →
  5. 05

    The Scale stage

    The role becomes a network: selected representatives from each department surface opportunities in their own area, support users, track value and bring learning to the EAT Office.

    Go to the stage →
How the parts relate

Four parts, one operating model

  • Business TechnologistOwns what we transform, why, and for which business outcome.
  • Forward Deployed EngineerTurns that transformation into a reliable, working technical system.
  • EAT OfficeManages priority, trust, value measurement and the cycle that repeats it.
  • AI Harness CapacityThe organization’s ability to reproduce that success in new business areas.
The aim is not for the organization to keep waiting for solutions from outside, but to develop the human capacity to turn its own business knowledge into value with AI.
Division of labor with the Forward Deployed Engineer

One owns the “why” and the “what”; the other owns the “how”.

The Business Technologist owns the “why” and the “what”: which work, which value, which user. The Forward Deployed Engineer owns the “how”: how the solution fits into the organization's data, systems and security limits. When one draws the scope correctly, the other does not build something no one will use. Both sit at the same table in the EAT Office.

Limits

What the role does not promise

  • A responsibility, not a title. No new headcount is created; it starts with a duty taken on by existing people.
  • Three zones. At low risk and complexity they build it themselves; at medium, together with the technology team; at high, the technology team leads. Data and security rules are never crossed in any zone.
  • The enterprise threshold. The moment a solution touches organizational data or others use it, it falls under governance; left outside it, it becomes a shadow system. Shadow systems are not banned; they are brought into the open.
  • Human oversight. The last word on a critical decision stays with a person; approvals are tiered by risk, not requested at every step.
  • The role replaces no one. Business analysts, product owners, domain experts and technology teams remain; the Business Technologist reduces the context lost between them.
Who is this path for?

Look at how you work before you look at your title.

  • Operations, process and quality
  • Finance, risk and audit
  • Sales, marketing and customer experience
  • HR and organizational development
  • Supply chain and procurement
  • Legal and compliance
  • Product, service and business development
  • Business analysts and product owners
  • Students and recent graduates
  1. Do you notice bottlenecks in your work that others take for granted?
  2. Are you curious about the real problem behind a request?
  3. Do you see processes through their relationships and exceptions as well as their steps?
  4. Do you see technology as a means to a business outcome rather than an end?
  5. Are you willing to build a small working example instead of just explaining an idea?
  6. Are you ready to be accountable for whether the result is used and measured?

If you give a strong “yes” to three or more of these questions, this path may be right for you.

A note for recent graduates

Being a recent graduate does not mean your domain knowledge is complete. This path doesn’t start with knowing everything; it starts with learning a field systematically, asking the right questions and taking responsibility for a real problem.

Development path

Business Technologist is not a certificate; it is a path you advance along by evidence.

Six levels; each one is earned with evidence. Inside the organization, on real work.

  1. 0

    Foundation

    Learns what AI can and cannot do, how to use it safely, how to evaluate it critically, and systems thinking.

    EvidenceA small, safe and explainable human–AI workflow draft from their own field.

  2. 1

    Domain discovery

    Maps a business area’s value chain, actors, processes, indicators, systems and risks.

    EvidenceA domain map and a problem-space analysis.

  3. 2

    Problem and workflow design

    User interviews, current-process analysis, root cause, baseline measurement and the division of tasks between people and AI.

    EvidenceA problem brief; current and target workflow.

  4. 3

    Solution and value building

    Solution hypothesis, user flow, prototype, evaluation criterion, pilot and value case.

    EvidenceA testable solution and a measurable value hypothesis.

  5. 4

    Delivery responsibility

    Takes responsibility within an application team for discovery, domain validation, indicators, user testing, stakeholder communication and adoption.

    EvidenceA contribution validated by the team and the business owner.

  6. 5

    Proven ownership

    Shows, in a real application, that the solution is used, has changed a process or behavior and has produced measured value.

    EvidenceUsage, business impact and validation by the problem owner.

Capability is not claimed; it is proven through a real problem, real output and business impact.
Why does the organization need this capacity?

AI transformation is not an agenda the technology department can carry alone.

IT builds the secure platform, the integrations and the technical standards. But from the center, on its own, it cannot uncover every department's real problems, user behavior, exceptions and value drivers. A Business Technologist network puts transformation ownership where the work happens; instead of invisible shadow systems, it creates a controlled, visible, value-focused way of building together.

  • Better AI opportunities are chosen.
  • Pilots are tied to real users and business outcomes.
  • Less context is lost between business and technology.
  • Employees’ domain knowledge is carried into organizational systems.
  • Adoption and behavior change are managed from within the work.
  • Security and governance become part of the design, not a final check.
  • Each application leaves the organization better prepared for the next.
Next steps

Build your future not only by using AI, but by showing what you change with it.

Becoming a Business Technologist is not about trying to look like a technology specialist. It is about understanding your own field more deeply, uncovering the real problem, designing the new way of working and taking responsibility for the result.

Tools will change and models will improve. Choosing the right problem, domain judgment, systems thinking and value ownership will last.

For you

Learn. Build on a real problem. Prove it in the field.

For your organization

Build Business Technologist capacity on real business problems. See where your organization stands today in fifteen questions.

SourcesGartner, Business Technologist definition and 2021–2022 research · Ciliv & Özdemir, Business Technologist Handbook v1.0 · Davenport et al., “We’re All Programmers Now”, HBR 2023 · World Economic Forum, Future of Jobs Report 2025