THE AI PRACTITIONER
← October 2026 posts

Case Study

Takeda's head of R&D did not get a digital lead. He was the digital lead.

5 October 2026 · 4 min read

Three felt hats hanging side by side on hooks against a weathered white wall.

When Takeda set out to rebuild its research and development around data and AI, the obvious move was to appoint a digital lead for R&D. Somebody technical, reporting to the head of the function, carrying the programme.

It did not do that. Andrew Plump, Takeda’s President of R&D, became the digital lead himself. So did the heads of commercial, manufacturing, supply chain and the corporate functions, each for their own area.

That decision is the most useful thing in a new MIT Sloan Management Review case study of the Japanese drug maker. It is also the one part of a very large company’s programme that a manager anywhere can copy without a budget.

Three hats, one review

The case, written by George Westerman and David Kiron, describes the arrangement plainly: “Digital accountability was embedded into every business leader’s role.” Each leader, in the case’s words, “had to wear three hats: functional leader, caring people leader, and digital leader.”

The hats were not decoration. Every quarter, the review that asked each leader about their function’s results also asked three more questions. How are you embedding digital into your strategy? How are you making trade-offs? What have you learned?

Notice what that does. Digital progress was not a separate report from a separate team, read by a separate committee. It sat in the same conversation as the numbers, asked of the same person, with the same weight.

Plump’s own description is the line worth keeping:

“I owned digital, data, and technology. I was making the commitment, and I wasn’t asking Gab for resources. I was asking him for support, education, and partnership. Made me accountable 100% on this.”

“Gab” is Gabriele Ricci, Takeda’s Chief Data and Technology Officer. His role was deliberately narrower than the title suggests. He describes himself as “the connector, the facilitator, and the mentor”. He leads the technology, but his job is helping each business unit find its own route rather than running the route for them.

Why handing it to IT tends to stall

Most organisations do the opposite, and for understandable reasons. AI looks technical, so it goes to the technical people. Or it goes to an enthusiast, a “champion”, who has the interest but not the authority.

Both arrangements share a weakness. The person who owns the AI programme is not the person who owns the function. The champion can suggest a change to how the team works, but cannot make it. The IT lead can deliver a tool, but cannot decide that the process around it should change.

The function head, meanwhile, can reasonably say the AI programme belongs to someone else. Everyone is involved and nobody is accountable.

Takeda’s early lesson, as the case records it, is the symptom of that weakness. One of its biggest early challenges was “avoiding the pilot trap” of local experiments that could not scale. The response was to “place fewer high-impact bets on areas where we know we need to transform.”

A pilot trap is what you get when experiments have sponsors but not owners. Each pilot is somebody’s project, and none of them is anybody’s way of working. Putting the function head in charge does not guarantee scale, but it removes the most common reason scale never arrives.

The fluency underneath

Ownership alone would not have been enough, and the case does not pretend it was. Takeda ran a Digital Academy, and 70% of employees took part in its initial sessions. In manufacturing, one day a month was reserved for mandatory digital training across 20,000 employees.

That second detail deserves attention. A day a month is a lot of production time. Somebody had to decide it was worth more than the output it displaced, and the person able to make that call was the head of manufacturing, not an IT department. The training followed from the ownership.

Staff also got a ChatGPT-like assistant through an internal community platform called myAibou, alongside a system for finding training and seeing what digital work was under way.

What does not travel

Two cautions belong here, because this is a case study rather than a survey.

First, scale. Takeda built three in-house capability centres, in Bratislava, Mexico City and Bengaluru, with well over a thousand engineers and data specialists between them. Very few readers have anything like that, and it would mislead to imply the ownership model works because of it. Ownership is the part that does not need it.

Second, the source. The case was produced as part of an MIT Sloan Management Review research initiative “in collaboration with and sponsored by EY”, which sells AI transformation consulting. It is built from interviews with named Takeda executives, so it records how leaders describe what they did.

It also contains no outcome figures: no time saved, no trials accelerated. Treat it as a well-documented account of a structure, not as proof that the structure produced a particular result.

Three things to do this month

Write down who owns AI in your function. Not who is interested in it, or who set up the tool. Who would be asked about it if it went wrong. If the honest answer is IT, a champion, or nobody, that is your finding.

Add three questions to a review you already hold. Not a new meeting. Takeda’s questions fit in five minutes: where are we using it, what did we give up to do so, and what did we learn. Ask them in the same review as the numbers, so they carry the same weight.

Ask your technology colleagues for support, not delivery. Plump’s distinction is the useful one. Asking for resources makes AI their project. Asking for support, education and partnership keeps it yours.

The head of R&D at a global drug maker decided the digital agenda was his job, not somebody else’s. That decision cost him nothing but accountability, and it is the cheapest part of the whole programme to copy.

Want this applied to your own work?

A discovery call is a short, no-obligation conversation about where AI fits in your team, and where it does not.