When we talk about building a DevOps organisation - what do we mean?

We don't do all of "this stuff" (waves hand towards a Jira or Azure Devops board) because we want to follow a particular methodology or necessarily use a set of technologies or solutions for our work. We're just trying to understand and improve how we build and deliver software better.

Seeing the frameworks and ideas around us as 'solutions' to our problems is tempting. So, for example, picking Scrum or Kanban, or using npm or pnpm or kubernetes or serverless. These are process, technology and platform decisions that can and will affect our ability to build and deliver software - but those are usually short- or medium-term decisions we will make all the time.

What is more fundamental to our purpose is the intent and direction of the business. If we can align our teams and our organisation with the intent and direction of the business, we can have more practical discussions about the benefits of one technology or platform or solution over another.

Likewise, if we decouple our feelings at a personal level from the framework, technology or solution - we can be more dispassionate about the choices we make for the good of the business.

Now it's no secret that I'm a big fan of Team Topologies. In fact, I'm such a big fan that the Conflux organisation has awarded me Team Topologies Advocate status (photo and description coming soon). However, I don't believe hiring a bunch of consultants and drawing pictures of your organisation's layout will fix everything in your DevOps world. Luckily, neither does Team Topologies. Using a basis of Conway's Law for architecture coupled with limiting cognitive load for teams aligned with our business value streams is a powerful concept. This underpins not just the technical but also the business direction.

My specific interest within the Team Topologies universe is the "DevOps teams". These are often seen as anti-patterns in organisations and indeed in the SAFe framework (notorious for Agile anti-patterns) they even have a name - the "System Team" or Teams. These are any platform teams which enable and support the stream-aligned teams through the provision of services (DevOp tools, CI/CD infrastructure, build, config, test setups, infrastructure and enablement). My speciality is understanding what platforms exist and what internal products platform teams provide. I help teams define and manage their products better as well as creating a team API (a way of working) which enables them to communicate and work more effectively with the rest of the organisation.

--

Continuing my research, as a follow-up to my earlier piece I look at the roles we take on as individuals during our work. I don't believe that individuals working in software development have one strictly defined 'personality type' but we (especially in the IT world) need to change somewhat to be flexible during our work. Sometimes, this change happens many times a day. Therefore we are adaptable - and that adaptability is sometimes difficult to manage both at an individual and team level.

The next time you're struggling with a problem, be it technical, be it organisational, social, or customer-related: remember that a lot of the time our context and experiences will directly influence our approaches to our solutions. Realising that can put us in a place where organisational problems and goals are more naturally shared. I'll be exploring these ideas more in future posts.

I hope you have a relaxing and enjoyable weekend. Until next time.

-- Richard

​

​How to Embrace Complexity and Uncertainty in Programming​

Published on October 10, 2023

or more accurately: “How to Train Your Brain to Handle Complexity and Uncertainty” This is part 2 of a 3-part series following my earlier post – Avoiding Toxicity. Here we start to find our place in the team and understand how our behaviours are affected by our context and how, given the challenge of writing… Read More »How to Embrace Complexity and Uncertainty in Programming​

​Read more...​

​