You are here: Home / News & Notes / To lead programmers, you must be humble
Oct
14
2008

To lead programmers, you must be humble

By | News & Notes, Opinion, Tech

16 Comments

dogcupsuperfantastic

I’m tired of talking about how great I am.  What about you, what do you think of me?

There may have been a point in time when someone understood all that there was to understand about computers.  Early on there may have been one person who could stand above his fellow scientists and claim to be the authority on everything in this young field.  Where wizards stay up late makes a good case for a few individuals who may have filled that natural desire we have for an overall authority on a subject.  Yet those men, great scientists and tremendous minds in an unproven field of study, were some of the most humble ambassadors of technology we will likely ever see.

Today we have no overall authorities.  No normal person can hope to represent enough deep expertise to be considered an expert in more than one specialty.  Exceptional people may be able to handle two or three fields before being overwhelmed by the fire hose of information needed to keep up.  Hollywood has it wrong, again, about smart people in technology because there are no generalists out there that know everything.  Computers is similar to any other complex system like medicine, law, scientific research and finance.  It demands that you specialize to do be considered an expert.  (This may also be why I like House as a show but have problems with a plot device that pretends there are doctors that can ever know everything.)  Anyone who either pretends to be an expert on the whole of technology or really has convinced themselves that they are will be doomed to huge management failures.

Pete Johnson Chief Architect at HP and a guy who clearly knows what he is doing around a computer wrote up good article on Dzone about why programmers hate working for Software Architects.  Pete’s experiences run parallel to my own as a manager of programmers and his first point sums up my advice to anyone who wants to lead a programmer.

  • Be humble
  • Ask your people for advice on subjects you don’t know.
  • Make it public knowledge that you are the least important person in the room.
  • Stand back and let them shine before your customers, but stand in front of them to take blame.
  • Programmers can sniff out BS.  Honestly admit when you’re unsure of a direction.
  • Keep them informed and let them know when you are giving fact and when its your opinion
  • Ask only what you would be willing to do yourself.  Prove it by doing it occasionally for them
  • Keep a diverse RSS list and forward on good information to experts in your group
  • Be humble

What’s on your list?

If you liked this article, consider subscribing to this blog via email or RSS. Also, consider subscribing to have our free weekly newsletter sent to your email inbox.

Photo attributed to SuperFantastic on Flickr CC

