DevOps

“MBA Washing” refers to the phenomenon where individuals, often with a strong theoretical or academic background but limited recent practical experience, adopt and reinterpret industry-specific terminology and cultural movements. – This reinterpretation is typically influenced by their academic learning, recent literature, and biases towards larger enterprise perspectives. As a result, the original intent and practical effectiveness of these concepts, such as DevOps or Platform Engineering for example, may be diluted or misrepresented. ...

Many organisations - while branding themselves as “Agile” - continue to make the mistake of estimating project velocity based on time than effort. ...

This is a high level intro to LLMs that I’m writing for a few friends that are new to the concept. It is far from complete, definitely contains some errors and is a work in progress. This is a work in progress and a living document. Language models, or LLMs, are a type of artificial intelligence that can generate text based on a given prompt. They work by learning patterns in large amounts of text data and using those patterns to generate new text. LLMs can be used for a variety of tasks, such as generating chatbots, answering questions, and creating art. ...

Deployment / Delivery Frequency I often end up needing to advocate for more frequent delivery/deployments with clients. There’s the usual benefits commonly discussed such as improved feedback, reduced risk, well understood processes, maintainable dependencies etc… however what’s often missed entirely is how it relates to the health and sustainability of the team. ...

We’re (still) not deploying enough It’s 2022 and not deploying frequently enough is still one of the most common causes of software failure. ...

A template team charter for software and platform engineering teams. Research1 shows there is great value in people embracing a shared vision and ideas that are bigger than themselves. When it comes to a team charter, it’s important to remember that it’s not a static document. It’s a living document that should be updated as the team evolves and grows. Keep in mind that One size doesn’t fit all. Consider your (teams) mission, cultural background and values. While not exhaustive - this is on the longer side, you may wish to distill as is practical, but I implore you not to only pick the easier items - that’s missing the point. These can give you talking points when performing postmortems, retros and during times of conflict. See also: ‘Using Old Ways of Thinking to Apply New Ways of Working’ and ‘BVSSHJ Principles’. ...

Stop trying to hire with titles like ‘DevOps Engineer’ or ‘Cloud Engineer’ “DevOps is … not a job title” “It’s more of a cultural practice, like innovation, and it makes just as little sense hiring “innovation engineers” and expecting your organisation to be innovative, without also creating the culture to foster innovation.” (Joel Shea when responding to this posted on LinkedIn) In most cases it’s clear the organisation doesn’t truly know what they want or need and likely don’t understand the nuances of the aspects of engineering. ...

As stated in my announcement post - after 7~ years, I resigned from Infoxchange several months ago. I planned on taking a holiday, relaxing, decompressing, dipping my toes in some off-the-shelf tech I haven’t spent a lot of time with and performing some personal growth through reading a number of books that have been sitting on my ’to read’ shelf. This is exactly what I’ve done. I’m now open to new opportunities I’d rather find a workplace that I can add great value too and be happy to work with than rush into a new role quickly, obviously if something great turns up right away - I’ll pursue it. ...

After 7~ years, I have resigned from Infoxchange. In 2012 I was hired to work with Infoxchange to “shake things up” (in the Systems Operations team) and stabilise the hosting environment. As Team Lead of Systems Operations I was tasked with melding the team and then for us to work to provide a stable, robust, modern and scalable platform for Infoxchange developed application hosting and product delivery and in a short time, with a small budget - we did just that. ...

“A chain is no stronger than its weakest link” Any improvement made anywhere besides the bottleneck is an illusion. Any improvement made after the bottleneck is useless because it will always remain starved waiting for work from the bottleneck. Any improvement made before the bottleneck merely results in more ‘work’ piling up at the bottleneck. Identify the system’s constraint(s) (that which prevents the organisation from obtaining more of the goal in a unit of time) Decide how to exploit the system’s constraint(s) (how to get the most out of the constraint) Subordinate everything else to the above decision (align the whole system or organization to support the decision made above) Elevate the system’s constraint(s) (make other major changes needed to increase the constraint’s capacity) Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system’s constraint. References The Phoenix Project Wikipedia - Theory of Constraints