İyi Bir Geliştirme Ekibi Lideri Olmanıza Hangi Beceriler Yardımcı Olur?

Merhaba. Adım Aleksandr Guzenko, büyük bir şirkette üç ön uç geliştirme ekibinin ekip lideriyim. Geçenlerde çalışanlardan biri yanıma geldi ve şöyle dedi: “Takım liderliğine doğru büyümek istiyorum. Nereden başlayayım?" Daha sonra kendisine rehber olarak göndermeye söz verdiğim bu makalenin fikri böyle doğdu.

Bu yazıda size nasıl ekip lideri olduğumu, bu pozisyonda hangi beceriler olmadan yapamayacağınızı ve "sıradan" bir geliştiriciyseniz ekip yönetimi becerilerinizi nasıl geliştirebileceğinizi anlatacağım.

Ekip lideri kimdir ve nelerden sorumludur?

Neden geliştirmeyi yönetmeye gittiğinizi, bunun yerine proje bütçesini saydığınızı anlamanın zor olacağı teoriyle başlayalım.

Klasik anlamda ekip lideri, geliştirme ekibinin başıdır. Bu doğrudur ancak bazı çekinceleri vardır.

Günümüz ortamında ekip liderleri, programcıların ötesine geçerek tasarımcıları, analistleri, test uzmanlarını, SEO uzmanlarını ve çeşitli BT ve BT dışı profesyonelleri kapsayacak şekilde genişliyor. Bu nedenle, ekip liderini aynı rolü paylaşan bir grup çalışanın lideri olarak tanımlamak daha doğru olacaktır, ancak ben özellikle geliştiricilere odaklanacağım.

İkincisi, takım lideri sadece bir takım lideri değil aynı zamanda çalışanlar ile yönetim arasındaki ana bağlantıdır. Bu önemli bir eklemedir ve nedenini aşağıda açıklamaya çalışacağım.

Üçüncüsü, ekip liderinin neyden sorumlu olduğunu anlamak için rol ve pozisyon arasında ayrım yapmak önemlidir.

Ekip liderinin rolü temel olarak yönetimsel görevleri içerir:

• yönetimin önemli konulardaki pozisyonunu iletmek;
• organizasyonel değişiklikleri gerçekleştirmek;
• Görevleri çalışanlar arasında dağıtın ve uygulamayı izleyin;
• mevcut ekip sorularını yanıtlayın;
• anlaşmazlıkları çözmek;
• takımda rahat bir atmosfer yaratmak;
• her ekip üyesinin özelliklerini dikkate alın;

Saf haliyle, işe alım sitesindeki sorumluluklar listesi aksini söylese bile, rol nadiren bulunur.

Ekip liderliği pozisyonu aynı anda birden fazla rolü birleştirebilir: ekip lideri, teknik lider ve lider geliştirici. Bu pozisyonda, bir uzman genellikle kodu kendisi yazar, ekibin çalışmalarını yönetir ve teknik kısımdan sorumludur:

• bir proje geliştirme stratejisi oluşturur;
• mimarlık tasarlar;
• belirli görevler ve projeler için bir teknoloji yığınını tanımlar;
• ilgili kütüphanelerin versiyonlarını izler;
• kod kalitesinden sorumlu;
• Proje için kritik hale gelmemesi için teknik borç seviyesini kontrol eder.

Ekip lideri ve teknik liderin tek kişi olması iş açısından çok daha uygundur. Uygulamada, büyük şirketlerde bile ekip liderliği pozisyonu, her üç rolün de farklı oranlarda birleşimini içerir. Bu nedenle, bir ekip liderinin ne yaptığına ilişkin fikirler sıklıkla farklılık gösterir.

Farklı şirketlerdeki geliştiricilere bir ekip liderinin sorumluluklarının neler olduğunu sorarsanız cevaplar büyük olasılıkla farklı olacaktır. Ekip liderleri arasında da benzer görüşler olacaktır. Bunu doğrulamak için herhangi bir iş arama sitesine gidin ve farklı açık pozisyonlardaki sorumluluklar listesine bakın.

Kimler takım lideri olabilir?

Bir geliştirme ekibine liderlik etmek için ciddi yetkinliklere ve deneyime ihtiyacınız var. Bu nedenle ekip lideri olmanın en yaygın ve doğru yolu, önce üst seviyeye yükselmek, daha sonra ise liderlik pozisyonunu hedeflemektir. Ancak bu her zaman gerçekleşmez.

