Scrum Master CV Şablonu: Kolaylaştırıcının Sessiz Emeğini Özgeçmişte Stratejik Bir Anlatıya Dönüştürme Rehberi

Scrum Master özgeçmişi yazmak, kulağa kolay gelen ama pratikte tuzaklarla dolu bir egzersizdir. Çünkü bu rol, özünde "yapan" değil, "yaptıran" değil, "kolaylaştıran" bir pozisyondur. Bir başka deyişle elde somut bir ürün, kod satırı, sunucu ya da tasarım dosyası yoktur. Aslına bakılırsa, bir Scrum Master'ın işi, çoğunlukla toplantı aralarındaki kısa konuşmalarda. Ekiplerin birbirini dinlemediği anlarda ya da backlog'da sıkışmış bir user story'nin sahibini arayan telefonlarda gizlidir. Kısaca, bu yüzden özgeçmişte bu "görünmez emeği" konuşturmak, başka hemen hiçbir teknik rolün özgeçmişinde olmadığı kadar gerekir.

Bu yazı, bir Cv şablonuYaklaşımıyla Scrum Master deneyiminin nasıl kurgulanacağını, hangi becerilerin nasıl yazılacağını ve hangi klişelerden kaçınılacağını ele alıyor. Amaç, adayın sadece etkinlik listesi sunan bir belge değil, etki anlatısı taşıyan bir özgeçmiş ortaya koymasını sağlamak.

"Master" sıfatının tuzağı: rolün özgeçmişe isabetsiz yansıması

Başvuru sahiplerinin çoğu, "Scrum Master" unvanındaki "Master" kelimesinin cazibesine kapılarak özgeçmişe yanlış bir ton yerleştirir. Genelde, sanki teknik bir mimari ya da ekip yöneticisiymiş gibi cümleler kurarlar: "X ekibini yönettim". "on kişilik bir geliştirici ekibine liderlik ettim", "sprint planlama sürecini sahiplendim". Bu cümlelerin her biri. Tek başına hatalı değildir; ama bir bütün olarak bakıldığında, rolün gerçek doğasını örtbas eder. Scrum Master, koltuğun arkasında oturan ve konuşmayı yöneten bir moderatör değildir. Aynı zamanda bir otorite figürü de değildir. Sahada, bu rol, ekibin kendi kendine organize olma kapasitesini koruyan. Büyüten ve gerektiğinde organizasyonun katmanları arasında tercümanlık yapan bir hizmetkâr liderdir.

Kısaca, bu yüzden "Scrum Master" unvanı özgeçmişte yazılırken, hemen yanına parantez içinde bir açıklama gelmesi düşünülmelidir.Servant Leader, Agile Coach, Team FacilitatorGibi tamamlayıcı ifadeler, okuyucunun zihninde yerinde bir çerçeve oluşturur.CvHazırlarken bu ufak detay, ATS taramasından da geçer; zira hemen her iş ilanı bu kelimeleri içerir.

Özgeçmişin sessiz kahramanı: hangi iş aslında anlatılmalı?

Scrum Master'ın iş tanımı, çoğu zaman takvimdeki etkinlikler üzerinden anlatılır: Daily stand-up, sprint planning. Refinement, retrospective ve review. Bu listeyi özgeçmişe yazmak, rolü tanımlamak için yeterli değildir; zira işin kendisi bu etkinliklerde değil, aralarında olur.

Stand-up'lar değil, o stand-up'ların arkasındaki karar

Genelde, daily stand-up on beş dakikalık bir etkinliktir; ama o on beş dakikanın verimli geçmesi için arkada yapılan iş. Çoğunlukla görünmez kalır. Gerçekte, bir geliştirici iki gündür aynı engele takıldığında, Scrum Master'ın o kişiyle yaptığı kısa yan sohbet. O engelin çözümü için atılan özel adımlar ve belki de ürün sahibiyle yapılan gizli bir anlaşma. Bunlar özgeçmişte anlatılması gereken asıl işlerdir.

Çoğu durumda, bunu yazmanın bir yolu, her deneyim satırında etkinliği değil, etkinliğin sonucunu yazmaktır. "Sprint planning toplantıları düzenledim" yerine "Ekiplerin sprint planlama sürecinde context switch yükünü azaltan bir planlama şablonu geliştirdim" gibi bir cümle. Basit değil. Pratikte, aynı işi anlatır ama rolün gerçek etkisini görünür kılar.

