Biraz daha az konuşma

Ne zamandı En son ne zaman bir toplantı planladınız ve sırf kimsenin dışlanmış hissetmesini istemediğiniz için gerçekten orada olması gereken üç kişi yerine sekiz kişiyi davet ettiniz?

En son ne zaman şirket genelinde 'Hey, dikkat kahve içenler: Demliği bitirirseniz bir tane daha yapın!' gibi bir e-posta gönderdiniz. Bu kuralı ihlal eden tek bir kişi olsa bile (ve o sizin kurucu ortağınız)?

En son ne zaman yeni broşürün renk paleti üzerinde, broşürle hiçbir ilgisi olmayan ama turuncuyu sevmediğini bilen bir programcıyla uzun uzun tartıştınız?

Bunlar yaygın bir hastalığın belirtileridir: çok fazla iletişim .

Artık hepimiz iletişimin çok önemli olduğunu ve birçok organizasyonel problemin iletişim eksikliğinden kaynaklandığını biliyoruz. Çoğu insan bu sorunu iletişim miktarını artırarak çözmeye çalışır: herkese bir e-postada cc'lemek, uzun toplantılar yapmak ve tüm personeli davet etmek ve bir kararı uygulamadan önce herkesin iki kuruşunu istemek.

Ancak iletişim maliyetleri, özellikle daha büyük ekiplerde düşündüğünüzden daha hızlı artar. Eskiden bir garajda birbiriyle her şey hakkında konuşan üç kişiyle çalışan şey, kafa sayınız 10 veya 20 kişiye ulaştığında işe yaramaz. O toplantıda olması gerekmeyen herkes üretkenliği öldürüyor. Bu e-postayı okuması gerekmeyen herkesin dikkati dağılıyor. Bir noktada, aşırı iletişim verimli değildir.

Bu, hızlı büyüyen start-up'lar için özellikle sinsi bir problem. Gerçekten küçükseniz ve yeni başlıyorsanız, o kadar çok insanınız olmaz, bu yüzden herkesi her şey hakkında döngüde tutmak o kadar fazla zaman almaz. Ancak büyüdükçe, herhangi bir tartışmaya potansiyel olarak dahil olabilecek kişilerin sayısı artar ve şirket olarak yaptığınız işlerin miktarı artar ve fazla iletişim kurmak için harcayabileceğiniz zaman ciddi bir sorun haline gelir.

Şirketler genişledikçe, içindeki insanlar uzmanlaşmaya başlar. Böyle bir noktada bazı yöneticiler 'herkesi aynı sayfada tut' sorunu yaşadıkları sonucuna varacaklardır. Ancak çoğu zaman gerçekte sahip oldukları şey, 'zaten bir şey üzerinde çalışan yeterince zeki insan varken insanların karışmasını engellemek' sorunudur.

Muhasebe'deki Bob'un yeni reklam kampanyasının fotoğrafçılığı hakkında söyleyecek yararlı bir şeyi olmadığı anlamına gelmiyor. Evet, Bob'un güzel sanatlarda yüksek lisansı var. Evet, Bob amatör bir fotoğrafçı. Ve belki de pazarlamadaki insanlardan bile daha iyi bir zevki vardır. Yine de Bob, pazarlama müdürüne ne yapması gerektiğini söylememeli çünkü bu verimli değil. Aslında, son derece verimsiz.

Örgütler içindeki aşırı iletişimin maliyeti Fred Brooks tarafından 1975'te yayınlanan kitabında ete kemiğe bürünmüştü. Efsanevi Adam-Ay . Brooks, IBM'de OS/360 projesinin yürütülmesine yardımcı oldu ve şirketin ana bilgisayarları için dev bir işletim sistemi kurdu. O günlerde bilgisayarlar büyük, oda boyutunda, su soğutmalı, bazen 256.000 baytlık devasa bir ana belleğe sahip makinelerdi. OS/360 muhtemelen o zamana kadar denenmiş en büyük yazılım projesiydi. ve öyleydi anıtsal olarak geç.

Projenin bazı yönleri zamanlamanın gerisinde kaldığında, IBM bu göreve birkaç kişi daha atadı. Ve Brooks'un insanları hala şaşırtan fark ettiği şey, bunun işe yaramadığıydı. Onun gözlemi Brooks Yasası olarak bilinir hale geldi: Geç bir projeye insan eklemek, onu daha sonra da çalıştırma eğilimindedir.

Bu cümleyi tekrar okuyun, çünkü sezgisel değil. Brooks, bir projeye insan eklemenin onu programın gerisinde .