Ekip sadece orta düzey programcılardan oluşuyorsa ve bunların arasında her şeyden haberdar olan, projeye destek veren bir inisiyatif çalışanı varsa mükemmel bir ekip lideri olacaktır. Evet, teknik becerisi kıdemliye göre daha az ama takımda daha üst düzey biri yoksa yetkinlikleri oldukça yeterli olacaktır.

Aynı zamanda, tüm son sınıf öğrencileri takım liderliği pozisyonunu uygun bir kariyer yolu olarak görmeyebilir. Liderlik pozisyonunda çalışmak gerçekten ilginç olmalı, aksi takdirde idari iş yükünden kurtulabilirsiniz.

İş yükünü kaldırabileceğinizi nasıl anlarsınız?

Kısa cevap: deneyin. Yöneticinize ücretsiz olarak ek sorumluluklar almak istediğinizi söyleyin ve ne olacağını görün. Bu bir kazan-kazan planıdır, dolayısıyla yönetim genellikle işbirliği yapmaya isteklidir.

Takım lideri kazanır : Birisi onun işini yapar.

İş kazanır : iş yapılır, ancak bunun için para ödemeniz gerekmez.

Ekip lideri stajyerinin ayrıca bir avantajı vardır : Bu modda birkaç aydan bir yıla kadar çalıştıktan sonra, başarılı olup olmadığını ve liderlik etmeyi sevip sevmediğini kendisi anlayabilir. Ve eğer her bir noktaya cevabınız “evet” ise bu yönde büyümeyi ciddi olarak düşünebilirsiniz.

Nasıl ekip lideri olunur: büyüme stratejileri

Yalnızca iki seçenek var. Birincisi, şirketteki diğer tüm geliştiricileri geride bırakmak ve "en yaşlı" çalışan olarak ekip lideri olmaktır. Ancak “eski” kelimesinin tırnak içine alınmasına gerek kalmaması riski de bulunmaktadır. İkinci seçenek ise inisiyatifi kendiniz almaktır.

Benim için nasıl olduğunu sana anlatacağım. Diplomama göre mesleğim yöneticilik olup, üniversitedeki eğitimime paralel olarak kendi başıma programlama eğitimi aldım. Bu yüzden, programcı olarak ilk işime başlamadan önce bile geliştirme ekibi lideri olmaya karar verdim.

İlk başta küçük şirketlerde çalıştım. Bunu kavramam ve genç bir oyuncudan güçlü bir orta oyuncuya dönüşmem iki yılımı aldı. Programlama deneyimi olmadan iyi bir ekip lideri olamazsınız: geliştirme sürecinin nasıl çalıştığını, hangi hataların ve tuzakların bulunduğunu anlamanız gerekir.

Birkaç yıl sonra büyük bir şirkette çalışmaya geldim ve hemen ekip lideri olmak istediğimi belirttim. Büyük şirketlerde genellikle altı ayda bir veya yılda bir, yönetici çalışanla buluştuğunda performans değerlendirmesi yapılır ve birlikte yakın gelecek için bireysel bir gelişim planı oluşturulur. Bu toplantıların her birinde takım lideri olmak istediğimi söyledim. Bana ilk kez şunu söylediler: “Her şey harika, ama önce deneyim kazan.” Liderlik deneyimi kazanabilmem için bir gelişim planı oluşturduk.

Yaklaşık altı ay boyunca ekip liderim ile birlikte görevleri değerlendirip ayrıştırdım ve çalışanlar arasında dağıtmaya çalıştım. İşimizin kalitesi aşağı yukarı eşit olduğunda, şirket benim de başkanlığını yaptığım yeni bir ön uç geliştirme ekibi kurdu. Büyük şirketlerde çok uzun süre beklemenize gerek yoktur.

Bir ekip liderinin gelişiminde iki önemli kilometre taşı olduğunu söylüyorlar: Birincisi iki ila altı çalışan, ikincisi ise 7 veya daha fazla çalışan. İlk başta yalnızca bir çalışanım vardı ve şimdi 12 çalışandan oluşan üç ön uç geliştirme ekibine liderlik ediyorum.

Sadece inisiyatif gösterdim, yönetimin karşısına çıktım ve fırsat doğar doğmaz ekip lideri olarak atandım.

Büyümeyi mi bekleyeceksiniz yoksa başka bir şirkete mi gideceksiniz?

