Stories about Software


The Dominant Leader Fallacy

There’s nothing quite like the pressure of assuming organizational leadership for the first time in a professional capacity. And, seriously, I mean in a professional capacity — I’m not talking about being voted captain of the freshman basketball team or student government something. Non-professional leadership scenarios are akin to poker games played at the kids’ table for chips only in that they’re artificial scenarios designed to build character by simulating the real thing. In these scenarios, a wrong decision can cost you a soda machine in the cafeteria whereas in a professional capacity wrong decisions can alter careers and livelihoods (and, in higher pressure gigs than I’ve ever had, sometimes even human lives).

I can’t speak across the board, but I can speak to organizational leadership against the backdrop of knowledge work (and in this case, I mean official leadership, as opposed to ad-hoc or thought leadership). In this field, you often have a good bit of “paying your dues” before you’re deemed ready for leadership. Sadly, the gatekeeper factors here are often duration of tenure or having been a leader before (the entry level Catch-22 all over again, wherein you need leadership experience to be given a leadership role and a leadership role to gain leadership experience). Thus, the waiting period might be years or even decades, in some cases, so if you’re ambitious, you’re probably chomping at your bit for a long time before it comes. And then it comes…

…and you’d better not screw it up! The very people that gave you the nod have you on quite the short leash, and they’re ready to yank you off the stage with a cane should you show the slightest hint of weakness. Whatever you do, never admit to ignorance of any sort. If it’s an acronym you’ve never heard or a technology you haven’t used, grit your teeth, fake your way through it and study up until 4 in the morning so that you can stay perfect in everyone’s eyes. And don’t think that this only applies to your superiors. Those you’re leading are also waiting for any excuse to dethrone you and lay their own claim, so don’t sleep on them, either.


Heh. I don’t know that I ever thought these things, consciously, but I certainly did to some degree on a subconscious level. And, while I’ve never been the sort to try to bluff at having knowledge I don’t, the part about staying up ’til 4 AM studying was (and still kind of is) definitely my style. I didn’t want to blow the whole leadership thing, so I broke my back trying to be perfect. But these days… not so much. I now break my back trying to do other things.

At some point, I figured out that trying to know more than 5 or 10 or however many people doesn’t scale very well and, even if it did, would winning knowledge trivia duels be the best use of your time as a leader? Maybe if you’re running a gang or a pack of wolves this makes sense — your cred is tied up in your ability to dominate any challengers. But I like to think that we have a bit more organizational sophistication in our approach. In knowledge worker professions, the best use of a leader’s time is removing obstacles that are stopping the team from excelling and figuring out how to create an environment that gives rise to good ideas.

If you’re a leader and you don’t know some finer point of the language that your team is using or you’re less familiar with a deployment tool than someone on your team, don’t hide that fact — embrace it! You’ve found a skill and there’s probably a need. Good leaders play match-maker in these situations. “Hey, you seem like you really know your Python and I know there’s some nasty code over in that particular module, so maybe you could get it sorted where the rest of us failed.” If you think back to the best leaders/bosses/managers/whatevers that you had in your career, did you appreciate them because they were better at everything than you were? Or did you maybe appreciate them because they got out of your way, trusted you, and guided the team toward playing to your strengths?

So if you’re new to leadership, relax and take a deep breath. You’re not playing a game of “king of the hill” and the team members aren’t adversaries looking for a crack in your armor. You’re playing a team sport and you’re more like the coach — they expect you to put them in a position to succeed rather than to push them out of the way and single-handedly win the game for them. So go in, cop to what you don’t know, and solicit volunteers for people to get the job done and maybe even teach you a thing or two along the way. Leadership is a matter of trust — not dominance.

Newest Most Voted
Inline Feedbacks
View all comments
Minnesota Steve
Minnesota Steve
9 years ago

The best managers I have had did not have technical backgrounds, and I think this is largely the reason. A lot less micro-management, second guessing of decisions and so on. There was one guy who for years I’d only ever worked with from the outside of his group, and he was always just this major a-hole who was tough to work with. Then I landed on his group and he was the best manager ever. I realized the reason he appeared an a-hole to the outside was he was constantly protecting his team from unnecessary distraction. Honestly one of the… Read more »

Erik Dietrich
9 years ago

Very good examples of archetypes of good and bad managers. The bad one you cite is perplexing to me. If anything, I probably tended to err as a manager too far on the side of not doing the things I hated rather than repeating them. I had hated micromanagement so much, that, at times, I might have been too hands off, for instance.

Rafal Barszczewski
9 years ago

I agree with this view, a common mistake from new leaders is the assumption that they need to appear as the most knowledgeable super developers, that know solutions to all problems. Instead of helping them build authority within the team, such approach will usually ruin it. Smart developers don’t need another smart guy as their boss.

Erik Dietrich
9 years ago

Totally agreed. Thinking back on the managers I’ve liked the most, they tended not to be developers (or, if they had been, they weren’t “alpha geeks”, so to speak).