top of page

SDM Implementation Patterns: SRM/SDM Tandem

Updated: Feb 26, 2023

This article is part of the "Finding your SDM" series.

The Story

Mario and Rob are the visible faces of a Digital Financial Product development service. This service develops and maintains the online platform that supports a personal finance product, and mostly satisfies the needs of the Personal Finance business line and their external Clients, and occasionally receives direct requests from some other company executives (like the CEO).

To do the work, the service has a team of software developers, a testing team, and a small team of business analysts. They collaborate closely with people from the UX department and various Marketing teams.

Rob is a Product Manager, and formally reports to the Business Line VP. He understands the domain and the market, and his role essentially involves capturing requests and ideas from the Business Line and turn them into features the service can delivery to enhance their offering. To do that, he works closely with the BA team, and helps manage the relation with UX and Marketing. The result of that collaboration is a set of options that he can present to the Business Line, so that the business teams can make concrete requests and priority decisions.

Mario reports into the PMO, and was assigned to the service as Scrum Master. He pays close attention to the promises they’ve made, and the flow of work to fulfill those promises. He also takes care of facilitating the relation with some tricky 3rd party dependencies.

During the formative period for the service, Mario was instrumental in helping the team adopt practices and processes (both upstream and downstream). In particular he provided Rob with techniques to help him develop ways to make sense of the upstream work and to figure out relative priorities. Then, together they developed processes to present options and make commitments to the Business.


  • A service with relatively complicated upstream and downstream workflows

  • Two managers, one focusing on the upstream, the other on the downstream, that understand that they need to collaborate in the interface

  • Business people that see the “tandem” as the entry point for the service (i.e. they understand that it’s not enough to talk to any of them separately to get work through the service)


  • An upstream leader collaborating with a downstream leader, in a relationship of equals, that at the same time acknowledges each other’s area of competence and focus.

  • The upstream leader (Service Request Manager, or SRM) manages the activities intended to capture, refine, and prepare options so that they can be brought to the commitment point to make a decision on whether to work on them or not.

  • The downstream leader (Service Delivery Manager, or SDM) manages all the activities that follow the commitment point, intended to develop (implement, build, etc.) work items once committed to the Customer, all the way to delivery.

  • At commitment time, both SRM and SDM facilitate the conversation between the service and their Customer to arrive at replenishment decisions.


  • Some common job titles for the SDM include: Scrum Master, Team Lead, Project Manager, Development Manager, Delivery Lead, etc.

  • Some common job titles for the SRM include: Product Manager, Product Owner, Product Director, etc.

  • Two “weaker”, though not uncommon, variations of these patterns are:

    • SRM as the “representative” of the Customer: The Customer delegates some aspects of decision making to the SRM when it comes to priorities and replenishment decisions. Essentially, replenishment conversations take place between the Service and the SRM, rather than the Service and the Customer directly.

    • SDM as the “spokesperson” for the service: the SDM makes commitments for the Service, rather than facilitating a conversation, or following commonly agreed explicit policies. Essentially, the SDM makes commitments in the name of the Service.

  • What distinguishes this pattern from its “dysfunctional” counterpart (SDM partially owns the output) is the absence of a “back door” through which work is accepted in without the full awareness of both leaders.

159 views0 comments

Recent Posts

See All


bottom of page