Retrospektifler değil, çatışma çözümü anları

Retrospektif, çoğu ekibin bir tür "şikâyet toplantısı" olarak gördüğü ama aslında psikolojik güvenliğin inşa edildiği yerdir. Scrum Master'ın buradaki asıl işi, formatı değiştirmekten çok, ekibin birbirine söyleyemediği şeyleri söyleyebileceği bir ortam yaratmaktır. Pratikte, bu, bazen bir teknik tartışmanın ortasında taraf tutmadan durabilmek. Kimi zaman iki kıdemli geliştiricinin arasındaki kişisel gerilimi yumuşatabilmek. Zaman zaman de sessiz kalan bir stajyerin sesini duyurmaktır.

Genelde, bu tür anları özgeçmişe taşımak için abartılı sahne anlatıları kurmaya gerek yoktur. "İki geliştirici arasındaki teknik boru tartışmasını. Açıkçası, çift programlama oturumlarına dönüştürerek ekip içi iş birliğini artırdım" gibi bir cümle yeterlidir. Buradaki anahtar, kişisel çatışmayı kişisel düzeyde anlatmak değil, onu ekibin işleyişine dair bir öğrenmeye çevirmektir.

Velocity değil, teslimat kalıplarının yorumu

İşin aslı, velocity, Scrum Master'ın özgeçmişinde yazılacak en tehlikeli metriktir. Zira velocity, ekiptir, ekip tarafından üretilir; Scrum Master'ın kişisel başarısı değildir. Bir önceki sprintte kırk iki story point, sonraki sprintte elli altı story point. Bu sayılar, özgeçmişte doğrudan yazıldığında, sanki bir pazarlama temsilcisinin aylık satış rakamı gibi durur. Oysa velocity'nin neden düştüğü, neden yükseldiği. Şöyle ki, hangi ekiplerde tutarlı olduğu, hangi ekiplerde dalgalandığı, bu yorumlama, Scrum Master'ın analitik kapasitesini kanıtlar.

Burada önerilen, velocity sayısından çok "teslimat tahminlerinin güvenilirliği" kavramını öne çıkarmaktır. Söz gelimi, ekiplerin sprint sonunda taahhüt ettiği işi tamamlama oranının zaman içinde nasıl değiştiğini anlatmak, hem Agile olgunluğa hem de Scrum Master'ın bu olgunluğu nasıl inşa ettiğine dair çok daha güçlü bir kanıt oluşturur.

Kolaylaştırma kelimesinin özgeçmişteki yankısı

"Facilitation" ya da Türkçesiyle "kolaylaştırma", Türkiye'deki özgeçmişlerde en çok yanlış kullanılan kelimelerden biridir. Açıkçası, çünkü çoğu kişi, kolaylaştırmayı bir toplantı yönetme becerisi olarak algılar. Oysa kolaylaştırma, bir insanın ya da bir ekibin, kendi kararlarını kendi vermesini sağlayacak ortamı inşa etmektir. Bu, sahne arkasında, görünmeden çalışan bir beceridir.

Somut eylemlerle dolu bir kolaylaştırma anlatısı

Bir özgeçmişte "ekip toplantılarını kolaylaştırdım" yazmak, neredeyse hiçbir şey söylememekle eşdeğerdir. Bunun yerine, kolaylaştırmanın neye dönüştüğü yazılmalıdır:

• Ekiplerin birbirine doğrudan geri bildirim vermeye başladığı bir kültürel dönüşüm
• Kısaca, toplantılarda konuşma süresinin dağılımını daha eşit hale getiren bir müdahale
• Sessiz üyelerin söz alması için tasarlanmış bir format
• İşin aslı, karar alma sürecinde oybirliğinden çoğunluğa geçiş için yapılan bir çerçeve çalışması

Bu tür somut ifadeler, ATS sistemlerinin de yakaladığı. Aynı zamanda insan kaynakları uzmanının gözünde "bu kişi işi biliyor" dedirten ifadelerdir.

"Yönettiğim ekip" yerine nasıl yazılır?

Scrum Master özgeçmişlerinin en belirgin hatalarından biri, "on kişilik bir yazılım ekibini yönettim" cümlesidir. Bu cümle, doğrudan yanlıştır; zira Scrum Master, ekibi yönetmez. Ekip, kendi kendini yönetir. Scrum Master'ın ekiple ilişkisi, yöneten-yönetilen değil, hizmet eden-hizmet alan ilişkisidir. Aynı zamanda, Scrum Master'ın doğrudan raporları yoktur; ekip üyelerinin performans değerlendirmesini de yapmaz.

