Bir ekip üyesinin “Bu iş tıkandı” demesi bazen doğru bir teşhistir. Fakat yöneticinin masasına gelen cümle burada kalırsa, ekipte iki kötü alışkanlık gelişir. Biri, her güçlüğün yukarıya taşınmasıdır. Diğeri, gerçekten yetki gerektiren meselelerin de aynı dağınık dil içinde beklemesidir.
Yöneticinin görevi her engeli kendi çözmek değildir. Ekip hangi kararı kendi verebildiğini, sınırın nerede bittiğini ve sınır aşıldığında kimden ne isteyeceğini bilmelidir. GOV.UK'nun çevik hizmet yönetişimi rehberi de ekiplerin karar yetkisini ve bu yetkinin sınırlarını bilmesini; sınırın dışındaki yardımın sorumlusunun açık olmasını ister. Bu, büyük projelere özgü bir idari ayrıntı değil. Günlük işte geciken bir onay, başka ekibin ayırmadığı zaman ya da iki hedefin aynı haftaya yığılması için de geçerli.
Ben yöneticinin engel bildiriminden önce üç soru istemesini yararlı buluyorum: Hangi iş durmuş durumda? Ekip kendi yetkisiyle hangi yolu denedi? Yöneticinin seçmesi gereken seçenek nedir?
İlk soru, sıkıntının adını ayırır. “Operasyon destek vermiyor” bir şikâyettir. “Müşteri geçişi için gereken erişim açılmadı; bu yüzden cuma günkü deneme başlayamıyor” ise işin sonucunu ve zamanını söyler. Sorunu bu kadar dar kurmak, karşı tarafı suçlamaktan çok kararın etkisini tarif eder.
İkinci soru, yöneticinin tekrar iş vermesini önler. Ekip erişim talebini açtı mı, alternatif veri kaynağını denedi mi, işi bölmeyi değerlendirdi mi? Bu bölüm bir savunma metni değildir. Yönetici, elindeki yetkiyle çözülmüş bir işi yeniden toplantıya çağırmamalı. Öte yandan ekip de ilk zorlukta “karar bekliyoruz” diyerek kendi hareket alanını kapatmamalı.
Üçüncü soru benim için belirleyici. Engeli anlatan not, yöneticinin seçebileceği yolu içermezse yönetici önce sorunu anlamaya, sonra seçenek toplamaya, en sonunda karar vermeye çalışır. Bu sıralama yöneticinin kararını geciktirir.
Örneğin not şunu diyebilir: “Cuma günkü denemenin başlaması için ya bilgi güvenliği onayı bugün 15.00'e kadar tamamlanacak ya da deneme iki hafta ötelenip müşteri bildirimi satış ekibi tarafından yapılacak. İlk yol için sizin bilgi güvenliği yöneticisiyle öncelik konuşmanız, ikinci yol için erteleme kararını onaylamanız gerekiyor.” Bu cümle yöneticiyi teknik ayrıntının sahibi yapmaz. Onun seçmesi gereken takası açıklar.
Association for Project Management, ortaya çıkan sorunun kayda alınmasını, neden ve etkisinin hızla değerlendirilmesini; çözüm için en uygun kişiye eylem verilmesini ve gerekirse sponsor düzeyine taşınmasını öneriyor. Aynı kaynak, yetki sınırı aşıldığında değişikliğin resmî karar yoluna girmesi gerektiğini de hatırlatıyor. Ben buradan daha küçük bir yönetim sonucu çıkarıyorum: Yöneticinin önüne gelen engel, “birileri ilgilensin” biçiminde kalmamalı; kararı veren kişinin kullanacağı yetkiyi tarif etmeli.
Bu kayıt, ekipteki sorumluluğu yöneticinin üstüne boşaltmak için kullanılmamalı. Yönetici seçeneklerden birini seçtiğinde, uygulama sahibi, yeni tarih ve ilk bildirim de aynı notta yer almalı. Aksi halde engel çözülmüş sayılır; işin sonraki adımı yeniden belirsizleşir.
Her engel için üç seçenek hazırlamak da doğru olmaz. Bazı konularda güvenlik, hukuk ya da çalışan sağlığı nedeniyle ekip doğrudan resmî sürece başvurmalıdır. Bazılarında ise yönetici önce ekibe bilgi, zaman ya da uzman desteği sağlamalıdır. CIPD'nin yönetici destek materyali, yöneticinin engelleri tanıyıp aşma yolları geliştirmesini; kendi üst yönetiminden gelen çelişkili yönlendirmelerde talimatı yazılı biçimde netleştirmesini öneriyor. Buradaki dikkat, çalışanı yalnız başına dayanıklı olmaya çağırmak değildir. Yönetici çözümün hangi parçasını üstleneceğini söylemelidir.
Benim küçük önerim, engel bildirimlerinin sonuna tek bir satır eklemek: “Yönetici kararı: …; uygulama sahibi: …; yeni kontrol zamanı: …” Bu satır, her sorunu büyütmez. Yöneticiye hangi seçimi yapacağını, ekibe de karar çıktıktan sonra hangi işi yürüteceğini verir.
