IT liderleri karar vericiler olmaları için takımları nasıl yetkilendirir?

Yöneticilerin çoğu konu karar vermeye ve eyleme geçmeye geldiğinde ekip üyelerinin her zaman yönlendirme beklemek yerine daha proaktif olmak için kendi başlarına daha fazlasını yapmasını ister. Eğer bu tür sonuçlar arayışında olan bir yöneticiyseniz, o zaman büyüyen bir ağacın dört bölümünü temel alan basit bir araç olan “Karar Ağacı” modelini kullanabilirsiniz.

Basit bir karar modelini kullanmanın iki yararı bulunuyor. Bunlardan bir tanesi insanları rolleri dahilinde yapabilmeleri gereken her şeyi yapabilmek için gereken güçle bağlamak içindir. İkincisi ise herkes için, kim neden sorumlu veya kiminin hangi yapıdaki kararları verme yetkisi olduğunu açıklığa kavuşturmak içindir.

RACI adlı bir diğer karar modeli bir süreç tabanlı modelde dört çekirdek rolü temsil eder; Sorumlu, hesap veren, danışma ve bilgi veren. Süreçler etrafındaki kararlarla uğraşırken, RACI sistemi oldukça faydalıdır. İnsanlar etrafındaki kararlar hakkında konuşurken ise kararın etkisine bakan daha basit bir şey ve kararın gözden geçirilmesi potansiyeli, bize daha faydalı bir iskelet sağlar.

Karar ‘tipi’ iskelet
Bu iskelet için kökleri, onu destekleyen gövdesi, ikincil yapılan olan dalları ve bu dallar üzerindeki yaprakları bulanan bir ağaç benzetmesi yapılabilir. Dolayısıyla elimizde kökler, gövde, dallar ve yapraklar var.

Etki açısından bir ağaç yapraklarını kaybedecek olursa, bu genellikle küçük bir etkidir. Peki hangi karar ve seçimler bir ağaçtaki yapraklarla kıyaslanabilir; ya eğer birisi hatalı veya optimal olmayan bir karar verecek olursa bunun etkisi nispeten küçük müdür ya da nötr müdür?

Bir ağaç sıklıkla nispeten küçük etkilerle çok sayıda dalını kaybedebilir. Tartışmasız olarak ana dallara sahip olan gövde var. Eğer ana dallardan biri yarılır veya gövdenin kendisi yarılırsa, bu ağacın sağlığı için ölümcül olabilir. Son olarak ağacın kendisinin temel dayanağı olan kökler var. Köklerin bütünlüğünü tehlikeye atan herhangi bir şey ağacın ölümüyle sonuçlanır.

Pratik uygulama açısından ilkin insanlarının sahip olduğu rol ve sorumluluk türlerine bakın. Güvenlik liderinize, uygulama liderinize, altyapı liderinize vs. bakın.

Bu alanların her biri içinde, temel olan karar türleri olacaktır ki bu da bir hatayı tolere edemeyeceğiniz kökler oldukları anlamına gelir. Ardından bir ya da iki hatayı tolere edebileceğiniz (ancak etkisi kayda değer olabilir ve düzeltmek zaman alabilir) gövde ve ana dal türünden kararlar mevcut.

Sonrasında dallarla ilgili kararlar var ki burası insanlara çok daha fazla tolerans verebileceğiniz yerdir. Ardından yapraklara benzeyen kararları ise gerçekten bilmeniz dahi gerekmez.

Dal seviyesindeki kararları muhtemelen bilmek isteyeceksiniz ama onaylamanız gerekmez. Gövde kararlarını ise bilmeniz ve onaylamanız gerekir fakat planlamak ve çözmek için çok fazla zamana ihtiyacınız olmayabilir. Kök seviyesindeki kararlar ise sıklıkla sizin vermeniz gereken veya planlamada yoğun bir biçimde dahil olmanızın gerektiği kararlardır.

Farklı karar seviyelerinin etkisi

Bu, kararın etki seviyesine bağlı olarak her bir çalışanınızın verme fırsatına sahip olduğu türden kararlara bakmanın basit bir yoludur. Diğer bir faktör bu kararların yeniden incelenebilmesi, hatta tersine çevrilebilmesindeki kolaylıktır.

Yaprak seviyesindeki kararlar genel olarak fazlasıyla düzeltilebilir çünkü onların etkisi nispeten küçüktür. Bilmek istediğiniz ama onaylamanız gerekmeyen dallar da tipik olarak düzeltilebilir veya tersine çevrilebilir.

Örnekler bir program tasarım kararı veya bir iç toplantıda ele alınan fonksiyonel bir pozisyon olabilir. Bu tür kararların çoğu emsallerle birlikte çalışılarak içeride verilir. Birkaç gün içerisinde bunları ortaya çıkarmak zorunda olduysanız ve bu tür bir karar hakkında herhangi bir sorun ya da endişeniz olduysa, dahil olan grubu tekrar bir araya getirmek, yeniden araştırmak ve belki kararı tersine çevirmek güç olmamıştır.

Bunu çalışanlarınızın IT organizasyonu dışında, belki bir iş birimindeki kıdemli insanlarla çalıştıkları zamanla karşılaştırın. Burada eğer sizi ilgilendiren bir kararı birkaç gün sonra öğrenirseniz, bunu tersine çevirmek ilişkilerinizin gücüne ya da söz konusu iş biriminin almış olabileceği takip eden kararlara bağlı olarak daha güç olabilir.

Bu gibi örneklere bakarak, önemli kaynakları tersine çevrilemez biçimde işlemedikçe, kurum içi kararların dal seviyesi kararlar olduğunu söyleyebiliriz. Tersine çevrilemez önemli kararları işleyen kurum içi kararlar, söz gelimi bir tedarikçi kontratı, gövde seviyesi kararlar olabilir.

