OKR'lere Ulaşmak vs. İşini Yapmak

• Mühendislikte çeyreklik OKR'ler (Objectives & Key Results), ürün planlamasıyla örtüşüyormuş gibi hissettirir
  • Genellikle "roadmap'i yürütmek" ile aynı anlamda yorumlanır
  • Eğer OKR'ler roadmap'ten farklı şeyler içeriyorsa, bu durumda roadmap ile çatışır
  • Varsayımsal örnek
    • Objective: Frontend Observability sağlamak
    • Key Result: 1. aşamadaki tüm özellikleri sunmak
    • Key Result: hata oranını %3'ün altında tutmak
    • Key Result: günde 1000 kullanıcının etkileşimde bulunması
• Pazarlamada ise çeyreklik OKR'ler şirketin niyetini açıkça ifade eder ve etkili şekilde çalışır
  • Pazarlama ekibi OKR yazımı konusunda daha az şikayet eder
  • Varsayımsal örnek
    • Objective: Frontend Observability lansmanıyla pipeline'ı canlandırmak
    • KR: 3 basın kuruluşunun lansmanı haber yapması
    • KR: landing page'in 2000 kez ziyaret edilmesi
    • KR: hedef hesaplardan 100 adet pazarlama nitelikli lead (MQL) elde etmek
• OKR neden pazarlamada daha kolay?
  • Kısmen şundan:
    • Pazarlama, çeyrek ya da iki çeyrek içinde tamamlanabilen proje işlerine daha çok benzer
    • Mühendislik ise sürekli güncellenen bir ritimde ilerleyen, devamlı ürün işi gibidir
  • Elbette pazarlamada da tekrarlayan bir iş ritmi vardır
    • reklamlar, webinar'lar, e-posta gönderimleri, etkinlikler vb.
    • OKR, bu çeyrekte hangi reklam, webinar, etkinliklere odaklanılacağını net biçimde ifade eder
    • Bu, kampanya özetiyle örtüşebilir ancak yeni kampanyalara, yeni hedeflere veya kanallara odaklanır
    • Sadece bu çeyrekte "her çeyrek yapılmayan yeni şeyler için" hangi maliyet ve zamanın harcandığını anlatır

Genel olarak düzenli şekilde süren işler OKR'de yer almaz. KPI'ın (anahtar performans göstergesi) amacı tam da budur

• Pazarlamada, "satış fırsatına" dönüşen "lead kazanımı" gibi temel iş için KPI'lar vardır ve bunlar sayılır
  • web trafiği, reklam performansı, SEO sıralamaları, webinar katılımı, etkinliklerde kurulan temas sayısı izlenir
  • Bu KPI sayıları, yalnızca yeni bir kitle ya da yeni bir mesaj gibi bir şeyi iyileştirmek veya farklı şekilde elde etmek istendiğinde OKR'de görünür
  • OKR; odak kaymasını, süreç değişikliğini veya yapmamız gereken konuşmaları ifade eder
  • Varsayımsal örnek
    • Objective: Honeycomb'un bilinirliğini 3 ülkede artırmak
    • Objective: fırsat başına maliyeti azaltmak
      • KR: MQL'den SQL'e dönüşüm oranını %7'den %10'a çıkarmak
    • Objective: yatırım yapmaya değer 2 use case bulmak
• Mühendislikte ise temel iş olan yazılım çalıştırma ve güncelleme dağıtımına ilişkin KPI'lar vardır
  • SLO'lar (Service-Level Objectives), deployment frequency gibi hızlandırıcı göstergeler sayesinde işlerin sorunsuz yürüdüğü anlaşılır
  • Roadmap'teki özellikleri yayınlamak temel işlerden biridir. Normalde OKR'ye dahil edilmemelidir
    • OKR, bu çeyrekte neyin değiştiğini, neyi değiştirmeye ve neyi öğrenmeye çalıştığımızı söyler
  • Varsayımsal örnek
    • Objective: Frontend Observability'nin sorunsuz lansmanı
      • KR: hata oranı %3'ün altında
    • Objective: 3 yeni ekip üyesini on-call rotasyonuna dahil etmek
    • Objective: başka ekiplerin 2 servisi benimsemesini sağlamak
    • Objective: timeline görünümünün tepkiselliğini iyileştirmek
      • KR: dağıtık izleme ile gecikmeye katkıyı belirlemek
  • Yukarıdaki örnekte "Frontend Observability'nin sorunsuz lansmanı" deniyor; peki bu zaten "roadmap dağıtımı"na dahil değil mi?
    • Özellik yayını sorunsuz lansmanın bir parçasıdır, ama konu bununla bitmez
    • Bu çeyrekte yayınlanacak tüm özellikler içinde bu özellik işletme açısından en önemli olanıdır
    • Bu özelliğin OKR'ye girmiş olması, insanlara başka işleri de ilerleteceğimizi, bug raporlarına hemen yanıt vereceğimizi ve bu yayını güçlü biçimde destekleyeceğimizi anlatır
  • Eğer ekibin OKR'leri roadmap'i tekrar ediyorsa, bu "iyileştirme girişimi olmadan mevcut durumu koruma niyeti" olarak yorumlanabilir
    • Yani bu, "bu çeyrek mevcut durumu koruma çeyreği" anlamına gelebilir ve bu iyi değildir
