Samar Abbas and the unfinished business of software

Samar Abbas wanted to find prime numbers. His own computer could only do so much. So, while living in a college hostel, he wrote a distributed program that used his classmates’ machines as workers. It was an early encounter with a proposition that would occupy much of his working life: several computers, cooperating, could accomplish something one computer could not.

He grew up in Karachi, Pakistan, and began programming at about eighteen. His first experience of a computer belonged to the MS-DOS era, when learning the file system was part of learning the machine. The discovery that a program could send messages to another computer changed the size of the problems he could imagine tackling. A socket opened; the possibilities widened.

That student experiment makes a useful starting point for understanding the co-founder and CEO of Temporal Technologies. Before the fundraising announcements, the cloud service, or the executive title, there was a programmer asking other people for a little computing power. His ambition had already outgrown the box on his desk.

“I didn’t have a set plan in place.”

Samar Abbas, on the start of his career

02A career without a grand plan

Abbas began his career at Microsoft in 2000. He did not arrive with a carefully mapped specialty. He wanted to try different things, and his first decade gave him room to do so: developer platforms, server products, and the tools programmers used to build software. His work touched .NET, SQL Server, and Visual Studio.

Building for developers put him close to a particular kind of frustration. A tool could be technically capable and still ask too much of the person using it. The distance between what a platform could do and what a programmer could comfortably make it do became interesting to him. Developer experience was becoming the subject of his work.

By 2010 he wanted to move into the cloud. Joining the Simple Workflow team at Amazon Web Services introduced him to Maxim Fateev, a technical collaborator who would eventually become his co-founder. The team brought the public version of Simple Workflow Service to market in early 2012. Abbas had moved from exploring different kinds of software to a problem he would revisit across employers: coordinating work that must survive interruptions.

03A hackathon with a long afterlife

Returning to Microsoft Azure, Abbas joined the Service Bus team and worked on Event Hubs. The messaging layer could help systems communicate at scale, but application developers still had to assemble their own machinery for handling failures. Messages travelling successfully between services did not, by themselves, make a whole business process reliable.

An internal hackathon gave him a chance to try another approach. He paired with Affan Dar, whose knowledge of Azure Service Bus complemented the stateful C# programming experience Abbas wanted to build. C#’s async/await capabilities offered a cleaner way to express the work than the promise-based approach they had used with Java at AWS.

The experiment became the open-source Durable Task Framework. Microsoft subsequently built Azure Durable Functions on that foundation. There is something pleasingly disproportionate about this chapter: a hackathon project acquired an afterlife inside a cloud platform. For Abbas, it also supplied another round of evidence. The programming experience mattered as much as the infrastructure underneath it.

04Uber had plenty of services. Coordination was harder.

In 2015 Abbas joined Uber’s Seattle engineering team. Fateev arrived about a month later. The reunion brought their experience of messaging and workflows into a company rapidly pulling apart its monolithic application and distributing work across microservices. As Abbas later recalled, Uber had reached the peculiar point of having more microservices than engineers.

The attraction of splitting software into smaller services is easy to grasp. Different teams can develop their own pieces. The complication arrives when a useful action needs several pieces to cooperate, each with its own availability and opportunities to fail. Software has a talent for moving the difficulty rather than politely removing it.

Abbas and Fateev built Cadence to help developers coordinate that work. Adoption inside Uber grew from zero to more than one hundred use cases over roughly three years. The project’s appeal extended beyond the company, with other engineering teams encountering similar problems. An internal success was becoming evidence of a wider need.

Leaving good engineering jobs to found a company was another decision altogether. Neither founder had managed people before starting Temporal. Their experience gave them confidence in the problem and the product; it did not confer automatic knowledge of hiring, sales, or running an organization. In October 2019 they left Uber and launched Temporal Technologies.

05The interruption is part of the job

Temporal’s central idea, durable execution, concerns what happens after a program starts and before it finishes. A machine may crash. A service may be temporarily unavailable. A process may wait a long time for someone to approve the next step. The useful work has to retain its place through those interruptions.

