DIBI 2017: The art of risk taking. #DIBI2017 @dibiconf
Last week, I was lucky enough to be able to attend the DIBI (Design It Build It) Conference in Edinburgh, thanks to the wonderful Sharpe Recruitment. The conference was all about taking risk, which is a particularly interesting topic for those working in tech — and particularly for myself as somebody with a software development background — it can often be discouraged to take engineering and design risks on anything more than personal side projects — which made the eclectic line up of speakers all the more interesting.
The day opened with a bang as ‘creative technologist’ Joshua Davis discussed how he regularly takes risks and pushes boundaries in his artwork, which includes amazing animations created using sprites written in Java. I found this opening particularly electric as he took us through his journey through taking risks that has led to him working on amazing psychedelic visualisations
Molly Nix discussed how ‘risk for a purpose’ makes sense in product design, and talked specifically about how the risk that Uber took during its Pittsburgh self-driving car trial paid off. She also had some really interesting stories about how to communicate something perceived as a risk to users, and how to turn concepts that they previously viewed as alien and scary into fun and enjoyable aspects of an experience. The takeaway from this was that risk is worth taking, but only when there’s a purpose to it and some potential goodness to come out of taking it.
Tobias Ahlin discussed how Mojang took risks and then evaluated the results during the development of Minecraft — a lesson from his talk being that you should have a ‘formula’ when taking risks so that you can evaluate wether or not they are working, and whether or not they have worked out as expected or not. The classic ‘formula to innovation’ that he suggested was to treat any project like a gamble, and evaluate “We believe that betting X amount of time/money working on Y will produce outcome Z” before taking the risk, then after the project has been complete, go back and see if the formula still holds with genuine data, and if the anticipated value has been added.
We concluded the day at the quirky Caves, where through informal chats with the speakers and with some really interesting fellow attendees, I came to the conclusion that risk is something that should be embodied more in technology projects.
Overall, a fantastic day with some real lessons particularly around how ‘the greats’ manage risk in design and engineering led tech projects, and without a doubt these are things that I will take away and apply as I work on setting up my engineering-driven software house, Nebula Labs, later on this year — thank you again for a brilliant day Sharpe Recruitment!