Ekip liderleri sıklıkla şirket içinde yetiştirilir ve bunun dikkate alınması önemlidir. Mevcut işinizde büyüme olasılığı varsa, inisiyatif almalı ve kendinizi bir yönetici rolünde denemelisiniz. Ancak takımın tamamı front-end ve back-end ise ve herkes kendi takım lideriyse bir mucize beklememelisiniz. Daha büyük bir şirkete geçmek ve gelecekte liderlik pozisyonu almak istediğinizi belirtmek daha iyidir. Süreçleri incelemek ve projenin iş mantığını anlamak için zamana ihtiyacınız olacak. Ancak şirkette uygun bir pozisyon açıldığında, büyük olasılıkla dışarıdan biri yerine sizi seçeceklerdir.

İyi bir ekip lideri olmanıza hangi beceriler yardımcı olacaktır?

Takım liderliği pozisyonunda hem sert hem de yumuşak beceriler eşit derecede önemlidir. Geliştiriciler genellikle zor becerilerde neyin eksik olduğunu bilirler. Üstelik bu gereksinimler uzmanlaşmaya ve teknoloji yığınına güçlü bir şekilde bağlıdır, dolayısıyla evrensel bir liste yoktur. Ürün ve şirket için kritik olduğunu düşündüğüm sosyal becerilerden bahsedeceğim.

Süreçlerdeki problemleri bulma yeteneği

Geliştirmenin hızı ve kalitesi ve dolayısıyla maliyet, şirketteki süreçlere bağlıdır, ancak bunlar nadiren idealdir.

Örneğin, bir hatayı düzelttiniz ve yapıyı standa getirmeye hazırsınız, iş bekliyor. Ancak bunu yapmak için beş boru hattından geçmeniz ve ilgili herkesin onayını almanız gerekir. Sorumlulara yazıyorsunuz - sessizlik. Onları çekiştirmeye başlıyorsunuz ama resmi mesajlar sırf yanıt vermek için geliyor; herkesin vakti yok. Düzeltilmiş versiyonun standa ulaşması altı saat kadar sürebilir. Ve tüm bu zamanı meslektaşlarınıza ulaşmak için harcıyorsunuz ve işletme para kaybediyor.

Diğer bir örnek ise farklı sistemlere, programlara, stantlara ve arşivlere erişimlerin çok fazla olmasıdır. Bankalar genellikle bundan muzdariptir. Bir kişi işe gelir, projeyi anlaması gerekir, ancak ilk bir buçuk ay hiçbir şey yapamaz çünkü - bu doğru - erişim yok. Erişimlerle ilgili bir diğer sorun da çok sayıda olması ve adlarının hatırlanmasının imkansız olmasıdır. Örneğin, dizinde "depoya erişim" yerine A32B18KZ olacak - onu bulmaya çalışın.

Bir geliştiricinin bir veya iki ay boyunca çalışmaya başlayamadığı gerçek durumları biliyorum. Bunca zaman maaş aldı ama hayal kırıklığına uğradı ve istifa etti. Yani şirket altı ay boyunca bir çalışan aradı, iki ay boyunca ona maaş ödedi ve ardından işe alım sürecine yeniden başlamak zorunda kaldı.

Süreçlerdeki bu tür sorunlar işleri zorlaştırmakta ve yavaşlatmaktadır. Ekip liderinin görevi onları görmek ve tam olarak neyin kötü çalıştığını ve başarısızlığın nerede oluştuğunu anlamaktır.

Sorunları çözme veya bunları işletmeye doğru şekilde iletme becerisi

Süreçlerdeki sorunları görmek değil, çözüm önerileri sunmak önemli. Yönetime başvurmadan bazı zorluklarla kendiniz başa çıkabilirsiniz. Örneğin bir takım, uyumsuz bir devlet yöneticisiyle mücadele ediyor. Proje küçükse veya henüz başlangıç aşamasındaysa, bir görüşme ayarlayabilir, en iyi seçeneği bulabilir ve yeni bir devlet yöneticisini kayıpsız olarak kademeli olarak nasıl tanıtacağınızın ana hatlarını çizebilirsiniz. Çözüm bulundu ve işletmenin sorunun varlığından haberi bile yoktu.