Consider a payment workflow as an illustration. Several steps may need to happen in sequence, and an interruption between them cannot simply erase the record of what has happened. Temporal provides infrastructure for preserving workflow progress and recovering execution. Developers still have to design their application correctly, including its interactions with outside systems. The platform handles a substantial part of the coordination and recovery machinery.

This explains why Abbas keeps talking about developer time. Every team that builds the same recovery mechanisms from scratch spends less time on the particular thing its customers came for. The routine handling of failures becomes repeated work spread across organizations. His career follows attempts to make that repeated work easier to use.

The company’s open-source foundation is part of that argument. Temporal’s server is released under the MIT license; customers can operate it themselves or use Temporal Cloud. Selling a managed service gives the company a business alongside the open project. The product reaches people through code, and the commercial relationship grows around the work of running it.

06The founders rearranged the chairs

In April 2024 Abbas became CEO, while Fateev moved from CEO to CTO. On an organizational chart, the change looked like a swap. Abbas’s explanation was more practical: he had already been running product and engineering, and the growing company needed more operational coordination across its functions. Fateev wanted to concentrate on technology and product direction.

The relationship had years of shared work behind it. They had met at AWS, reunited at Uber, and built a company together. Abbas described their opinions as strong but loosely held. That combination allowed the two to discuss which responsibilities suited each person without treating a title as a permanent possession.

A company can grow beyond the skills its founders initially needed. Admitting that fact while things are going well requires a certain freedom from ceremony. Here, the engineering partnership continued while the division of labor changed. Software people are forever reorganizing systems; occasionally the organization itself deserves the same attention.

Temporal also added MongoDB chief product officer Sahir Azam as its first independent board member in August 2024. The appointment connected Abbas’s new executive responsibilities with someone experienced in building a business around developers and open-source software. The company was putting more structure around a product that had begun with two engineers.

“We want to meet developers where they are.”

Samar Abbas, on the product’s approach

07A faster company still needs a useful result

By 2026 Abbas was asking Temporal to examine how AI could change its own work. The push went beyond engineering. Recruiting and business development were experimenting with tools and workflows, while the company used its own infrastructure for internal automation. A company selling reliable execution was also testing what that execution could make possible inside its own walls.

He described engineering teams shipping features twenty to thirty percent faster with the same-sized team. Yet he did not claim to have established a direct connection between AI use and revenue growth. That distinction matters. Producing more work and delivering something customers value are separate measurements, and an executive does not make them identical by placing them on the same slide.

Abbas also resisted turning token consumption into an employee leaderboard. More generation could mean more material for somebody else to review. Temporal had encountered that problem itself, with insufficiently reviewed AI output creating work downstream. Speed has a way of sending its invoice to the next person in the process.

His skepticism about easy productivity numbers fits the earlier career. He has spent years looking at the work concealed underneath a seemingly simple application. With AI, the concealed work includes checking the output and deciding whether it helps. A quick answer is only the beginning of the transaction.

08The same problem, longer running

The commercial scale changed sharply. In March 2025 Temporal announced a $146 million Series C at a $1.72 billion valuation. A $300 million Series D followed in February 2026 at $5 billion. On September 14, 2026, the company announced a $550 million Series E at $12.55 billion. Those are company financing figures, attached to the organization Abbas now leads.

At the September announcement, Temporal reported more than 4,300 paying customers and 1.9 trillion billable actions processed during August. It also reported a team of 570 people. The numbers describe a different managerial task from the one facing two engineers in 2019. More organizations now depend on the system, and more people must coordinate its development and operation.

Abbas’s current interest in AI agents connects directly to the old workflow problem. Agents can call tools, move through several systems, and wait before taking their next action. He argues that companies must control the authority they give those agents, including what happens when a failed action is retried. An approval should remain an approval with the same limits after an outage.

On October 6, Temporal announced that the Oso team had joined to accelerate its work on AI agent security. The practical questions were identity propagation and policy enforcement as agents act across enterprise systems. Reliability and authority were meeting in the same execution layer.

Abbas wants to build toward a world in which more agents work together on more complex problems. He sees an echo of personal computing: useful machines become more useful when connected, and their coordination demands new infrastructure. His college program borrowed his classmates’ computers to look for primes. The company he leads now supports work moving between machines at a very different scale. The question has travelled with him: once the program begins, what will help it get to the end?