This long hiatus on the blog will allow me to pick up this old draft and introduce this idea in a very organic way. If we take a look at the activity on these articles, one might think that I completely forgot about my website. The reality is that I have a dozen of half-written drafts, three different code projects and some opinion articles that I actually did not dare to publish (and more on that on a later date, perhaps) However, from a reader’s point of view, this site is dead and abandoned since 2017.
This is something that I see happening a lot on big organizations with DevOps adoption efforts. When a chance for improvement is located, and somehow it affects either the tools available, or a repeatable process, it is usually followed by a Proof-of-Concept. I am not referring to a company-wide push, or a strategic decision, but rather some quality-of-life change, or perhaps some attempts at automating something when there’s no established framework available for it – specially related to the current culture of the company. Whether this effort might be successful or not , it does not matter: the problem is that the findings from the exercise are kept within the team instead of sharing them, because they are not mission-critical, or out of fear that they might be seen as a waste.
When the effort is successful, a small part of the company suddenly becomes more agile, their KPIs increase, and they grow steadily. However, if this improvement is not made known openly, not everyone has the chance to take advantage of the new asset.
In all likelihood, it’s way more probable that the things not openly discussed are failures. The business world tends to see failure as negligence, as the result of incompetence or as the consequence of a disaster. An unsuccessful attempt at improving something might indicate that either there is no margin for progress or, more likely, a block or an oversight. This issue can be related to technology, or to immovable procedures related to business logic. And unless someone involved in management is participating in this experiment, this effort will go nowhere.
The bigger the company is, the bigger the chance that your department or group might be missing on potential enhancements. So, how can we help distribute this knowledge? I have previously talked about the concept of Communities of Practice. Associating coworkers this way provides the perfect space to discuss about the small improvements that can turn into a differentiating value in the long run.