The complexity and cost in organisations is indeed mostly about coordination. This is a difficult problem and largely unsolved in fact.

Feels a bit odd to go to such length to put it in numbers. And yet, it's clear that friendships in the workplace are a must. They should be fostered rather than stifled.

This is good advice. Going for something extremely small first is a good way to on board in a new project.

Good questions to consider to gauge how you work. Can improve the organisation if you really get to the bottom of it.

Interesting insights about pair programming.

Indeed, having generalists in teams is definitely what you want. Having only specialists will reduce the project efficiency.

The other advantage of not relying only on specialists. You actually get teams better at solving problems due to the extra context and communication channels the generalists will bring.

This is something I've definitely seen indeed. There are clearly a threshold effect in the amount of code you have to manage. Solutions working at smaller amounts don't work anymore a couple of order of magnitudes higher, and vice versa.

It's fine to surround yourself with people smarter than you. It's a good thing... except if they are competitive. Then it can become a curse and kill your motivation.

A bit too high on the "positive caricature scale" to my taste. That said there's a kernel of truth there, focusing on the developer experience will lead to improved impact.

You can also have experiments on your organisation. This is actually a good thing and probably should be done when something keeps popping up as a problem.

We can cast doubt on the "Spotify Model" (not really a model anyway...) all we want. Still, I think the whole "guild" idea in there was spot on. This article gives a feel of how it can be setup and the benefits it can bring.

Very interesting maturity model about proper communication in a remote work setup. I think it definitely makes sense and doesn't feel too difficult to evaluate.

A very long read but contains lots of insights. Goes from two very famous security related failure, to highlighting how a test first approach could have helped. It then finishes with a long section on how to foster a testing culture in an organisation.

Interesting stuff, very rich I think I'll have to get back to it. This gives good clues and ideas of metrics to look at when evaluating teams output. Some of the findings confirm hunches which is welcome. It also shows that measuring productivity keeps being a messy business, there are so many factors influencing it in some way.

I'm a bit on the fence regarding this article. That being said there's something I like about it: it's not always purely about money. It's also a good reminder that if the reward is in monetary form it's almost impossible to not somehow alter team dynamics with it.

I think the Open Agile Adoption ideas have been unfortunately unnoticed. It's thus hard to tell if it would have been fairly efficient. What's sure though is that the widespread mandate approach used during the past decade does a disservice to teams.

Good opinion piece, I wholeheartedly agree with the author on the topic. Like it or not, politics happen in organizations. Ignoring this fact is an enabler for bad decision making.

I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.

An old series of posts which highlights quite well why GitFlow can be a problem and that you likely want something simpler. Since I still find GitFlow often recommended as a knee-jerk reaction, this is a good article to have in hand.