Bu yüzden özgeçmişte, "ekibi yönettim" yerine "ekibin kendi kendine organize olma kapasitesini geliştirdim" ya da "ekipteki karar alma süreçlerini kolaylaştırdım" gibi cümleler kullanılmalıdır. Sonuç net. Kısaca, bu küçük dilbilgisel tercih, özgeçmişin tamamına yerinde bir ton verir.

Engelleri Kaldırmak: Çoğu CV'nin Atladığı Bölüm

Scrum Master'ın en temel sorumluluklarından biri, ekibin önündeki engelleri kaldırmaktır. Bu engeller teknik olabilir, organizasyonel olabilir, kültürel olabilir. Genelde, ama özgeçmişlerde bu bölüm çoğunlukla ya çok yüzeysel ya da hiç yoktur.

Organizasyonel engeller

Genelde, organizasyonel engeller, Scrum Master'ın çoğu zaman en çok emek harcadığı ama en az konuştuğu alanlardır. Bir ürün sahibinin sürekli backlog değiştirmesi. Üst yönetimin sprint ortasında acil işler vermesi, başka bir ekibin API'sinin sürekli bozulması. Tasarım ekibinin tasarımları sprint başına yetiştirememesi. Bir noktada, bunlar, Scrum Master'ın organizasyonun değişik katmanları arasında diplomatik dil kurmasını gerektiren durumlardır.

Bu tür engellerin özgeçmişe yazılması, adayın sadece ekip içinde değil, organizasyon genelinde etki yaratabildiğini ortaya koyar. Pratikte, "Ürün sahibinin scope değişikliklerini sprint ortasına yayma eğilimini. Frozen backlog uygulamasıyla sınırlandırdım" gibi bir cümle, okuyucuya somut bir müdahale anlatır.

Ekip içi engeller

Ekip içi engeller daha hassas bir konudur. Somut olarak, zira burada ekseriyetle insan ilişkileri, motivasyon düşüklüğü, bilgi paylaşımı eksikliği, kişisel çatışmalar gibi konular vardır. Bunları özgeçmişe yazarken, kişi isimleri vermeden ve kişisel detaylara girmeden, sürecin ve sonucun üzerinden konuşmak önemlidir.

"Ekipteki iki kıdemli geliştirici arasındaki teknik tartışmaların sprint planlamayı kilitlediği bir dönemde. İşin aslı, çift programlama ve mob programming oturumlarını hayata geçirerek tartışma ortamını iş birliği ortamına dönüştürdüm."

Bu tür bir cümle, durumu anonimleştirir ve sonucu öne çıkarır. Kişisel çatışmanın detayına girilmez; ama müdahalenin ne olduğu ve nereye evrildiği net biçimde yazılır.

Metrikleri doğru kullanmak: velocity tuzağı

Scrum Master'ın özgeçmişinde metrik kullanmak, hem fırsat hem tehlike barındırır. Zira metrikler, somut kanıtlar sunar; ama hatalı metrik, hatalı bir hikâye anlatır.

Hangi metrikler Scrum Master için anlamlı?

Scrum Master için anlamlı metrikler, ekibin nasıl çalıştığını gösteren metriklerdir. Velocity'nin kendisi değil, velocity'nin tahmin edilebilirliği. Açıkçası, sprint burnout, bir başka deyişle sprint sonunda yetiştirilemeyen iş oranı. Ekip içi çapraz fonksiyonellik oranı, birden fazla iş tipini yapabilen üye sayısı. Toplantı yükü dağılımı. Kısaca, defect escape rate, bir başka deyişle müşteriye ulaşan hata oranı. Team happiness index gibi anketlerle ölçülen psikolojik güvenlik göstergeleri.

Bu metriklerden herhangi birini özgeçmişe yazarken, sadece sayıyı değil. Bir noktada, sayının zaman içindeki değişimini ve bu değişimin nedenini yazmak gerekir. "Sprint burnout oranı belirgin biçimde düştü" gibi bir ifade güçlüdür; ama yanına "bu düşüş. Genelde, refinement sürecini sıkılaştırarak ve Definition of Ready kriterlerini netleştirerek sağlandı" gibi bir açıklama gelmediğinde havada kalır.

Metrikleri insan hikâyelerine dönüştürmek

