Annie Vella published another insightful post that resonated with me. As an Engineering Manager, her point #3 “Colleagues stopped talking to each other. Rather than asking one another, they now rely on a model, further compounding the ambiguity and exposure gaps” worries me, and it has influenced some changes in how my team works:
Firstly, the stand-up length. Throughout my career, the standard advice has been that a stand-up should take no more than 10-15 minutes. Anything longer used to feel like a failure, for wasting everyone’s time. But first with hybrid work and more recently since engineers started spending most of their day talking to Claude instead of each other, the lack of face to face time has become concerning, as it becomes increasingly likely that important design decisions get made in isolation.
“If standup takes too long, people have less time to work” is no longer a practical concern. On the contrary, it has become necessary to slow things down a bit and give everyone enough time to really go into the details of all the decisions they are making. The idea of scrum has never been more important - everyone comes together at the start of the day, before breaking out to do their individual work.
So the length of the stand-up no longer worries me. In fact, the more time engineers are spending discussing with each other, the better. I have really come to embrace the one-hour stand-up.
Secondly, the changing mindset about code reviews. Plenty has been said about the “pull requests are the bottleneck” topic. But from an engineer’s point of view, there’s so much AI assisted code generated every day that they cannot be expected to be the quality gates and provide meaningful feedback to each and every PR. (Increasingly, the feedback comes from rules-based agentic reviews anyway.)
As a manager I have to recalibrate my expectations from human code reviews, so that people don’t get overwhelmed, and stop checking PRs altogether. Not everyone in the team might have enough context to be able to “review intent” or “express taste”. This was lowkey always an issue with junior devs reviewing their seniors’ PRs.
It is important that people at least go through the PRs, as a way to keep up with what others in the team are doing. So I asked my team to treat PRs like reading the morning newspaper. I mean, at least catch up on what’s happening in the project even if you think you are not able to contribute through feedback.