少しの間、サーバーエンジニアリーダーをやらせていただいたことがあり、
その時心がけていた、実践してみた5つのことをまとめておきたいと思います。
1.みんなでコードレビュー
その名の通り、プロジェクトに参画している全員（サーバソースはサーバリポジトリを、クライアントソースはクライアントリポジトリを）みんなでコードレビューするという試みです。
開発チームにはおそらく1人はテックリードがいるかと思いますが、
そのテックリードによるコードレビューによって、品質担保しているチームは多いと思います。
そのコードレビューをみんな（テックリード込み）ですることで、
・ナレッジの均一化
・多様なアイディア集積
・属人化軽減
のメリットが望めます。
一方で注意しないといけないのが、マージしてもいい条件やレビュー観点をちゃんと定義して共通認識をもっていないと、
・いつまで経ってもマージされない
・小さなツッコミが大量コメント（例えばコード規約的なとことか）
・結果誰もみない（誰かみるだろうからいっか）
といったデメリットが発生しえるので、例えば
リクエストタイトルに**[軽微]とか[緊急]**とかをつけて、優先的にみてもらったり、週3とかで、みんなで集まってコードレビュー会の時間を設けたりして対策できたりするかなと思います。
2.TDD
もうこれは今の世の中当たり前だったりするかもですが、テスト駆動開発です。
TDDというとテストファーストなので、実装前にテストケースを書いてそれを満たすように実装していくって流れになると思いますが、個人的には1メソッド実装して、そのテストケースを書くという流れでも特に支障なかったので、そこの順序は開発しやすさを優先していいのかな〜と思います。
テストを書く書かないは論争があったりしますが、自分は書いてた方が
・改修における影響範囲が把握できる（カバレッジが網羅されてる前提）
・開発スピードと精神的安定（動くという安心感）のバランスがいい
・重たいメソッドを実装しなくなる（なるべく細分化する）
などのメリットがあるんじゃないかな〜と思います。
ビジネス的に何よりもリリースを急いでいたり、サーバー込みなモック開発、新規のアジャイル開発などでは、
先にガッツリ実装して、運用中にテストカバレッジを上げていくしかないこともあると思いますが、
やはりテストがある時とない時ではリファクタスピードも上がるし、デグレリスクも抑えられるかなと思います。
ちなみに自分はこれを読みました。
https://books.google.co.jp/books?id=BMCdGAAACAAJ&dq=%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA%E5%85%A5%E9%96%80&hl=ja&sa=X&ved=2ahUKEwjuuayU5LHtAhVdyosBHci-CNsQ6AEwAHoECAMQAg
3.開発ローテーション
新規の機能を開発する際、基本的には1人の工数をあてて、設計・見積もり、実装、テスト等をすると思います。
そして作った機能は、必然として、サービスの運用とともに機能自体のブラッシュアップされるものです。
その際、「この機能はAさんに実装してもらったから、Aさんにお願いしよう」と安易に決めてしまうと、
その時その時の開発スピードはあがりますが、俗人化というデメリットも生まれやすくなります。
俗人化による悪影響は例えば、
・営業時間外にその機能に障害が出た際、機能を作った担当の方に何がなんでも連絡をつける必要が出てきたりしてしまう
・同時期に同レベルの機能開発案件があって、Aさんにはそっちに当てたいけど、この機能改修のスケジュールだとAさんでしかできなさそうという脳内バッティング
・誰も触ったことのない機能はコードレビューしづらい
などなど。
改修要件が出てきたときは一度、担当割り振りパズルを組み立て直す時間はとるべきかなと思います。
割り振り直してみて、結局Aさんでもいいし、Bさんにチャレンジしてもらって、Aさんにも別機能開発にチャレンジしてもらってもいいと思います。
自分は後者の方が長期的なサービス運用チームを見据えると、開発コストがどんどん安くなるんじゃないかなと思います。
（ただし入退室が激しいチームとかだと当てはまらないかもです。。入れ替わりが激しいなら特に開発フレームワークというか規約とかに力を入れて、誰がみても、いちいち言わなくてもドキュメントさえ読めば全部できちゃうようにしておくことに力を割いた方が良きかと思います。）
4.テックリードと実装開始前の設計相談
これは社会人として当たり前の「報連相」の一つとして俗に教えられる「2割報告」や「5割報告」というやつです。
結論からいうと、
機能開発する際、設計や実装方針を実装前に事前にテックリードと相談しておく機会を設けるということです。
また、ここでいう2割というのは途中まで設計したものを報告するというのではなく、報告する時点で頭の中では実装は終わっている状態まで持っていった上で、相談します。
これを実施せずにばっと実装して動くものを作り、プルリクを投げてレビューを依頼したとすると、
「これはどういう意図ですか？」
「こういうDB設計の方がよくないですか？」
「ここはキャッシュを使って欲しい。」
「このCSV設計だと今後の汎用性に欠けるので、再設計をお願いしたい」
などのレビューが来て、大きなやり直しが発生しえます。
そして、運用中のサービスとかになると、スケジュールがかつかつだったりするので、
返答として、「ちょとやり直す時間がないので、今回はこのままでいきたいです。。」というゴリ押し返答になったりします。
これはプロジェクト的にだめだめです。（むしろ社会人としてだめだめだと思います。）
これを回避できるのが
テックリード（テックリードがいなければ、信頼できる他のエンジニアの誰か）に実装前に設計を当てておく（味方に引き入れる）こと
です。
自分がやっていた2割報告は主に
①要件説明
②API設計(インターフェース設計)
③DB設計
④CSV設計(ローデータ設計)
⑤ログ設計
⑥迷ってるポイントあれば相談
こんな感じ。普通にがっつり30分はmtgします。
（のちのちレビューでひっくり返って徹夜するよりも遥かに費用対効果がいいと思います。）
5.チームタスクの可視化
リモート環境になってより、今誰が何をやっているか、いつ終わるのか、明日は何をやるのかが見えづらくなりました。
もちろん朝会だったり夕会だったりで進捗報告を聞くものの、業務委託の方とかだと契約的に進捗報告義務がなかったりするので、聞けなかったりすることもあると思います。
そこで、自分はプロジェクトが使っていたタスク管理ツールのうち、自分が管理していたチーム内タスク一覧なるものを公開して、誰にどれだけタスクが積まれていて、誰がいつから空くかを見えるようにしてみました。
そしたら、チームメンバーにも恵まれたことも大きくありましたが、
誰々がぱつってるからその人の未来のタスクを他の人に棚卸しできたり、
技術的負債タスクを自主的に拾ってくれたりするようになりました。
また、他セクションからとある機能に関する質問とかが、担当していないエンジニアにきた際、「その機能は今〇〇さんが実装してますよ」とリーダーが答えなくても、メンバーが先に答えてくれていたりするのは地味にリーダーは助かりますw（なぜならリーダーはメンションがひっきりなしにとんでくるポジなのでw）
--
以上です。
つらつらと５つ挙げてみました。
何かの参考になれば幸いです。