Maxim Fateev and the art of picking up where you left off

Maxim Fateev had never had a direct report before he started a company. Then he became its CEO. Four and a half years later, he went back to technology, describing his new CTO job as something closer to chief architect. At the time of that account, he said, he had zero reports again. For an executive biography, this is an unusual place to begin. For Fateev, it gets quite efficiently to the point: what is the work, and how much of the day can he spend doing it?

The work has been remarkably consistent. A program starts. It calls another service. Something stops responding. A machine dies. The program has already done useful things, but useful things are difficult to reconstruct from the wreckage. Fateev has followed variations of that problem through Amazon, Microsoft, Google, Uber, and the company he co-founded, Temporal Technologies. The employer changes; the interrupted business remains.

There is a dry comedy to the subject. We ask computers to remember practically everything, then arrange for a program’s working memory to vanish when its process crashes. Fateev’s answer is to make progress durable. A machine can be replaced. The work should retain its place.

A website on one machine

He first joined Amazon in 2002. By his account, it had about 800 developers, a scale that looks modest from the vantage point of the Amazon that followed. The company was moving away from one large application toward a collection of services. He remembers an earlier arrangement in which a developer could run the whole website on a single development machine. Convenient, until the growing application became inconvenient to build and change.

Breaking up an application solves some problems and creates a fascinating assortment of others. Each service can do its own job. Getting the services to complete a shared job requires coordination. Messages cross boundaries. Responses arrive later. A piece of information can be available in one place while another part of the system is still waiting for it. The diagram acquires more arrows than anybody originally ordered.

Fateev worked close to those arrows. He led Amazon messaging infrastructure work that became a foundation for Simple Queue Service, and later led the architecture and development of AWS Simple Workflow Service. He also developed the Amazon Flow Framework. These were practical attempts to make work across machines easier to organize, rather than asking every application team to assemble the same machinery again.

His objection to queues was precise. They could offer useful behavior while a service was slow or unavailable: hold the messages, let other services continue. But a useful runtime mechanism could still leave developers with a difficult programming model. The business process was scattered across handlers and state machines. Understanding the whole sequence became a separate engineering task.

“I never had a single report before I started the company.”Maxim Fateev, describing his route from engineer to founder

Two engineers, one recurring argument

In 2010, Samar Abbas joined the AWS Simple Workflow team and met Fateev. That encounter became a long collaboration. They subsequently worked elsewhere, then reunited at Uber in 2015. Abbas brought his own experience with the Durable Task Framework at Microsoft. Fateev brought years spent dealing with messaging, workflow, and the inconveniences of distribution. They had arrived at similar questions through overlapping careers.

At Uber, Fateev worked on Cherami, a messaging system, and co-created the Cadence workflow engine with Abbas. Both became open-source projects. Cadence offered a way to express long-running business logic in code while an underlying service dealt with persistence, queues, and timers. A developer could write a sequence that looked like a sequence, rather than leave the reader to infer it from a collection of callbacks.

Cadence’s development began from below. Fateev recalls that Uber management had not commissioned the team to invent a workflow technology. They built an initial version and secured more resources later. Adoption followed the same pattern: engineers found uses for it. He described more than a hundred internal use cases over the project’s first three years at Uber.

In 2017, Uber made Cadence open source. Outside organizations could inspect it, try it, and contribute. Uber’s own demonstrations showed how it coordinated work, including an Uber Eats example with eight steps. An ordinary food order turns out to have quite a busy backstage. The customer sees a meal moving toward the door; the software sees a sequence of actions that need to agree about what has happened.

A company for the work already underway

The external users changed the next question. Fateev recalls organizations such as HashiCorp, Box, Coinbase, and Checkr adopting Cadence. Its usefulness was crossing the boundary of the company where it had been developed. That made a dedicated organization a practical proposition. A team inside Uber had responsibilities to Uber. A broader developer community needed its own attention, and a hosted service needed somebody willing to operate it.

