This Week's Favourite Fraggl Links

Postsecret

Here are my favourite links from this week curated by Fraggl:

And of-course you can sign up to Fraggl here.

OKRs

Thanks to the always good Wunderkammer newsletter for pointing me at this piece on OKRs (Objectives and Key Results) the simple but very sensible organisational system that originated in Intel but has been a long-term staple at Google. The system, involving setting quarterly measurable, definitive objectives at a company, team and/or individual level, and then supporting that with quantifiable key results seems obvious but I suspect most companies fail to do it in quite such a simple, straight forward way.

I particularly liked the idea of a scoring system between 0-1 that not only highlights when things need serious attention but also one where the goal is not to achieve a perfect 1 (since that would mean your goals were too easy) but instead to aim for around 0.6-0.7.

And I also liked the way that Google apparently make all OKRs (from Larry Page down) public knowledge within the company, going as far as making them and the associated scores visible within the public directory and on internal profiles. This transparency helps everyone understand what everyone else is working on, ensuring greater empathy and understanding for individual or team priorities, and giving focus to how an individual might make their own priorities align with someone else’s in order to get stuff done. Simple. But then the best ideas always are.


Spotify Engineering Culture

Spotify Engineering Culture - part 1 from Spotify Training & Development on Vimeo.

I'm giving a talk at Learnfest today which has already proved to be a refreshingly different and fascinating conference (more on that later). Tamas Mihalovits, the Global Training Manager at Spotify (who ran one of the sessions here) told me about this video on Spotify's Engineering Culture. It's a more in depth look at the scaling agile approach that I talked about here and really worth watching. Lots of great stuff in here including the importance of not getting too tied up in process ("Rules are a good start, then break them when needed"), the squads, chapters and tribes approach to agile structures (really like the 'aligned autonomy' idea), and the approach to work environment. Much that is applicable outside of engineering teams too. Thanks to Tamas.