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