Ways of Working, a repository of tips for how a team should work together

What the repository is and what it is not

Ways of Working, abbreviated WOW, describes how people work, especially together in teams. The README says you and your teammates can use this page to help your ways of working, and that there are 100+ tips for teamwork here along with articles the maintainer uses with his own teams.

The list of concepts it draws on is long and slightly repetitive, which is itself informative: principles, values, whys, tenets, ground rules, aspirations, norms, working agreements, culture and more. Those are not synonyms, but they overlap, and a team that has never written any of this down genuinely does not know which one it needs.

What the repository is not is a framework or a method with steps. There is no process to follow, no assessment to score and no certification. It is a catalogue, and the value is in the selection rather than in any individual tip.

The README also carries a metadata comment with a version of 16.1.0, an updated timestamp of 2022-07-27, a contact address for Joel Parker Henderson, and a list of tags covering working agreements, principles, values, tenets, culture, feedback and leadership. The tracked version number and the tag list suggest it is maintained as a personal knowledge base that is published for others to use, and the 2022 update date in the header against a repository push in August 2026 tells you the index moves but the content changes less often.

There is a glossary in the doc/ directory, and for a collection that uses this many near-synonymous terms, the glossary is the part to read first.

The licence field on the repository says it is not one GitHub can classify, and the README does not state terms. The content is largely collected from other people's published work, which raises the question of what can be reused, and that is worth checking with the maintainer before you paste any of it into a company document.

The four success questions and why they are the useful part

The most useful section of the README is the one that asks what success looks like, because it converts a catalogue into a checklist.

Are your ways of working explicit? The example asks whether they are written and easy to access and read any time, such as in your team's documentation. The point is that an unwritten norm is not a norm, it is an expectation that people discover by getting it wrong.

Are your ways of working understood? The example asks whether you can confirm that each teammate is familiar with all the ideas, and also knows where to find out more. That second clause is the practical one: a document nobody can find is not understood either, and the README is separating the two failures.

Are your ways of working open to debate? The example asks whether each teammate knows how to suggest changes, and also can provide comments, feedback and opportunities for new ways of working. A written agreement that cannot be amended is a rule, not an agreement, and the failure mode is that people stop bringing up problems.

Are your ways of working alertable? The example asks whether all teammates know quickly if someone breaks the ways of working, and also who is responsible for handling a breakage. This is the question most written agreements ignore, and it is the one that decides whether the document does anything. An agreement with no named person responsible for raising a breach will be breached silently.

Those four questions are a good structure for a team meeting, and they are also a way to evaluate any team practice document you find, including the ones in this repository. Most writing about working agreements gets the explicitness right and the other three wrong.

Where the collected documents come from, and the range they cover

The repository's value is partly the collection of source documents, and the list of names is a map of the genre.

There are overview pieces that frame the whole idea, most notably Team Norms, Working Agreements, and Simple Rules by Esther Derby, and Working Agreements by Jane Haskell. Those two are the ones to read first, because they explain the difference between the concepts the README lists in a jumble.

Then there are primary sources on specific practices. Adult Principles by John Perry Barlow, Principles by Nabeel S. Qureshi, Ground rules at Tesla by Elon Musk, Ground Rules by Tree Bressen, Ground rules for effective meetings by Get The Picture, and High-velocity decision making by Amazon. How to send progress updates by Slava Akhmechet, How we structure our work and teams at Basecamp, The Five Keys to a Successful Google Team, and The unwritten laws of engineering at Stedi are all in the same spirit: one organisation's actual practice, described by someone from inside it.

There are also encyclopaedic and framework documents, among them Software Engineering at Google, the Scaled Agile Framework, The Core Protocols by McCarthy, The 7 Habits of Highly Effective People, and The Pragmatic Open Source Contributor, plus 101 Additional Advices by Kevin Kelly and Project management practices by Hacker News participants, which is the only crowd-sourced item and the one most likely to contain the odd idea worth trying.

And there are checklists. The Engineering management checklist by Patrick Newman, the Onboarding and induction checklist, and Strategies to improve workplace communication are the practical artefacts you would actually hand to a new starter.

Two entries deserve a note because they are held up as counter-examples rather than examples. People are package deals by Steve Jobs and Terrible Software, and Rules of the Road by Jerry Perenchio, sit in the collection alongside the recommendations. The repository is not only a set of things to do.

The supporting repositories are the same idea as a network. Leadership and Principles by the same author are separate repositories, so the collection is one node in a wider personal network of documents on how organisations operate.

How to use it and what to watch out for

The way to use a collection like this is as something to discuss rather than a policy to adopt, not as a policy to adopt.

Start with the four success questions, because they are diagnostic rather than prescriptive. If your ways of working are explicit and understood and open to debate and alertable, you may not need most of the catalogue. If they are explicit but not alertable, the fix is naming a person responsible for raising breaches, and no tip from this repository is required for that.

If you do want to write something, the realistic sequence is to pick the three or four ideas that match problems your team actually has, draft them in your own words, and then test them against the four questions. The drafting is where the work is. A team that copies a working agreement from a blog post has adopted somebody else's agreement, including the parts that do not apply to them, and the ones that do not apply are what people ignore.

Two specific warnings. The first is that each source document carries its own context. Ground rules at Tesla describes one organisation under one founder at one point in time, and reading it as a template for your own team misses the part that made it work there. The same applies to The Five Keys to a Successful Google Team, which describes a specific period of a specific company.

The second is the terminology. Principles, values, tenets, norms, ground rules and working agreements are used interchangeably in the README's own list, and different authors mean different things by each. If your team uses one word for two concepts, the agreement will be ambiguous in exactly the situations where precision matters. The glossary is the fix, and it is the first thing to read.

The last thing to check before reusing any of it is the licensing. The repository reports no standard licence, and much of the content is other people's published work with their own terms. If a document is going into a company handbook or a public engineering blog, that question needs an answer, and the maintainer is the person to ask.

Editorial conclusion

Adopt Ways of Working as a source to draft from when a team has no written agreements and does not know where to start, since the breadth covers most of the vocabulary a team might need. Skip it if you are looking for guidance on a specific practice, because the repository collects rather than argues. Verify first by picking three ideas that match problems your team actually has, drafting them in your own words, and checking with the team that the result is one they would recognise as their own rather than as imported policy.

Frequently asked questions

Official sources

1. Issues
2. README
3. ways-of-working/ways-of-working on GitHub