The thing about SDM - manager of managers

As SDMs get to the higher end of the line manager role, they start to be less reactive, more proactive; less tactical, more strategic. The projects they deliver are not just “one damned thing after another” anymore. The dots start to connect into lines, although always zigzagging ones, never perfectly straight.

They own multiple team charters now. They have to hire new SDMs, or promote team members from within, to scale their teams.

They become the “manager of managers”.

The two keywords for manager of managers are: structure and standard.

First, about team structure.

When a team gets big enough, it needs structure to function. Big teams tend to spend more time on inner team communication rather than getting things done. The overhead slows them down.

So a manager of managers’s job is to define a sensible structure between their sub teams: divide big teams into smaller ones that each have a clearly defined charter and identity. Each team should know what it owns and what it does not own. It’s responsibility is cohesive internally but loosely coupled with other teams externally - just like a well defined distributed system architecture.

A deeper reason why team structure is so critical is the Conway’s law, which states

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

A manager of managers is the ultimate “architect” of the system they own. But the way they influence system architecture starts with team structure. For example, if a SDM wants to have a system with decoupled control plane and data plane, it is a good idea to have separate control plane team and data plane team. The two teams, following Conway’s law, will more likely drive toward the architecture that have clearly separated code base, delivery pipeline and runtime components between control plane and data plane, with clean interface to communicate each other.

Second, standard.

A line manager’s focus is on process: improve it if there is one, define one when there is none. But a manager of managers’s focus is on standards. Process is about “how”, but standards are about “what is right and what is wrong; what is good and what is bad”. For example, a runbook may define how to recover a failed system, but a standard on availability defines the system needs 99.999% up time. Operation readiness review checklist is another example of a “standard”

With the right team structure and the right standard of “good and bad”, and a lot of well defined processes, would the teams start performing?

Not necessarily. No process, structure or standard can replace people’s aptitude and attitude. A group of people need to share a common narrative - a story - to become a team. To achieve that, we need the organization leader to curate the org’s culture.

Stay tuned for the next post on “The thing about SDM - organization leader”.