Home / Blog / 5 practical things I know I’d take with me if I left Outlandish

5 practical things I know I’d take with me if I left Outlandish

By Harry Robbins, 16 Feb 2021

1. Use consent based decision making

Seriously, if you just do one thing, this is the most important. If you’re tired of people saying “you should…” and “I knew this was a bad idea” then you need consent-based decision making. It’s simple – anyone can propose anything they like and if everyone on the team agrees to try it you try it. If one or more people don’t think it’s safe enough to try you don’t try it and you find another way round. We’ve been telling you this for ages – here’s me seven years ago(!)here’s Abi four years ago – and here are ~monthly courses we run where you can come and learn and practice.

 2. Wireframe everything as early as possible

There is no better way of getting a shared understanding of what you’re doing as if you draw a picture of the thing you’re making. No drawing skills? No problem. Just do your best – put all the key elements on the page, WRITE THE CORRECT LABELS (do not write “item, item, button” no one know what that means), and keep refining it until you’re confident someone seeing it for the first time knows what they’re looking at. Write some notes and arrows to help them. Want to do it digitally? I use Whimsical online and Linea Sketch on iPad. Paper is at least as good – don’t be afraid to start a new sheet – a piece of paper is a lot less expensive than building the wrong thing!

3. Practice communicating

Communicating – listening, speaking, writing and understanding – is surprisingly difficult and something worth practicing.

I was angry with my friend;
I told my wrath, my wrath did end.
I was angry with my foe:
I told it not, my wrath did grow.

— William Blake, Agile Project Manager’s Handbook Volume 1, 1794

We use a few different techniques at Outlandish – largely introduced to us by the marvellous Pete Burden. Some of the tools are quite simple – the ‘FONT’ framework is about breaking down what you want to say into feelings, observations, needs and thoughts to make it clearer what you’re saying. “I heard you say X to Y; When I heard that I thought you meant Z; I’ve been feeling really sad and angry every time I think that and I need to know why you think Z” often results in “That’s terrible that you thought that! I said A not X, and I meant B not Z!” We cover this in our “Practical Communication for teams” course which we run about once a month, and you can try Googling “nonviolent communication” to get started.

4. Clearly document your goal

Triangle showing main goal, outcomes and activities

We create something called a Theory of Change for each project which specifies how the world will be better if the project succeeds, what the necessary constituent parts of that success are, and what we need to do to bring those parts into existence. We use a really simple layout like this example to capture these for most projects, though we also do much more detailed plans for larger projects.

It’s amazing how often it turns out that people have completely different ideas about the aims and priorities of a project – or that someone thinks of a really key element that is essential but had otherwise gone undocumented.

Every time those things happen I chalk of a £10k win to theory-of-change. It’s expensive and soul destroying to build the wrong thing.

We use Miro for online theory-of-change workshops. On their “teams” package (from $16/month) you can create a board and then “allow anyone with the link to edit” so you don’t have to pay for every member of the team to contribute to the process.

 

 

 

 

 

5. Iterate

Making a simple version of something – a ‘minimal viable product’ – is an essential and, if you’re a manager-type, hard-to-manage discipline. I have been guilty many times of having an idea about how a feature could work just-so and ended up ploughing far more resources into it that it merited. Make something that works – and that has measurable usefulness. Then work out what is the smallest feature that would improve it most, and build that. Many of our most successful projects have started when someone based at the client organisation has had a stab at making (and maybe even testing) something that does what they need.

 

 

Photo by jesse orrico on Unsplash