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.

Definitely this, as projects scale, keeping an eye on dependencies between teams is key to efficient allocation. This will happen by trying to eliminate said dependencies, reallocating between teams.

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

Not fond of the metaphor used here which leads to quite some noise. Still, this article contains interesting ideas to try to push R&D initiatives forward. Definitely needed to improve any kind of organisation.

You've see a co-worker doing this, right? They're unlikely to be spies, but still they're inadvertently using sabotage tactics.

Another way to approach Architecture Decision Records. A different format to try to foster a more collaborative approach.

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.

Looks like a nice visualisation for workshops making sure you keep progress in check.

When hype meets group think, you can quickly create broken culture in your organization... We're seeing more examples lately.

Indeed, arguments have a function. If they're used they need to be regulated, otherwise you won't get the best ideas possible in your organization due to competition.

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

Interesting tips to reduce the power dynamics in organisations.

Very nice piece. This is indeed mostly about building organizational knowledge. If someone leaves a project that person better not be alone to ensure some continuity... lost knowledge is very hard to piece back together.

This law is unfortunately too little known. Here is a nice and short primer. Be careful though, it's short but packed with information, might require more reading around the concepts highlighted in this article.

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.

Surprisingly, I bumped into this article as I'm wrapping up reading the Team Topologies book. This highlight fairly well some of the concerns I have with it and where it shines. I think it's right to turn to the principles it's built on rather than use the model it proposes as a blueprint.

It's bloody hard to build a strategy. This article is full of good wisdom to make one. This won't make it really easier, but at least you won't start in the wrong direction and will be able to know if what you produce is any good.

I'm not sure the incentives are right... it's better to clean up as you go. Still some places would benefit from such an event from time to time and even if you clean up as you go missed opportunities happen.

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.