經營技術
經營技術是說，不要只是把做產品/項目的過程當作完成任務或提升自己能力的過程，而是要當作爲企業積累技術的過程。
這聽起來很容易，但做起來有難度，比如這幾個問題：
1. 團隊是否有一個可複用的技術庫？（DLL，類，函數，各種層面的）
2. 團隊是否有一個機制令得這些庫被充分利用？（一個可度量指標就是代碼行/功能點，越低越充分）
……
一般而言若不進行有效管理，20人團隊的代碼冗餘率可能在95%左右，也就是95%左右的代碼是多餘的。在2004年的一次技術改造中，一個19萬行，13人×9年的產品，被改造爲1.3萬行，1人×1.5年的相同產品（更關鍵的是缺陷少了，這次改造的直接動因就是原來產品的缺陷衆多而且隱藏很深）。
這並不是個例：這家公司是納斯達克上市的上千人的電信軟件公司，其開發和管理強於一般的中小公司，後者的技術水平可能更差。但由於普遍而言人們使用別人代碼的比例很低（我們常常感覺到用過別人的東西，但若自己數數，又會發現不過就幾百行代碼而已），所以人數越多可壓縮的比例越高；再加上由於多數人連自己的複用做的也不好，所以在未完善管理的情況下，對代碼進行大規模壓縮的潛力一般都接近在2×人數倍以上。
注意這個例子中，較少的代碼不但有更高的生產率，質量也隨之提高，甚至更加明顯。
類似這種規模和週期的軟件及團隊，都應該刻意地在開始就不要只以完成當前任務爲唯一目標，而開始架構和積累整個技術架構。
“若剛開始的時候老闆不給充分的時間怎麼辦？”一則我從來沒有見過老闆指着我們的可複用庫說：“不要編寫這個，直接給我壘代碼”；二則及時被給予足夠的時間，多數團隊也沒有形成這樣的可複用庫；三則可複用庫的生效速度是很快的，若前三個月投入複用的時間還沒有賺回來，那麼多半做錯了……考慮到這些，多數時候缺少對技術的經營，其實是我們軟件人員自己的問題。
經營過程
過程就是人們做事的方法，說大一些，就是“企業文化”。
文化是很容易被談論又很容易被忽視的東西。很多底層的程序員能看到遠在天邊的企業文化，但卻看不清楚自己面前的編碼文化。
在2001年的一個團隊裏邊（就是我第一次感受鬆結對編程與139團隊的那個團隊），剛開始只有5個人，人們不需要專業的測試人員而仰賴高手幫助新手查看代碼和自己自主測試來保障質量；一年以後，當團隊擴張到25個人的時候，這個傳統仍然存在——此時我們的專業測試人員只有2個，而且只負責整體測試。
這是因爲在團隊成立的開始，團隊嘗試建立起一種以高質量爲榮的團隊文化，所有制造大量的缺陷程序員（包括剛開始時的我本人），都會同時受到鄙視和幫助，人們可以選擇接受兩者，或者只接受前者。結果是接受幫助的人逐漸擺脫了被鄙視的局面，他們繼承了這種傳統，進而幫助後來的新人。
可以被經營的過程有很多，有很多完全無需領導授權即可進行，另一些需要在進行一定程度後說服領導進行下一步的支持。這些過程包括：
1. 代碼審查
2. 開放的辦公室空間
3. 白板和經常的討論會
4. 基於白板的簡單設計（比如預想陳述）
5. 看板
6. 鬆結對編程
7. 1-3-9團隊
……
誰來經營
“如果老闆能讓我放手管理，我也可以經營好我們的團隊。可是……”這是常常聽到的一句話。
實際上，老闆一般都是“放手”管理的。多數團隊的領導者（尤其項目經理）與自己團隊相處的時間，超過再上一級的100倍。若這些時間——其實應該說是精力——被充分用來經營團隊，而不是簡單地執行傳聲筒和工頭的角色，本文所說的經營完全可以實現。