Metrik, insanın önüne geçtiğinde, bir Scrum Master'ın özgeçmişini soğuk ve teknik bir belgeye dönüştürür. Çoğu durumda, oysa bu rolün doğası gereği, anlatılan şey sayılar değil, o sayıların arkasındaki insan dönüşümleridir. Bu yüzden, metriklerin hemen yanında sınırlı bir bağlam cümlesi yazmak yeterli olacaktır: "Ekipteki sessiz üyelerin söz alma sıklığı belirgin biçimde arttı. İşin özü bu. Pratikte, bu, retrospektif formatını değiştirerek ve konuşma süresini bilinçli olarak dağıtarak mümkün oldu" gibi.

Koçluk becerisini özgeçmişe yazmak

Şöyle ki, koçluk, Scrum Master'ın en çetrefilli anlatılan becerilerinden biridir. Zira koçluk, sonuç odaklı değil, süreç odaklıdır. Net konuşmak gerekirse, bir koç, ekibin kendi çözümünü bulmasını sağlar; ama bu çözümün doğrudan koça atfedilmesi zordur.

Mentor mu, koç mu, danışman mı?

Bu üç kelime, özgeçmişlerde sıklıkla birbirinin yerine kullanılır. Ama aralarında önemli farklar vardır:

• Aslına bakılırsa, mentor: Deneyimli birinin, daha az deneyimli birine uzun vadeli rehberlik etmesi
• Koç: Belirli bir hedef için, sorularla kişinin kendi çözümünü bulmasına yardım etmesi
• Danışman: Konuya dair tavsiye veren, çoğu zaman spesifik bir soruna çözüm sunan kişi

Scrum Master, çoğunlukla bu üç rolün bir karışımını üstlenir. Ama özgeçmişte "ekibimi koçluk ettim" yazmak yeterli değildir. Gerçekte, bunun yerine, koçluğun ne tür bir gelişimle sonuçlandığı yazılmalıdır: "İki junior geliştiricinin ilk kez bir user story'nin tüm yaşam döngüsünü sahiplenmesini sağladım" ya da "Ekip içindeki bir teknik lider adayının. Kendi fikirlerini ekip toplantılarında sunabilmesi için güven inşa ettim."

1:1'lerin özgeçmişteki yeri

Kısaca, birçok Scrum Master, ekip üyeleriyle düzenli 1:1 görüşmeler yapar. Bu görüşmeler, çoğunlukla haftada otuz dakikadır ve içeriği özelleştirilmiş konulardan oluşur. Ama 1:1'ler, özgeçmişte nadiren yazılır. Zira çoğu kişi, 1:1'leri "toplantı" olarak görmez ve özgeçmişe taşımaya değer bulmaz.

Aslına bakılırsa, oysa 1:1'ler, bir Scrum Master'ın ekipteki en derin müdahalelerini yaptığı alanlardır. Burada bir üyenin kariyer kaygısı dinlenir. Sahada, başka bir üyenin motivasyon düşüklüğü keşfedilir, bir başkasının teknik bir konuda yönlendirmeye ihtiyacı olduğu anlaşılır. Bu görüşmelerin toplam etkisini özgeçmişe yazmak, "ekip içi iletişimi güçlendirdim" gibi yüzeysel bir cümleden çok daha anlamlıdır. "Düzenli 1:1 formatıyla ekip üyelerinin kariyer gelişim planlarını takip ederek terfi süreçlerini destekledim" gibi bir cümle. Somut ve inandırıcıdır.

Stakeholder yönetimi: organizasyonun dönüşüm anlatısı

Scrum Master, sadece ekibin içinde çalışan biri değildir. Aynı zamanda ekibin organizasyonla konuşma biçimini belirleyen. Üst yönetimden gelen sinyalleri ekibe taşıyan, ürün sahibinin kararlarını sorgulayan bir aracıdır. Bu aracılık rolü, özgeçmişlerde çoğunlukla "diğer ekiplerle koordinasyon sağladım" gibi genel bir cümleyle geçiştirilir.

Oysa bu rol, çok daha somut yazılabilir:

• Üst yönetimin Agile olgunluk düzeyini artırmak için düzenlenen yönetici brifingleri
• Gerçekte, ürün sahibinin backlog önceliklendirmesini, ROI ve müşteri değeri çerçevesinde yeniden tasarlama süreci
• Dış müşterilerle yapılan demo oturumlarında ekibin anlatı stratejisini güçlendirme
• Kısaca, diğer Scrum Master'larla birlikte kurum içi bir Agile topluluğu oluşturma

