Interesting tips and actions to help frame the conversation. The goal is to get the team better self-organized and directed.

Very good primer on a widespread and very hard to avoid bias. This is why it's hard for projects to properly meet deadlines.

Very nice piece about the various types of complexities we encounter in our trade, and what we can or should do about it.

Definitely this. Listen and write down issues before you start to complain. There might be reasons why things are as they are. Take the time to understand them and refine to have a better feedback.

Lots of good advices of course. It goes a long way to improve the quality of the project and the ease to on-board people. This is quite some initial work though.

A bit US centric at times, but there are some more generally applicable advices in this piece. This can help you navigate in the time of a company reorganization (not always called out as such).

Interesting idea... indeed organizations can carry legacy processes and ideas as well.

This study does a good job looking at the impact of community smells over the presence of code smells. This is an excellent reminder that the organization influences greatly the produced code.

Interesting survey results. This kind of confirm what we already suspected regarding longer work day and the amount of meetings.

Good blueprint for building up and following up (the most important part really) of a strategy in your organization.

Good point on why you don't want to drive your organization simply on RFCs. Yet another fad of "this worked for them, let's do it as well"... per usual this fails to take into account the specificity of the context where it worked.

This is a constant trade-off to find. How in organizations give autonomy while ensuring some consistency? A couple of ideas.

Interestingly (or maybe unsurprisingly) most of the factors this research found impactful are not technical. So mind the social constructs of your organization.

This is a sound advice. In other words, don't commit too early, only when you got enough information. Of course monitor to make sure you don't miss said information.

Nice little article about Conway's Law. Shows nicely all the ramifications it has.

Definitely this, what matters most is being able to change previous decisions. In comparison each decision itself is less important.

Neat little journaling system using vim. I can hear Emacs users cringe from here though.

Interesting way to organize your data. This gives a library feel for sure. At least it makes me curious.

We might start in a software career attracted by the "perfection of the machines" (already debatable) but indeed to make anything meaningful we need to interact with other people. I often say it but I'll say it again: it is a team sport.

Indeed, it's important for architects to get their "hands dirty". Organizations where it's not the case prevent their architects to challenge their assumptions pushing them to stay in their ivory tower. It's a good way for bad decisions to pile up over time.