top of page

SDM Implementation Patterns: SDM at the Front Desk

Updated: Feb 26, 2023

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


The Story

Mary is the Team Lead for the Public Website Team. This is a relative small team that takes care of making updates to the public side of the company’s website. They receive requests mostly from Marketing teams and a few other Development teams, when they need content updates, creation of new pages and site areas, small fixes (such as broken links, styles or icons). They occasionally are involved in larger projects; a recent example was a general update of the website look & feel, which involved massive changes all throughout the site.


Mary is the recognized “entry point” for this team: when any other team in the organization needs a change in the Public Website, they all know they should talk to Mary. She has setup an “inbox” for requests (a combination of Jira and an email address) where customers need to submit any requests for work, and has given explicit instructions to her team members to enter items in this inbox if they are ever approached by any customer directly, before doing any work on these requests. She performs some basic prioritization of the work, and also takes care of clarifying requirements before starting the work (involving other team members as required).


When it comes to doing the work, Mary usually assigns individual tasks to team members. She has been trying to adopt more “agile” ways of working, by introducing daily stand-ups, iteration planning meetings, and encouraging more task self-selection, pairing, etc. She diligently tracks and resolves impediments team members encounter and follows up with external dependencies when required.


To deliver their work, Mary’s team must adhere to a deployment process defined by the IT department for all teams, which involves handing over a build to a Release Management team, and then being available to solve any post-deployment issues. Mary has worked with her team to establish an internal release testing procedure that minimizes surprises on deployment days.


Context

  • A (relatively small) service comprising one or more teams, with a clearly identified leader

  • The Leader is seen by the rest of the organization as the “entry” point to the service, and also usually its “spokesperson”

  • The Upstream Workflow is relatively straightforward, consisting mostly on refinement and some (internal) prioritization.


Pattern

  • A member of the service (usually in a leadership role) takes responsibility (“ownership”) of setting up a process to submit work to the team, allow the service to make commitments, and then deliver on those commitments.

  • The Leader is actively involved in observing flow from commitment to delivery, addressing impediments to flow, and ensuring delivery.


Variations

  • In addition to Team Lead, other common titles for the SDM include: Team Manager, Project Manager, Scrum Master, Product Owner, Senior Dev, Team Architect, etc.

    • In particular to Scrum contexts: while the Scrum Master is usually assumed to be this Leader, is not uncommon to find Product Owners playing this role, relying on Scrum Masters for more “secretarial” (day-to-day) activities, and actually having a larger say in defining the process and manage flow

  • As the service gets bigger (more teams, larger groups) other patterns emerge (see: “SDM by Committee”, “SDM by Functional Authority”)

  • As the Upstream workflow becomes more elaborate, the SRM role appears as distinct from the SDM (see: “SDM/SRM Tandem)

  • When the Leader is unwilling to take ownership of the service end-to-end, but still retains the ownership of some aspect of it while resorting to Blame, Justification and/or Shame for all the others, the result often is the “SDM in Denial” pattern.


Maturity Level Considerations

  • At lower maturity levels (KMM ML1-2), significant amount of demand can be irrefutable; while this will severely limit the SDM’s ability to reject/defer commitments, the SDM at the Front Desk is still able to set policies to manage flow after commitment (a common example: the separation between the “commitment to do” from “commitment to start”). As a result, demand and capability will still be out of balance and the service unpredictable, but the SDM might be able to achieve (local) relief from overburdening.

  • As the maturity level increases, and with it the level of trust and capability, the SDM’s options to switch to a more collaborative/participatory stance will also increase. Exercising these options (rather than relying on “dictating” policy), however, also depends on personal style and cultural considerations.




92 views0 comments

Recent Posts

See All

Comments


bottom of page