This is the eleventh in a series of blogs about enterprise DevOps. The series is co-authored by Nigel Willie, DevOps practitioner, and Sacha Labourey, CEO, CloudBees.
By nature, technicians are problem solvers. Many companies assess an individual’s ability to solve problems as a precursor to an employment offer.
If you are delivering a DevOps transformation, your key customer group will be your DevOps technicians. It is critical you differentiate your customers (DevOps technicians) from your stakeholders and sponsors (the business and executives).
A key point to remember about your customers, or technicians, is that some find it easier to articulate solutions rather than requirements. The desire to resolve problems is critical and should not be discouraged, however in the absence of further information it can be particularly challenging for any organization.
Examples of common behaviors
“I don’t want this, I want that as it is better / easier to use’’
Anybody who has rolled out an automation solution will recognize this feedback. One of the advantages with today’s technicians is they regularly work on their own projects outside of company time. This means your customer group, the DevOps technicians, will have significant knowledge of solutions available and will often have experience using a variety of automation solutions. This is an advantage to the enterprise.
The challenge, if you are delivering automation solutions, is that this knowledge often leads to significant pressure for a multitude of solutions.
We previously discussed how to create a governance structure that enables the voice of the DevOps technician to both be heard and acted upon. (In a forthcoming post, we shall discuss those areas of your automation chain that are more open to diversity and those which better suit a limited range of solutions.) All we can guarantee is that in a large population, you will regularly find a significant minority who request a specific solution on the grounds they prefer it to the current option. One of the great joys of humans is we abhor mass consensus.
While personal preference is a consideration to procurement, we have not met many chief financial officers who will sign the check based on this, alone. It is critical that some business benefit is espoused if investment is to be obtained.
“I need you to change this product so that it does this, followed by this and connects to that via this”
This is a slightly different situation. It is also very common.
The DevOps technician has a requirement, and rather than raising a discussion about that requirement, has worked out how it could potentially be solved by some specific changes to the automation chain, or a tool within it. The solution may be correct, but it may not be optimal. It is critical the requirement is understood before the potential solution is assessed. It may be that the problem has already been solved elsewhere and the requestor is not aware of this. It may be this is a genuine requirement, but the suggested solution will cause unforeseen issues elsewhere that the requestor is not aware of.
Encourage ideas, but insist on requirements
We firmly believe the enthusiasm and ability of the technical community in any enterprise is a critical asset that should be harnessed. We further believe DevOps technicians consuming any automation pipeline or processes daily are best placed to identify the shortcomings and issues. They should be firmly encouraged to articulate any issues or requirements as this is critical to the culture that DevOps relies upon. We would argue that if the organization is not open to feedback, the technicians will find ways around the issues they face within the ‘gray economy’ of your organization which will create problems in the medium term.
As we synthesize all the issues, any solutions posted into a requirement portal should be pushed back to the requester with instructions that they articulate their requirement first, and then detail their potential solution on the same ticket.
By understanding requirements, the organization can:
Better detail the process and any gaps within it.
Understand issue and functional gap patterns. Requirements tend to be common and suggested solutions bespoke.
Better prioritize solution deliverables by aligning them to business requirements.
Create business cases for actions as it is easier to assign value to a requirement. A solution normally involves cost.
By training DevOps technicians to better articulate their requests as requirements, you can increase skills across your organization which can assist in other areas. An individual who thinks in terms of requirements rather than solutions can use this skill to improve their approach to testing their own product.
About the Authors
With over 20 years’ experience working in IT for one of the world’s largest financial institutions, Nigel has experience managing and delivering global transformation programs. Starting his career as a developer, Nigel’s most recent role was to deliver cross-platform DevOps automation capabilities to the enterprise.
From his experience, Nigel understands many of the challenges and mistakes involved; indeed, he claims to have made most of the mistakes himself. Nigel has also had the good fortune to work with a lot of highly skilled individuals, both as colleagues and across the industry. He is attempting to share some of his personal observations and thoughts in the hope they will be of value to others. Nigel is a great believer that every initiative is individual and any observations he makes are intended as principles or guidelines, not rules.
Sacha is a native of Switzerland and graduated in 1999 from EPFL. While at EPFL, he started his first consulting business - Cogito Informatique. In 2001, he joined Marc Fleury’s JBoss project as a core contributor, and implemented JBoss’ original clustering features. Sacha went on to become GM for JBoss Europe. In this role, he led the strategy and helped to recruit the partners that fueled the company’s growth in that region. In 2005, he was appointed CTO, overseeing all of JBoss engineering.
In June 2006, JBoss was acquired by Red Hat (NYSE:RHT). As CTO, Sacha played a crucial role in integrating and productizing the JBoss software with Red Hat offerings. In 2007, Sacha became co-General Manager of Red Hat’s middleware division. He left Red Hat in 2009 and founded CloudBees in March 2010.