DaveWentzel.com            All Things Data

Benevolent Dictators

I'm currently working on a team of data architects.  We usually agree quickly on a given design for most problems, but occassionally we do not.  When there is disagreement, the question becomes whose design wins?  How should we determine the "winning" design?  If the debate drags on too long the team's velocity comes to a crawl.  

In other situations there is a designated "lead architect" whose design approach may not match what most other team members feel is correct.  But again, on-going debate causes velocity to suffer, tensions to flare, etc.  How do you solve these issues?  

I'm often asked to help interview new managers.  I love to ask candidates how they would handle these two situations.  Occassionally a really bad candidate will state that he will decide the design.  Yikes.  In every other case I have heard some variant of wanting the team to "discover" the best approach and democratically determine it.  Ideally this is the correct approach if the team is high-functioning.  Democracy in these situations is generally a good thing. Still, in a situation where there is a 50/50 split on approaches, what should happen?  I always press the manager-candidate and in every case I hear that we should continue the democratic process until we sway someone to the other side and reach consensus.  No matter how long it takes.  No matter how many people slowly get alienated by the argumentation and loss of velocity.  At this point, the manager-candidate has failed for that interview question.  We aren't jurors in a capital case, we are trying to make good, quick business decisions.  

The real heart of the question is how should we govern our team?  Again, the worst approach is the manager makes the decision.  Democratic processes are not terrible if the team is comprised of all talented individuals.  In other words, if all votes are equal then the team must be comprised of similar contributors.  A jr programmer's vote should not be equal to the architect's.  

benevolent dictatorship is really the right way to go.  

The Benevolent Dictator (BD) is the person who makes the ultimate decisions.  The BD works in the best interest of the team, organization, shareholders, customers, etc.  People hate the term benevolent dictator, but I think it's accurate to the position.  Benevolent dictators are not appointed but instead are recognized for their abilities.  

Not every team will have a BD.  Not every team will be lucky enough to have a single person with technical prowess, speaking abilities, listening skills, etc.  However, most teams will tend to have a natural leader.  The BD is rarely the manager of the team because the manager is rarely technical-enough to handle the role.  The BD is foremost a technical position.  

Benevolent dictators are not always loved by everyone on the team.   Often I'll hear people bad-mouth the BD behind his back, but rest assured, when the BD is present the attitudes change.  And if the BD rules against a given design you can bet the BD will have temporarily alienated some folks.  

And the love for the BD is often transient. If the BD makes a totally unpopular decision the team can turn on the BD quickly.  Or if the BD tries to wield power for personal aggrandizement, people will flee the BD.  I argue that in those cases the person was not really the BD anyone.  BDs can't be usurpers.  

A BD must be willing to admit that a decision was wrong as relevant data emerge.  JM Keynes once said that he changes his mind as the facts change.  I hate Keynesians, but in the BD role I have to agree.  Wrong decisions will be made, but it takes maturity to recognize it quickly, admit it, and change course.  

People think that self-organizing teams are democratic teams where the leader is chosen.  I don't believe that.  Naturally, any single person will think he is better than anyone else at a given task.  If a team needs to democratically-elect the leader the team will not get the best candidate.  A true BD knows that if he needs to be elected it will mean extra work and time that he cannot devote to what is most important.  The election is not what is important.  Further, he will need to do battle with others who are usurpers and really just want power for its own sake.  The BD doesn't need to be elected, he's the de facto leader.  No one votes on who is the BD, it just naturally happens.  True "self-organizing teams" will rally behind the BD.   "Worker bees" will naturally want to gravitate towards the BD, and election is totally unnecessary.   

After I tell people my theory on BDs they first tend to think I'm crazy.  After thinking about it most people begin to agree with the basic BD structure.  Most people then want to know how they can become BDs.  Obviously technical proficiency is important.  A thorough understanding of the business domain is critical.  You must be a good listener and good speaker, and know when to utilize both skills.  Negotiating skills are necessary.  Likability is important.  There are obviously other traits too.  

I like to think I've been a BD off and on throughout my career.  Some folks aspire to be CEOs, others are content with being "worker bees".  Others want to get to middle management as quickly as possible.  I don't generally have aspirations for management.  I always aspired to be a BD.  I believe I accomplished this during my tenures with multiple teams and multiple employers.  I believe this because I was usually a key person being sought out for my opinion on complex problems.  After being a BD for awhile I actually became bored with it.  I think a sign of a maturing BD is that he no longer wants to be a BD anymore.  The power certainly isn't important.  He doesn't wish to mentor anymore, settle disputes, and be concerned with organizational issues.  

The maturing BD realizes that even though he is the de facto leader, he has a lot to learn that he can't teach himself.  This happened to me and I took a position at another company where I knew I could work for another BD that could help me mature further.  It worked.  I went from the BD at one company to basically a jr level programmer.  At first it was hard swallowing the fact that I was no longer BD, but soon I found myself naturally gravitating toward my new BD.  The BD there saw my potential and helped me to grow into a BD role as an even better BD.  And it didn't take long, albeit on a different team.  I was definitely a subordinate to that BD, but a mature person understands his role.  I always give credit where it's due to my BD mentor.    

Add new comment