Related Posts with Thumbnails
  • http://blog.nerdguru.net/ Pete Johnson

    Hi Aaron,

    Thanks so much for the kind words, I really appreciate it and I’m glad you enjoyed my DZone piece.

    I particularly like your third bullet there about being the least important person in the room. My favorite technique for that one is to poke fun at my baldness at the beginning of a meeting or, when engaging with folks on the business side, admit that my job title really only means I’m the biggest nerd in the room. Being conceited serves nobody, as you point out, and knocking yourself down a notch tends to relax everybody else.

    —Pete

    Pete Johnson
    Hewlett-Packard Company
    Marketing and Internet Platform Services IT
    Portals and Applications Chief Architect
    Work email: pete.johnson@hp.com
    Personal email: pete.johnson@nerdguru.net
    Personal Blog: http://nerdguru.net

  • http://blog.nerdguru.net Pete Johnson

    Hi Aaron,

    Thanks so much for the kind words, I really appreciate it and I’m glad you enjoyed my DZone piece.

    I particularly like your third bullet there about being the least important person in the room. My favorite technique for that one is to poke fun at my baldness at the beginning of a meeting or, when engaging with folks on the business side, admit that my job title really only means I’m the biggest nerd in the room. Being conceited serves nobody, as you point out, and knocking yourself down a notch tends to relax everybody else.

    —Pete

    Pete Johnson
    Hewlett-Packard Company
    Marketing and Internet Platform Services IT
    Portals and Applications Chief Architect
    Work email: pete.johnson@hp.com
    Personal email: pete.johnson@nerdguru.net
    Personal Blog: http://nerdguru.net

  • http://www.adjuggler.com/ Jonathan Rivers

    My Number one:

    -Be Specific

    Know what you want and how you want it to work. Be able to describe that in great detail, and then give concrete examples of how a particular feature will be used, and how often it will be used.

    -Jonathan

  • http://www.adjuggler.com Jonathan Rivers

    My Number one:

    -Be Specific

    Know what you want and how you want it to work. Be able to describe that in great detail, and then give concrete examples of how a particular feature will be used, and how often it will be used.

    -Jonathan

  • http://aaronworsham.com/ Aaron Worsham

    @Pete

    Brilliant advice since striking conversations with people is one of the greatest ways to learn new things. Anyone attending programming conferences should especially listen to it as you never know when your hallway conversation about some obscure language is really with the chap who wrote it (me talking politely and obliviously with Jim Weirick about Rake. Great guy!)

  • http://aaronworsham.com Aaron Worsham

    @Pete

    Brilliant advice since striking conversations with people is one of the greatest ways to learn new things. Anyone attending programming conferences should especially listen to it as you never know when your hallway conversation about some obscure language is really with the chap who wrote it (me talking politely and obliviously with Jim Weirick about Rake. Great guy!)

  • http://aaronworsham.com/ Aaron Worsham

    @Jonathan

    This is so important for programmer leaders to hear because many of the ones I’ve worked with are terrible at communicating these things. As a Business Analyst for a client I used to joke about difference between a project being ‘Done’ and being ‘Programmer Done’, which is really just a little sad.

    Thanks for the comment!

  • http://aaronworsham.com Aaron Worsham

    @Jonathan

    This is so important for programmer leaders to hear because many of the ones I’ve worked with are terrible at communicating these things. As a Business Analyst for a client I used to joke about difference between a project being ‘Done’ and being ‘Programmer Done’, which is really just a little sad.

    Thanks for the comment!

  • http://paul-zubkov.com/ Paul

    While I can agree on some points, the main thing is you have to be able to stand up and shoot the hot shot coder down when needed. Humble does not cut it at times. From personal experience. I know that every developer who reads this will feel worm and fuzzy inside, because the whole idea behind it is that the developers are gods and managers are lowest form of life who do not appreciate a great artists behind the IDE, but starting as a coder myself and doing mostly management right now, I have to say that developers without management would be doing what they like to do as oppose to what has to be done. And it what has to be done that pays the bills.

    Just an opinion.

    Paul

  • http://paul-zubkov.com Paul

    While I can agree on some points, the main thing is you have to be able to stand up and shoot the hot shot coder down when needed. Humble does not cut it at times. From personal experience. I know that every developer who reads this will feel worm and fuzzy inside, because the whole idea behind it is that the developers are gods and managers are lowest form of life who do not appreciate a great artists behind the IDE, but starting as a coder myself and doing mostly management right now, I have to say that developers without management would be doing what they like to do as oppose to what has to be done. And it what has to be done that pays the bills.

    Just an opinion.

    Paul

  • http://aaronworsham.com/ Aaron Worsham

    @Paul

    Your opinion is very well represented and I respect it, agree with some of it, and I’m glad you pointed it out. Thing is, I consider team building to be a separate management issue. The teams I’ve built start with mutual respect for each others contribution. Hot shot coders who are net negatives, as you mention, just don’t make it in my group. If someone decides they are irreplaceable and start doing ‘what they like’ instead of what we need, its just management 101 to either get them to think differently or move on.

    But thats just my opinion.

    -Aaron

  • http://aaronworsham.com Aaron Worsham

    @Paul

    Your opinion is very well represented and I respect it, agree with some of it, and I’m glad you pointed it out. Thing is, I consider team building to be a separate management issue. The teams I’ve built start with mutual respect for each others contribution. Hot shot coders who are net negatives, as you mention, just don’t make it in my group. If someone decides they are irreplaceable and start doing ‘what they like’ instead of what we need, its just management 101 to either get them to think differently or move on.

    But thats just my opinion.

    -Aaron

  • http://devjargon.com/ Alex

    Excellent points made. Working for/with someone who is humble is a far better experience than working with someone who is conceited.

  • http://devjargon.com Alex

    Excellent points made. Working for/with someone who is humble is a far better experience than working with someone who is conceited.

  • Javier

    Let them be creative and always be able to listen.

  • Javier

    Let them be creative and always be able to listen.