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

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.

This is still a good framework to think about what motivate developers in a team. Not everyone is the same.

Don't just blindly apply dailies. Make sure they really solve a problem in your team.

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.

Both approaches have their pros and cons of course. Whatever you pick, it has to start with a care for quality shared within the team.

If your team is solely in "pushing tickets out" mode, there's indeed a problem. Teams needs more agency and care for the output to actually strive long term.

I like this article. Indeed, focus on building organisations and teams where it's easy to do the right thing bit hard to fail. This is much better than obsessing over mythical 10x engineers.

Interesting trick. Good way to frame decision making when needed.

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.