How to fix your all hands

How to fix your all hands
5 minutes by Michael Lopp

All hands meetings become necessary when a team grows too large to naturally stay in sync. Most current versions fail because they feel like information dumps that employees could read in an email, and they center on leadership rather than the team. The article sets out to fix this by redefining the All hands as a meeting that recreates the natural communication flow of a small, close team.

Managing sideways
12 minutes by Kevin Goldsmith

Getting teams you don't control to change how they work is harder than getting leadership to agree. A good idea and people's willingness to act on it are nearly unrelated. The most durable approach is to start with teams that already want the change, let real results recruit the next adopters, and build shared ownership before scaling. Forcing compliance through authority or borrowed power tends to produce resistance that outlasts the win.

Treating people like pawns builds brittle empires
12 minutes by Yew Jin Lim

Good management means fixing broken systems, not pushing people harder. Teams work like systems with real limits, and ignoring those limits creates burnout and brittle organizations. Keeping teams small, focused, and protected from overload produces more than manufacturing urgency ever will. The managers who treat people as fuel may win promotions short term, but leave behind organizations that quietly fall apart.

How to run a technical due diligence: The fine prints
11 minutes by Sergio Visinoni

When a company acquisition closes, two key agreements shape the technical work ahead. Transition Service Agreement maps out how shared systems like HR tools or infrastructure get handed over, covering timelines, costs, responsibilities, and service guarantees. Share Purchase Agreement can also include conditions to fix serious risks, such as data privacy violations, before ownership transfers. Once the deal closes, the real migration work begins.

Building software is learning
6 minutes by Thorsten Ball

Building new software means constantly discovering what you actually want. No matter how clear a request seems, the only way to find out if something is right is to build it and let reality push back. The goal is to shrink the time between "let me try this" and that moment of correction. Prototypes, short specs, fake demos, and small daily releases all do this faster than weeks of solo building.

And the most popular article from the last issue was:

• Key activities for sustainable engineering team