ways-of-working VS questions-for-employers

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.

Tl;dr some potential employers and managers lie in interviews to even on the job. GL to any future SWE/junior. Here's Qs to ask interviewers to help filter out ones like my current employer: 1, 2, 3, 4, 5, 6. Imo students/alumni should not jump on the first offer they get if they can afford it since the outcomes can be costly from skills fading, to experience, to length of employment, to rejecting competing employers/jobs, and more.

Questions for potential employers

Ya it's tough, saw your recent post as a junior dev too. While no workplace is perfect, the overall combo in the above list (esp. lack of consistent eng work) is the most concerning imo. Someone on a diff. post shared Qs to ask interviewers to filter/detect 🚩 before accepting a job: 1, 2, 3, 4

https://github.com/tBaxter/questions-for-employers https://github.com/viraptor/reverse-interview