Ancak çoğu sorun ancak üst yönetimin yardımıyla çözülebilir. Örneğin yapıların standa çıkışını hızlandırmak için tüm departmanlarda iyi bağlantıları olan ve karar vericilere erişimi olan bir kişiyi belirleyip onay sürecine dahil edebilirsiniz. Diğer departmanlardaki meslektaşlarından geri bildirim gelmezse kime yazması gerektiğini biliyor ve süreci manuel olarak ayarlayabiliyor. Ancak bu tür işler ayrı bir pozisyon gerektirdiğinden şirket yönetiminden onay almanız gerekir.

Erişim sorunu da benzer şekilde çözüldü. Çoğu geliştiricinin aynı sistem ve programlara ihtiyacı vardır. Örneğin, ön uç geliştiriciler için - bir depo, stand, Jira vb. Öyleyse neden onlar için standart bir erişim paketi hazırlayıp onlardan küçük bir maaş talep edecek bir kişiyi işe almıyorsunuz? Ancak bu aynı zamanda şirketin üst yönetiminin iradesini de gerektirir.

Bu nedenle bir ekip liderinin temel becerilerinden biri sorunun özünü işletmeye doğru bir şekilde aktarabilmektir. Burada bazı sırlar var.

• Bir kez yeterli değil . İlk temastan sonra sorunlar nadiren çözülüyor, bu nedenle belirli aralıklarla yönetime gidip onlara sorunu hatırlatmanız gerekiyor: “bu takımın moralini bozuyor”, “üretkenliği kaybediyoruz.”

  
  

• Ekibin sorunları ile ticari çıkarlarının nasıl bağlantılı olduğunu görürseniz bu noktaya gelin . Örneğin, sadece birkaç saatlik çalışma olmasına rağmen düzeltilmesi iki gün süren kritik bir hata vardı ve sonuç olarak işletme para kaybetti. Yönetime gidiyorsunuz ve yapıların koordinasyonu sorunu hakkında konuşuyorsunuz. Böyle anlarda işletmeler önerilere olabildiğince açık oluyor. Ancak çözümün zaten hazır olması gerekir.

İşletmeyle aynı dili konuşun

En emin yol, sorunu yönetime götürmeden önce sorunun şirkete ne kadara mal olduğunu hesaplamaktır.

Ön uç ekip lideri olarak düzenli olarak çalışanlardan geri bildirim topluyorum. Örneğin geliştiriciler sürekli olarak görevlerin yeterince tanımlanmadığından şikayet ediyorlar. Bu nedenle sorunun yazarının onlardan ne istediğini öğrenmek uzun zaman alıyor. Daha sonra test uzmanları geliştiricilerin yanına gelir ve ne yapıldığını, tam olarak neyi test etmeleri gerektiğini ve zincir boyunca ilerlemeye çalışırlar. Sonuç olarak, herkes özü hala kendi yöntemiyle anlıyor ve hatalar ortaya çıkıyor.

Ortalama olarak ekibin çalışma süresinin %40'ını hataları düzeltmeye harcadığını hesapladım. Ekiple birlikte geriye dönük bir analiz yaptık ve bu hataların yarısının yalnızca sorunun özünü yanlış anladıkları için ortaya çıktığını tespit ettik. Yani, geliştiricilerin çalışma zamanlarının %20'si, görevlerin yeterince tanımlanmaması nedeniyle boşa harcanıyor. Bu, yönetime gitmeniz gereken numaradır. Bunu paraya dönüştürmek kolaydır; iş dünyasının anladığı dille aynıdır.

Ekip içinde uygun bir ortam yaratın

İnsanlar birbirleriyle çalışmaktan keyif aldıklarında her türlü etkileşim daha sorunsuz hale gelir. Scrum neden bu kadar popüler? Bu belgelerle ilgili değil, insanlarla ilgilidir. Bazen bir meslektaşını iki gün boyunca yanıtını belgelemesi ve her şeyi ayrıntılı olarak anlatması için beklemektense iki dakika aramak daha etkilidir. Dolayısıyla ekip içinde karşılıklı anlayış ve yardımlaşma ortamı oluştuğunda insanların birbirleriyle iletişim kurması daha kolay olur. Örneğin bir kod parçası buldunuz ve onun ne işe yaradığını anlamıyorsunuz. Takımdaki durum iyi değilse, arayıp sormaya korkacaksınız - "aptal olduğumu düşünecek."

