We’ve all had that experience where we’ve planned the perfect discussion only to have it hijacked by a passionate side-person, lose focus halfway through, or produce the exact same takeaways as you had before you began the discussion.

When bootstrapping new teams, they need to go through the standard process of forming, storming, norming and performing. And in the context of fast-growing companies, with their own level of uncertainty, how can we achieve high performance when teams and goals are constantly changing?

In 2013, Google famously published a leading reference for establishing Objectives and Key Results as a way to align teams and set short-term goals.

It’s all well and good for the agile manifesto to recommend self-organising teams, but what does that actually mean in practice? What’s the best way to do it, how far should you take it? Total anarchy is probably not the answer here… right?

Ever experienced that unexpected and urgent crisis that needs immediate effort and expertise? No matter how agile we are I’m willing to bet every team/project/organisation experiences these interrupts – the ‘Black Swan’ events – on a surprisingly regular basis.

Everywhere we look, developers are working on side or ‘passion’ projects. While these projects are incredible ways to expand your knowledge faster, accelerate your career, and gain recognition in the developer community, the truth is that not everyone can or wants to spend extra time outside of work on coding.