Bu tür çalışmalar, özgeçmişin "Organizasyonel Etki" bölümünde yazılmalıdır. Çünkü bu bölüm, adayın sadece bir ekibin değil, organizasyonun dönüşümünde rol aldığını kanıtlar. Birden fazla ekiple çalışan ve kurum genelinde Agile pratiklerini yaygınlaştıran bir Scrum Master. Bu bölümü doldurabildiği ölçüde öne çıkar.

Açıkçası, cV'nin Yapısal Anatomisi: Bir Scrum Master Özgeçmişinin İskeleti

Bir Scrum Master özgeçmişinin iskeleti, klasik teknik rollerden farklıdır. Kısaca, çünkü bu rolde "yaptığım projeler" yerine "etki alanlarım" vardır. Aşağıda, bu iskeletin ana bölümleri yer alıyor.

Özet bölümü

Özet bölümü, dört ile altı cümle arasında olmalıdır. Bu bölümde şunlar sıralanmalıdır:

1. Toplam deneyim yılı ve kaç değişik ekiple çalışıldığı
2. Endüstri ya da sektör bilgisi (finans, e-ticaret, SaaS gibi)
3. Öne çıkan yetkinlik (organizasyonel dönüşüm, koçluk, multi-team koordinasyon gibi)
4. Sertifika bilgisi (PSM I/II/III, CSM, SAFe gibi)
5. Kariyer hedefi ya da değer önerisi

"On yılı aşkın deneyimle, başka ölçeklerde çok sayıda ekibin Agile dönüşümünü kolaylaştırdım. Gerçekte, ekiplerin kendi kendine organize olma kapasitesini geliştirmeye, organizasyonların Agile olgunluk seviyesini artırmaya odaklanıyorum. PSM II ve SAFe SPC sertifikalarına sahibim." gibi bir paragraf. ATS'nin de yakaladığı, insan gözüne de hitap eden bir giriştir.

Deneyim bölümü

Net konuşmak gerekirse, deneyim bölümünde her pozisyon için şu yapı kullanılmalıdır:

• Firma adı, pozisyon unvanı, çalışma tarihi
• Ekip büyüklüğü ve ekibin bağlı olduğu organizasyonel yapı
• Üç ile beş arasında etki odaklı madde

Bu maddeler, "yaptım" değil "etki yarattım" üzerine kurulu olmalıdır. Her maddenin sonunda, mümkünse somut bir sonuç ya da ölçüm yer almalıdır. Bir deneyim satırı şöyle başlayabilir: "On iki kişilik iki ürün ekibinin Scrum Master'ı olarak görev aldım. Üç ay içinde sprint tahmin doğruluğunu belirgin biçimde artıran bir Definition of Ready kontrol listesi hazırladım. Genelde, ekipler arası bağımlılık yönetimi için haftalık bir senkron ritüeli tasarladım."

Yetkinlikler bölümü

Yetkinlikler bölümü iki sütuna ayrılabilir. Bir sütunda teknik olmayan, davranışsal yetkinlikler; diğer sütunda akış ve metodoloji ile ilgili yetkinlikler yer alır.

Davranışsal yetkinlikler:

• Çatışma çözümü
• Koçluk ve mentorluk
• Psikolojik güvenlik inşası
• Aktif dinleme
• Adaptasyon ve belirsizlik yönetimi

Aşama yetkinlikleri:

• Scrum, Kanban, Scrumban
• SAFe, LeSS, Nexus gibi çerçeveler
• Jira, Confluence, Miro, Notion gibi araçlar
• OKR ve KPI tasarımı
• Agile metrikleri ve raporlama

Bu iki sütunu birleştirip tek bir "Yetkinlikler" listesi yapmak, ATS uyumluluğu açısından daha güvenli bir tercih olabilir. Ama iki sütunlu yapı, görsel olarak daha okunabilir bir cv şablonu ortaya çıkarır.

Sık yapılan hatalar ve kaçınılacak klişeler

Scrum Master özgeçmişlerinde tekrar eden bazı kalıplar var. Bu kalıplar, zaman içinde o kadar yerleşmiş ki, çoğu aday bunları farkında olmadan kullanıyor.

İlk hata:Somut olarak, "Agile mindset" gibi soyut bir ifadeyi yetkinlik olarak yazmaktır. "Agile mindset" bir yetenek değil, bir yönelimdir. Bunu yazmak yerine, bu yönelimin nasıl bir davranışa dönüştüğü yazılmalıdır.

