As enterprises push to turn technology investment into measurable business outcomes, some professional-services teams are moving away from rigid, fixed-scope contracts toward more flexible, goal-driven delivery. One example is the OKR-centric model used by Databricks Professional Services (PS), which combines objectives and key results (OKRs) with small, agile delivery teams. This article outlines how that model works and the questions to weigh when considering it.
OKR-focused delivery
The core idea is to organise an engagement around a customer’s objectives and key results rather than a static statement of work. In practice this is intended to deliver several things: customer-centric execution, where project scope and priorities align with the client’s own OKRs; real-time collaboration, where teams can add goals, adjust key results and pivot as priorities change; skills-and-resource fit, matching specific expertise to particular key results at the right moment; and measurable impact, using shared OKRs to track progress transparently and link the work directly to customer return on investment. The stated benefit is clearer accountability and a tighter connection between activity and outcomes than a rigid contract typically allows.
Pod-based deployment
To support this, Databricks introduced “pods” in 2024 – small, autonomous, cross-functional teams built for speed and impact. Unlike a traditional model that assigns one or two engineers for the length of a project, a pod operates as a self-contained unit with full ownership of its outcomes, and a pod lead can bring in the right expertise when it is needed. The intended results include faster delivery, stronger accountability and higher customer satisfaction through transparent communication and consistent alignment. The company points to engagements such as its work with Shell as examples of the approach in practice, though these are vendor-described cases rather than independent evaluations.
Echoes of the forward-deployed engineer model
The emphasis on embedded expertise and outcome-driven delivery echoes the “forward-deployed engineer” (FDE) model that has gained popularity in an AI-first environment. In that model, engineers work closely alongside a customer across the full spectrum of software engineering – infrastructure, CI/CD, data engineering and application development – rather than delivering from a distance. Embedding engineers this way is meant to shorten feedback loops, build the customer’s in-house capability and reduce total cost of ownership over time.
What to watch
This model is described from a single vendor’s perspective, and the benefits cited are largely self-reported, so prospective customers should validate claims against references and their own pilot experience rather than taking them at face value. OKR-based delivery also has failure modes: if key results are poorly defined or gamed, they can create a false sense of progress, and flexible scope can drift into scope creep without disciplined governance and clear change control. Small autonomous pods depend heavily on the quality of the pod lead and on the client providing timely decisions and access, and outcome-based engagements require both sides to agree on how success is measured before work begins. Used well, OKR-centric, pod-based delivery can align a services engagement tightly with business goals; used loosely, it can blur accountability. For related context on how organisations are structuring AI-era delivery, see how enterprises are preparing for agentic AI. Further material is available on the Databricks blog.
