Micromanagement with purpose š§
Or: you canāt delegate what you donāt understand
A couple of years ago, I was attending a leadership development workshop. The facilitator posed a simple question to the virtual room: āwhat was the trait you disliked the most of your previous managers?ā Within seconds, the word cloud filled up with one answer: micromanagement.
No surprises there. Having someone constantly breathing down your neck, demanding unnecessary updates, scrutinising every comma, or dictating every technical decision is frustrating and demoralizing. But over time, Iāve developed a bit of a hot take on this. Micromanagement is bad, of course, but as a leader, I want to keep the option open. Because if itās true that in this industry, success depends on delegation, you canāt delegate understanding.
The leaders I respect most are the ones who can zoom out and provide sharp, actionable insights rooted in industry and product knowledge, and who know when to step in, when to let the team grow (even if that means making mistakes), and when to challenge a decision they donāt agree with. That balance (knowing when to trust, when to guide, and when to dive deep) is what separates a great leader from a controlling one. Get it wrong, and thatās when micromanagement becomes the problem. Itās not micromanagement itself that people hate (and agreed, I might find a better word for it later), but using it blindly and without purpose.
If I look back on my own experiences, I never felt micromanaged or undermined when a senior person provided perspective or unpromptedly asked to discuss how I was approaching a task or project. Frustration only arose when their input was unnecessary or factually inaccurate - but thatās a separate issue!
Why micromanagement is bad?
Itās well known that one of the key strengths of an effective leader, especially a newly appointed one, is delegation. When leaders insist on overseeing every detail, they deprive their team of the chance to take ownership and build the skills needed to be independent executors and decision-makers.
Beyond that, and perhaps more selfishly, a leader who inserts themselves into every decision risks becoming a bottleneck. This not only increases their workload (a perfect recipe for burnout) but also slows the team down, hurting efficiency and adaptability. It holds back individual growth and leaves employees feeling undervalued and distrusted. Over time, this dynamic leads to stagnation, where the team becomes reactive instead of proactive, waiting for instructions rather than driving initiatives.ā
A crucial aspect of leadership involves assembling a team of individuals whose strengths complement and surpass one's own. By micromanaging, leaders (inadvertently or not) suppress the diverse perspectives and new ideas that world class talents bring to the table. This not only limits the team's potential but also deprives the organization of fresh approaches and solutions. ā
All in all, a reactive culture that slows down individual growth (aka āall the bads of micromanagementā) leads to frustration, diminished creativity, and high turnover, putting an almost literal ceiling on a team's output. Leaders who canāt let go end up holding everyone back, including themselves! Instead of fostering growth and autonomy, they create a cycle where neither the team nor the leader can truly progress, dragging down both productivity and long-term success. But hereās the question: what about the complete opposite?
The role of a leader in tech
If micromanagement limits growth, the opposite extreme isnāt great either. A manager who doesnāt understand (or even try to understand) their teamās domain ends up as little more than a shadow of authority, forwarding emails from above and hoping for the best. A managerās job isnāt to be involved in every detail but to make sure the team can move forward independently and effectively, with the right level of context and, above all, support.
Support, of course, can be human: being present, listening, and unblocking when needed. But it also means making sure each person has the right safety net: the people, tools, and knowledge they need to do their job well. And when things donāt go as planned, a manager who has built a solid understanding of the domain (or at least the ability to ask the right questions at the right time) can step in to take real accountability for delivery. Thatās not about jumping in and taking over (Iāve seen it happen, and while itās not always a bad call, it should be rare), but about knowing when to intervene and when to step back. Delegation isnāt just offloading tasks; itās an investment in people. Handing over responsibility doesnāt mean disappearing, it means trusting while ensuring the right tools, context, and guidance are in place. Knowing which ones to lean on, and when, is key to success. Just as importantly, managers need to understand their teamās work well enough to advocate for it. That means stepping in when someone is out, fairly representing their contributions, and pushing back when their work isnāt getting the recognition it deserves. Understanding the full depth of the work is crucial to being an authoritative and legitimate voice when it matters.
Beyond delegation, a great manager provides perspective. Sometimes, the most valuable input isnāt solving a problem but helping someone see it differently, especially for more senior individuals. Itās about connecting dots they hadnāt considered, sharing industry insights, or flagging risks before they become real issues. In engineering, itās true that highly technical team members often have skills and depth that their managers donāt, and thatās how it should be. But being so deep in their craft, they might sometimes miss the broader perspective that a good manager can provide. This balance is especially critical in data science. The hardest problems here arenāt purely technical; they emerge at the messy intersection of product, data, and real-world constraints. A good manager in this space doesnāt just manage people; they help navigate that complexity, ensuring the teamās work is understood, valued, and (most importantly) used.
I spoke about this last year at the AI & Big Data Expo in London š¬š§ in my talk, 'Donāt LLM Before You Can Walk.' I explored the gap between technology issues and product issues that often hold back machine learning projects from delivering real impact. Check it out if you're interested!
The path to understand a domain
As a leader, your primary role is not to fix problems directly, but to understand them deeply, even from a bird's-eye view. Approach the domain with curiosity, asking questions that get to the core of the challenges at hand. You wonāt always have all the answers, and thatās perfectly fine, your team probably doesnāt either. But starting with the right questions is the first step toward finding good answers down the line. As you progress in your leadership journey, your job increasingly becomes about digging beneath the surface, seeing past the day-to-day symptoms, and identifying the root causes. To do this, you must build mental models that allow you to navigate complexity, simplifying the situation without losing sight of the bigger picture. The details are often your enemies. They can easily draw you into the weeds, which, while rewarding in the moment, can make it harder to see the true issue. Finding the right balance is key, and itās a skill that requires continuous practice.
As you embark on this journey, embrace the discomfort of not knowing everything, particularly for high-performing individuals stepping into leadership for the first time. This discomfort is a necessary part of growth. The most effective leaders acknowledge their personal ignorance and make it a point to ask the right questions at the right time, without fearing that a lack of immediate answers undermines their authority (a very good series of posts on how to practically start delegating is here and here!). When someone asks me what makes a good manager in this industry, Iād say curiosity, among other skills. Knowing when and where to seek answers (and being genuinely passionate about the process) becomes just as important as having those answers at hand.
Embedding transparency within your teamās workflows is essential. It ensures that critical information isnāt siloed or hidden, allowing everyone (including you!) to access whatās needed when itās needed. The more open and accessible this knowledge is, the faster you can identify gaps and spot areas for deeper investigation.
Donāt shy away from complexity. Itās often the most intricate problems that yield the most valuable insights. Every minute spent untangling these complexities will pay off in the long run. This may sound counterintuitive, because an effective leader simply cannot dive into every day-to-day technological issue their team faces. However, deciding when to step in and fully understand things (without proxies) can be incredibly rewarding and valuable in the long term. When you consistently seek to understand, rather than simply solve, you build a foundation of knowledge that is far more sustainable than any quick fix could offer. In the end, knowledge is always better than ignorance, and your role as a leader is to continually pursue it, even when the answers arenāt immediately clear.