managers-playbook VS ways-of-working

Welche Branche? Für SWE gibt es hier interessante Lektüren: https://github.com/ksindi/managers-playbook

Title aside (“manager” - I agree with other commenters, don’t focus on being a manager), this is a food resource https://github.com/ksindi/managers-playbook

Written ways of working can help teams internally, and it turns out can also greatly help with managing up the chain of command.

If you have ways of working, then I would love to know about them. I maintain a repo of help for tech teams here: https://github.com/joelparkerhenderson/ways-of-working/

> are your ground rules and team values always open for debate

Yes including asynchronous e.g. on a chat channel, and synchronous e.g. during a retrospective.

> on Friday afternoon when all your services have gone belly up

Yes. For example some teams choose a way-of-working for emergencies that uses the abbreviation "ANC" for the priority order of Aviate, Navigate, Communicate. If there is an emergency,then the team focuses first on keeping the system running, second on figuring out where to go and how to get there, and third on talking. Afterward, then the team does a causal analysis e.g. postmortem or after-incident report, including fielding any ways-of-working areas that came up in the channels because of the emergency.

> when someone new (a vendor say, or an intern) violates those ground rules and values do you shut them down with some variant of "we don't do that here" like "you have violated the ground rules"?

Yes. For example there are sometimes fast-moving high-urgency multi-team meetings that include many new people who don't know about ways-of-working. We open the meeting by saying e.g. "This meeting's moderator is Alice." then Alice quickly explains the ways-of-working: one person talks at a time; debate the issue not the person; focus on the agenda not side tasks; call a timeout if something important is amiss; etc."

> Are your ground rules explicitly enumerated somewhere and all team members familiar with them in enough specific detail to know whether or not something violates them?

Yes, such as using docs, or wikis, or README files, etc.

You can see many of the public ones in the repo at https://github.com/joelparkerhenderson/ways-of-working where there are a bunch of them collected across many teams.

If there's anything in the repo that you believe can be improved, or clarified, or grown, then I welcome constructive criticism. Likewise if you have opinions of different ways to handle team values, or skip them, I'm interested in knowing what you think.