Spotify’ın ekip modeli hazır bir organizasyon şablonu değildir; şirketin belirli dönemdeki çalışma yaklaşımını anlatır. 2014 tarihli özgün sayfa, bunun tamamlanmış bir yolculuk olmadığını ve ekipler arasında farklılık bulunduğunu özellikle söylüyor. Dolayısıyla başka bir şirketin ekip adlarını veya kutularını kopyalamak, aynı işleyişi kurduğunuz anlamına gelmez. Sizin için doğru başlangıç, organizasyon çizelgesinden önce hangi bağımlılığın işi geciktirdiğini görmek. Sonra karar yetkisini, ortak bilgiyi ve çalışma sınırını bu ihtiyaca göre değerlendirebilirsiniz.
Özgün anlatı neye dikkat çekiyor?
Bir yönetim yaklaşımı popülerleştiğinde birkaç kelime bütün hikayenin yerine geçebilir. Ekiplerin adı değişir, sunuma yeni bir şema eklenir ve organizasyonun yenilendiği düşünülür. Ancak aynı onaylar ve bilgi beklemeleri sürüyorsa günlük iş pek değişmez.
Spotify Engineering’in 27 Mart 2014 sayfası, mühendislik kültürünü anlatan bir görsel sunum yayımlıyor. Yazılım danışmanı Henrik Kniberg’in bu anlatısında yolculuğun sürmekte olduğu, bütün ekipler için her zaman aynı şeylerin geçerli olmadığı açıkça belirtiliyor. Bu kısa sınır bile kaydı evrensel bir reçete gibi okumamamız için yeterli. Ayrıca 2014 kaydı, şirketin bugün birebir aynı organizasyonla çalıştığını göstermez.
Vakadan alınacak öğrenim, belirli kutuları savunmak değil; uygulamanın koşullarını merak etmek. Bir yapı hangi işi, hangi yeteneklerle, hangi karar sınırında yapıyor? Bu soruların cevabı olmadan yalnız isimleri değiştirmek zorlayıcı olabilir.
İlk öğrenim: Çözmek istediğiniz sorunu isimlendirin
Bir ekibi daha bağımsız yapmak istediğinizde bağımsızlığın neden gerekli olduğunu açıklayın. Müşteri düzeltmesini yapmak için sürekli başka onay mı bekleniyor? Uzmanlık mı eksik? Yoksa öncelik her gün mü değişiyor? Bu sorunların çözümleri aynı değildir.
Örneğin müşteri şikayetini çözmek için operasyon ve satış arasında bilgi gidip geliyorsa ilk ihtiyaç ortak kayıt olabilir. Ekibi yeniden adlandırmak bu bilgiyi kendiliğinden bir araya getirmez. Karar bekleniyorsa yetki sınırı konuşulmalı; teknik uzmanlık eksikse destek sağlanmalı.
Sorunu yazarken gözlenen durumu ve yorumunuzu ayırın. “Organizasyon kötü” yerine hangi işte, hangi noktada ve neyin beklediğini belirtin. Gözlemle varsayımı ayırma yaklaşımı, yapı tartışmasını daha somut hale getirir.
İkinci öğrenim: Bağımsızlık bilgi ihtiyacını kaldırmaz
Bir ekip kendi kararını verebilir, ama diğerlerinin işini etkileyebilir. Ortak müşteri, aynı sistem veya sınırlı uzman desteği gibi bağlantılar vardır. Bu bağlantıları yok saymak, hızlı kararların sonraki adımda çatışmasına yol açabilir.
Hangi bilgiyi ortak kullanacağınızı belirleyin. Fiyat listesi, teslim kapasitesi veya ürün özelliği farklı ekiplerde farklı sürümlerle tutuluyorsa sorun yetki değil doğruluk olabilir. Güncel kaynağın yeri ve değişiklik haberinin nasıl verileceği anlaşılır olmalı.
Bu düzen bütün kararları merkezi hale getirmek zorunda değildir. Ortak kaynağı kullanmakla her adımda onay istemek farklıdır. Ekibin kendi başına yapabileceği iş, danışacağı nokta ve birlikte karar vereceği konu ayrı yazılabilir. Çalışma ilişkisinin ihtiyacını görün.
Üçüncü öğrenim: Rol değişirken yetenek ve destek de değişir
Bir kişiye daha geniş görev verildiğinde bunun için gerekli bilgiye sahip olduğu varsayılmamalıdır. Daha önce yalnız tablo hazırlayan çalışanın, müşteri önerisini tek başına seçmesi yeni bir sorumluluk olabilir. İş dağılımı kadar gelişim desteği de düşünülür.
Önce yeni rolün gerçek görevlerini karşılaştırın. Hangi adım için deneyim var, hangisinde birlikte çalışma gerekiyor? Eksikleri kişiye “uyum sağlayamıyor” etiketiyle yüklemek yerine gerekli uygulamayı belirleyin. Yeni yapı, öğrenme ihtiyacını görünür yapabilir.
Üst rol için yetenek açığını belirlemek, bu karşılaştırmanın kişisel tarafını destekler. Unvanın değişmesiyle görevleri yapabilmek aynı sonuç değildir. Kanıtı iş örneğinden okumak daha yararlıdır.
- Sorunu tanımlayın
Yapı değişikliğinin hangi gecikmeyi çözmesi gerektiğini yazın.
- Bağımlılığı belirleyin
Ekiplerin birbirinden hangi karar ve bilgiyi beklediğini görün.
- Dar kapsamda sınayın
Yeni çalışma sınırını tek iş üzerinde deneyip sonucu değerlendirin.
İki ekip arasında teslim sorununun incelenmesi
Şöyle bir durum düşünün: Pazarlama, satış ekibinin istediği kampanya dosyasını hazırlıyor. Satış, son anda müşteri koşullarının farklı olduğunu söylüyor ve dosya yeniden yapılıyor. Yönetim ekipleri birleştirerek sorunu çözmeyi düşünüyor. Önce son teslimin nasıl ilerlediğini inceliyorsunuz.
Çalışma notunda üç bekleme görülüyor: satıştan hedef müşteri bilgisi, ürün ekibinden onaylı özellik, pazarlamadan hazırlanmış metin. Yeniden çalışma, ilk müşteri bilgisinin eksik olmasından kaynaklanıyor olabilir. Bu durumda birleşme kararı vermeden ortak görev başlangıcını iyileştirmek denenebilir.
Doldurulmuş başlangıç kaydı şöyle olur: “Hedef: mevcut müşteriye yeni kullanım alanını anlatmak. Kullanılacak ürün bilgisi: onaylı özellik sayfası. Hariç: fiyat taahhüdü. Son kontrol: satış temsilcisi. Açık soru: hangi müşteri örneği kullanılacak?” Bu kayıt ekibin adından bağımsız olarak iş ilişkisini açıklıyor.
Tek kampanyada deneyin. Eksik bilgi erken görüldü mü? Dosyanın sahibi belli miydi? Son anda eklenen talep gerçek bir yeni ihtiyaç mıydı, baştan bilinebilecek bir ayrıntı mı? Farkı kaydedin. Bir işin sorunsuz geçmesi bütün organizasyonun değişmesi gerektiğini veya gerekmediğini tek başına kanıtlamaz.
Deneme sonunda ekiplerle konuşun. Pazarlama artık her şeyi satışa onaylatıyorsa yeni bir gecikme oluşturmuş olabilirsiniz. Bilgi gerekli olduğu halde kimse bakımını yapmıyorsa kayıt kısa sürede eskir. Sorumluluğu kullanıcılarla birlikte netleştirin. Tek kaydın farklı ekiplerde nerede kullanılacağını da gösterin. Böylece aynı bilgi yeni bir dosyada tekrar yazılmak yerine güncel kaynağından alınabilir; değişiklik olduğunda kimin haber vereceği anlaşılır olur.
Gerekirse yapı değişikliği sonraki adım olur. Ama bu kez kararın hangi soruna cevap verdiğini ve hangi öğrenmeye dayandığını bilirsiniz. Bir şirketin başarılı görünen şemasına benzemekten daha değerlisi, kendi işinizdeki bağlantıları çözebilmektir.
Kendi rolünüzün değişen beklentilerini bir gelişim planına dökmek isterseniz 12jobs ile planınızı oluşturabilirsiniz. Şirket modelleri, sorularınızı zenginleştirebilir; sizin koşullarınızı değerlendirmenin yerine geçmez.
Sık sorulan sorular
Spotify modeli yanlış bir yaklaşım mı?
Bu yazının iddiası o değil. Belirli bir şirket anlatısını hazır ve evrensel şablon saymamak gerekiyor. Özgün kaydın kendi sınırlamalarını okumak, hangi ilkenin kendi işinize uygun olduğunu daha dikkatli seçmenize yardım eder.
Ekip adlarını değiştirmek neden yeterli değil?
Onay, bilgi ve kaynak ilişkileri aynı kaldığında günlük iş de aynı kalabilir. Yapının amacı hangi bağımlılığı değiştirmekse onu açık yazın. İsimler anlaşmayı kolaylaştırabilir, fakat karar düzeninin yerine geçmez. Sorunu gerçek teslimde gözleyin.
Küçük şirkette nasıl başlangıç yapabiliriz?
Son geciken işte kimden hangi bilginin beklendiğini çıkarın. Tek bir başlangıç kaydını birlikte deneyebilirsiniz. Çalışma anlaşması, beklentileri ekip büyüklüğünden bağımsız olarak netleştirmeye yardımcı olur.
Yapı değişikliğinin sonucu neyle izlenir?
Sorunun kendisine uygun işaret seçin: bekleme, yeniden çalışma, belirsiz karar veya yanlış bilgi. Yeni kutuların sayısı başarı ölçüsü değildir. Değişen iş yoğunluğunu da not edin; sonucu bütün koşullardan bağımsız tek nedene bağlamayın.