İkinci hata:Sertifikaları özgeçmişin en üstüne koymaktır. Sertifikalar, deneyimin yerini tutmaz. Bu yüzden sertifikalar, özgeçmişin sonuna ya da "Ek Bilgiler" bölümüne yerleştirilmelidir.

Üçüncü hata:Her iş deneyiminde aynı etkinlikleri sıralamaktır. Genelde, "Daily, planning, retrospective, review" gibi bir liste, her deneyimde tekrarlandığında, özgeçmişe hiçbir derinlik katmaz. Bunun yerine, her rolde başka bir zorluk ve değişik bir müdahale anlatılmalıdır.

Dördüncü hata:Özgeçmişi gereğinden fazla uzun tutmaktır. Scrum Master rolü, kısa ve öz anlatıya daha uygundur. İki sayfayı geçen bir özgeçmiş, çoğu zaman okunmadan elenir. Bu yüzden her cümlenin bir işe yaraması, her maddenin bir etki taşıması gereklidir.

Beşinci hata:Sadece teknik takımlarla çalıştığını varsaymaktır. Oysa bir Scrum Master, ürün ekipleriyle, tasarım ekipleriyle, veri ekipleriyle, hatta pazarlama ve satış ekipleriyle çalışmış olabilir. Çapraz fonksiyonel deneyim, özgeçmişte açıkça yazılmalıdır.

Sertifikaları ve topluluk katkılarını konumlandırmak

Çoğu durumda, pSM, CSM, SAFe, PMI-ACP gibi sertifikalar, Türkiye'deki iş ilanlarının çoğunda "aranılan nitelik" olarak listelenir. Bu yüzden sertifikaların özgeçmişte isabetli yerde ve isabetli formatta yer alması gereklidir.

Sertifikaları yazarken, sadece sertifika adı değil, sertifikanın alındığı yıl ve kurum da yazılmalıdır. "PSM II" yerine "PSM II, Scrum.org, 2022" gibi bir ifade, sertifikanın güncelliğini de gösterir. Aynı şekilde, sertifikaların yanına hangi yılda alındığı ve hâlâ geçerli olup olmadığı yazılırsa. Okuyucu zihninde "bu kişi sertifikayı bir kere aldı, sonra güncellemedi" sorusu oluşmaz.

Topluluk katkıları ise özgeçmişte fark yaratan bir bölümdür. Bir meetup grubunun kuruculuğu, bir konferansta konuşmacı olmak, bir blog'da Agile üzerine düzenli yazılar yazmak. Bir açık kaynak projede Agile danışmanlığı yapmak. Bunlar, adayın rolü sadece iş yerinde değil, iş dışında da sahiplendiğini ortaya koyar. Aslına bakılırsa, bu tür katkılar, başta orta ve üst düzey pozisyonlar için fark yaratır.

Son söz: görünmez işi görünür kılmak

Scrum Master özgeçmişi, özünde bir paradoksla uğraşır: Rolün en değerli yanı, görünmez olandır. Ekip kendi kendine organize olmaya başladığında, Scrum Master'a artık ihtiyaç duyulmaz; bu, başarının en hatırı sayılır göstergesidir. Ama özgeçmişte bu "görünmez başarı"yı anlatmak için. Gerçekte, somut kanıtlarla dolu, bağlamı güçlü, etkisi ölçülebilir cümleler yazmak iyi olur.

Doğru kurulmuş bir Scrum Master özgeçmişi, ne sadece bir etkinlik listesi ne de sadece bir metrik tablosudur. İkisinin arasında, insan hikâyesinin anlatıldığı bir köprü gibidir. Bu köprüyü doğru kurabilen adaylar, hem ATS'leri hem insan kaynakları uzmanlarını hem de mülakatta karşılaşacakları teknik liderleri etkileme şansına sahip olur.

Herhangi bir cv şablonu hazırlanırken bu rehberdeki çerçeveyi referans almak. İşin aslı, özgeçmişin her bölümünün aynı hikâyeyi anlatmasını sunar: Kolaylaştıran. Koçluk eden, engelleri kaldıran ve ekibin başarısını kendi başarısı olarak gören bir hizmetkâr liderin hikâyesini. Bu hikâye, bir cv şablonu içinde ne kadar tutarlı biçimde anlatılırsa, mülakat daveti almak o kadar kolaylaşır.