7 ways to burn money as a developer - Part7: Cross-Team Collaboration

Part 7: Cross-Team Collaboration

This may be hard to swallow for collaboration evangelists, spotify-model-ambassadors and control-freaks.
Nevertheless, cross-team-collaboration is actually very costly and can be quite harmful for productivity.

All our efforts in that field result primarily from treating scrum by-the-book as the baseline for all future development team (and organisation) layouts we experimented with over the past fifteen years or so.

Everything that came after scrum more or less bought into the assumptions about roles, team sizes and such (and simply added more collaboration overhead).

From my experience, I can tell you that the “ideal scrum team” is basically never ideal. I have seen hyper-productive teams containing one, two, three and also more than ten engineers, in fact.
But the ‚ideal scrum team‘ suprisingly never resulted in an ideal or even extraordinary result.

If you put the ideas about a team’s minimum and maximum size, structure and roles – – and all other related dogma aside and solely focus on aspects that are actually relevant for a teams success, you potentially reach a moment of clarity.

A hyper-productive team, should be assembled around a mission, a goal. It should have access to everything it needs to succeed. It should include and own most of what it needs to succeed on an ongoing basis and at all times.

Such a team may be led by someone considered a product person, a technologist, a business person or whatever.
What it takes is someone that has a vision, a mission, a goal – and is able and empowered to communicate, facilitate and make decisions along the way.

What it takes is people to manifest that goal. This may be design-focus people or strong engineers. This may be 1, 3, 7 or 10.

If the delivery of the team integrates into an environment (think: product within a platform), the environment needs to be specified clearly.

You need documentation and governance around access to resources of the environment (think: user identity, permissions, UI framework…) to allow the unit to integrate into it. But the team should encompass and own everything they need.

The need for cross-team-collaboration and alignment often results from a poor organisational layout imposing dependencies and shared ownership.

Other aspects are knowledge sharing and code standards.
While having them within a team of people, the efforts to standardise everything across a huge organisation is simply not worth the result.

The key problem is the amount of relationships team members need to maintain. Relationships between 5 people results in 10 connections that need to be maintained.
A team of 3 needs to maintain only 3 connections.
17 people that aim to be “one team” need to maintain 136 connections.

The bigger the group that tries to align and collaborate, the lower the time and energy left to solve problems.

Therefore your team should be ready for its mission and able to execute on it with as few connections and dependencies to the outside world as possible if you want to excel.

If you find yourself in a lot of “guilds” and other (low impact) alignment activities outside your team, you likely find yourself in a structure that keeps people from delivering and which is burning company money on activities that produce little effect.

Thank you for listening to my thoughts. I hope you found them helpful and they help you to reflect.

Make sure to not miss the previous 6 parts of this series:

If you missed the previous parts of this series, go read and discuss them as well!

Part 1 – Trends
Part 2 – Microservices
Part 3 – Docker + Kubernetes
Part 4 – Kafka
Part 5 – Low abstraction technologies
Part 6 – Using Slack for Monitoring