IT liderliğinde net konuşmanın gücü

Liderlik iletişiminde ifadelerinizi keskinleştirmek için harcayacağınız ek zamanı, yanlış anlamaları azaltarak aslında defalarca kez geri kazanabileceğinizi biliyor muydunuz?

Çoğu lider, günün koşturmacasında “şimdi detayına girmeyeyim” der ya da “herkes zaten ne demek istediğimi anladı” diye varsayar. Fakat IT ekipleriyle çalışan herkes bilir: En basit cümledeki küçük bir belirsizlik, günlerce sürecek karmaşaya neden olabilir.

Bazen “otoriter görünmeyeyim”, bazen “kontrolü vereyim” diye düşündüğünüz için bazen de “çok da önemli olmayabilir” diyerek “keskinleştirmediğiniz” iletişiminiz, ekibinizin iş çıktılarına olumsuz etkiler yaratabilir. Çünkü teknoloji ne kadar karmaşık olursa olsun, iletişimdeki gri alanlar her zaman en pahalı “bug”lardır.

Bir yazılımcıyla konuşurken “bu taskı gecikmeden bitirir misin?” dediğinizde, gerçekten ne söylemiş oluyorsunuz?

Sizin için “sprint bitmeden” anlamına gelebilecek olan o kelime, onun zihninde “yarınki scrum toplantısına kadar” demek olabilir. Ve işte, henüz farkında bile olmadan, minik bir yanlış anlaşılma projenin kaderini değiştirebilir.

Ben yıllardır IT ekipleriyle çalışan biri olarak şunu gördüm: Kod satırlarında netlik arıyoruz ama cümlelerimizdeki gri alanları pek umursamıyoruz. Oysa çoğu proje krizi, teknik hatalardan değil “kim neyi ne zaman yapacaktı?” sorusuna verilen farklı cevaplardan çıkıyor.

Netleştirmenin sağladığı 3 büyük kazanç

İletişimdeki belirsizliği ortadan kaldırmak, yazılım dünyasının belki de en az konuşulan “refactor” projesidir. Ve bunu yaptığınızda üç önemli şey olur:

1. Yanlış anlamalar ortadan kalkar

“Bu API’ı sağlam yap” dediğinizde herkesin kafasında farklı bir “sağlam” tanımı olabilir. Bir yazılımcı için “güvenli bir API”, diğeri için “performanslı bir API”, bir başkası için ise “kodu okunabilir bir API” anlamına gelir.

Ama şöyle derseniz: “Saniyede 1000 isteği 100ms altında yanıtlasın ve %95 test kapsamına sahip olsun.”

Beklenti keskin ve net olur, kimse kafasında yeni bir senaryo yazmaz, projeler hızlanır, hatalar azalır.

2. Geri besleme daha yapıcı hale gelir

“Bu kod çok karmaşık olmuş” gibi belirsiz bir cümle, karşı tarafta sadece savunma duygusu yaratır.

Ama şöyle dediğinizde: “Bu fonksiyondaki iç içe geçmiş if-else blokları okunabilirliği düşürüyor, switch-case ya da polymorphism ile sadeleştirebilir miyiz?”

Eleştiri bir saldırı değil, iyileştirme önerisi olur. Bu tarz cümleler, ekip içinde güven duygusunu artırır ve geri bildirimi korkulan bir şey olmaktan çıkarır.

3. Daha iyi kararlar verirsiniz

Bir toplantıda “daha modern bir framework seçelim” dediğinizde, herkes kafasında başka bir şey hayal eder. Birine göre “modern” react’tır, diğerine göre svelte, başkasına göre ise “daha az kodla daha çok iş yapan” herhangi bir teknoloji. 

Ama şöyle sorduğunuzda: “Modern derken topluluk desteği mi, performans mı, öğrenme kolaylığı mı?”

Kararlar varsayıma değil, ölçülebilir kriterlere dayanır.

Bir diyalog: DevOps görüşmesinde kaçırılanlar

