Earlier this week, I read a terrible WSJ interview with WeWork’s CEO who said that the most engaged employees are those who want to spend time in the office. Ignoring the inherent bias from a CEO of a company that sells office space, Scott Berkun (@berkun) offers a perspective of where fear of remote work stems from.

This is a fantastic article from Kate Leto (@kleto) a lot of leaders struggle with. In many cases, a team will need to work with another team, influence a different outcome and priority and this article provides a good starting point - raise your organisational awareness.

For leaders, in particular, finding time for uninterrupted work may feel utterly unrealistic but is important. Here are some methods you can use to optimise what limited ‘deep work’ time you have.

I’ve read about how AirTag’s can be socially abused (e.g. make it easy to stalk someone) but this article from Jim Salter (@jrssnet) is the first I’ve read about this product’s first security breach 🤨.

This is the 8th annual “State of Testing” report offering insights typically from those who self-identify as performing some sort of testing. I found some interesting results like 39% report doing some sort of chaos engineering (up from 9% in 2020) and more people wanting to find better ways to test ML/AI work.

This short article from Llewellyn Falco (@LlewellynFalco) & Jacqueline Bilston (@jmasonlee) provides a succinct description of what an agile technical coach does and how that might differ from a normal agile coach. These types of coaches, in my experience, are rarer but can offer much more value.

If you’re like several of the leaders I coach, I’m sure there have been many debates about how best to balance working from the office and remote work. I enjoyed this article from S. Mitra Kalita (@mitrakalita) highlighting some points you may not have considered.

I’m saddened by this experience report shared by Nat Bennett (@nota_bennett) who share their burnout experience from pairing all day. Although I recognise some of their symptoms, having done a lot of pair programming in my life, I also never worked in an environment where we pair programmed all day every day for long periods of time. I always worked in teams where we would have solo time for research, reading, and other activities. Good lessons though for leaders and managers responsible for the environment.

I like this article from Jacob Bo Tiedemann (@jabopiti) and Tanja Bach (@tanjabach) as it shares some concrete examples of what poor developer experience looks like and what you can do to change it. It also emphasises the financial cost which technical leaders need to recognise *and* communicate to influence management to invest.