Ekip içinde iyi ilişkiler sürdürmek için haftada bir saat süren görüşmeler yapıyorum. Bu zamanı üç parçaya ayırıyoruz. Birincisi “rahat”. Memleri ve şakaları paylaşıyoruz. İkinci bölüm sorunların tartışıldığı bölümdür. Bazen Miro'da kartları birlikte atıyoruz ki bu herkesin hoşuna gitmiyor. Adamları tam olarak neyin yavaşlattığının resmini bu şekilde elde ediyorum. Daha sonra çözüm seçenekleri bulabiliriz, daha sonra yönetimle lobi yapacağım. Ve yine "rahatlamış" bir şekilde bitiriyoruz: filmleri veya başka bir şeyi tartışabiliriz. Bu tür toplantılar olumlu bir atmosfer yaratıyor ve bir lider olarak takımda ne gibi sıkıntıların olduğunu anlamamı sağlıyor.

Temsilci

Yeni ekip liderlerinin yaygın bir hatası, iş süreçlerini kendilerine odaklamaktır. Bu durumda ekip lideri aniden hastalanırsa veya tatile çıkarsa işler durmaya başlayacak ve sürekli çekilecektir. Bunun olmasını önlemek için ekipten birine ekip liderinin sorumluluklarının bir kısmını yerine getirmeyi öğretebilirsiniz. Örneğin, ayda bir kez görevleri dağıtma konusunda başkalarına güvenin. Böylece ekipte bir başkası bu yeteneğe sahip olacak ve ekip lideri, o olmadan hiçbir şeyin bozulmayacağını bilerek, sakin bir şekilde tatile çıkabilecektir.

Belki de bu, bir ekip liderinin çalışmasını değerlendirmek için iyi bir kriterdir: eğer ekipten çıkarılırsanız, güvenlik marjı bir ay için yeterli olmalıdır.

Ekip içindeki sorumluluk alanlarını doğru şekilde dağıtın

Geliştirme aşamasında, bir projedeki riskleri yönetmek için veri yolu faktörü gibi bir ölçüm kullanılır. Tüm projenin çökmesi için kaç ekip üyesinin hayali bir otobüsün çarpması gerektiğini gösteriyor. Bus faktörü = 1 ise ciddi sorunlarınız var demektir.

Örneğin karmaşık bir proje geliştiriyoruz. Gelişmiş bir modülü var ve yalnızca bir geliştirici onun nasıl çalıştığını ve nasıl yönetileceğini biliyor. Bu kişinin hastalanması, işten ayrılması veya tatile çıkması durumunda bu modülün değiştirilmesi çok uzun ve pahalı bir prosedüre dönüşecek ve bu da tüm projeyi olumsuz etkileyecektir. Bunun olmasını önlemek için, diğer çalışanlara yavaş yavaş karmaşık modüller veya kütüphanelerle çalışmayı öğretmeniz gerekir.

Ekip lideri, süreçleri tek bir kişiye sınırlamadan, onu proje için kritik hale getirmeden, ekip içinde sorumluluğu doğru şekilde dağıtabilmelidir.

Projenin stratejik vizyonu

Ekip lideri projenin nereye gittiğini, hangi sorunları olduğunu ve bunların nasıl çözüleceğini anlamalıdır. Örneğin ekibin toplam iş yükü haftada 100 çalışma saatidir. Ve işletme 100 saat boyunca isteklerini yerine getiriyor. Şu anda proje üzerinde teknik borç birikiyor ve bununla da ilgilenmenin zamanı geldi. Ekip liderinin görevi, teknik borcun kritik hale gelmesinden önceki anı takip etmek ve ekibin zamanının belirli bir yüzdesini mevcut sorunları çözmeye harcaması için yönetime lobi yapmaktır.

Bir ekip lideri olarak ne gibi sorunlarla karşılaşabilirsiniz?

Ekip liderlerinin alarm zillerini fark etme konusunda neden tükendiğini başlangıçta bilmek daha iyidir.

İşletme açısından yanlış anlaşılma

Bu, aylar boyunca yönetime ulaşmaya çalıştığınızda, sorunlarınızı ve hazır bir çözüm bulduğunuzda en sık karşılaşılan sorundur, ancak en üstte sorunu birikmiş yığına koyarlar ve hiçbir şey olmaz. Birkaç nedeni olabilir. Birincisi, iş dünyasında yanlış dil konuşuyorsunuz ve yaklaşımınızı değiştirmelisiniz. İkincisi, patronunuz “her şeyin en iyisini bilir” ve her şeyi kendi bildiği gibi yapmaya devam eder. Bu durumda en iyi çözüm şirket değiştirmek olacaktır.

