With the emergence of the SDM & SRM roles with Kanban, we need to ask the questions, when do we need these roles? When do we need both? And are they merely roles an existing member of staff takes on as new responsibilities, or might they be new positions for which we need to hire? This post provides guidance based on what we’ve seen in the field so far.
When do we need a Service Delivery Manager?
I genuinely believe you always need a service delivery manager. This role has existed since the first Kanban at Microsoft in 2005. In the early days the SDM role was always played by a project manager. So it isn’t a new position but a refinement of existing responsibilities for an existing member of the staff. The SDM is therefore a role played by someone external to the value stream or workflow.
In the upper diagram, a service delivery workflow is shown spanning a functionally silo’d organization. The SDM facilitates the Replenishment Meeting receiving customer requests and facilitating a collaborative decision making process to select, sequence and schedule work to flow through to delivery. The SDM will collaborate with the functional manager or team leads and play a reasonably active part in the day-to-day operation of the kanban system, definitely attending and perhaps facilitating the Kanban Meeting.
It’s been reported to me that in some organizations, the concept of a service delivery workflow is very weak, while the functional silos and structure are very strong. Usually, such companies lack any significant focus on customer satisfaction or any service-orientation in their thinking, mindset or value system. I’ve specifically had this reported to me from a large Swedish industrial company and several companies in China in the technology or finance sectors. In these instances, the change agents, usually process coaches or members of the PMO, felt it was necessary to create the Service Delivery Manager role as a specific position within the firm. The act of doing so, is actually making a very clear commitment to service delivery and customer satisfaction. In other words, the bar for the change initiative is raised – senior leaders are being asked to acknowledge that service delivery and customer satisfaction are important. They are being asked to explicitly put customer focus in the spotlight and make it part of the corporate value system. This is a non-trivial but hugely important step.
So where there is a current lack of customer focus and a lack of understanding of existing service delivery workflows, where the concept is weak, you need to create a position for SDMs.
When do we need a Service Request Manager?
A Service Request Manager is likely to be needed when contact with the customers, or service requestors is weak or distant. The SRM becomes a proxy or advocate for the customers. However, it is important that we don’t place the SRM in a decision making role. We don’t want them becoming a dysfunctional proxy for the customer, showing bias towards one over the others. We always want the SRM as the facilitator of selection not the person doing the selection. In organizations, where contact with the customers is weak, there is often already an intermediary possibly a sales engineer, an account manager, a product manager or in Agile adopting organizations a product owner. So we want to elevate that person’s role into the role of SRM. It is a set of new responsibilities, not a new position.
When the SRM role exists, the SRM will take on the responsibility for the Replenishment Meeting and will play roles in the Strategy Review and Risk Review.
When might we need SRM as a new position? If the SDM is the “flow manager” for service delivery, then the SRM is the “flow manager” for ideation or discovery. So we might expect to see SRM emerge as a specific role when we have an upstream or discovery kanban system. The more focus we have on ideation, option validation and discard, and discovery and validation of concepts (or minimum viable products, MVPs) the more likely we are to need a SRM as a specific position in our organization.
The SRM role is described as “marshalling options”. This is the act of facilitating flow, and discard or upstream kanban work.
When might we need both roles?
In discussing this amongst my colleagues and with leaders in the Kanban community, Mike Burrows commented, “I have seen the need for one or the other but never both.” And that is probably a fair statement, we have seen firms adopting SDM or SRM roles but so far we haven’t seen both, at least not explicitly. With larger scale ESP implementations, we do see a lot of SRMs. One client advertised for SRMs by placing job advertisements for Product Owners. This makes sense. You recruit for a title that people are familiar with, then you mold them into what you need. That client has a strong sense of service delivery and without doubt function managers or team leads are playing the role of SDM. It just hasn’t been made explicit in that company.
So I suspect that as we see greater emphasis on the use of Kanban upstream and the growth of Enterprise Services Planning, with business emerging where ESP/Kanban is _the_ way that they manage their professional services company then we will see strong growth and use of both SRM and SDM roles.
At smaller scale and where there is little ideation, option development and discard, and a strong connection to the customer together with a strong sense of service delivery, in these cases, I expect only one role, SDM, played by an existing member of the staff. So Kanban as we knew it in 2005-2008 doesn’t involve new positions or additional headcount, but the future with Enterprise Services Planning, particularly in organizations with a weak sense of service delivery and a lack of customer focus, we are likely to see the new job title of Service Delivery Manager emerge. In companies that do a lot of innovation and act as a market leader in an uncertain and emerging market, we are likely to see the emergence of Service Request Manager as a new position. Where both circumstances exist, we’ll see both roles in use, perhaps both as new positions and additional headcount.