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.

When Gustave Eiffel built his namesake tower, it was nearly twice as tall as the tallest structure on Earth. His crews built it in an astounding 22 months, pioneering new construction techniques to deliver it in time for the opening of the 1889 Exposition Universelle. It was amazing then, and it’s just as captivating today.