I attended the Devops Finland meetup at SOK today. This was my first meetup at the SOK offices. I did not know what to expect going in. Would these be technical talks about tooling or something else.

The SOK building is at Fleminginkatu 34, massive and old, near where I walk. I crossed the street, walked past the McDonalds and the petrol pump, took a left, crossed a street and was standing in the courtyard soon. Not standing, I kept walking, it was cold.

At the reception, the security took my ID and gave me a temporary pass. This is not usual. But this was a bank after all.

I found a familiar face here, so took a selfie with them, ate some pizza, chatted a little. And then moved into a similarly ancient looking hall.

There were two presentations scheduled for today. Both the presentations ended up being meaty and left me with things to chew on. Here’s a brief recap.

1. How to put strategy in developer productivity by Niko Kivelä & Jacob Lärfors

The talk was focused on the build - measure - learn cycle. Building capabilities provides features, focusing on tools distracts from solving real problems. Measuring can point us in the right direction. Communities offer a way to learn, share and engage with the engineers.

Biko and Jacob had agreed on three words they would not use in the presentation going forward or else five pushups. The words being:

1. Agile
2. Devops
3. Platform engineering

Niko did say the d-word and so had to do the pushups.

They also talked about communities and how,

1. Boundaries are good - autonomous teams form boundaries
2. Siloes in business are bad - everyone working on same problems
3. Communities bridge siloes

Development guidelines are developed using the must-should-recommended approach. Which is something I should read up more on, later.

2. Structuring teams for fast value delivery by Gaurav Bhorkar

Software is a constantly evolving thing. As the system grows the complexity increases as well. This could lead to declining quality if it is not managed. All of this happens under constrains defined by the organisation - what language you can use for example.

Organisational factors can destroy performance. Things like dependencies, staffing, structure and clarity, software architecture, etc. Companies are likely to build software designs that mimic the organisation’s communication structure.

A good team structure is one that allows for fast flow. It contributes to the organisation’s strategic direction.

Organisations need two main capabilities for modern software engineering - learning (feedback) and managing complexity.

A good teams need to have right expertise, be autonomous, have long term ownership over a domain and be strategic. Team is built of people. They need autonomy, have mastery and ownership of their domain.

How to make changes to team structure?

1. Observe
2. Find value streams - what is the team trying to do
3. Make changes
4. Rinse and repeat

Ideal team size is 5. With 7 people the number of communication pathways is 21.

This talk pulled from a bunch of ideas and thoughts that people have had many years ago (a fact pointed out by Gaurav many times during the talk). I imagine he had read these things over many times, taken notes and that has morphed into this project. I like this way of developing ideas and thinking about things. Small things become large.