Nasıl olabilir? Bir ekibe yeni bir kişi eklediğinizde, o kişinin ekipteki diğer tüm kişilerle iletişim kurması ve koordine etmesi gerekir. Bu önemli bir şey gibi görünmüyor, ama öyle. Yeni çocuk neler olup bittiğini bilmiyor, bu yüzden takımdaki başka biri -- daha geçen hafta üretken iş yapan biri -- işini durdurmalı ve bu acemiye ipleri göstermelidir.

Takım ne kadar büyükse, o kadar kötü olur. Tek kişilik bir ekibiniz olduğunda, iletişim gereksiniminiz yoktur. Yok.

İkinci bir kişi ekleyin ve şimdi tek bir bağlantınız var: Adem ve Mary arada bir birbirleriyle konuşmak zorundalar.

Şimdi üçüncü bir kişi ekleyin, diyelim ki, Srinivas ve Srinivas'ın Adam ve Mary ile konuşması gerektiğinden, birden bir bağlantıdan üçe geçtik.

Dördüncü bir kişi ekleyin. Burada bana yardım edecek isimler tükeniyor -- Tamam: Britney. Onu eklersek ve hepsiyle koordine olması gerekiyorsa, altı bağlantınız olur.

Matematiksel olarak eğimli olanlar için formül şudur: Ekibinizde n kişi varsa, (n^iki-n)/2 bağlantılar. Bu çizelge bunun nasıl bir sorun haline geldiğini göstermektedir:

Görebildiğiniz gibi, iletişim maliyetleri oldukça hızlı bir şekilde yükselmeye başlar, ta ki büyük ekiplerde herkesin yapabileceği tek şey diğer herkesle koordineli çalışmaktır -- ve hiç kimse hiçbir işi bitirmez. 2006'da, Microsoft'ta eski bir programcı olan Moishe Lettvin, Windows Vista'daki bir menüde - bilgisayarınızı kapatmak için kullandığınız menüde - yer alacak öğelerin listesini koordine etmek için harcadığı yılı anlatan bir blog yazısı yazdı. (Görmek Windows Kapatma Crapfest .) Lettvin, bu menünün tasarımında 43 kişinin hepsinin söz sahibi olduğunu anladı. Kırk üç! Brooks'un formülüyle bu, 903 bağlantıyı yönetmek anlamına gelir. Lettvin, koordinasyon görevlerine o kadar çok zaman harcadığını ve 12 ayda 200 satırdan daha az kod ürettiğini söylüyor.

Patron olarak, iletişim yollarını azaltmanın yollarını tasarlamanız gerekir. Şirket çapındaki e-posta listelerini ortadan kaldırın - ya da en azından onlara göndermek için 1,50$ ücret alın. Büyük toplantılar yapmayı bırakın. İnsanların bir toplantıya dahil olmadıkları için gergin olmadıkları bir kültüre ihtiyacınız var, bu da insanları işlerini yaptıkları için ödüllendiren ve diğer insanların işlerine karışmaktan çekinmeyen bir kültüre ihtiyacınız olduğu anlamına geliyor.

Ve her projede, iletişimin gerçekleştiğinden emin olmak için bir kişi atayın - ancak yalnızca doğru iletişim. Aksi takdirde, ekip oradaki herkesle uzun toplantılar yapmaya başlayacak ve açıkçası, insanlar sosyalleşecek, şişirecek, konuşacak ve gerçekten umursamadıkları şeyler hakkında sadece kendi seslerini duymak için tartışacaklar.

Sanırım bu, 1950'lerin eski yönetim tarzının yanlışlıkla bir şeyleri doğru yaptığı vakalardan biri. General Motors tarzı şirketlerde, en azından, doğru cevabın organizasyondaki her bir kişinin ihtiyacı olmadığının bir nebze olsun farkında olduğunu gösteren düzgün, düzenli organizasyon şemalarında yukarı ve aşağı hareket etmek için bilginin nasıl gerekli olduğu konusunda bir fikirleri vardı. her şeye dikkat et.

Şirketinizi kurduğunuzda, muhtemelen iletişim kurma konusunda harika bir iş çıkardınız. Herkes birbirine her şeyi anlattı. Müşterileriniz buna bayıldı çünkü satın alma siparişlerini sormak için aradıklarında herkes siparişin nerede olduğunu biliyordu. Ancak büyüdükçe, herkese her satın alma siparişi hakkında bilgi vermeye devam edemezsiniz, bu yüzden tam olarak doğru kişilerin öğrenmesi ve başka kimsenin öğrenmemesi için belirli iletişim sistemleri icat etmeniz gerekir. Gizli olduğu için değil. Çünkü zaman kaybı.

Joel Spolsky, Fog Creek Software'in kurucu ortağı ve CEO'su ve popüler Joel on Software blogunun ev sahibidir. Sütunlarının bir arşivi için şuraya gidin: www.inc.com/author/joel-spolsky .