Of Coders, Professional Programmers, Martial Arts and Ginger CatsThe VB.NET Salary Gap

How to be a Benevolent Dictator

September 16th, 2007

A Bad Boss-tator in actionThe software development world is filled with bosses who treat their words as if they were edicts from the throne. This works, sometimes, but it is often at the expense of team morale. Without the prevalence of bosses like this, we wouldn’t knowingly laugh at Dilbert’s “pointy haired boss” or Office Space’s Bill Lumbergh. However, a pure majority rules scenario also encounters problems when a tough, contentious, decision has to be made. Most often the ‘decision’ in this case is no decision at all and the problem goes unsolved. Between these two extremes is where the Benevolent Dictator comes into play.

Leading Without Leading

The first idea is to allow the team to make the majority of their decisions as a team. You don’t have to jump into every difference of opinion with your words from on high. Instead, listen, find points of agreement and bring them up, and help the team to reach a consensus. This gives the team a feeling of group achievement and comradery that would be missing if you forced the issue.

You shouldn’t make important decisions without some input from the team, either in the form of a vote or a group discussion. Too often, managers will make decisions on things like which version control system or coding standard is to be used and barely consult the team or even not consult them at all. By allowing participation the benevolent dictator insures popular support for a decision.
However, you should not simply abdicate your role as leader to someone else. I have seen some managers, particularly ones with lacking technical or interpersonal skills, allow a more forceful person to become the defacto leader. This can undermine your ability to lead a team when your leadership is needed. And there will always be time when it is needed.

But You May Need To Impose a Decision

One common failing in self-lead teams is the inability to reach a decision, particularly on tough choices. As one team member I used to work with was fond of saying, “That’s a non-issue”. Unfortunately, often it was an issue and it came back to bite us later. The benevolent dictator’s role is to identify those areas where a hard decision is needed. If the team can’t reach a consensus by being guided toward it, then it will become time to impose a choice to break the deadlock. Sometimes just the implication that this will happen will be enough to have the team develop a consensus.

Sometimes a decision might be so polarizing, like those that often come up when discussion coding standards, that putting it up for vote or organized group discussion might damage the team’s ability to function. In that case, it may make sense for you to impose a solution or compromise rather than having the team at each other’s throats. They might not like you for a while but, with any luck, the team should be intact. The key thing here is to use your power very judiciously and not arbitrarily and to give a good, solid, explanation for your decision.

The Goal: An Effective Team

The goal of anything a benevolent dictator does should be to build an effective team, a team that develops software that solves the problem at hand. When your decisions, or lack of decision, fails to work toward that goal, your leadership of the team has become ineffective. If your interpersonal or technical skills are holding you back, take steps to improve them. Likewise, if you find yourself bullying your team, learn to keep this tendency in check. It’s all about seeking the right balance to achieve your goal, a high performance team.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Development Teams

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (No Ratings Yet)
Loading ... Loading ...

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities