At the end of January I was lucky enough to be given a ticket to a two day long software development conference called “Monki Gras” (named after the company that runs the event, Red Monk) in London.
The theme of the conference was “scaling craft”, a pretty ambiguous theme which over the next two days was nicely pinned down by the wide variety of speakers. This theme was roughly translated into answering the question: “how do we maintain quality when scaling up to mass production?”.
Some of the speakers invited included, most importantly, Phil Gilbert of Design@IBM fame, who discussed how he is trying to bring a culture of design into the company, and to name a few more: Rafe Colburn from Etsy, Chris Aniszczyk from Twitter, Shanley Kane from Basho, Steven Citron-Pousty from Redhat and Ted Nyman from Github.
The conference was more than just good speakers. Fantastic food (specifically Japanese and Vietnamese) was provided on both days for lunch, along with some craft beers; coffee was available all day from an artisan coffee company, and the evening entertainment was hosted at London Fields Brewery where we were given a five course meal cooked by a top London based street kitchen. Quality was a theme in every aspect of the conference that mattered, whereas the hall where most of the talks were given was quite plain and basic, but all attention was on the speakers.
The first question that was addressed by the speakers was that of “What is craft?”. Rafe Colburn did a great job of opening the conference by discussing the common misconceptions associated with “hand crafted treasures compared to mass produced crap”. Not everything that is made at home is high quality, and not everything that is massed produced is is low quality. There are benefits to both – craft maximises the skill and creativity of the individual artisan and mass production optimizes predictability and repeatability.
Other speakers approached this topic too: Chris Thorpe has set up a company called The Flexiscale Company where he uses 3D-scanning technology to scan rare train engines so they can be forever preserved in their current state. Using these scans he is then able to 3D-print accurate models of the trains to any scale a model train enthusiast would desire. I personally have never seen the attraction to model trains, but his talk was one of the highlights of the conference as it honestly and unintentionally captured something really special about craft – the unashamed enthusiasm and passion for what you do. This same enthusiasm was displayed in the talk given by Diane Mueller (ActiveState) about a personal project to geotag Totem Poles in the Pacific Northwest (at the end of her talk she invited anyone interested to join her in tagging the totem pole in Virginia Waters). Manufacturers were given a good slogan for this mentality by Chris: “Make things people want, rather than make people want things”.
So how does a software company maintain this sense of passion, and craftsmanship, when it is scaled up to a company the size of IBM? Phil Gilbert’s talk was centred around design, but he touched on this idea when he asserted that developers can lose sight of the value, and ultimately the end result, when they only work on a small part of a huge product (and as part of a small team within Message Broker development I sympathise). His solution was something known as “Commander’s Intent”, the idea that in battle all soldiers are briefed on the overall goal of the mission before they are in the chaos of the battlefield. When they then enter the battlefield no further orders are given; it is the responsibility of the commander to ensure that everyone has understood their goal and how to reach it so they are able to make informed decisions themselves rather than have minute details dictated at every move.
To apply this to software development Phil suggests appointing someone to own the decision making process, and a trusted community of people reviewing (but not dictating) outcomes. But most of all, ensure that your staff prepare for (great) outcomes and understand the value of what they are working on. Cyndi Mitchell from ThoughtWorks expanded on this, adding an analogy from her experiences growing up on a hog farm (where the product is the hogs and the developers are the farmers), in particular she stated that “everyone in the system has to understand quality”.
In the most extreme example of this, Ted Nyman from Github discussed how their organisation has no managers. In response to this every employee must have a sense of ownership, and if this is effective everything the employee needs to get done will get done.
Although the conference was a technical one, it became clear that software development was only the medium in which people were discussing their ideas. Instead the conference was really about culture, and on this topic there was a lot of food for thought. In Heroku, a platform as a service company, the number of deploys a day are in the high hundreds. “Move fast and break [stuff]” was the (family friendly version of the) mantra for their organisation, and this was only possible if developers’ time became sacred. They introduced the headphone rule: headphones on means ‘do not disturb’, and the fantastic piece of advice “work in caves, dwell in commons”. This demonstrates the flip side to protecting developers time: when you’re not working, communicate! Coffee breaks become an important part of the working life (hence the title of their presentation “Coffee as collaboration”) as this is when ideas can be shared and discussed. Taking time to document your work to get the recognition you deserve and killing off projects that aren’t working can only happen if communication is just as important as the development.
This protection of the developer was also discussed by Rafe Colburn, whose advice for companies looking to scale was to automate everything that could be automated, leaving time for developers to work on their beloved craft. Phil Gilbert suggests using release hills with clear goals (three maximum) so that people can reclaim their craft, but also building in regular iterations of design and innovation to keep the craft fresh.
On the topic of iterations, Government Digital Services (GDS) discussed how in the space of two years they scaled their team from a handful of people to 200 employees. They attributed their success to constant iterations of processes, tools and people, avoiding the dreaded “single point of failure”. Understanding how to effectively do this comes down to understanding your “ecosystem” (a term commonly misused), as explained by Steven Citron-Pousty. He used his background in ecology to encourage people to think about nature’s ecosystems in comparison to those in their organisation, in particular identify the keystone developers as well as the day-to-day developers, and understand the sometimes unexpected relationships between them and their colleagues.
Another point of discussion (initially introduced by Mazz Mosely from GDS) was the issue of “rock star” developers. These can be the aforementioned “single point of failures”, but more importantly they are those mysterious developers that the entire success of the product is pinned onto. Other than not being what they may be hyped up to be, rock stars can also be disruptive to teams – feeling that only their opinions count and not using the shared knowledge of their colleagues. A better approach is to cultivate an environment where everyone is respectful and understands that the “users” of your product are not just the end-users, but also your colleagues.
In summary (some takeaway coffee if you will), culture is one of the most important aspects of a company. Culture, as asserted by Shanley Kane and Ted Nyman, is not the furniture in your office or the perks your company offers, but it is what eventually picks between two good ideas. With this in mind, it becomes increasingly important that the whole organisation has the same mentality behind their work. As software engineers we like to think of ourselves as craftspeople, and can easily become frustrated if our work becomes mindless, so how can we avoid this happening? Here are some top tips to avoid this kind of disappointment:
- Teams should be honest about what they can achieve in an iteration, at the risk of losing faith in the product and only completing the easy tasks just to tick them off a list,
- expect, encourage and respect feedback from your colleagues
- and understand the quality and value of what they are working on.
