Interesting comparison of different definitions for software complexity (which is an ambiguous term to say the least). It leads to nice consequences when team dynamics are considered.

I prefer aiming for egoless positions in teams... But if it doesn't work, I guess this little trick can help turn someone around.

Good summary of the different possible options around remote work.

Or why it's important to deeply understand what you do and what you use. Cranking features and throwing code to the wall until it sticks will never lead to good engineering. Even if it's abstractions all the way, it's for convenience but don't treat them as black boxes.
Interestingly this article draws a parallel with organizations too. Isn't having very siloed teams the same as treating abstractions as black boxes?
Quite some food for thought here.

What is the "Whole Team" practice from XP? Well, it's fairly simple in the end... it's about collaboration really. Needs to be reminded often though.

Nice little exercise to quickly figure out if the skillset of a team properly matches their project.

Trying to measure individual productivity is definitely a trap. You'd better not try, otherwise you'll have wrong behaviors or you'll punish the wrong persons.

Interesting way to frame the question for leadership roles.

We should definitely put the 10x engineer myth to rest. Let's focus on setting up the right organisation and culture instead.

Nice tricks to help the team jell. I should try this more.

Aligning people with differing core values in a team is indeed necessary but difficult. It can kill your project for small teams, for larger teams you will likely need to think your organization keeping the misalignment in mind.

Good reminder that teams are made out of people. It's good to look at the daily standups less as a technical management tool and more as a need to get into the work.

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

This is a bit cartoonish I'd say but there's some truth to it. I indeed regularly get onto consulting gig where you find out that the people already had the solution to their problem. In those cases it's very often because communication channels are broken somewhere (team don't feel at liberty to share what they noticed, managers having a hard time to listen, etc.).

Interesting ideas in there. It's not enough to pick up that something is off in a conversation. It's better to influence things to defuse the tension. Clearly not that easy to do, will require quite some practice.

Another way to look at the fact that software engineering is a team sport. Missing this fact can lead to problems.

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.

Definitely this. Having "heroes" brings obscurity and hide the problems, this prevents management from knowing and handling the issues. This also create lots of missed opportunities for collective learning and improvements.

This is definitely a worthy advice with lots of interesting side effects. For me the main motive beyond cheer curiosity is developing more empathy towards others with different roles.

The advice is sound. Having more written records of such things definitely help teams. It can have a benefit in other forms (notes or todo's) if you do it just for you.