“if you can do the human aspect you will always have a job in tech”
– Rachel Chalmers, Velocity NYC 2016
We had the opportunity to attend Velocity in New York last month. Several clear themes emerged during the conference, and while there was a high degree of technical content at different points, the most important learnings were about people and the sharing of knowledge.
Empathy, People and Tools
Perhaps the most consistent thread that came through in the sessions we attended and conversations we had with attendees was that of tools augmenting and helping, but not being the primary focus. This was perhaps best summed up by Andrew Clay Shafer of Pivotal during his keynote section on day two:
— Fintan Ryan (@fintanr) September 22, 2016
As a community DevOps understands the need for empathy, but understanding this need is not the same as helping to ensure empathy exists in teams and people work on addressing their various unconscious biases, in everything from hiring to their day to day behaviour.
Two keynotes in particular, from Rachel Chalmers of Unitive and Katherine Daniels of Etsy, really hit home on these points. As we noted above Rachel highlighted just how important the human aspect of working in technology is, and the importance of being self-aware. If you are good with both people and technology, if you have empathy with others, you will never be out of work in this industry.
— Fintan Ryan (@fintanr) September 21, 2016
The world of the rock star techie is still all too common across the technology industry, and, sadly, is still very prevalent within open-source communities. That is not to say that other industries do not have similar problems, they do, but we see far too many gushing commentaries on then 10x or 100x engineer, focused solely on code, within the technology sector. Let us be pretty blunt about this, it doesn’t matter how good someone is on a technical level, whatever the industry, being an asshole is never acceptable and is incredibly damaging to the wider team and organisation, no matter what the perceived short term benefits may be.
During her keynote Katherine Daniels also focused heavily on the need for empathy in organisations and delved into the need for both collaboration and affinity within teams and the wider organisation in her keynote. There was also a lot of focus on how a lack of diversity can stifle creativity – a pointed and accurate commentary on problems of homogenous and corrosive cultures.
The other area which Katherine spent time on during her talk was the tools aspect of DevOps. This is best summed up in her words
‘Tools reinforce culture.
They do not replace it.
Tools will not fix a broken culture.”
These are fifteen words to quote to the next vendor that tells you that their technological solution will fix everything in your organisation, cause digital transformation and make you vastly more productive without any substantive change elsewhere.
Technology at Scale – USDS
The potential of properly applied technology on to transform government around the world is well understood. However, to say the experience in most parts of the world is poor would be very polite. A combination of vested interests from vendors, consultancies, systems integrators and advertising dependent media consistently belittle the transformation efforts which are slowly taking place.
In spite of this we have the emergence of specific cross departmental digital functions in government, from GDS in the UK to DTO in Australia and others around the world. The US has the USDS, and one of the most interesting talks during Velocity was from Mikey Dickerson of the USDS.
Now it must be said that all of these organisations have a proverbial mountain to climb in their respective countries, and the change is slow and gradual. But it is occurring. It will take time, the level of cultural change required is huge, as is creating the required sense of urgency and ensuring the relevant buy in at senior levels. Even on saying this, there is an awareness growing at the top levels of government around the world that the status quo with technology cannot continue.
The USDS uses three major criteria to evaluate projects which people should keep in mind when thinking about IT and government scale.
- The greatest impact for the greatest number of people
- Likelihood of success
- Ability to scale across government
A huge focus for USDS is making the customer experience far simpler and consistent across multiple different agencies. While Mickey felt that ‘this is not innovation, it is basic well known technology applied well’, I would respectfully disagree. Improved user experience and flow improvements are innovations, just a different type of innovation. We spend a lot of time talking about the importance of packaging, design and experience here at RedMonk, and the work of applying technology well falls squarely into that box.
The full video of the talk is well worth 20 minutes of your time, but if you only watch one section, watch the user experience video about five minutes in.
Sharing Knowledge: Uber
Uber’s Tom Croucher gave a frank and honest talk on site reliability and some rules they now apply in Uber in his talk ‘Don’t gamble when it comes into site reliability’.
Their four rules are, as rules such of this always are, deceptively simple on paper
- Always know when its broken
- Avoid global changes
- Moving traffic is faster than fixing
- Make your mitigation normal
Tom also gave us a wonderful new alternative definition of the CAP theorem: Can A client Proceed. Which when it really comes down to it is all that a business wants to ensure.
Now to me the most important of these particular rules is that of making mitigation normal. Testing and retesting all of your mitigation strategies and plans on production systems at peak loads is something that needs to be part of your everyday process.
This is far from a trivial thing to implement, and more importantly to get buy in for. As we have noted several times recently the ability of an organisation to rethink its appetite for risk is key to transforming to new ways of using technology. In the world of cloud native companies this kind of thinking is second nature, but for many traditional IT functions the idea of running something like a switch between data centres during peak hours on a regular basis is beyond their ability to even contemplate, never mind implement.
Once again we come back to the need for cultural change.
ChatOps and Conversational Interfaces
As we have recently noted ChatOps is emerging as an additional tool in the armour for DevOps teams, and eventually for the wider business. As a theme it came through loud and clear throughout the conference, and one of the most interesting demos was a voice interface using Amazon Alexa given by Alois Reitbauer of Dynatrace.
What made this demo far more interesting was the incorporation of machine learning with the data, to create a conversational interface for business users. We will see more and more of this type of interface developing over the coming years.
— Fintan Ryan (@fintanr) September 21, 2016
Ashish Kuthiala gave us some insights into how HPE are using ChatOps to help with collaboration in a globally distributed team. This type of increased collaboration and sharing among teams is one of the more interesting aspects we see with ChatOps. Many big vendors are using ChatOps in this type of manner already, but they are yet to really figure out how to create product offerings around this emerging trend.
One of the more interesting peeks into the future was the SNAFU catchers talk, including perhaps the nerdiest networking joke you could ever do, where John Allspaw and Zoran Perkov demonstrated TCP and UDP.
The SNAFUcatchers project bills itself as a ‘Consortium for Resilient Internet-Facing Business IT’, a place where lessons can be shared and learned from by the wider community. As everyone in an ops role in a traditional enterprise knows, when things go well, no one notices – its only when things go wrong that the rest of the business sits up and takes notices. The cloud native companies understand the importance of ongoing operations, and the discussion during the session touched on how to inform the wider business.
Richard Cook and David Woods of Ohio State University are leading the project, and given their respective backgrounds they will definitely inject some different thinking into how we perceive DevOps. Now I for one love to see cross disciplinary work, particularly where insights from medicine are included.
The founding sponsors/partners of SNAFU Catchers are IBM, Etsy, IEX and O’Reilly and it will be very interesting to see how this project evolves over the coming year. More details will emerge on the SNAFU Catchers website, with the history of SNAFU and SANFUcatchers being well worth a read.
Disclaimers: O’Reilly provided my ticket for Velocity. Pivotal, Amazon, IBM and HPE are current RedMonk clients.