FDE: Who Is Responsible for Customer Outcomes?

Pavel Golubev returns to Code of Leadership after an earlier conversation about his move from consulting into Data Science and AI. This time he describes changes in customer engineering at Microsoft. His former unit built solutions without charging customers directly: the economic justification was increased Azure consumption. That allowed considerable technical freedom, but attributing the financial effect to a particular team was difficult. Several contributors could claim credit for the same growth in cloud spending.

According to Pavel, the new structure gives engineering units a more direct financial target: payment for customer work. Microsoft investment funding can still cover part of an engagement, but free implementation in exchange for future consumption is no longer the central model. Managers consequently spend more time on sales, estimating commitments, and matching opportunities with available engineers. Pavel presents an operating model still being reorganized, with unresolved processes, rather than a finished or universal definition of FDE.

Engineers now enter customer conversations earlier. Instead of receiving a request for agents to handle a specific document workflow, they may hear that a company wants to become a global leader. Pavel describes a workshop with a German construction company that began at this level. FDE leadership must turn broad ambitions into concrete use cases, consider possible engagement formats, and identify the required expertise. Technical judgment is needed before a project has been agreed.

Customer budget cycles complicate staffing. A promising program may only become funded by April, while engineers are available now. Keeping them unassigned is expensive; sending them to another long engagement may leave the team unavailable later. Sales planning and staffing are therefore inseparable. Finding a need does not mean that a customer can purchase immediately or that the proposed team will remain available until the start date.

Pavel describes agreements tied to a business outcome defined with the customer. Missing the target can mean losing payment or continuing beyond the agreed fee. Alexander asks about the upside: if the supplier shares the risk, does it also share additional success? Pavel says revenue sharing is discussed case by case. A customer building an internal product may want neither joint commercialization nor shared intellectual property.

The central contradiction appears before the contract. Previously, one or two engineers could investigate the data and feasibility over a short period. In the current process Pavel describes, teams sometimes commit before gaining access to the data. He proposes selling a separate feasibility stage or funding it through Microsoft’s investment budget. This is a suggested improvement, not an established general rule. Alexander observes that prohibiting a small initial investment makes choosing a viable larger solution harder and increases later risk.

Another constraint is the pair of main offers: a team for three months or for a year. Pavel considers this inflexibility a problem. Customers are asked to accept uncertainty, a long commitment, and substantial expenditure together. A smaller, testable step could help both sides establish whether they can work together before making larger promises. Alexander connects this to trust: an initial useful result creates opportunities for further work inside the organization.

Risk management nevertheless extends beyond pricing. Business program managers translate promises into contractual checkpoints and conditions for revision. If the original idea proves unworkable after a few months, the parties can change the scope or end the engagement while paying for the completed portion. This does not remove uncertainty, but it makes the consequences of an incorrect starting assumption more manageable.

Pavel’s concrete example concerns document automation at an oil company in Latin America. Employees manually prepared reports and documents for numerous counterparties. The business agreed on reducing preparation time, while internal IT raised security requirements. Once work began, the team discovered that employees in equivalent roles had different permissions for email, documents, and SharePoint. A custom agent would have required reproducing complex access logic, exceeding the scope of the smaller engagement.

The team proposed Copilot Studio, where agents in the described setup used the initiating user’s permissions. Business users were willing to learn the interface, but IT resisted self-service creation because it feared losing control. The compromise left agent creation with IT, which received requests from the business. This introduced an organizational step but made deployment acceptable. Pavel describes shorter preparation times and a clearer role for internal IT as a satisfactory outcome for the parties. The technically less restrictive option had proved organizationally unacceptable.

A budget alone does not establish the ability to deliver an outcome. Before starting, the supplier must understand whether its customer counterpart can change processes and coordinate other departments. Pavel distinguishes a personal experiment from an engagement backed by someone with funding, authority, and a willingness to drive change. Under the earlier model, another department sometimes blocked a completed solution. Screening opportunities must therefore examine more than technical appeal.

Sales remains a team activity. Pavel does not describe becoming a conventional salesperson: his contribution is to assess feasibility, explain the team’s capabilities, understand the customer’s stack, and discuss previous attempts. A CTO may benefit from engineering detail; an executive discussing business direction needs a different conversation. There is no universal winner between a technically informed salesperson and an engineer who has learned to sell. Their usefulness depends on the counterpart and the stage of the engagement.

Pavel describes industry units, regional teams, and multidisciplinary groups comprising engineers, data scientists, and technical program managers. His Data Science responsibility crosses reporting lines: line managers formally allocate people, while he contributes to professional practice and delivery quality. A senior specialist may also lead a project or take on architecture work.

Within a project, disciplines do not become isolated silos. The team jointly divides responsibilities, such as evaluation and data pipelines. Working alongside customer engineers includes sharing development practices, not merely handing over code. Pavel mentions fast iterations and agents. The conversation does not specify detailed arrangements for ongoing support, but developing the customer team’s capabilities is explicitly part of the work.

FDE work requires learning unfamiliar industries quickly, negotiating, and acting with incomplete information. Staffing can change between a proposal and a project’s start: the original specialist may be busy elsewhere, so a replacement must rapidly build context. Pavel describes this as demanding and unpredictable work. Job titles change, but the underlying task of building a useful solution inside another organization existed before the FDE label.

Alexander sees an opportunity for intensive learning: working with different stakeholders, distinguishing industry-specific details from transferable patterns, and testing modern tools on real problems. Pavel closes with a practical criterion: see the business outcome behind the technical choice. If rules can solve the problem, a request for an agent does not justify unnecessary complexity. An engineer’s value lies in choosing an appropriate approach, not in always using the newest technology.