ギットラボが非同期の作業に大きく依存できるのは、タスクレベルから次の3つのルールに従っているからである。
ルール1：タスクを実行する責任と、その完了を宣言する責任を分ける
従業員が同じオフィスで働いている前提であれば、手軽なコミュニケーションと社会的手がかりを読み取ることで、曖昧な点を効率的に解決し、仕事の責任や権限をめぐる衝突にも対応できる。しかし、リモートワークの場合、これは難しいだろう。
そこでギットラボでは、それぞれのタスクに完了責任を担う「直接責任者（Directly Responsible Individual：DRI）」を設けて、完了に至るまでの方法はその人の自由になっている。
ただし、DRIはタスクが完了したかどうかを決めることはできない。その役割は「メインテイナー（Maintainer）」と呼ばれる人物が果たしている。DRIの統合要請を受け入れるか否かを決める権限は、このメインテイナーが握っているのだ。
すべてのタスクでこの役割分担を明瞭化することで、混乱や遅延が減らせる。また、フォーキング、つまりローカルのコピーをつくって、複数のDRIが同時並行に、それぞれの好きな方法で、担当する部分のコードの作業ができるようになる。ドキュメントやコードの作業版における不要な変更を避け、一貫性を保つのはメインテイナーの仕事である。
ソフトウェア開発以外、たとえば、ギットラボのハンドブックで経費に関する規定を載せるページを作成している場合、社内の誰もがDRIになりえる。DRIがそれぞれ、自分の選んだ方法で特定の規定を書き、メインテイナーの役割を果たしているCFOがその提案を受け入れるか拒否するかを判断する。メインテイナーがDRIにフィードバックする場合もある（ただし、指示は出さない）。
いったんその規定が使われ始めたら、誰かが新しい規定を提案しない限り（あるいは提案するまで）、ハンドブックに統合されたページの内容が、経費の規定に関する唯一の真実となる。
新しい規定が提案された時も、メインテイナーがそれを受け入れるか拒否する、あるいはフィードバックする。このような場合、いわゆるマネジメントの立場にいる人々がメインテイナーの役割を果たす。
ルール2：「実用最小限の変更」の原則を尊重する
作業が非同期で行われる場合、協調の失敗が長期にわたって表面化しないというリスクがある。たとえば、2人が同じ問題に並行して取り組んでしまい、どちらかの労力が無駄になったり、1人が加えた変更がもう1人の作業と噛み合わなくなったりするケースだ。
こうしたリスクを最小化するため、従業員には「実用最小限の変更（minimum viable change）」を提出することが奨励されている。不完全な初期バージョンのコードやドキュメントに対する変更案の提出である。こうすれば、作業が噛み合っているかどうか、重複していないかどうかに気づく可能性が高くなる。
言うまでもなく、実用最小限の変更の指針は、アウトプットが暫定的で不完全だとしても「責めない（no shame）」指針とともに示さなければならない。リモートワークの場合、他人がやっていることを可能な限り早く知ることは、完成したプロダクトを受け取ることよりも価値が大きいからだ。
ルール3：常に公開でコミュニケーションをする
ギットラボのチームメンバーは「社内メールを出さない」とよく口にする。社内メールを送る代わりに、スラックのチームのチャンネル上であらゆる質問を投げかけ、あらゆる情報を共有する。
チームリーダーはその後、どの情報をチーム以外の人とも共有しておけばよいかを判断する。必要だと判断された情報は、全員が使える場所、すなわち「問題」を集約するドキュメントや会社のオンラインハンドブック上に保存されるので、社内外から誰もが閲覧できるようになる。
このルールを守れば、重複のリスクはなくなり、間違って同僚の作業を台無しにしてしまうリスクもなくなる。
マネジャーは相当の時間を費やして、従業員が仕事を通じて得た情報を整理収集する。また、将来のチームにはどのような情報が広く必要となり、社外にいる人々に役立つのかを、誰よりも熟知していることが求められる。