Fateev and Abbas founded Temporal Technologies in October 2019. They forked Cadence to create Temporal, taking the opportunity to revisit technical decisions accumulated while keeping an existing production system compatible with its users. The transition involved more than changing a name. Existing users had code and expectations. Improving an interface and moving a community are different jobs, and both require care.

Fateev has described this as an unusual startup beginning: they believed they already had evidence of product-market fit. Engineers were using the predecessor, including outside its original employer. That evidence helped answer whether the idea was useful. It still left the founders with the business of hiring, running a company, and persuading more developers to consider an unfamiliar model.

Trust mattered because the product sat underneath important applications. An engineer choosing a workflow engine is making a decision about what happens after a deployment, a restart, or an outage. A conference talk can introduce an idea. Confidence in infrastructure takes longer. Fateev’s history with the problem helped, but the software also had to acquire a history of its own.

A program with a memory

The term at the center of Fateev’s work is durable execution. Consider a simplified process with three steps: request information, wait for approval, then perform the next action. The wait might last longer than the machine running the code. Durable execution gives that process a recorded history from which it can recover its state and continue when the necessary infrastructure is available.

Temporal separates workflow logic from activities that do outside work. Its server records the event history and schedules tasks. Workers, controlled by the developer, run the application’s workflow and activity code. If a worker fails, another can reconstruct the workflow’s progress through replay. The server is keeping track; it is not a secret computer doing all the customer’s application work.

That division also explains why the idea should be described carefully. Recovering a workflow does not make every external action harmless to repeat. Activities can be retried; developers still need appropriate handling for effects such as charging a payment. The attraction is that a durable foundation takes on recurring coordination tasks, giving application code a clearer account of the process it is meant to perform.

The CEO goes back to the drawing board

In 2024, the founders adjusted their responsibilities. Fateev became CTO, and Abbas became CEO. The announcement put Fateev’s attention on technical vision and Abbas’s on operational leadership as the organization grew. By then, Temporal reported 1,100 customers and 250 employees. The project that had once needed its first resources now needed people to manage quite different kinds of work.

Fateev’s later description of his role is unusually candid about its shape. He called himself one of the CTOs who does technology, more like a chief architect. The absence of direct reports was part of that description. A title that often implies a management hierarchy could, in his case, mean a return to architectural questions. The founders’ partnership made room for that arrangement.

He has also spoken about learning from the people around him at Amazon. Asked about influences, he emphasized colleagues and the experience of seeing how infrastructure engineers approached problems. There is a useful humility in that account. The career includes recognizable systems and employers, but the education he describes happens in working conversations: somebody explains a choice, somebody else asks why, and the design gets better.

The new agents meet an old problem

By 2026, AI agents had given his subject a fresh audience. In an April conversation with WorkOS CEO Michael Grinich, Fateev discussed agents whose work involves model calls, external tools, and waits. They can branch in ways that a simple fixed pipeline does not. They also remain programs running on fallible infrastructure. A long task can lose its progress at a very inconvenient moment.

In July, he joined 1Password’s Nancy Wang and Jeff Malnick to discuss the distributed systems hiding inside these applications. The conversation included a demonstration of an agent surviving a crash. The appeal of that demonstration is wonderfully literal: stop the process and see whether the work returns. A recovery mechanism has rather less room for theatrical interpretation than a slide describing one.

September brought another measure of the attention around the company: a $550 million funding round at a $12.55 billion valuation. Those are Temporal’s numbers. They mark the commercial scale of the organization Fateev helped build, while his underlying subject remains the engineering of interrupted work. In a conversation that month, he stressed how long it takes to learn to build core infrastructure.

His longer ambition has room for a future beyond the business itself. He wants Temporal’s open-source project to succeed independently of the company, and developers to understand durable execution well enough to use it where it fits. That is a fitting aspiration for a career carried across several employers. The idea has already survived changes of address and changes of title. Fateev would like the programs built with it to show a similar talent for continuing.