VP of Engineering Olarak Geçen İlk Yıl
2021 yılı VP of Engineering pozisyonunda görev yaptığım ilk yıldı. Bu yılda akılda kalanlara geçmeden önce hangi ölçekteki şirkette çalıştığımdan kısaca bahsetmek yerinde olacaktır. Çünkü bu pozisyonda yaptıklarınız şirketin bulunduğu aşamaya göre farklılıklar gösterebiliyor.
Binalyze şirketinde görev yapıyorum. Binalyze hızla büyüyen ve Digital Forensics yazılımları geliştiren bir girişim. Geçen yılın başlarında 7 kişi ile başlayıp yıl sonunda 45 kişilik bir ekibe ulaştık. Alınan ilk yatırım ve ikinci yatırım ile birlikte, geliştirilen yazılımlar ve artan kişi sayısı ile büyümeyi ve hızı iliklerimize kadar hissettiğimiz bir yıl oldu ve olmaya da devam ediyor. Hızlı büyüyen bir teknoloji şirketinde bu pozisyonda görev yaptığınızda öğrendikleriniz de haliyle bir o kadar fazla oluyor. Geriye dönüp baktığımda aklımda kalan başlıkları şöyle özetleyebilirim:
Kod yazmayı bırakmak
Binalyze’da yazılım geliştirici olarak başladım. Geliştirilen yazılımların mimarilerinin tasarlanması ve özelliklerin geliştirilmesinde aktif olarak görev aldım. VP of Engineering görevini kabul ettikten belli bir süre sonra daha kod yazmaya devam ettim. Fakat şirketin büyüme hedefleri doğrultusunda alınan yatırımlar ile birlikte büyüme hızlanmalıydı ve haliyle “yazılım geliştirici” şapkamı bir kenara koymam gerekti. İtiraf etmeliyim ki bu beni baya zorladı. Daha önceki çalıştığım şirkette de yönetici pozisyonlarında görev yapmıştım. Bu pozisyonlarda hem kod yazıp hem de yönetim işlerini çok sorun olmadan yönetebiliyordum. Fakat Binalyze hep duyduğumuz o hızlı büyüyen girişim hikayelerindeki tecrübeyi derinden hissettiren bir şirket. Yönetim pozisyonuna geçiş ister istemez beni kod yazmaktan uzaklaştırdı. Burada beni en çok zorlayan şeylerden biri de bu yeni pozisyonumda verimliliğimi nasıl ölçeceğim konusuydu.
Kod yazarken gözle görülür somut bir çıktı üretiyorsunuz. Dolayısı ile ne kadar efor harcayarak nasıl bir çıktı ürettiğinizi görmek nispeten daha kolay. Fakat yönetim kademesine geçtiğiniz de artık verimliliğinizi ölçeceğiniz metrikler değişiyor. Ölçütleriniz yazdığınız kodlardan ziyade insanlara yaptığınız katkılar ve çalışanlara doğru bir çalışma ortamı sağlamak için geliştirdiğiniz süreç ve sistemler oluyor. Yönetim pozisyonuna geldiğinizde artık kişisel verimliliğinizden çok sorumlu olduğunuz departmanın verimliliğini düşünmek zorundasınız. Yönetim pozisyonunda olanlara hep sorulur, “Bir yönetici kod yazmalı mı?” diye. Buna benim vereceğim cevap bu tecrübemden sonra çok net: Kesinlikle yazmamalı. Neden? Çünkü aynı anda iki şapka takmaya çalıştığınızda emin olun ki üstlendiğiniz bu iki görevin birinde çuvallayıp başarısız olacaksınız.
Günlük işlerden kafayı kaldırıp büyük resme odaklanmak
Üst düzey bir yönetici kademesinde görev yaptığınız da günlük işler arasında kaybolmayı bırakmalısınız. Bu gerçeği ne kadar erken kavrarsanız o kadar iyi. Günlük işler derken nelerden bahsediyorum? Yönettiğiniz ekipten gün içerisinde hem teknik hem de diğer konulardan sorular gelecektir. Bu sorunların yanında beklenmedik aksaklıklardan kaynaklanan durumlar ister istemez sizi günlük detayların içine çekmeye çalışacak. Tabiki bu sorunlara gerekli çözümler üretmek, aksaklıkları gidermek ve ekipten gelen soruları cevaplamak sizin sorumluluğunuzda. Fakat bu sorunlara çözüm üretirken nerede duracağınızı bilmelisiniz. Günlük süreçlerde kaybolursanız uzun vadede yapmanız gereken önemli işleri ıskalamaya başlarsınız. Nitekim bu bahsettiğim şey başıma geldi.
Günlük işlerle boğuşmaktan uzun vadede planladığım işlere hiç vakit ayıramadığımı farkettim. Güne başlarken planladığım işler bir takım sebeplerle sürekli bölünüyordu. Hızlıca akşam oluyor ve gün içerisinde yaptığım işleri gözden geçirdiğimde yaptıklarımın planlanan işlerle hiçbir alakası olmadığını farkettim. Bunun geçici bir süreç olduğu konusunda kendimi ikna ettim. Fakat bu yanlış bir varsayımdı tabi. Bu kısır döngünün farkına varmam biraz zaman aldı. Günlük sıkıntılar aslında şirketin büyümesinden, ekibe yeni katılan kişilerden dolayı ortaya çıkan ekibin ölçeklendirme problemleriydi. Bu problemlerin tek çözümü doğru sistematik süreçlerin şirket içerisinde oturtulmasıydı. Bahsettiğim uzun vadeli önemli işler derken bu tarz işleri kastediyorum.
Aslında günlük işler ve aksaklıkların çözümü, uzun vadeli bu işler üzerine kafa yorup gerekli süreçleri oturtmaktı. Fakat günlük işlerle vakit harcamaya devam ederken aynı zamanda bu işlere nasıl zaman ayırabilirdim? Bu farkındalığı kazandıktan sonra takvimime “Focus Time”’lar koyarak, gün içerisinde uzun vadeli önemli işler üzerinde çalışmaya başladım. Kendimi gereksizleştirip, ekibin otonom bir yapıya kavuşmasını sağlayacak süreçleri geliştirmeye başladıkça benim de günlük yoğunluğum azalmaya başladı. Bu yüzden günlük işlerden kafayı kaldırıp uzun vadeye odaklanmak bu yıl içerisindeki en iyi çıkarımlardan biriydi. Aslında bunun böyle olması gerektiğini başından beri biliyordum ama nasıl olması gerektiği konusunda cevabım yoktu. Burada aslında cevap, acil olan günlük işleri aksatma pahasına uzun dönemli önemli işlere odaklanmaktı. Bazen kısa vadede çok gerekli gibi görünen işleri bir kenara bırakabilmeyi bilmelisiniz. Uzun vadede getirisi daha yüksek olan ve gelecekte sizi sürekli meşgul edecek bu tür günlük işlere çözüm olacak sistemler üzerinde çalışabilmelisiniz. Bugün feda edilmiş gibi görünebilir fakat aslında yarının potansiyel sorunları bugün yaptığınız bu fedakarlıklar sayesinde önlenmiş oluyor.
Delegasyon
Hızlı büyüyen bir girişimde, özellikle ilk yıllarda şirket her ay değişir. Bu bazen günlük bazda bile olabilir. Şirketin büyümesini devam ettirecek şekilde ekibi ölçeklendirmek için yapılan her yeni personel alımı ile birlikte artık yeni bir ekibiniz vardır. Bu konu ile ilgili yaptığım okumalardan birinde çok kıymetli bir yazıya denk gelmiştim. Bu yazıda yazar hızlı büyüyen şirketlerdeki delegasyonu, lego parçaları ile yapılan kulelere benzetiyordu. Şöyle ki; şirkette üzerinize aldığınız her iş, geliştirdiğiniz her sistem legoları birleştirerek geliştirdiğiniz kulelere benzer. Bu kuleleri inşa edip gerektiğinde yetkin kişilere devretmelisiniz ki şirketin aksayan diğer yerlerine el atıp orada da gerekli kuleleri inşa edebilesiniz.
Eğer bu delegasyonu yapmayıp, “bu kuleyi ben geliştirdim ve legolarımı başka birine devredemem” zihniyeti ile hareket ederseniz takımı ölçeklendirmeniz hayalden öteye geçemez. Sonunda da ölçeklendirme problemlerinden dolayı şirketin büyümesinde kritik hatalara neden olursunuz. Geliştirdiğiniz projelere, tasarladığınız sistemlere, yazdığınız koda kısacası sahiplendiğiniz tüm işler ile aranızda duygusal bir bağ kurmaktan kaçının. Bu projeleri geliştirme aşamasında sahipliği üstlenerek, sorumluluk ve hesap verebilirlik ile hareket etmelisiniz. Fakat zamanı geldiğinde profesyonelce davranıp bu sahipliği başka birine devredebilmelisiniz. “Bunu devredersem üzerinde çalışabileceğim başka ne kalır?” demeyin. Hızlı büyüyen girişimlerde her zaman savaşılacak bir cephe bulunur.
Dar boğazları testip etmek
Eğer takıntılı olduğun konular nelerdir diye sorsaydınız dar boğazları tespit etmek vereceğim ilk cevaplardan biri olurdu. Bu pozisyondaki ilk yılımda bu konu üzerine çok fazla kafa yordum. Ekibin tökezlemesine neden olan, verimliliğin düşmesine neden olup işleri aksatan noktaları tespit etmek kritik öneme sahipti. Burada hem kişilerden kaynaklanan hem de şirketin büyümesi ile doğru orantılı olarak getirilen yeni politikalardan dolayı bu darboğazlar oluşabiliyor. Aslında bu darboğazlar büyümenin ve değişimin kendisinden kaynaklanıyor.
Kişilerden kaynaklanan dar boğazlara verilecek en yaygın örnek girişimin başında kurucu ile birlikte yola çıkan yazılımcılar verilebilir. Bu arkadaşlar birer savaşçı gibi her cephede görev alıp birden fazla sorumluluk üstlenirler. Fakat girişim büyüdükçe, müşterilerden gelen taleplerin artması, yazılımın büyümesi gibi sebeplerle bu kişiler artık üzerlerine aldıkları birden fazla görevi yerine getirememeye başlayıp sistemde bir darboğaz haline gelirler. Bu kişiler yetkin oldukları için, onların yükünü azaltacak, darboğazları ortadan kaldıracak yeni ekip arkadaşları bulmak da bir hayli zaman alan bir süreç. Dolayısı ile kişilerden kaynaklı darboğazları tespit ettikten sonra doğru kişileri bulana kadar geçen sürecin uzun olabileceğinin bilinmesinde fayda var.
Tecrübe ettiğim diğer bir darboğaz da ya sistem yokluğunda ya da varolan sistemin artık şirketin büyüyen yeni yapısına yetersiz kalmasından kaynaklanan darboğazlardı. Şirketin başında çok bir sisteme gerek olmuyor aslında. Startuplarda çalışmış arkadaşlar bunu iyi bilirler. Çözülecek problemler ve ürüne eklenecek yeni özellikler vardır. Bunların planlanması için toplamda bir elin parmaklarını geçmeyecek kişiler bir araya gelip hızlıca karar alıp uygulamaya geçerler. Benim durumumda da olay bundan farksızdı. Fakat şirket ve geliştirilen ürünler büyüdükçe, oyuna farklı departmanlar ve ciddi ölçekteki müşteriler dahil olunca artık eski düzen ile hareket etmemiz pek mümkün olmadı. Takımın ritmine göre, müşteri ihtiyaçları ile aynı hizada olacak yazılım geliştirme yaşam döngüsünü oturttuk.
Darboğazlarla ilgili okuma yapmak isteyen arkadaşlara kısıtlar teorisini konu alan aşağıdaki 2 kitabı önerebilirim:
İletişim
Aydan aya büyüyüp değişen bir şirkette çalıştığınız zaman bilginin ekipler arasında paylaşılması, şirketin hangi yönde gittiği konusunda herkesin aynı sayfada olduğunun sağlanması büyük önem arz ediyor. Bilginin kendisi kadar ne şekilde iletildiği de çok önemli. Binalyze’da uzaktan çalışma biçimini benimsiyoruz. İşin hangi saat aralıklarında yapıldığından çok hedeflenen tarihlerde doğru çıktıyı alıp alamadığımızla ilgileniyoruz. Bu sebeple mühendislik ekibinin kendi verimli olduğu zamanlarda bölünmeden odaklı bir şekilde çalışabileceği iletişim yöntemini oturtmak en öncelikle işlerden biriydi.
Hem uzaktan çalışma biçimine uygun hem de mühendisleri gereksiz toplantılardan uzak tutarak bölünmeden çalışabileceklerine yardımcı olacak asenkron iletişim yöntemini benimsedik. Asenkron iletişim derken neyi kastediyoruz? Slack veya Microsoft Teams gibi programlardan kişileri aramak veya chatten yazmak yerine ilgili işlerin yönetildiği görevler üzerinden bu iletişimi yönetmek birinci önceliğimiz. Yani işin temelinde konuşmak yerine yazmak var. Yazılı iletişim işin temelini oluşturuyor. Kişilere özel chat ekranlarından direkt mesaj göndermiyoruz. Bunun yerine projeleri yönettiğimiz yazılımlarda kişilerin görevleri yazılı olduğu için, o işle ilgili herhangi bir soru sorulması gerekiyorsa bu kişiyi arayarak yapmayı tercih etmiyoruz. O görevin yorum bölümünde ilgili kişinin ismi bahsedilerek bir tartışma başlatıyoruz. Bahsi geçen kişi buna hemen cevap vermek zorunda değil. Müsait olduğunda tartışmaya katılarak asenkron bir şekilde tartışmayı sürdürebilir. Tamamen kendi tercihi. Bu yüzden herkes bildirimlerini kendine göre ayarlıyor. İsterse ismi geçtiği anda hemen cevap verebilir ama iletişim asenkron olduğundan dolayı bunu yapmak için gerekli olan düşünme zamanını bulabiliyor. Aramalarda genelde bu zamanı bulmak pek mümkün değil. Sizi acele ile karar vermeye zorluyor ve bu da çok verimli olmuyor. Buradaki tüm iletişim modelini “yazmak düşünmektir” olgusu üzerine kurduk. Gerekli hallerde tabi ki toplantı yapıyoruz. Fakat önceliğimiz elimizden geldiğince bu gerekli halleri azaltmak.
Mülakatlar ve işe alımlar
Mülakatlar en çok zamanımı alan işlerden biriydi. CV’lerin değerlendirilmesi, uygun olan adaylar ile yapılan görüşmeler, adaylara atanan projelerin değerlendirme görüşmeleri derken geriye dönüp baktığımda pastadaki en büyük dilimlerden biri buydu. Sadece yapılan görüşmelerden bahsetmiyorum. İşe alım ve mülakat süreçlerinin belirlenmesi, ekip ile birlikte adaylara atanacak projelerin hazırlanması büyük emek ve zaman isteyen süreçlerdi.
İşe alım süreçleri büyük önem arz ediyor. Oluşturmak istediğiniz kültür ve buna uygun kişileri bulmak için buradaki kriterleri iyi belirlemeniz ve tüm süreci buna göre tasarlamak çok önemli. Çekirdek ekibin kültürü kaybetmeden büyümesi bu sürecin ne kadar iyi tasarlandığına bağlı.
Bu ilk yılda bazen yanlış yaptığımız tercihlerden dolayı zor kararlar vermek zorunda da kaldık. Kültüre uymayan bir adaya aklınızdaki soru işaretine rağmen evet derseniz ve deneme süresi boyunca bu şüpheler daha da güçlü hale gelirse düzelmesi için çok fazla beklememek gerek. Bu tarz durumlarda “biraz daha bekleyeyim belki düzelir” diye düşünmek benzer durumların %90'nin da beyhude bir düşünceden öteye geçemiyor malesef. Bu yüzden kültürünüze daha fazla zarar vermeden, emeğinizi de daha fazla harcamadan o zor kararı vermeli ve yolları ayırmalısınız.
Aslında bu konuda edindiğim tecrübelere göre size de önerebileceğim bir kural benimsemiştim. Eğer aday ile ilgili aklınızda bir soru işareti varsa cevap kesinlikle hayır olmalı. Hayır cevabı ile aslında kaybettiğiniz bir şey olmuyor. Fakat evet cevabı ile her iki taraf içinde harcanan emek ve zaman var. En kötüsü de işin sonunda anlaşamama durumunda her iki taraf için de o zor ve üzücü konuşmayı yapmak var. Bu kuralı gayet iyi işletebildik aslında. Fakat görüşmelere genelde adayın yakından çalışacağı takım arkadaşlarını da dahil ettiğimiz için bu arkadaşlardan gelen olumlu görüşlere aldanıp “nasıl olsa aday bu arkadaşlarla çalışacak. O yüzden bir şans verebiliriz.” gibi bir düşünceye kapılmaya hiç gerek yok. Bir şekilde “hayır” kuralını işletmeli ve içinizdeki o hisse güvenmelisiniz.
1:1 Görüşmeler
Bu pozisyonda görev yapıyorsanız aksatmamanız gereken en önemli görevlerden birisi ekip üyeleri ile yapacağınız bire bir görüşmeler olmalı. Bu görüşmeler sayesinde varsa problemleri daha küçükken tespit edip daha fazla büyümeden çözme şansınız var. Sadece problemleri çözmek için değil aynı zamanda nelerin iyi nelerin kötü gittiği konusunda fikir sahibi olabilmek için de güzel bir fırsat. Uygulamaya çalıştığınız yeni politikanın ekip üyeleri tarafından nasıl algılandığı, aksayan yönlerinin olup olmadığı gibi konular hakkında yine bu görüşmeler sayesinde geri bildirim toplayabilirsiniz.
İlk yılımda bire bir görüşmeleri aksatmamak en doğru yaptığım işlerden biriydi. Takım büyüklüğümüz henüz çok fazla olmadığından dolayı herkes ile bire bir görüşme fırsatım vardı ve bunu iyi değerlendirdiğimi düşünüyorum. Bu görüşmelerdeki ilk amacım takımımdaki kişilerle aramızda gerekli olan güveni tahsis etmekti. Bu sebeple onları daha yakından tanımak için iş dışındaki konulardan da konuşmaya gayret ettim. Hem onları tanımak hem de onların da beni tanımaları için gerekli olan fırsatı bu görüşmelerle bulmuş oldum. Bu görüşmelerdeki diğer bir amacım da takımdaki arkadaşlarla aramızda bir bariyer olmadığı, açık ve dürüst bir şekilde birbirimize geri bildirimlerde bulunabileceğimiz konusunu vurgulamak oldu. Bunun bire bir görüşmelerde çok önemli olduğunu düşünüyorum. Karşınızdaki insan size geri bildirimde bulunmaya çekiniyor, problemleri söylemek yerine içine atıyorsa bu görüşmeleri yapmanın hiç kimseye bir faydası yok. O yüzden ilk olarak güveni tahsis ederek açık ve dürüst bir iletişim kanalı kurabilmek bu işin temelini oluşturuyor.
Temelleri attıktan sonraki aşamalarda takımımdaki arkadaşlara mentorluk yaparak hedefledikleri kariyer gelişimlerine katkıda bulunmaya çalıştım. Bunun için tüm olumlu olumsuz geri bildirimler bu görüşmelerde verildi. Verilecek geri bildirimlerle ilgili birkaç öneride bulunmama izin verin. Eğer ekip üyesinin başardığı önemli bir iş varsa bu tarz olumlu geri bildirimleri diğer ekip üyelerinin de görebilmesi için açık bir şekilde verilmeli ve ekip üyesini onore etmelisiniz. Fakat yapacağınız kritikleri ve olumsuz geri bildirimleri ise bire bir görüşmelerde direkt olarak kişiye vermelisiniz. Bu iki önemli noktaya dikkat etmenizi öneririm.
Koordinasyon
Mühendislik departmanı, teknoloji şirketinin kalbinde yer alan bir departman. Haliyle bir çok farklı departmana da doğrudan bir bağı bulunuyor. Başlarda ekibimiz küçük olduğu için haliyle bir çok şapka taktik. Ürün yönetiminden başta CEO’muz sorumluydu ve yeri geldiğinde bu şapkayı ben de taktım. Ekip büyüdükçe ürünün yol haritası, geliştirilecek özelliklerin planlanması, müşterilerden gelen taleplerin değerlendirilmesi gibi konulardan sorumlu ayrı bir ürün ekibi oluşturduk. Bu ekip mühendislik ekibine doğrudan bağımlı olduğu için burada bir köprü görevi görmesi gerekti.
Sadece ürün ekibi ile değil, pazarlama ve satışın tek bir çatıda toplandığı büyümeden sorumlu ekiple de bir koordinasyon gerekiyordu. Geliştirilecek özellikler hakkında tanıtımların yapılması, webinarların hazırlanması, blog postların yazılması, sosyal medya postlarının hazırlanması gibi daha bir çok aktiviteden bu ekip sorumluydu ve üründe neler yapıldığının bu ekibe doğru bir şekilde iletilmesi gerekti.
Aynı şey destek ve güvenlik ekipleri için de geçerli. Şirket büyüdükçe buradaki gerekli prosedürlerle mühendislik ekibinin doğru bir şekilde koordine edilmesi, gelen yeni prosedürlere göre mühendislik ekibinin verimliliğini etkilemeden aradaki dengenin bulunması gibi sorumlulukları da yerine getirdik. Burada genelde hissettiğim şirkette kurulan her yeni ekiple sanki savaşılması gereken yeni bir cephe açılıyordu. Mevcut iş yükünüze yenilerinin eklenmesi gibi. Haliyle heryere yetişebilmek için aradaki dengeyi iyi bulmak gerekiyor. Burada en çok dikkat edilmesi gereken nokta, savaştığınız cephelerin çokluğundan dolayı elinizden geldiğince süreçleri otomasyona bağlamanız ve kendinizi olabildiğince gereksiz hale getirmeniz. Bu ekipler size bağlı değil kurulacak sistemlere bağlı hareket etmeliler. Bu şekilde sizin yokluğunuzda da işler aksamadan, herkes ne yapacağını bilerek doğru bir akış izlenebilir.
Toplantı, Toplantı, Toplantı!!!
Yönetim pozisyonunda görev yapıyorsanız zamanınızın büyük çoğunluğunun toplantılarla geçeceği gerçeğine alışmalısınız. Bu toplantılar çok farklı konularda olabiliyor ve haliyle her biri kendi özelinde farklı bir yaklaşım gerektiriyor. Toplantılarla ilgili tecrübe ettiğim ve naçizane size de önerebileceğim birkaç nokta var. İlki bir toplantı ayarlamadan veya başkasından gelecek bir daveti kabul etmeden önce toplantı konusunun mail üzerinden halledilip halledilmeyeceğini sorgulayın. Çoğu konunun toplantı gerektirmeden mail üzerinden halledilebileceğini unutmayın. Diğer bir konu daha önce de dediğim gibi takviminizde odaklanarak çalışabileceğiniz zaman dilimleri ayırın. Uzun vadeli önemli işler üzerinde çalışabilmeniz için bu zaman dilimlerine ihtiyacınız var. Aşkı halde günleriniz (benim durumumda olduğu gibi) asıl yapmak istediğiniz işler yerine takviminizdeki boşlukları dolduran plansız işlerle geçebilir.
Dikkat edilmesi gereken noktalardan biri de rastgele gelişen toplantılar. Teams veya Slack üzerinden gelen rastgele bir aramanın birçok kişinin dahil edilerek bir toplantıya dönüşmesi çok muhtemel. Bu yüzden bu tür rastgele aramalara kibarca “hayır” demenin yollarını bulmalısınız. Bu konuda ekibi de bu yönde yönlendirmeli ve rastgele gelişen toplantılara hayır deme kültürünü benimsemelisiniz.
Gelelim toplantılarla ilgili en önemli noktaya. Toplantı notları! Geçtiğimiz yıl farklı önem derecesine sahip toplantılarda bulundum. Bunlardan en önemlileri geliştirdiğimiz yazılımlarla ilgili toplantılardı. Yeni bir mimari tasarlanması veya mevcut mimarı üzerinde değişikliklerin yapılması, kritik bir hatanın düzeltilmesi, önemli bir yeni özelliğin planlanması gibi farklı farklı konuları ele aldık. Tecrübe ettiğim şeylerden biri de bu tarz önemli toplantılarda konuşulanlar zamanla unutulabiliyor veya alınan kararlar toplantıya katılan her bir katılımcı tarafından farklı şekillerde anlaşılabiliyor. Başlarda bu durum çok olmadı. Fakat takımdaki kişi sayısı ve geliştirilen yazılımlardaki özellik sayısı arttıkça toplantılarda alınan kararların uygulamada farklı bir şekilde işletildiğine tanık oldum. Alınan kararların dökümente edilmesi gerekliliği kendini başka şekillerde de gösterdi. Önemli birçok kararın alındığı bazı toplantıların bitiminde herkes alınan kararlarda hem fikirdi. Tüm konuşulanların birkaç gün sonra da tüm detayları ile birlikte hatırlanacağı sanıldı. Fakat iş uygulama safhasına geçince “Bu iş hakkında hangi kararı almıştık? Bu neydi, o neydi?” gibi sorular sorulmaya başlandı. Yanlış hatırlanmalardan dolayı yanlış uygulamaların yapıldığına da şahit oldum. Bu yüzden verebileceğim tavsiyelerden biri hafızanıza güvenmeyin, sizi yanıltabilir. Bunun sebebi hafızanızın zayıf olmasından ziyade gün içerisinde sürekli olarak yeni ve önemli bilgi bombardımanına maruz kalmanız. Bu yüzden her şeyi akılda tutmaktansa, alınan tüm kararları dökümente ederek daha sonradan açıp bakılabilecek bir referans kaydı oluşturmak daha akıllıca olur. Hem hafızamıza da çok yüklenmemiş oluruz.
Originally published at https://huseyinpolatyuruk.com on February 4, 2022.
