When the Squad Shrinks

The signal

The Public Cloud CSM team moved from 20 people to 12. I worked on redesigning coverage for the smaller team. Dividing the same work among fewer people would not, by itself, answer what customers needed or what the team could realistically deliver.

The leadership decision

The useful question was not simply, “How many accounts can each CSM carry?” It was, “What kind of help does each account need, and what level of coverage can we support?” A coverage model is a set of service choices, not just a spreadsheet of assignments.

A reusable way to investigate

Start with the work: onboarding and implementation demands, technical complexity, stakeholder coordination, commercial timing, and the consequences of a missed handoff. Then identify which needs require continuity with a named person and which can be served through a shared motion.

Make the trade-offs explicit. For each coverage tier, define what remains available, what changes, who responds, and what triggers a move to more intensive support. A pooled label without a response path is not a service model.

Protect the handoff

A manager should be able to explain the new model to both the customer and the CSM. Who owns the next action? Where does context live? Who notices that an account needs more help? Which commitments must be renegotiated rather than silently dropped?

Use the first reviews to check whether the model matches the work. Look for queues, repeated escalations, unclear ownership, and accounts whose complexity was underestimated. Those are reasons to revisit a design choice, not proof that a CSM needs to work harder.

The boundary on the story

The experience here is the coverage redesign under a smaller staffing model. This case does not claim that every customer received identical service, that the model eliminated risk, or that a quantified business result followed. Its practical lesson is to make the service choices visible.