Oblique Strategies

In the Seventies the brilliant Brian Eno, together with Peter Schmidt, created 100 cards containing cryptic remarks aimed at breaking a dilemma or deadlock, particularly in creative situations.

They comprised unusual, sometimes counter-intuitive ways of looking at a problem. They were called Oblique Strategies and I think you can still buy them from Eno’s website.

With that spirit in mind, although perhaps a bit less concise and inscrutable, I’d like to propose some different ways of dealing with development issues.

These ideas are not meant to be used every day, and they’re not meant to be guiding principles, but maybe next time there’s a problem it might be worth considering a few – before rejecting them and just sitting at your desk with your head in your hands looking miserable. That can work sometimes.

THINGS ARE CHEAP

We all know it’s the people on a team that define its success. When managers flippantly say ‘it’s our staff that count’, they’re possibly not just being patronising, but stating the obvious too.

Most of the cost of a team is the team, not its equipment or environment. But managers occasionally seem to struggle to pay for the things that can give easy wins.

Some problems are alleviated by ‘throwing equipment at them’ – massively specified continuous integration-build PCs, better equipped meeting rooms, third monitors, more RAM and so on. Things are cheap and easy, people are expensive and complicated. Try the easy stuff first.

ABDICATE YOUR RESPONSIBILITIES

Got a difficult problem? Don’t try and solve it in a managerial way, just tell the protagonists to sort it out. They’re better placed than you.

This works best where a problem is localised, and not spread across the workflow in a team – if it is it may need some arbitration.

But teams can become dependent cultures where people feel they need to go to someone else to sanction or action change, so try and challenge that every now and again. A simple ‘You do what you need to’ can be surprisingly liberating.

STOP WORKING

Got a really big issue? One that’s contaminating the way work is done? Get the whole team to stop and concentrate on that one issue.

Some people may not be part of the solution, but by making a grand gesture, and by focusing everyone, you raise the priority to maximum and will get to a solution in the fastest way.

Everyone mucks in, testing, reviewing etcetera. Better five days of no progress on the game but a fixed workflow than 12 months of frustration.

On a recent (non-CA) game we were putting features in late, after Alpha, whilst also bug fixing. Rather than accelerate on the feature development we stopped and worked for a week on only fixing bugs.

That meant we then had hard data about the fix rate of the team, the real stability of the code and so on – and we could work out how long it would take to get to ‘gold master’ once we were feature complete. It allowed everyone to see the wood for the trees.

CONSTRUCTIVE CONTROVERSY

Got a disagreement between key staff, or parts of the team? As a manager, be prepared to whip up debate, and force issues to a conclusion.

You’ve obviously got to manage the situation carefully and professionally, and you will need to be clear that the individuals are capable of this kind of discussion.

I’m not talking about anything aggressive, but simply about getting the issue out in the open, allowing people to say what they feel, and arbitrating a carefully directed discussion.

You may need to take a contrarian approach to really get to the meat of the issue. It’s more John Humphreys than Jonathan Ross, and it’s often more important to keep the discussion flowing than it is necessary to damp it down.

At the end of the debate you need to close it down, ideally with a final decision – you cannot let the issue float on after a discussion like this.

I’m wary about mentioning this technique, but it’s a really powerful tool in a manager’s toolset.

These are just a few odd ideas for approaching problems, hopefully not to be used too often. Problem solving itself has a suite of some really useful formal contrivances including de Bono’s Six Thinking Hats, voting matrices and Ishikawa’s fishbone diagram.

It’s really worth trying some out – some will stick, some will fail. To some people’s great disappointment you don’t have to wear hats when using the Six Thinking Hats technique. But you can if you want to.

Brian Eno’s ever-inquisitive mind, and ability to manipulate technology and techniques in his own creations, and when working with others, is inspirational.

I hear he has recently been working with Coldplay though, proving that no one is perfect.