unicolet.org

 🏎️ (Another) Great piece by Luca Rossi  on AI, this time about AI governance. At the beginning Luca mentions brakes, which immediately reminds of a great quote I got from Matthew Skelton : why do cars have brakes? to go faster! Almost counterintuitive at first, but when you think about it, cars can only go as fast as their stopping power allows. It's a balance, really. High performing teams know it, that to go fast you need more "brakes": linters, sast, coding guidelines, reviews, documentation, tests of all kinds and assorted automation. Beautiful piece, highly recommended: https://refactoring.fm/p/getting-started-with-ai-governance

Interesting take on how one of the most regarded teams in the world (US Navy SEALs) use a dynamic hierarchy depending on the desired outcome: The US Navy SEALs offer a compelling example of how teams can dynamically shift their hierarchy. In the field, SEAL leaders employ strict, hierarchical, top-down command and control to ensure a unified front and clear delivery of their objectives. However, in after-action reviews on base, those same SEALs will deliberately flatten their team’s hierarchy, even going so far as to remove their stripes and insignia, to encourage open discussion and reflection uninfluenced by rank. Original article:  https://www.forbes.com/sites/londonschoolofeconomics/2026/03/12/the-most-successful-teams-dont-stay-flat-or-hierarchical-for-long/

Another illuminating quote from Matthew Skelton , posting about Mike Burrows book Wholehearted : Don't re-organize people; re-organize purpose This made immediately sense to me, as I often find that teams that struggle to perform are teams that don't have purpose or have lost it or are so removed from their outcomes that they mechanically complete the next thing. Also, this once again shows how crucial the role of the chain of command is for providing this purpose (the why), making a compelling case against micro-managers, or we-need-a-process-for-everything managers.

An enabling constraint is a limitation or rule that, rather than hindering creativity or progress, actually promotes innovation and problem-solving. In software development, we've all experienced the positive effects of enabling constraints. Examples of enabling constraints in sw development are: trunk-based development continuous integration static code analysis/checks, i.e.: enforcing rules such as function or method length, number of parameters, naming conventions, etc Recently, I've been thinking about the use of enabling constraints at the organizational level. One example I think I heard here was about strengthening the cooperation between engineering and marketing. The solution can be remarkably simple: have marketing prepare the material for a feature  before  its implementation. What I was wondering is: how should we think about this change in terms of Team Topologies? Before diving into the topologies and interactions I would observe that this change adheres to som...