Definitely this! All systems are produced in a given context. The organisation and the people producing it are what matters most to get something of quality (or not).

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.

This is a good way to see that the architecture questions are multi-layered. And yes, in enterprise contexts they go all the way to the company strategy level.

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.

Interesting view... This explains quite well why most organizations have both formal and informal processes. I'm not sure I agree that the informal will always be fought against by management though. I've seen clever management which accepts the informal processes as long as it doesn't harm the organization.

I wouldn't frame it as always superior (I'd argue the article falls a bit in this trap). Still this can sometimes be an alternative to driving everything purely on project mode. Some organizations would benefit from such a change of perspective other less so.

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.

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.

Nice list of templates to use for better handling of engineering management in your organisation. Pick, choose and adapt what makes sense to the context.

I don't think it's always unfolding exactly like this but there's some truth to that. Most projects see a "let's rewrite it in X" phase, this is rarely the best outcome.

A good way to frame the possible models for your organization regarding remote work. The GitLab Handbook stays a very good resource regarding remote work, they really thought about it and documented their findings.

A good reminder that long hours are not a sign of success with your project... on the contrary.

A bit of a long read, but does a good job explaining the use of assertions and how to introduce them in your organization.

A good reminder that there's a lot of things going on in something as mundane as a stand up meeting. It needs to be organized properly for the needs of the teams.

Interesting idea. Didn't make one but maybe I should sit and take some time to do that.

Interesting article about expert generalists (also called "paint drip people" by Kent Beck). This is definitely a skill to foster in teams. The article is long enough that I'm not in agreement with everything in it. That being said there's a lot of food for thought here.

An old paper which is still very relevant today. It's very much written in the context of the early women's liberation movement, and yet the lessons a much more broadly applicable.