Keep your CSMs 100% Accountable

It is no secret that software companies struggle to manage the customer experience when faced with feature requests.  My background has led me to be fairly rigid on feature request and institute processes that pretty much deflect and prevent such requests.  I know this is not the optimal way to work for certain clients but across the entire client base, it is a rule-of-thumb that has served me well.  

I train my CS team to perform at 100% accountability.  Do what you say you will or you will get burned. This is part of my day one expectations doc, it’s part of our 1:1’s and part of our daily interactions. My team understands that they are expected to perform at 100% accountability.

On the surface, this is an easy expectation to understand: “make sure I do everything….always”.  Under the hood though, I am training my teams to drastically and intentionally reduce commitments.  More clearly put, if you commit to nothing then you have nothing to do and are therefore 100% accountable. It doesn’t always work that way as we all know.  

If you accept this concept and start to look at your behavior academically, you quickly start to notice the onslaught of commitments that are near projectile from your mouth.  “I’ll do that right away”. “We WILL fix this”. “I’ll have this to you by 5pm”. “We will do whatever it takes for you to be successful”. 

These are just light examples that are typically used in everyday interactions.  They’re mostly harmless but may lead to a few missed commitments or a few late evenings of catching up.  As portfolios get larger, these small commitments can start to compromise accountability. In general, I advise that CSMs eliminate volunteering these lightweight commitments and let the customer make the ask.  This approach leads to fewer commitments (which increases the ability to be 100% accountable) and it also leads to a higher quality of commitments based on exactly what the customer wants. 

The real trouble comes when a customer is escalated.  As the urgency increases and the stakeholders get more senior, it typically leads to more significant commitments.  This is when the big-gun commitments usually come out. Things like “We will implement this fix today” or “I will prioritize this with our development team”.  These commitments often have more dependencies and are generally more expensive to deliver. They also drastically jeopardize your ability to be 100% accountable which erodes trust and credibility.

So, with all of that said, I have introduced a simple tool to remind my team to keep their commitments top of mind and manageable.  I call it the Commitment Scale.

The commitment scale is really simple.  On the low end, you can commit to nothing.  On the high end you can commit to code. Of course, this is just an example of what applies to our business and will need to be tailored for yours.  

I always put code on the far right because I see it as the most risky commitment (remember I acknowledged I was biased).  I see code as risky for a few reasons:

• Prod/Eng might not do it
• The code might not work
• The code might not work the way the customer expected
• The code might take much longer to deliver than the customer expected
• The customer might request further code 

Most everything is less risky than code and can be committed and delivered with less cost to the organization.  Simple things like “I will escalate this Jira ticket” is a commitment that can be accomplished with little effort.  Other things like training and analysis come with lower lifts. Furthermore, they can help work around the need for code.  

Long story short, I too often see new CSM’s immediately assume that code is the answer and then struggle to get the request moved through the supply chain.  Driving the team to consciously manage their commitments reduces overhead on the organization and generally leads to higher impact deliverables and more successful customers.