而對於技術性的係統或框架，通常會召集這方麵的專家開會，介紹新係統，並討論為什麼做這個係統，以及其優缺點、跟已有係統的關聯。這種討論會，相對技術性比較強，一般不會有產品經理參與（他們不大懂後台的技術），更多的是邀請有相關經驗的後台工程師參加。比如，我們反欺詐組在構建機器學習模型時，就邀請了數據科學家（Data Scientist）、反垃圾信息（Anti-Spam）組裏麵經驗豐富的機器學習專家來參與技術研討會（Technical Review）。邀請什麼樣的人參加會議非常重要。因為人多了，可能無法進行有效果、有效率的討論；人少了，則又可能錯過一些可以借鑒的經驗。在這種時候，我作為研發經理，就要積極地給具體負責的工程師多一點幫助，參加技術會議，幫他尋找合適人選，甚至由我出麵邀請專家參與。
這種討論最重要的目的就是利用Facebook優秀的技術資源，把最相關的、合適的人包括進來，保證一個係統沒有大的設計缺陷，使得潛在的瓶頸一開始就盡可能地被發現，而不要等到後來才發現，那樣太被動。但Facebook最注重實踐的反饋，在做完一些限定時間內必要的論證之後，就會開始進入實現工作。一般最多進行一次或者兩次技術研討會，不會讓對設計的討論無休無止地進行下去。
這裏要特別強調的一點是，Facebook非常注意不重複開發新的技術係統。一個原則是：有好的開源係統，就用開源的；有好的商用產品，就購買商用的；必須自己開發的或者跟Facebook核心競爭力息息相關的，則集中力量開發一套，而不是重複勞動，開發多套類似係統。
對於開源係統，隻要有一個優秀的、活躍的開發社區在維護，Facebook就會積極地利用並且毫不吝嗇地給予反饋。這方麵最好的例子就是Memcache係統。Memecache允許多台機器共享內存以出現超大的網絡緩存池，作為前端服務器和後台數據庫之間的一個緩衝地帶，可以極大地提高對用戶訪問的響應速度。Memcache一開始在Livejournal（一個博客網站）上開發，後來，Facebook采用之後又做了大量的後續開發，並成為這一係統最大的使用者。所有應用Memcache的網站，實際上都從Facebook及其他技術人員的開源工作中受益良多。此外，類似的例子還包括hadoop（一個分布式係統的基本出架構，由Apache基金會開發），給予Map-reduce 的大規模並行處理係統，等等。
而對於一些跟核心數據息息相關的係統，即使市場上有商用係統，Facebook還是決定自己開發。比如，我們剛開始做反支付欺詐的時候，就在購買外部軟件和服務還是自己開發之間反複討論過，最後還是決定自己做。一方麵，當時的思路是想在社交平台上建立一個通用的支付流程，使用別人的反欺詐服務就必須將必要的支付和用戶私人數據傳給服務商，這將在數據安全上產生隱患，也不利於Facebook自己去積累打造安全可信的支付環境所必需的技術能力。另外一方麵，傳統的反欺詐主要針對用戶的財務行為和數據進行分析，從沒有人嚐試利用社交數據來打造安全可信的支付環境，而Facebook作為全世界最大的社交網絡，是第一家有能力、有機會進行這方麵嚐試的公司，我們不想放棄這麼一個有可能創造曆史的機會。所以，最後決定自己組建團隊去開發。
另外，Facebook從不期望由一個人去完成某個項目所有的事情。我會要求某個組員來承擔某個項目的責任，但要的是讓他驅動整個項目，並不代表所有的事情都完全靠他個人去做。我會要求他善於使用整個公司的力量，學會積極主動地獲得別人的幫助，事半功倍地完成一個項目，同時在這個過程中獲得成長。如果讓其他組幫助做一些事情更加適合的話，我也會鼓勵朝這個方向努力。比如，我們組經常在工具組開發的工具框架上進行二次開發，然後發現有些功能可能更加適合在框架上直接實現，我就會鼓勵組員去說服工具組來進行這種開發。又比如，我們對某種大數據處理之前都沒什麼經驗，那可能做出來的東西就不夠紮實，有可能會犯一些不必要的錯誤。要避免這種情況，就可以去大數據處理組獲得相應幫助，尋求適當的指導。我也經常鼓勵項目負責人來指揮我替他做事，隻要這些事情的確能幫他完成任務，而且合情合理。