Field Notes Sudeep Das

A journal of practice

Making AI practical for industries.

These notes are about the work that comes after the demo: how organizations decide where AI belongs, how they adopt it across teams, and how they keep it useful once it is in everyday use. I write from the experience of leading large technology and platform programs, where the hard problems are rarely the model and almost always the work around it.

Notes

Three essays on practice

Featured note · Adoption

Adoption is the hard part

A promising pilot is not the same thing as a working practice. In my experience, value shows up later — when habits change, incentives stop fighting the new path, and someone is still reviewing the work after the launch is over.

Read the note

AI strategy

When to build, when to buy, when to wait

A decision frame I use when a team is ready to “do something in AI”: whether to build a capability, buy one, or wait — and how to tell which judgment you are actually making.

Industry practice

Start with the work, not the tool

If you cannot describe the current process without naming a product, you are not ready to insert a new one. Map the work first, including the exceptions, and only then decide where a tool belongs.

Frameworks

Working models I use

01 · Before a pilot

Readiness before a pilot

Before I will support a pilot, I want a plain-language answer to a short set of questions. They are not a scorecard. They are a way to find out whether we are ready to change a real workflow, or only ready to put on a demonstration.

  1. Can we describe the work in a sentence — who does it today, what starts it, what finishes it, and what “done well” looks like?
  2. Is there an owner who will still be accountable for the outcome after the pilot ends, not only a sponsor who will attend the kickoff?
  3. Do we understand the exceptions: the cases that do not follow the happy path, and who handles them today?
  4. Is the information this work depends on available, timely, and good enough to act on — or are we hoping the system will compensate for a messy input?
  5. If the system is wrong, how will someone notice, how quickly can they intervene, and who is allowed to stop it?
  6. Are the people who do this work helping to shape the pilot, or are they only being asked to use the result?
  7. If this works, what will we stop doing, and who has the authority to actually stop it?
  8. How will we judge success in the real workflow — not in the demo — and on what date will we look honestly at that evidence?

If we cannot answer several of these, the next step is not a pilot. It is more work on the problem, the process, or the ownership. That is not delay. It is how you avoid a stall you could have predicted.

02 · A decision frame

Build, buy, or wait

Most teams treat this as a binary choice between building and buying. In my experience, the third option — wait — is often the more serious one. The point is not to have a position on AI. It is to put a capability into a workflow that can stand on its own, or to have the discipline not to.

Buy — when these are true

  • The workflow is common; many organizations do this job in roughly the same way.
  • Your advantage is in how you use the output, not in owning the method.
  • A normal team can operate the tool after the people who ran the pilot have moved on.
  • You can still name an internal owner for outcomes, exceptions, and the decision to stop.

Build — when these are true

  • The workflow is distinctive: the value sits in your process, your data, or the way your teams handle exceptions.
  • You need to own the method, or the capability has to sit close to a process you already run.
  • You are trying to create a platform that more than one team can use, in ways a single product will not support.
  • There is an owner who will treat what you build as an operating system, not a demo environment.

Wait — when these are true

  • The problem is still fuzzy; people cannot describe the work without arguing about what it is.
  • The organization is already mid-change and cannot absorb another system, including the work of running it.
  • The capability is moving fast enough that a decision made this quarter is likely to look naive the next.
  • The only urgency is social: a need to be seen doing something.

A test I use for buying: if we stopped maintaining this ourselves in a year, would we have lost something important, or only something convenient? If the answer is “convenient,” buy, and spend the attention on adoption. If you build, build the smallest thing that can become the default path for a real slice of work. Waiting is not doing nothing — it can mean mapping the work, running a small reversible experiment, or setting a date when you will decide.

Four questions I use

  1. Is the workflow distinctive, or is it common?
  2. Do we need to own the method, or only the outcome?
  3. Can this organization absorb another system in the next year — including training, review, and daily operation?
  4. If we decided six months from now instead of today, what would we actually lose?

03 · After the demo

Stages of adoption

I do not treat adoption as a switch that flips after a successful demo. It is a sequence. Teams get into trouble when they talk as if they are in one stage while the signs still belong to another.

01

Framing

The problem is named in operational terms. People can describe the work, the handoffs, and what good looks like without mentioning a tool.

The sign A written statement of the work that a practitioner would recognize as true.

02

Experiment

A bounded pilot runs on real work, with a review date and a way to stop. Success is defined in the workflow, not only in a demonstration.

The sign Someone has the authority to cancel it, and would actually use that authority.

03

Absorption

The new path is becoming the default for a defined set of cases. Training is no longer a special event.

The sign Going back to the old workaround takes more effort than staying with the new path, at least for the cases you claimed.

04

Habit

The work runs this way even when the original sponsors are busy. Exceptions have an owner. Quality is reviewed on a cadence, not only when something breaks.

The sign A new person joining the team is taught this as “how we do the work,” not as “the tool we are trying.”

05

Stewardship

The system is treated as an operating asset. Someone can explain when it should be changed, limited, or retired, and cross-team use is deliberate rather than accidental.

The sign The conversation has moved from “will people use it?” to “how do we keep it healthy?”

A pilot that cannot leave stage two is not a failure of the model. It is a signal that habits, incentives, or ownership were never designed.

Curriculum

AI strategy for industries

A working outline for a course on making AI practical in industry settings. Each module is meant to be useful on its own; together they follow the path I have found most reliable: frame the work, choose where to act, decide how to bring a capability in, and then operate it with care.

I

Framing the problem

Learn to describe industry work in operational terms before choosing a tool, and to tell the difference between a curiosity and a decision.

  • What “the work” actually is: starters, handoffs, exceptions, and done well
  • Writing a problem statement that does not have a vendor in it
  • Distinguishing exploration from a commitment to change a workflow
II

Choosing where AI can help

Learn to pick a few places where AI is likely to help — and to say no everywhere else.

  • Mapping value, risk, and judgment in a live process
  • Where repetition, scale, and exception-handling actually sit
  • The case for waiting, and how to wait on purpose
III

Build, buy, or wait

Apply a practical decision frame to how a capability should enter the organization, including what must be owned internally.

  • What you must own, and what you can use
  • Judging whether a product can be operated after the pilot team moves on
  • Organizational capacity: training, review, and the cost of one more system
IV

Adoption inside the organization

Design the work after the pilot — the habits, incentives, and ownership that decide whether a capability lasts.

  • Why promising pilots stall, and how to see it early
  • Making a new path the default, including across teams
  • Incentives that quietly fight the new work
V

Responsibility and ongoing review

Make review a normal operating practice, not a one-time gate at launch.

  • Who notices when the system is wrong, and how quickly they can act
  • Exceptions, escalation, and the handoff back to a person
  • When to limit, change, or retire a system
VI

Platforms that last

See the difference between a one-off tool and a capability the organization can reuse, and what it takes to run the latter.

  • Shared platforms versus isolated experiments
  • Cross-team adoption without pretending every team is the same
  • Operating an AI-supported process over time

Topics

A working index

About

I am a technology and AI leader with deep industry experience in enterprise platforms, advertising and media, and global tech services. I write here about making AI practical: the strategy, adoption, and operating discipline that turn a promising capability into work that lasts. This is a site for practice, not a personal profile.