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.

One of the challenges facing teams, particularly small ones, is having to balance the time spent on doing fun new things and having to support old (or antique!) systems and processes. These are the ‘business as usual’ (BAU) things which probably underpin the current revenue of your business.

Team leadership and technical leadership come with variety of challenges and require various skills. One of them is an insightful future outlook and being ready for what’s yet to come.

How does time impact on your working day? Would you like to hack time and live outside the clock? The answer is likely to be yes.