Geçen yıl bir ekip, kritik bir DevOps pozisyonu için aday görüşmesi yaptı. Görüşmeden sonra toplantı odasında şöyle konuşuldu:

  • Yönetici: Evet arkadaşlar Murat’la görüştük, ne düşünüyorsunuz?
  • Dilara (Takım Lideri): Genel olarak iyiydi ama kültürümüze çok uyumlu gelmedi.
  • Yaprak (Kıdemli Yazılımcı): Benim içim ısınmadı, biraz soğuktu, enerjisi düşük geldi.

Bu noktada çoğu lider “Peki o zaman, sonraki adaya bakalım” deyip geçer. Ama ya Murat aslında aradıkları en teknik adaysa?

Aynı konuşmayı biraz “netleştirme” ile yönettiğinizi hayal edin:

  • Yönetici: “Kültüre uyumsuz” derken neyi kastettin? İş yapma biçimi mi? Davranış modeli veya değerlere uyumu mu? 
  • Yönetici: “İçim ısınmadı” derken hangi davranışı fark ettin? Heyecan eksikliği mi yoksa iletişim tarzı mı?

Birkaç basit soru, soyut hisleri somut gözlemlere çevirir. Belki Dilara aslında adayın waterfall alışkanlıklarından bahsetmek istiyor. Belki Yaprak, “soğuk” derken sadece biraz çekingen olduğunu kastetti. Bu açıklık, ekibin adil ve doğru bir karar almasını sağlar.

IT dünyasında duyduğumuz gri kelimeler

Hepimiz bu cümleleri duymuşuzdur:

  • “En kısa zamanda halledelim.” (Bir saat mi, gün sonu mu?)
  • “Hızlıca bir göz at.” (5 dakikalık bakış mı, detaylı analiz mi?)
  • “Güzel bir refactor yap.” (Performansı mı artır, okunabilirliği mi?)
  • “Sunucuyu birazdan ayağa kaldıracağız.” (Bugün mü, hafta sonu mu?)

Bu kelimeler masum görünür, ama yanlış anlama potansiyeli yüksektir. Ve çoğu zaman, biz bu boşlukları kendi kafamızdaki en kötü senaryoyla doldururuz. “Yakında” demek yöneticinin kafasında “bugün öğleden sonra” iken, ekibin kafasında “hafta sonu” olabilir.

Bir arkadaşımın anlattığı bir örneği hiç unutmam: Bir ekip yöneticisi “Bu işi hızlıca halledelim” dedi. Yazılımcı da “hızlıca” kelimesini, “şu an üzerinde çalıştığım iki iş bitince” olarak yorumladı. 

Sonuç: Bir gün geciken teslimat ve gereksiz bir stres dalgası.

Bugünden itibaren ne yapabilirsiniz?

Bir IT lideri olarak yeni bir refleks geliştirin: Toplantılarda, günlük stand-up’larda, bire bir sohbetlerde “grilik” kokan her kelimeyi fark edin.

Hızlıca, yakında, iyi, güzel gibi kelimeler duyduğunuzda durun ve sorun: “Hızlıca derken ne kadar hızlı?” “Yakında dediğinde, bugün mü, hafta sonu mu?”

Bu küçük sorular, büyük yanlış anlamaları önler. Üstelik ekip içinde güveni de artırır çünkü herkes artık tam olarak ne kastedildiğini biliyor.

Bir de tersi var: Kendi cümlelerinizi de “gri kelimeler” taramasından geçirin. “Testleri gecikmeden tamamlayın” demek yerine, “Çarşamba 17:00’ye kadar tüm testleri tamamlayın ve %90 kapsam raporunu Slack’te paylaşın” deyin. İlk cümle niyetinizi anlatır, ikincisi beklentinizi.

Son bir not

Teknoloji ne kadar gelişirse gelişsin onu geliştiren, yöneten, yaratan yine insan. Kod satırlarını düzelttiğimiz kadar cümlelerimizi de netleştirebilirsek, projeler sadece daha verimli değil, daha huzurlu da olur.

Ve unutmayın: Net iletişim sadece “işi doğru yaptırmak” için değil, ekip içindeki güven duygusunu korumak için de kritik. Çünkü net olmayan sözler sadece iş akışını değil, ilişkileri de bozar.

Belki de bundan sonra liderlik toplantılarında, projelerden çok, kelimeleri “refactor” etmeye başlamalıyız. 

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu