Eliot's Ramblings

Debugging the Boss: The Hyper-Owner


Last week I started this Debugging the Boss series, to highlight specific traits that lead to management problems. I expect most people will see these traits in themselves or their bosses (I certainly do). I think everyone has some of these traits… in fact every manager should have many of these traits. What’s important is having them in moderation.

I’m going to post one of these every week or so until I run out of traits to write about. First up: The Hyper-Owner.

The Hyper-Owner

The Hyper-Owner/micromanager is a manager who bottlenecks their team by forcing all decisions to go through them, never delegating. This can be due to explicit distrust, but more often it is just a subconscious need to control everything. Hyper-ownership can be born from good motivations, but ends up having very bad consequences.

Behavior in meetings: Monopolizing. Sometimes even talks on behalf of people who are in the room.

Impact on team: Vacuums morale out of the team as members perceive the absence of confidence in them. Nobody likes the idea that they are a flunky who is only there because you can’t clone yourself.

Impact on product: The Hyper-Owner materially impacts velocity by delaying decision making. They will also erode the ambition of the product as velocity decreases. Users of the product can be alienated due to feedback that is never acted on.

When the status quo is that this person dictates everything, even a “perfect” micromanager who makes all the right decisions will stifle product development. The culture born of this management style impedes creativity, and punishes telling the Hyper-Owner they are wrong. When the business runs into areas outside this Hyper-Owner’s expertise, what you get is iTunes Ping, for example.

The trait gone wrong: Responsibility. The Hyper-Owner thinks their job is to be responsible for every single decision made at any level below them. It’s good to feel responsible, but bad to prevent the people you manage from feeling responsible too.

Debugging: Let go of your fear, you must. You hired the people on your team because they were the best (right?). Deliberately choose a decision to have a team member make, no matter how small, and then absolutely abide by it. Their decision may lead to an outcome you think is less optimal, but do not revert, rather try to understand the reasoning that led to that decision, and discuss the reasoning with the team member… but do not tell them it was wrong. Think of this process as an investment which will pay dividends in greater reliability and team velocity when your team is a well-oiled machine.

Not to be confused with: The Glory Hog.