This week is brought to you by the letter C, thinking a lot about people and data.
Chats with friends at GDS
After speaking about it a while ago, I finally had a coffee with the excellent Steve Messer from the Government Digital Service, our building-mates. We shared our experiences working in similar spaces - providing services to other development teams - and started to conspire about having a Whitechapel building tech event for cross-organisation collaboration.
Given we both work in the Whitechapel building, the branding opportunity is just too good to pass up!
Conventional Commits
I’ve recently been spending some of my “in between meetings” time with Esther, our testing coach, thinking about observations we can make about the nature of work we’re doing by inspecting the commit messages in our codebases.
Almost all of our teams have adopted some form of the Conventional Commit spec, also known as Angular commits, Karma commits, or Semantic commits - having a machine-parseable format meant we could quickly script up (using Python and Dulwich) a CSV export of the last 4 months on our ad-exchange, and used Google Data Studio to make some COOL CHARTS.
We drew a number of different conclusions from this about the way we work, the frequency of our commits, and the nature of the work we’re doing (for example, what’s the breakdown of “proactive” vs “reactive” development), and we’ll be pulling this thread a bit more to see what we can learn.
As with all code metrics, these won’t become targets, but are an “elephant’s tail” that can be combined with other observations to promote discussions about the way we work.
In particular, it now gives us a vocabulary to think about how we class the work we’re doing.
(Author’s Note - I spent my 20% time building a library to encapsulate the Conventional Commits spec, check it out on GitHub)
Conflict Transformation
Sarah from my team ran the first of a five-part workshop series on Conflict Transformation - it’s great to see people talk about their passions, but it made me take the conflict I experience both at and outside work in a different frame.
For example, a lot of conflict centers around an issue, but is layered in:
- Personal relationships - how you actually relate to the person you’re conflicting with. The issue might be about dirty dishes, but it’s wrapped in the relationship dynamic between you and your housemate.
- Environment - the environment in which the conflict takes place. The issue might be about who takes notes in a meeting, but it’s wrapped in both the relationship with your manager and the context of the organisational structure.
- Society - the underlying social implications. The issue might be about who takes notes in meetings, but it’s wrapped up in the ‘isms’ that underpin a lot of interactions - some parts of the software development industry have a well-documented trend of sexism, for example.
If a conflict provokes a strong emotional reaction, it could be about more than just the issue itself.
I’m excited for the future sessions in this workshop!
Chaos-testing organisations
This was a bit of a head-scratcher for me - Unruly emphasises collaboration highly, and we decentralise a lot of our responsibility within teams. Our Team Leads are a lot like “Team Captains”, still playing the game but have wider concerns extending from the well-being of their teammates to strategic thinking.
As a result of this, there are few times that a Team Lead will have to “exert their authority” and indeed we want to avoid those situations where possible. They feel like a symptom that something, somewhere is missing, whether it’s context or a wider picture.
In these situations, it can feel very jarring for a collaborative team to suddenly be told “what to do”, for example in a crisis situation where someone has to take control and make calls.
The question I’m wrangling with is - are there ways that we can insulate our organisation and process against this sudden culture-shock, in the same way that some companies chaos-test their code and infrastructure?
I’m interested to hear if anyone has ideas about this.
Cross-team work
A pair from one of the core development teams had a task to ensure their workstations were provisioned correctly, and after chatting with us they started an ad-hoc mob across both teams to propose ideas and spike solutions.
I loved this, because it moves from a model of “we we schedule time together” to “let’s form a group to solve a problem and then dissolve”, like ephemeral sub-teams dedicated to exactly one issue.
It feels a lot closer to a model that Woody Zuill described as analogous to “jamming” together at a music festival - we listen for situations where our input or expertise is needed, and then go there for as long as we need.