• OKR şudur: "Bu çeyreği farklı kılan ne?" "Yeni olan ne?" "Nasıl farklı olmak istiyoruz?" "Neyi öğrenmek istiyoruz?"
  • OKR'nin özel bir odağı vurgulamasını sağlayın. Her şeyi OKR'ye koymaya çalışmayın

[jhj0517]

Daha sonra sonucu sayılarla ifade edilebilen hedeflerle edilemeyen hedefleri iyi ayırt etmemiz gerekecek.

[aer0700]

Plan yapılırken piyasa koşullarına dair öngörüler de işin içine girer; peki bu öngörülerin yüzde kaçı istatistik, yüzde kaçı CEO'nun temennisi, bunu sayıyla ifade etmek zor olur herhalde.

[roxie]

Sayılarla ifade edilemeyen hedeflerin neler olduğunu düşünüyorsunuz?

[ethanhur]

OKR'ler, amaç odaklı organizasyonlar ve Agile'ın hepsi kulağa gösterişli geliyor ve sanki organizasyonun sorunlarını çözecekmiş gibi hissettiriyor; ancak gerçekte bunları iyi uygulamak zor maddeler değil mi diye düşünüyorum.

Bu aralar OKR'lerin de organizasyonun yetkinliklerine ya da işin yapısına göre gerçekten çok dikkatli değerlendirilip uygulanması gerektiğini düşünüyorum. İyi çalışmadığında ortaya çıkan maliyetin çok büyük olduğu kanısındayım.

https://x.com/sundarpichai/status/1543328071532523521

[GN⁺]

Hacker News görüşü

• Facebook'ta çalıştıktan sonra küçük bir ekipte çalışırken, OKR'ler ve performans değerlendirmeleri hakkında endişelenmeden çalışmanın ne kadar harika bir şey olduğunu fark ettim. Ekip içinde kendini markalaştırmak ve pazarlamak çok yorucuydu.

  • Sistem düşüncesi açısından, OKR'lerin insan faaliyetini sayılara indirgemesine temelden karşıyım. Bu, insanları gerçek sorundan koparıp yanlış yöne sevk ediyor.
  • W. Edwards Deming'in "The Essential Deming" adlı kitabında okuduğum bir anekdot aklıma geliyor. Şirket, petrolü mavnalarla taşıyan verimsiz sistemi iyileştirmek için yeni bir yönetici atadı; bu yönetici metrikler oluşturdu ama hedef koymadı. Sonuç olarak mavna kaptanları maliyetleri düşürmek için gönüllü olarak rekabet etmeye başladı ve proje büyük kâr getirdi.

• OKR'ler gibi şirket önceliği ve hedef belirleme çerçeveleri, ekipler arasındaki önceliklendirme yaklaşımı uyumsuzluklarını ortaya çıkarmaya yardımcı oluyor. Ancak şirketler bunu çoğu zaman angarya gibi görüp öğrenme fırsatını kaçırıyor.

• Bir lider olarak, OKR'ler ortaya çıktığında hedef odaklılık ve bunları sonuca çevirme ihtiyacı olduğunu anlıyorum. Ancak bunu iyi yapabilen liderler nadir; birçok lider sadece kendi alanını inşa etmekle ilgileniyor.

  • Bir mühendis olarak, OKR'leri, operasyonları ve haftalık planları kesintiye uğratan işler oluyor. İyi bir PM bunu azaltabilir ama çoğu durumda böyle olmuyor.

• OKR'lerle hiç ilgilenmeyen insanlar da var. Şirkette 2-3 yıl çalışıp maaş artışı alıyorlar; ilk yılı rahat geçiriyor, ikinci yılda ciddileşiyor, üçüncü yılda ise yeni fırsatlar arıyorlar.

• Teknik olmayan bir alanda iç müşterilere yönelik çalışıyorum ve OKR'ler dayatılıyor. Ürün yöneticileri geliştiricilerle kullanıcılar arasında konumlanıyor ve ekipler arası koordinasyon olmadan her ekip kendi OKR'lerini yazıyor.

  • Örneğin, bir ekip betonu %15 daha az kullanmak isterken başka bir ekip binayı %15 daha yüksek yapmak istiyor. Bu, gerçek müşteri ihtiyaçlarını yansıtmıyor.

• Hızlı sonuç isteyen insanların Agile, OKR'ler ve KPI'ları okuyup kendilerini zor duruma sokmasını izlemeyi seviyorum. Yöneticiler bunları dayatıyor ve uygulayan insanların bunları gerçekten anlamaya ayıracak zamanı olmuyor.

  • Hırslı genç insanlar bunu ileri taşıdığında ekip verimsizleşiyor ve ürün ekibi OKR'lere takıntılı hale geliyor.

• Yöneticiler, teknik çalışanlardan geri bildirim almadan OKR'ler belirliyor ve bir kez belirlendikten sonra bunlar değişmiyor. Bu, ekip dinamiklerini bozuyor ve insanları hedef metrikleri tutturmak için sistemi oynamaya itiyor. Sonuçta önemli yetenekler şirketten ayrılıyor.

• Her yeni metrik eklemesi bir üretkenlik vergisi getiriyor:

  1. Metrikleri kötüye kullanmaya harcanan zaman
  2. Metrikleri dokümante etmeye ve görünür kılmaya harcanan zaman