Kaynak eksikliği

Basit bir örnek: Ekibiniz sürekli olarak görevlerle boğuluyor ve artık yeterli el yok. Küçük ve orta ölçekli işletmelerin yeni çalışanları işe alacak parası olmayabilir. Bu durumda, sistem analisti rolü gibi ek bir rol üstlenebilir ve işin daha hızlı ilerlemesi için görevleri tanımlamaya başlayabilirsiniz. Büyük şirketlerde büyük olasılıkla para var ama karar verme zinciri çok uzun ve üçüncü ve dördüncü seviye patronlar arasında bir kedinin geçmediğinin ve bu nedenle sürecin durmayacağının garantisi yok. Burada sadece üst yönetimden birini kendi tarafınıza kazanmaya çalışabilir veya sadece bekleyebilirsiniz.

Çalışmanın sonuçları görünmüyor

Bir şirkete gelirsiniz, strateji geliştirirsiniz, planlar yaparsınız, işe tutkuyla bağlanırsınız ama zaman geçer ve hiçbir şey değişmez. Burada umutsuzluğa kapılmanız uzun sürmüyor: “Tüm bunlara kimin ihtiyacı var?” Bu durumda projenin neden ilerlemediğini anlamak için geriye dönük bir analiz yapabilirsiniz. Kendinize şunu sorun: "Belki de yanlış hedefi vuruyorum, yanlış sorunları çözüyorum?"

Hedefe ulaşmak için gerekli araçların eksikliği

Bu, size liderlik pozisyonu verildiğinde, sorumluluk verildiğinde ancak herhangi bir kontrol aracı verilmediğinde meydana gelir. Örneğin, röportajları bağımsız olarak yürütmenin ve geliştiricileri ekibinize katılmaları için işe almanın bir yolu yoktur. Burada sadece iki seçenek var: Ya işletmeye ulaşıp pozisyonunuzu belirtmeyi deneyin ya da şirketi değiştirin.

Üst yönetime doğrudan erişim

Ürünü geliştirmek ve ekibin mevcut sorunlarını çözmek için ekip liderinin karar vericilerle sürekli iletişim halinde olması gerekir. Eğer “zirveye” erişim kapatılırsa sorunlar çözümsüz kalacak, gelecek vaat eden kalkınma stratejileri söylenmeden kalacak ve çalışma motivasyonu kaybolacaktır. Tükenmemek için yönetimle ilişki kuramıyorsanız şirket değiştirmek daha iyidir.

Kalıcı acil durum modu

Bazen çok fazla görev vardır ve ekip artık gelen akışla baş edemez. Sürekli acil bir durumda, düzenli aramalar arka planda kaybolur; bu saati hataları ortadan kaldırmak için harcayabilecekken kimin memlere ve boş sohbetlere ihtiyacı var ki? Sonuç olarak, tüm ekip, er ya da geç gücü tükenecek ve insanlar ayrılmaya başlayacak olan tahrikli bir ata dönüşür. Ekip liderinin yapabileceği tek şey, personeli genişletmeye çalışmak veya görevleri sıraya koymaktır.

Takımdaki kötü atmosfer

Herkesin birbirinden nefret ettiği, önceden kurulmuş bir ekibe katılırsanız bu durum gerçekleşebilir. Takımda toksik bir iletişim tarzı çoktan kök salmış durumda ve herhangi bir karşılıklı yardımdan söz edilmiyor. O zaman yapılabilecek tek şey tüm ekibi dağıtıp yeniden üye almak.

Sorun ne olursa olsun, her zaman olumlu bir sonuç alma şansı vardır. İlk başarısızlıktan sonra pes etmeyin. Biraz beklemeniz veya yaklaşımınızı değiştirmeniz faydalı olabilir. Ancak her şeyi denediyseniz ve boş bir duvara çarpıyormuşsunuz gibi geliyorsa, o zaman ayrılma kararı tek doğru karar olacaktır.

Çözüm

Sorunları çözme yeteneği bir ekip liderinin önemli bir niteliğidir. Ama ne yazık ki her zaman işe yaramıyor. Ancak bir veya iki yıldır zamanı işaretlediğinizi hissediyorsanız ve bunu hiçbir şekilde etkileyemiyorsanız ancak büyümek istiyorsanız, şirket değiştirmek kötü bir fikir değildir. Değişimden korkmayın. İş değiştirmek normaldir.