Next week, I’ll be speaking at Agile 2013. As a CEO, I go to plenty of conferences, but most of them are domain-specific: meeting Red Gate’s customers, or other CEOs and senior leaders, or seeing what’s going on in the SQL Server and .NET spaces. On the surface, Agile doesn’t feel like a great conference fit for me. Red Gate has been using agile methodologies and development/project management practices since 2007, but this tends to be the realm of people like our Head of Development and Head of Project Management.

But since last October, I’ve been experimenting with using agile methodologies and practices to run my leadership team. The dysfunctions we’d been experiencing as a team for quite some time struck me as similar to the problems our dev teams kept running into in Red Gate’s pre-agile days, so I sat down with our two biggest agile gurus and asked them to help me figure out how to work better with my team.

What we did, how we did it and how well it worked is the meat and potatoes of my speech, but, to summarise: we started holding a daily standup around a whiteboard as a leadership team and gradually iterated on this until it became fit for the purpose we needed it for. Nine months on, we’re much better as a team at sharing information and understanding where we’re spending our time, and the level of trust on the team has also improved. However, we’ve still not nailed decision-making and working on complex projects – it’s these goals that we’re now trying to work towards.

What I’d most like to share with you, though, is something which struck me whilst putting together my presentation for next week: there are plenty of business and management books out there, but they’re all concerned with strategy and big ideas. There’s nothing about the actual mechanics of running a business or a high-performance leadership team. I don’t mean ideologically, I mean tangibly and day-to-day – how to structure and run meetings, how to design your interactions so that everything important is covered and decisions are made, how to make sure power and responsibility don’t end up siloed with one or two individuals or in one or two areas of the business. I’d wager that this is a problem every leader comes up against, but the market for books just hasn’t plugged into this gap.

My hypothesis – and one which I haven’t put to the test yet – is that agile is the natural contender to fill this void. One of the most valuable things it brings to software development is a clear framework for running projects which can be made to work in any domain and almost any set of circumstances. It follows that an agile framework for actually running your business would be something that tons of people around the world would find massively useful.

There’s plenty more on this topic within my presentation, which I’m looking forward to sharing with a room full of agile practitioners and business leaders at the conference next week. I’m planning to end my talk with a series of predictions, and the one I’d like to share more widely is this: by 2015, if not sooner, I reckon there’ll be people whose job is to facilitate the CEO, and whose job title reflects their role. One of my main regrets about the way we implemented our daily standups as a team was stopping having them facilitated too soon. The facilitation aspect was one of the most beneficial parts of the whole process, and it’s easy to see how this help could be expanded to encompass all aspects of a CEO’s role.

I know it would be massively helpful for me!

Simon