Diğer paydaşlarla organizasyon dışında alınan kararlar veya pozisyonlar da gövde seviyesi olabilir. Ve uzun vadeli kontratlar, büyük satın almalar, strateji taahhütleri, kendiniz için rezerve etmek isteyebileceğiniz kök türünden kararlara örnek olabilir.

Bir karar onayını, bilgilendirme ilkesini saptamak

Dal seviyesi kararlara gelindiğinde, her ne kadar onaylamanız gerekmese de, bunların yapıldığı zamanda bilgi sahibi olmanız gerekir ve çalışanlarınızın da sizin onları bildiğinizi temin etmesi gerekir. Bu takip edilmesi gereken kritik bir nokta.

Dal seviyesi kararlar hakkında çalışanlardan gelen e-postalar diğer e-posta yığınları içinde kaybolabilir ve yöneticiniz tarafından zamanında görülemeyebilir. Bu yüzden ikinci bir teyit mail’i göndermek veya ilk mail’i öncelikli olarak işaretlemek elzemdir. Bir başka yöntem de yöneticinizin ofisine giderek güncel bir kararla ilgili ayrıntılı bir e-posta gönderdiğinizi kendisine hatırlatmaktır. Böylelikle kararla ilgili herhangi bir soru işareti veyahut endişe olması halinde bu mümkün olduğunca ivedi bir biçimde, onu tersine çevirme önemli bir sorun olmadan önce, çözülebilir.

Bir kez bu türden bir modeli uygulamaya karar verdiğimizde, bir sonraki adım onu yorumlamak ve onların ortamına göre özelleştirmek için çalışanlarınızla bir araya gelmektir. Bu astlarınızdan her birine verdikleri kararların, örnekleriyle birlikte, dört farklı seviyesini inandıkları şekilde tanımlamalarını isteyerek başlayabilir. Kolektif olarak modelin gerçekte neye benzediğini görmeye başlarsınız ve buradan itibaren değişiklikler ya da düzenlemeler için işbirliği yapabilirsiniz.

Bu size içinde çalışacağınız bir başlangıç iskeleti sağlar. Çalışmanın bu şekilde olduğunu, onu efektif yapan şeyin yinelemeli bir süreç olduğunu varsayın ve bu insanlar meseleleri farklı yorumlayacak ve bazı hatalar yapacaklar.

Söz gelimi, insanlarınızdan birisi bir karar verir ve onlar bunun bir yaprak kararı olduğunu varsayarak sizi bilgilendirmezler. Bunu birkaç gün sonra fark edersiniz ve, “Hmm, bunu gerçekten bilmek isterdim.” dersiniz. Birlikte oturduğunuzda o “Ben bunun bir yaprak kararı olduğunu düşündüm çünkü…” diyebilir. Siz de ardından, “Bu durumda her ne kadar bunu onaylamam gerekmese de bu türden bir şeyi hemen bilmek isterim,” diyebilir ve bunun nedenlerini tartışabilirsiniz. Bu iskelet ve süreçle birlikte birbirinizden bir şeyler öğrenirsiniz ve bu kararların gerçekte ne olduğu etrafında birbiriniz arasında paralellik oluşturursunuz.

Bu aynı zamanda çalışan toplantılarınız için bir iletişim iskeleti halini alabilir. Takım üyeleriniz için bu, toplantılarda hangi bilgilerin paylaşılması gerektiğine ve hangi sorun ya da kararlarda takımının bir araya gelmesi gerektiğine karar vermelerinin bir yoludur.

Kolektif olarak yapmanız gereken kararlar gövde kararları olabilir. Kolektif olarak vermeniz gerekmeyen ama herkesin farkında olması gereken kararlar dal kararlar olabilir. Ve ardından normalde her bir departman içinde kalan günlük operasyonel kararlar olduklarından, yaprak kararlar bu toplantılara gelmemelidir.

IT operasyonlarını örnekleme olarak kullanmak: Standartlar kök veya gövde kararları olma eğilimindedir ki ikisini de sizin vermeniz ya da onaylamanız gerekir. Tüm astlarınızın karar verme sürecine dahil olması gerekir çünkü standartları ayarlamak herkesi temel bir düzeyde etkiler.

Diğer taraftan ürün seçimi, ürün seçimi bu standartları temel aldığı sürece, bir dal kararı olarak düşünülebilir. Herkesin onu bilmesi gerekir ancak onaylama veya karar süreci içerisine tümden dahil olmaları gerekmez; tüm departmanlar çapında kullanılacak bir araç olduğu ortaya çıkmadıkça.

IT uygulama geliştirmeyi örnekleme olarak kullanmak: Eğer kaynak kodun bakım ve geliştirmesi için araçlar satın alıyorsanız, muhtemelen yürütmedeki iş arkadaşlarınızdan onaya ihtiyaç duymazsınız. Diğer yandan eğer performans görüntüleme için kullanılacak bir aracı seçiyor ve her bir fonksiyonun aynı aracı performans görüntüleme için kullanmasını istiyorsanız, o zaman bu daha çok herkesin onaylaması gereken bir gövde kararı gibi görünür.

Yukarıdaki kararların ve örneklerin çoğu IT organizasyonunun üst seviyelerini hedef alıyor. Ancak aynı model organizasyonun tüm seviyelerinde kullanılabilir. Her seviyeden takım liderleri Kök, Gövde, Dal ve Yaprak türünden kararlarını tanımlayabilir. Ardından onlar kimin hangi karar hakkına sahip olduğu üzerinde anlaşmak, daha fazla karar verme sorumluluğu üstlenmeleri için onları yetkilendirmek üzere takım üyeleriyle çalışabilir.