This article seems to mirror a concept I have started employing everywhere in life, not just as a leader: <i>go and see for yourself</i>.<p>There is nothing that helps you understand how something works as well as going to the place where it happens and interacting with it, to build your own mental model of how things fit together. If you rely on reports or other people's retellings, you're interacting with their mental models, which are at least one step removed from the actual system you want to understand.<p>Of course, it's critical that people understand it's not about trust. I fully trust that people have reported to me things exactly as they experienced them. It's about understanding – I understand things better when I get to experience them too.<p>(Obviously, I've stolen this from Toyota management.)
I both agree and am shamed by this article. As a team lead I asked my managers to "just trust me" too many times over too many years. Blinding trusting someone does him no service, quite the opposite: it causes them to take reckless paths which they will regret later.<p>I will not take the whole shame upon myself though. The article point "Engage directly with data" is something few managers take the time and effort to do. As such I am often forced to expand significant energy providing the evidence which the manager should have collected for himself. A lot of managers also don't really get to know the people they lead and quite often start from scratch for each interaction like we just met even after 5 years. These two pain points cause me to seek complete autonomy for me and my team, which means I also take my manager's responsibility for decision making. Over the long term I get overwhelmed and start looking for a new job.<p>There's ways I could attack every point of the article as context is always king. But I've been in the context he's talking about long enough to understand his perspective and fully agree with the conclusions even though, again, I feel shamed for falling in the traps presented.
> Today it’s common for first-time managers to get the advice that they should immediately stop writing code at work.<p>Really?<p>It seems like a very complicated blog and I think the trust more easily comes from openness. If I am speaking to a dev about why their task count is much lower than the team average, I can be open and say, "If your task count is lower, it might be my process, it might be that you are being distracted by the company or by others or it might be that you are struggling in some way and I can help...", that openness (which is true, I am not out to get people), means that the developer knows that it isn't personal or because I am an arse. We can then talk about what is going on.<p>Same with the "I have a problem", if it is small, sure, trust them to fix it. If it is something bigger (we want to change from Git to SVN), then I don't think anyone would be offended by a Zoom call to discuss the challenges that exist and whether they could be resolved in another way.
It's similar to how when an engineering colleague says "I'm getting a weird error here", I go over to their desk (assuming WFO), ask them to explain what they're doing, look at their screen, and ask them to run a few related commands to get more context. Without that, I don't have enough context to help.