At two in the morning, the software has stopped working. Somebody has a pager. Somebody has a customer. And somewhere, perhaps, there is a very impressive demonstration that now seems to have taken place on another planet. Srini Tallapragada has offered this hypothetical scene as a test of AI-written software: an engineer cannot simply shrug and explain that an AI produced the code. The customer expects someone to take responsibility.
It is a useful place to begin a career that stretches from punch-card programming to Salesforce’s AI engineering work. Tallapragada has spent years building systems that other businesses depend on. His subject is the life of software after its introduction: the permissions, the upkeep, the awkward integration and the person who needs an answer before the next meeting.
Before the cloud, a deck of cards
Growing up in India, Tallapragada chose computer science. His college had a Soviet copy of an IBM 370 mainframe, and he learned punch-card programming and assembly. In February 1997, he came to the Bay Area and joined Oracle’s Server Technologies division as an engineer. There is a pleasing historical span in that beginning. His early instructions to a computer arrived through holes in cards. Much later, his teams would work with software that accepts instructions in ordinary language.
His education paired a BTech in computer science from NIT Warangal with a PGDM from XLRI in Jamshedpur. The combination put technical study alongside management training. Both belong in this story, because the problems he would describe most often involved an organization as well as a machine.
At Oracle, he held engineering and applications development leadership posts. He moved to SAP Labs as a senior vice president in February 2009, returned to Oracle in April 2011, and joined Salesforce in May 2012. His next progression took him from senior vice president of engineering to executive vice president, then President, Technology, and, in December 2019, President and Chief Engineering Officer.
A cloud that needed explaining
The Salesforce years included engineering leadership across Lightning, Einstein, Hyperforce and Data Cloud. Each name describes a different part of the company’s evolution: interfaces, AI, infrastructure and data. Taken together, they describe the challenge of changing a working platform while people continue to use it. There is no convenient interval in which customers agree to stop needing their businesses.
Hyperforce reworked Salesforce’s infrastructure to deliver its applications on major public clouds. In his 2021 writing, Tallapragada connected the architecture to practical concerns: where customers could run services, how close those services were to users, and how regional requirements could be accommodated. The engineering decisions had consequences for a customer’s geography, performance and existing investment.
Infrastructure makes an odd sort of public achievement. When it works, people tend to notice whatever they were trying to accomplish with it. An application responds. A record loads. A colleague carries on. The absence of drama is part of the point. Writing about Hyperforce, Tallapragada presented it as a way to keep customers moving as the underlying technology changed.
He later called Hyperforce his hardest leadership leap of faith. His lesson was to explain the reason repeatedly. That is a less cinematic account of leadership than the solitary flash of conviction. It also leaves a much more useful instruction for the next person running a difficult project.
“Everyone needs to understand the why”
Srini Tallapragada, on leading change
The customer joins the engineering chart
In 2025, Salesforce expanded his role to include customer success and professional services. Engineering, technical support and the teams helping customers implement the products came into a shared remit. An organization chart rarely makes gripping reading. This particular change made a practical connection visible: the people building the software and the people responsible for making it useful had closely related work to do.
At TDX in March that year, Tallapragada described an enterprise data problem. Companies had plenty of information, but much of it was difficult for business users to reach. Data lakes, APIs and separate systems could leave a person surrounded by information and unable to get an answer. For AI, that creates an obvious constraint. A fluent response cannot compensate for missing business context.
His conversations with CIOs also returned to the investments customers had already made. They had data infrastructure, governance practices and reasons for choosing them. They worried about being tied to one vendor. Tallapragada argued for connections to existing data and the ability to bring different models. The commercial proposition was Salesforce’s; the customer problem was familiar to anyone who has ever bought software and discovered that installation was merely the opening ceremony.
By April 2026, he was describing AI adoption as a sequence in which companies begin with productivity gains and then redesign workflows. He emphasized implementation capacity and the role of partners, including TCS, Infosys, Accenture and Deloitte. Buying a capability and getting an organization to use it are separate pieces of work. His expanded job had placed him across that gap.
- InfrastructureWhere the software runs
- Data & contextWhat it can know and access
- Customer workflowHow people put it to work
When faster code forms a queue
His own engineering organization supplied a particularly useful complication. In December 2025, Tallapragada described how AI-assisted development increased the volume of code awaiting review. Faster generation had created more material for reviewers to inspect. The productivity story had acquired a queue, which is a very enterprise-software thing for a productivity story to acquire.
His account described Engineering 360, a system bringing engineering information together, and PRizm, an AI-assisted review tool. It also covered permissions and audit trails for AI tools. These details matter because a count of generated lines says little about whether the resulting system is easier to operate. A team can produce more material while handing its colleagues more trouble.
He also described an engineering agent working in more than 1,000 Slack channels. The placement was deliberate: engineers could use it where they already collaborated. Even a tool intended to change work has to find its way into the working day. Requiring everyone to visit another destination would have introduced a small, persistent tax on using it.
Slack channels with the Agentforce Engineering Agent
In May 2026, his follow-up described a move toward coordinated coding agents and reusable skills. He also left room for unresolved questions. How would junior engineers develop when AI absorbed more introductory tasks? How would product and design roles change? Small-team experiments were underway, but he did not present them as settled organizational answers.
That uncertainty belongs beside the enthusiasm. The person responsible for a large engineering organization has to consider how tomorrow’s experienced engineers acquire their experience. A successful automation project can still leave a training question. Tallapragada’s account made space for both, which gives the discussion more substance than a simple race to generate code faster.
The bill reaches beyond the screen
He has also argued that engineering decisions have environmental consequences. In 2023, he supported green coding and sustainability practices across software design, implementation and operation. The point broadens the account of responsibility. Software appears on a screen, but it runs on equipment, and that equipment consumes power.
For a leader working on cloud infrastructure and AI, those concerns occupy the same territory as performance and scale. Choices accumulate across an application’s life. The efficiency of a system includes what it asks of the machinery beneath it. A polished interface can conceal a considerable electricity bill; the server has never been impressed by good typography.
An engineer enters the boardroom
GoDaddy appointed Tallapragada as an independent director effective January 25, 2023. Its announcement pointed to his product and platform experience as useful to the company’s efforts to scale. He had previously served on Avalara’s board from July 2021 until October 2022, when it became private. These appointments put engineering judgment into a setting where the questions include oversight, investment and the direction of a business.
On August 6, 2026, he stepped down from his Salesforce operating role and became Special Advisor to the CEO. His transition arrangement runs through August 6, 2027, subject to its terms. The remit includes helping transfer his responsibilities and advising on product, technology, innovation, business development and customer matters.
In his public farewell to day-to-day leadership, he thanked Marc Benioff, Parker Harris, colleagues and the Trailblazer community. He recalled a send-off at Laulima and said he would take time to reflect and plan his next chapter. Community leader Kavindra Patel, in turn, remembered his willingness to listen and his support for the India Trailblazer community. A career described through platforms also leaves a history of people who remember a returned message.
On October 1, Broadridge announced his nomination for election to its board at its upcoming annual meeting. The nomination extends the boardroom direction of his work while his Salesforce advisory role continues. It also keeps him near the question that runs through the career: how does an investment in technology become something a business can depend on?
The answer has to survive an ordinary working day, and occasionally a very inconvenient night. Tallapragada’s early mainframe and his later AI agents belong to different computing worlds. In each, someone still has to understand the system well enough to stand behind it when the demonstration is over.