DevRel Ne İş Yapar? — 1. Kısım
Teknasyon’da DevRel Manager olarak ilk yılım, Developer Relations’ın 4 C’si ve (geliştiricilere yönelik bir ürününüz yoksa bile) neden bir DevRel’e ihtiyacınız olabilir?
Yaklaşık 1 yıl önce Teknasyon’a “Geliştirici İlişkileri (DevRel) Yöneticisi” olarak dahil oldum. İlk zamanlar bu durum –bana gelen onlarca soru gibi– benim de cevabını bilmediğim sorulara sahip bir süreç idi. Fakat bunu doğru şekilde anlayabilmek ve doğru stratejiler geliştirebilmek için bu konu üzerinde okumalar, çalışmalar yaptım. Getir’in eski DevRel’i Eser Ozvataf’tan bu alana girmeden önce oldukça tüyo ve ipuçları aldım; Teknasyon’un diğer yöneticileriyle de (CTO, HR Manager, GM, takım liderleri, vs.) bu konu etrafında sürekli olarak beyin fırtınaları yaparak bu süreci geliştirip olgunlaştırdık. Bu süreç boyunca Teknasyon’da çalışan birçok geliştirici ile 1–1 görüşmeler yapıp geri bildirimler topladım ve buradan edindiğim geri bildirimler bu konudaki stratejilerimi belirlememde oldukça faydalı oldu.
Bu mini el kitapçığı niteliğinde hazırlamaya çalıştığım bu yazı dizisinde bu süreci ve deneyimlerimi paylaşmaya çalışacağım. Bununla beraber içeride bu süreçte geliştirmeye çalıştığımız sistemi ve stratejilerimizi de aktarmaya çalışacağım. Umarım sizin ve ekibiniz için de faydalı olur.
Bu yazı dizisi 4 bölüm şeklinde yayınlanacak.
“DevRel” henüz dünya için de çok yeni sayılabilecek bir kavram. Her ne kadar geçmişi 80'lere kadar gitse de popüler olmaya da yazılım sektörünün çok büyük bir sektör haline gelmesiyle birlikte son 4–5 senede başladı. Bu yenilik onu çoğu zaman açıklamaya çok muhtaç hale getiriyor. Hala herkes tarafından net bir şekilde anlaşılmış değil, çünkü içeride benzer süreçler işletilse de bu görevler diğer farklı yöneticilere dağıtılmış durumda. Çok karıştırıldığı ve net anlaşılmadığı için şunu da netleştirmek gerek: “Geliştirici İlişkileri” diyince geliştiricilerin birbirleriyle ya da başka ekiplerle olan ilişkilerini yönetiyormuş gibi bir algı ortaya çıkabiliyor. “Geliştiriciler o kadar asosyal ki, ilişkilerini yönetmek için yönetici tutmuşlar”gibi bir algı bile oluştuğuna şahit oldum. Fakat işin aslı hiç ama hiç bu değil. Bu ünvan daha çok şirketin geliştiricilerle olan ilişkileri üzerine kurulu bir ünvan.
Öncelikle -hızlıca- DevRel’in 80'lere dayanan geçmişine bakalım:
DevRel’in Kısa Tarihi
Mary Thengvall’ın “What is DevRel?” konulu blog post’una göre ilk DevRel programı, Apple’ın 80'lerde Macintosh için uygulama geliştirici bulmak ve geliştiricilere bu konuda destek olmak için Mike Murray, Mike Boich ve Guy Kawasaki ile başlattığı “Developer Evangelism”in günümüzdeki uyarlaması. Dolayısıyla bu başlığın geçmişi de oldukça geriye dayanıyor.
Developer Evangelism vs Developer Relations
“Evangelist” kelime olarak “müjdeleme, yayma” anlamı taşıyor. Dolayısıyla “Developer Evangelist” aslında tam olarak bu işi yazılım anlamında yapıyor. Evangelistler developer-first (müşterisi geliştiriciler olan) bir teknoloji ürününü geliştiricilere tanıtıp, kullandırıp yaymaya yakın olan bir görev üstleniyor.
Developer Relations ise daha çok bir “şemsiye” terim. Altında evangelism (ya da advocation) yanında açık kaynak, dokümantasyon, topluluk yönetimi, geliştirici deneyimi gibi birçok alt kavramı da barındırıyor.
Özellikle geliştiricilere direkt geliştirme ortamları, araçları sunan “developer-first” şirketlerin geliştiricilerle ilişkisi çok yüksek düzeyde olduğundan bu ihtiyaçları çok daha yüksek önem arz ediyor. Fakat bu yazı serisinde “developer-first” olmayan şirketlerin de bu konuya nasıl odaklanabileceğine dair fikir edineceksiniz.
Peki DevRel Neden Bir Anda İhtiyaç Oldu?
Yazılım sektörünün son yıllarda kazandığı ivmeye bağlı olarak yazılım geliştirme ekosistemi çok gelişti, yeni alt uzmanlıklar oluştu, işler daha kompleks hale geldi. Bu karmaşıklık, pazarın büyüklüğü, insan kaynağının yükselmesi gibi nedenler geliştiricilerin kullandıkları ürün ya da şirketleri seçerken birçok parametreyi göz önünde bulundurmalarına neden oldular. Geliştiriciler için önemli olanı tespit etmek ve o alanı güçlendirmek ya da geliştiricilerin çalışma ortamlarındaki konforunu iyileştirerek bu karmaşıklık içerisindeki verimlerini ve motivasyonlarını yüksek tutabilmek bir ihtiyaç haline geldi. Eser Ozvataf’ın bir benzetmesiyle, geliştirme süreci bir UI (kullanıcı arayüzü) gibiyken, DevRel süreci ise UX (kullanıcı deneyimi) süreci olarak, bir ihtiyaç neticesinde ortaya çıktı. Özetle, DevRel, geliştiricilerin tüm bu ekosistemdeki uçtan-uca deneyimlerini tasarlamak ve iyileştirme ihtiyacının bir neticesi haline geldi. Büyük yazılım şirketleri, startup’lar, açık kaynak yazılımlar vb. ekosistemdeki hemen her varlık, bu konuda çalışmalar yapmaya başladılar.
Şirketlerin Geliştiricilerle İlişkileri
Her şirketin geliştiricilerle olan ilişkisi, yaptıkları işe göre bambaşka şekillerde, bambaşka amaçlarda olabilir. Bu da farklı DevRel stratejilerinin birbirinden çok ama çok farklı olmasına neden oluyor.
GitHub’ın geliştiricilerle olan etkileşimi ile Meta’nın (Facebook’un) geliştiricilerle olan etkileşimini çok farklı görebilirsiniz; çünkü geliştiriciler GitHub’ın müşterisi iken Meta’nın müşterisi değil, kullanıcısı. Ya da Google daha çok kendi geliştirdiği teknolojilerin kullanımı ve topluluk oluşturması için bir strateji üzerine gidiyor ve bunların tamamı (birbirlerinden ne kadar farklı olurlarsa olsunlar) “DevRel” yani “Geliştirici İlişkileri” olarak geçiyor.
Özetle, şirketlerin DevRel kavramından anladığı, hedefleri, varlık amaçları bambaşka olabiliyor. Teknasyon’un da DevRel tarafındaki hedef ve stratejileri kendine has bir biçimde farklılık gösteriyor.
DevRel’in Türleri Nelerdir?
Geliştiricilerin olduğu her yerde geliştirici deneyimi önemlidir. Bu temele dayanarak hem şirketimizde çalışan hem de şirketimizde çalışmaya aday, ya da topluluk üzerinde etkileşim kurduğumuz geliştiriciler olduğunu biliyoruz. Bu da bizim ekibimizdeki geliştiriciler için yürüttüğümüz sürece “Internal DevRel”; ekibimizde olmayan, dışarıda etkileşim kurduğumuz geliştiriciler için ise “External DevRel” olarak tanımlayabiliriz.
Teknasyon’un Geliştiricilerle Olan İlişkisi
Peki biz Teknasyon olarak geliştiricilerle nasıl bir ilişki içerisindeyiz? Bunu anlamak için öncelikle Teknasyon’u çok az da olsa tanımak gerekiyor:
Teknasyon bir teknoloji şirketi. Altında onlarca mobil uygulamalarla birlikte B2B/B2C SaaS projeler, direkt müşterilere ulaşan B2C projeler ve uygulamalar, şirket içerisinde geliştirilip içeride kullanılan onlarca aracı da mevcut. Tüm bu teknoloji yığınını geliştiren oldukça kalabalık bir geliştirici ekibine sahip. İşte tam bu noktadaki bu genişlik, “geliştirici ilişkilerini” daha önemli bir hale getiriyor.
Eğer teknoloji ekibi kalabalık bir topluluktan oluşuyorsa şirketinizde yönetmeniz gereken bir DevRel programına ihtiyacınız olabilir.
Teknasyon’un geliştiricilerle olan ilişkisi de büyümenin doğru şekilde gerçekleşmesi üzerine kurulu. Bir şirkette doğru şekilde büyümek ise temelde iki şekilde ilerliyor:
- Recruiting: Dışarıdaki yeni yetenekleri şirkete katmak
- Retention: İçerideki iyi yeteneklerin içeride kalmasını sağlamak
Bu iki hedefi sağlamak için ise uyguladığımız yöntemlerin temeline ise biz 4 C dedik. Gelin birlikte bu 4 C’yi inceleyelim:
Eğer developer-end bir projede DevRel yapıyorsanız, birebir aynı süreci ve stratejiyi recruiting değil, müşteri kazanma (sales) ve müşteri elde tutma (retention) olarak da uygulayabilirsiniz.
“Gerçekte ne yaptığınızı anlamadıkları için topluluğunuz tarafından kabul edilmediğinizi mi hissediyorsunuz?
Geliştirici İlişkileri’ne hoş geldiniz.”
— Mary Thengvall
DevRel Framework: “DevRel’in 4 C’si”
“DevRel’in 4C’si” sistemi bana ait ya da benim bulduğum bir yapı değil. DevRel okumaları yaparken SendGrid’in bir blog post’unda denk geldiğim ve çok beğendiğim bir sistem. (Herhangi bir kavram sistematik hale getirilince beni damarımdan yakalıyor, yazılımcı olduğum için diye düşünüyorum.)
Teknasyon’da uyguladığımız DevRel rolü yalnızca dışarıdaki geliştiricilerin değil aynı zamanda içerideki geliştiricilerin deneyimlerini de önemsiyor. İçerideki deneyimin ve dışarıya sunduğumuz deneyimin denk olması bizim için çok önemli. Zira geliştiricileriniz sizin birincil topluluğunuz.
Birlikte çalıştığınız geliştiricileriniz sizin birincil topluluğunuz.
Buradan yola çıkarak, orijinal yazıda her ne kadar “3 C” olarak tanımlansa da, içerideki geliştirici deneyiminin daha iyi bir hale gelmesi için çok önemli bir konu olan “Culture” temelini de bu C’ler arasına ekleyip (hem de en başa) bu yapıyı biraz genişlettik, modelledik ve derinleştirerek alt maddelerini oluşturduk. Şu an tüm DevRel stratejilerimiz bu framework üzerinde hareket ediyor.
Herhangi bir şirket –geliştiricilerle ilişkisi hangi şekilde olursa olsun– “geliştirici ilişkileri” yaklaşımlarını 4 ana temel üzerinde konumlar ve konumlamalıdır. Bu temellerin İngilizcelerinin baş harfleri C ile başladığı için “DevRel’in 4 C’si” diyoruz:
Culture, Community, Content, Code.
Şimdi, her bir C’yi alt maddeleriyle açıklamaya çalışacağım. Fakat her bir alt madde başlı başına ayrı bir uzmanlık konusu ve üzerine sayfalarca ayrıntı yazılabilir, bu nedenle özetlemeye gayret edeceğim.
Yukarıdaki grafikten de anlayacağınız üzere, her C’nin kendi içerisinde Internal ve External olarak dağılımları mevcut. Bunları şöyle kabaca oranlarsak pek de yanlış olmaz:
- Culture: 20% External, 80% Internal
- Community: 70% External, 30% Internal
- Content: 50% External, 50% Internal
- Code: 30% External, %70 Internal
1'inci C: Culture
Herhangi bir organizasyonda (şirket, topluluk, okul, vs.) her şey öncelikli olarak “kültür” ile ilişkilidir. Yanlış bir kültürde yapılan doğru işler yanlış sonuçlar ortaya çıkarabilir. Bu nedenle DevRel stratejileri ekibin/ekiplerin kültürünün doğru inşa edilmesi, daha iyi hale getirilmesi, bozulmasının engellenmesi ve iletişimin güçlendirilmesi temelleri üzerine inşa edilmelidir. Doğru kültür (1'inci C), diğer tüm C’lerin (community, code ve content) temelini oluşturur ve onları da ayakta tutar.
Doğru ekip kültürü, farklı insanların birlikte uyum içerisinde çalışmasını sağlar. Teknasyon’da doğru ekip kültürü oluşturmak DevRel stratejilerinin belki de en önemli tarafını oluşturuyor. DevRel stratejileri doğru kültürü geliştirme hedeflerine HR (İnsan Kaynakları) ve teknik ekiplerle karar veriyor ve bu konudaki stratejilerini birlikte belirliyorlar.
DevRel ekibi, doğru kültürün oluşması ve korunması konusunda HR ve teknik ekip liderleriyle birlikte stratejiler geliştirir.
Aynı zamanda, yine eğer geliştiricilerin dışarıda olduğu bir DevRel modelinde çalışıyorsanız, bu kültür sizin topluluk kültürünüzü de oluşturur. Bu nedenle “culture” ayağını bu durumda dahi dışarıda bırakmak doğru olmaz.
İletişim
Doğru kültürün en temel yapı taşı iletişimdir. İnsanların birbirlerini anlamadıkları, birbirlerini dinlemedikleri, kendilerini doğru ifade edemedikleri herhangi bir grup ya da organizasyonda gelişime açık, sağlıklı bir kültür oluşumundan bahsedemeyiz. Toplumda her ne kadar geliştiricilerin iletişim becerisi olmadığı genel kanısı var olsa da doğru iletişim kanalları ve doğru iletişim yöntemleri ile tüm insanlar iletişim kurmak isterler ve iletişim kurarlar.
DevRel stratejisi, doğru bir kültür inşa ederken bu doğru iletişim kanallarını da açmak üzerine geliştirilmelidir. Ekip üyelerinin birbirleriyle olan iletişiminin, hiyerarşik yapıdaki açık ve iki yönlü iletişimin, diğer ekiplerle olan ilişkilerinin doğru şekilde inşa edilmesi kültür altyapısının daha iyi olmasını sağlar.
Doğru ekip içi iletişimde öncül kural “mevcut sorunu, başka bir sorun ortaya çıkarmadan çözmeye çalışmak” olmalıdır. Bunu sağlamak için iletişimin bazı temel prensiplerini (farkında olmak, sorumluluk, saygı, güven) sağlamak gerekir. Sorunlar teknik ya da beşeri bir sorun olabilir. Toplantılar sonuçsuz kalmaz, alınan kararlar doğru şekilde uygulanır ya da uygulanamıyorsa neden uygulanamadığı paylaşılır. Yöneticiler ve çalışanlar birbirlerine açıktır. Eleştiriler kişiselleştirmeden yapılır, gelen eleştiri kişisel algılanmaz. Feedback kültürü insanların birbirlerini düzelterek daha iyi ekip üyeleri olmalarını sağlayacak şekilde inşa edilir.
Doğru iletişimin 4 temel prensibi: Sorumluluk, farkındalık, saygı ve güven.
İlk Katılım (Onboarding)
Ekibe yeni biri katıldığında karşılaştığı “kendi yolunu bulabilme”, “yardımseverlik” ve “hızlı adaptasyon” yöntemleri iyi bir kültürün oluşmasında rol oynar. Özellikle yazılım ekiplerinde projeye olan uyum süresi uzadıkça –özellikle junior– yeni geliştiriciler üzerindeki baskı hissi, imposter sendromu ve stresin çok fazla arttığı gözlemlenebilir. Bu durum geliştiricinin sorunu sistemde değil kendinde aramasına ve kendisini yetersiz hissetmesine neden olabilir. Halbuki yetersiz olan çalışan değil sistemin teknik onboarding sürecidir.
DevRel, geliştiricilerin girdikleri bu süreçleri optimize edecek “onboarding” sistemleri kurulması stratejileri üzerine çalışır. Kurulan doğru sistemler scale olur, insan sayısındaki büyümeyi rahatlıkla kaldırabilir. Ekibe kaç kişi gelirse gelsin, yöneticiler her geleni sisteme adapte etmekle uğraşmazlar; bunun yerine, geliştiriciler kendi kendilerini adapte edebilecekleri bir onboarding sistemi ile adaptasyon yollarını kendi kendilerine bulurlar. Sistem, her yeni geleni, kişilere en az ihtiyaç duyacağı yöntemlerle kendisine adapte etmeye meyilli olmalıdır. Yani insanlardan bağımsızlaştırılma hedeflenir. Birazdan bahsedeceğimiz “belgelendirme” (documentation) de bağımsızlaştırmanın bir parçası ve onboarding için önemli yapı taşlarından biridir.
Bu durum aslında developer-end şirketler için de geçerli. Yani şirketiniz, diyelim ki, açık kaynak bir proje geliştiriyorsa, ürününüzü kullanan kullanıcıların “onboarding” süreçlerini çok rahat ve hızlı bir şekilde aşıyor olmalarını beklemelisiniz ve bu süreçte support taleplerini minimize etmelisiniz.
Bununla beraber, İK ile yakın çalışılan bu onboarding sürecinde, geliştiricilerin işe alım süreçleri de iyileştirilir. Adayın doğru bir süreçle işe başvurusundan, bulunduğu projede ilk commit’ini attığı ve ilk sorunu çözdüğü sürece kadar gittiği yoldaki tüm süreç aday için doğru ve güzel bir deneyimle sunulmalıdır.
Kurumsal Hafıza
Geliştirici ekiplerinde alınan kararların “neden” ve “nasıl” sorularının cevapları kurumsal hafıza olarak tutulmalı ve kültür insanlardan bağımsız hale getirilmelidir.
İnsanlara bağımlılık oluşturmuş ve kurumsal hafızanın kişiler üzerinde tutulduğu bir kültürde sistem her an tehlike altındadır.
Bu bağımsızlaştırma konusundan bir önceki “ilk katılım” tarafında da bahsetmiştik; belgelendirme kısmında tekrar bahsedeceğiz. Doğru ve eksiksiz bir belgelendirme, doğru kültürün inşası için vazgeçilemez ve geri plana atılamaz. Kurumsal hafızanın da önemli bir kısmı yine belgelendirme ile desteklenir.
Şirket içerisinde alınan her teknik karar, geliştirilen bir kod parçasının nedenleri, kritik bilgiler, vb. tüm bilgi doğru şekilde kayıt altına alınıp hafıza oluşturulmalıdır.
Yine aynı şekilde, teknik hafızadan bağımsız olarak, geliştiricilerin talepleri, yöneticilerine bildirdikleri pozitif ve negatif tüm geri bildirimler kayıt altına alınmalı ve konular üzerindeki ilerleme karşılıklı olarak kontrol edilmelidir. Bunlara OKR’ları KPI’ları vb. de dahil edebilirsiniz.
DevRel stratejileri, kurumsal hafızayı tutmak ve korumak için stratejiler belirler ya da belirlenmesi konusunda yardımcı olur. Aynı zamanda mevcut hafızadaki sorunları tespit edip düzeltilmesi konusunda destek olmaya da çalışır. Tüm bunlar iletişimin güçlü olmasını sağlar ve DevRel’in hedeflerinden biri olan “retention” (çalışanı elde tutma) hedefine de katkı sağlar.
Uzaktan Çalışma
Özellikle son yıllarda internet sistemlerinin oldukça gelişmesi ve (pandeminin de etkisi ile) ekiplerin uzaktan çalışabilmelerinin önünün açılması “uzaktan çalışma” kültürünün oluşmasına neden oldu. Elbette bu kültür beraberinde birçok avantaj ve dezavantajı da getiriyor.
DevRel ve HR’ın recruitment hedeflerine daha hızlı ulaşmasında uzaktan çalışma çok büyük bir avantaj yaratıyor. Dünyanın her yerinden, konum bağımsız işe alım yapabilmek daha fazla yeteneğe erişimi sağlıyor. Şirketinizin daha hızlı büyümesinin de önünü açıyor. Ayrıca ekibinize sunmak zorunda olduğunuz ofis alanı konusunda da sonsuzluk sağlıyor. 90 kişilik bir ekip için 90 kişilik fiziksel bir ofisiniz olmasına gerek kalmıyor, bu da büyüme konusunda çok büyük bir avantaj.
Fakat madalyonun iki yüzü var. Uzaktan çalışan ekiplerde iletişim ve ilk katılım (onboarding) ciddi sekteye uğrayabiliyor. Bu durum ekip içerisinde negatif bir kültür oluşmasına neden olabiliyor. Geliştiriciler kendilerini sosyal bir ortamda bulamadıklarından kendilerini yalnız hissedebiliyorlar.
DevRel stratejileri uzaktan çalışan geliştiricilerin de kültür içerisine dahil olabilmesini ve ekibin kültürüne sahip olabilmesini sağlamayı amaçlar. Doğru bir uzaktan çalışma kültürüyle aynı zamanda verimin de daha yüksek olduğu gözlemlenebilir.
Çeşitlilik (Diversity)
Az önce “doğru ekip kültürü, farklı insanların birlikte uyum içerisinde çalışmasını sağlar” demiştik. İşte bu farklılıkların var oluşu, aslında bizim kültürümüzün doğru olduğunun bir işaretçisi olurken, aynı zamanda kültürümüzün daha doğru olması için de bir tohum, bir yatırım niteliği taşıyor. Bu çeşitlilik (diversity) döngüsü Teknasyon’da DevRel’in “doğru kültür” için var olmasını sağlamaya çalıştığı temel hedeflerden biri.
Çeşitliliği yüksek bir ekip çalışanlarının birbirlerini daha iyi anlamasını, daha yüksek empati kurabilmesini, durumlara farklı açılardan bakabilmesini sağlar. Dolayısıyla çeşitlilik, iletişimin en önemli ayaklarından biridir. Kültürü de daha geliştirilebilir bir pozisyonda tutar.
Verimlilik
Oxford Üniversitesi’nde yapılan bir araştırmaya göre, mutlu olan çalışanlar %13 daha verimli çalışıyorlar. Doğru bir iletişimle geliştirilmiş doğru bir kültür bize sonuç olarak verimliliği getiriyor. Doğru kültürde çalışan geliştiriciler ve ekipler daha mutlu oluyor. Mutluluk ise bize çoğunlukla verim olarak geri dönüyor.
Yazılım ekiplerinde “verimsizlik” çok karşılaşılan bir sorun. Herkes çok çalışır fakat çıktılar yeterince kaliteli olmayabilir. Bu durum hem maddi hem kültürel sorunlara neden olur. Mesai ihtiyacı artar, deadline’lar yetişemez. Ürünün pazara çıkışı gecikir. Herkes çok yoğundur, çok çalışıyordur fakat bir şekilde işler yetişmiyordur. Ekip motivasyonu düşer, insanlar bunalır. Hatta zaman zaman burnout’a kadar gidebilir.
DevRel stratejileri içerideki verimsizliği CTO ve teknik liderlerle birlikte çalışarak çözmeyi ve artırmayı hedefler. Bunun için içerideki geliştiricilerle sürekli olarak görüşüp verimsizliğin kaynağını bulmaya çalışır ve bunu yok etmek için stratejiler geliştirir. Verimsizliğin kaynağı şirketten şirkete, hatta ekipten ekibe çok farklı olabilir. Doğru bir kültüre sahip olan bir şirket ortaya çıkan verimsizlik kaynaklarını hızlıca yok edebilme eğilimi göstermelidir.
Sonuç olarak, şirketin geliştiricilerle ilişkisinde “kültür” çok önemli bir role sahip. Biz de bu nedenle “4 C” sisteminde, kültürü diğer tüm C’lerin başına koyduk.
Sonraki Bölüm: 2. C: Community. Yakında yayında…
Bu 4 bölümlük bir yazının ilk bölümü. 4 Bölüm tek seferde çok uzun olacağı için bölüştürerek yayımlamayı daha uygun buldum. Sonraki bölümlerle ilgili fikir edinmek için yukarıdaki framework’ü inceleyebilirsiniz.
Kaynaklar, yazı içerisinde linklenmiştir.
