Human DevOps

12th September 2023 - Platform teams in DevOps

Published 6 months ago • 2 min read

When you need something done to a system that you work with, can you do it for yourself or do you need to ask someone to help you out?

The answer to that question depends on your situation:

  • You might not have the knowledge
  • You might not have the access
  • You might not have the time
  • You might not have the inclination

But what we do then determines what our colleagues need to do. If we call up somebody else or interrupt their train of thought, are we doing ourselves as an organisation a favour in the long run? Is there a better way for teams to hand off work to each other?

This is not a question with a simple answer, and it's a question that gets to the heart of many problems when providing a service internally in a software development organisation. If you want a better service, define that service and its boundaries first.

This is one of the subjects I've been thinking about for the last couple of weeks as I find myself working with a service team with defined boundaries and responsibilities but varied interaction modes. While we would love to start thinking about self-service options for our developer team customers, it's a team still forming under new governance. In these circumstances how hard is it to keep a good level of service and consistently improve it? When do we target different levels of service? What is our ultimate goal?

As a thought experiment, I'm putting together a list of questions we can ask ourselves about the purpose of this team. This will give us an idea of where we are now with our team maturity and where we would like to be in six months or in a year's time. If you'd like to hear more about this I'll be sharing it soon but feel free to reach out directly.


Did you read the McKinsey report about Developer Productivity? What did you think of it? My take is that McKinsey knows their audience, and they have done a great job of stirring up many development leaders into a froth of excitement - see Kent Beck and Gergely Orosz's response for example.

There have been many takes on both the original article and the responses, but my favourite one has been this thread in the DORA community group. This also links a Martin Fowler piece from 20 years ago (of course) called CannotMeasureProductivity.

What do you think? Is developer productivity important, and what place does happiness or motivation play in it?

I'm reading Daniel Pink's "Drive". His ideas around intrinsic motivation (autonomy, mastery and purpose) can perhaps play a core role in helping platform teams understand their purpose in an organisation. Can teams change themselves from within in the same way an individual can if they choose to?

I'm interested to hear your thoughts. Feel free to hit reply and let me know.

-- Richard

Azure DevOps YAML pipelines: The land of confusion

Published on September 2, 2023

Coming from the open-source world, you're probably used to GitHub actions and being able to set up your pipelines quickly. No drama. Nice and simple. Simple projects, simple solutions. If you're in the corporate world and need something more substantial, Azure DevOps has been and continues to be the standard for making more complex pipelines.… Read More »Azure DevOps YAML pipelines: The land of confusion


When You Are Doing Devops

Published on August 29, 2023

As any software engineer knows, naming is often the most challenging thing we do. I've struggled with naming things over the last twenty months. Here are some highlights. In January 2022, I wrote "Automation for the Nation ". A book on why automation is a good thing. I completed it (80%), but it's not yet seen… Read More »When You Are Doing Devops


Human DevOps

by Richard Bown

Join my newsletter for regular views and news about doing effective, essential human DevOps engineering. I dive into the human factors that make successful DevOps organizations and the teams and platforms at the heart of your socio-technical systems. From leadership to team setup, maximizing performance, tools and techniques.

Read more from Human DevOps

If you've followed the story of Maxine Chambers in the Unicorn Project, then you know it's not a simple "10x engineer saves the day" engineering tale of derring-do. It's a struggle; it's hard for Maxine. Her story starts with an effective demotion because she's taken the blame (or been pinned) for an outage. The rest of the book explores the toxic culture at the fictional company Parts Unlimited. We learn about the people, the places, the feelings and that elusive thing 'culture' that the...

20 days ago • 1 min read

It's February. So, what's going on with your project? What's happening in your organisation? Are people happy? Are improvements being made? Over the last few weeks, I had a few thoughts about improving from the ground up. I work day-to-day as a DevOps engineer, and from there, I can shape interactions we have as a team with other teams and also what products (or platforms) we offer. I feel lucky to have this role as I get to work with many developers with different challenges in multiple...

27 days ago • 1 min read
Friday 12th January - Leading with Kindness

January can seem like a long month in the Northern Hemisphere. This last week certainly seemed like a very long week! I hope you can start to think about the weekend. I’ve recently explored the subject of happiness in software engineering from an organizational perspective and explored the foundations of how software organizations comes about and why we occasionally find it so difficult to square. Let’s start with the concept of the happy individual building an application. It gets more...

about 2 months ago • 2 min read
Share this post