Wednesday, July 14, 2010

People, too many expectations

Recently I've converted from a real job in testing, into a manager of testing people. It's odd going from expecting awesomeness in oneself to being responsible for the awesomeness of a team of people.

For one thing, the people underneath me, that I'm supposed to guide, none of them can move fast enough. Things take longer then normal, projects never seem to be as easy as they first appeared. At first I thought this was because I was a new manager and I needed to guide them more, but I have no wish to micro-manage people. I've been micro-managed and it was all I could do to get my manager off my back (sometimes lying) and then do what I needed to do.

Next I thought perhaps people weren't applying themselves enough. So I grabbed some people I knew had the requisite skills and gave them a project I thought was simple. Results: took three times what I thought it should.

So then I chucked it up to people not having enough time, I mean a QA Engineer whose on at least one team doesn't have that much free time, not to mention in reality most of the QA people under me are on multiple teams. But I can receive detailed feedback from these same QA people about topics that they had to have researched.

I've finally come to the conclusion that it isn't them, it's me (not surprisingly).

I couldn't keep pace with my own expectations, how would anyone else be able to do that? For one thing I never seemed able to move at a pace that was acceptable, there was always something more that I could do, some little thing that could be tweaked or made better, a new feature added, some better way to store, retrieve or move data. So it's not that I've settled for less, it's that I've realized that each individual has just this small sliver of time that they can devote to 'side' projects, and most of those people need to learn something (often times multiple things) new, before they can even start the project.

PS: This isn't a ding on them. The crew I have is some of the best people I've had the pleasure of working with. However I have to temper my need for results / speed with what people can reasonably do, without burning themselves out.

2 comments:

  1. You *need* to read peopleware. (demarco/lister) One bit: http://javatroopers.com/Peopleware.html and search for "estimate" The section is: Chapter 5: Parkinson's Law Revisited.

    Take a look at the chart. While it's not directly applicable, it is. The best productivity is when there is no estimate. Of course, the real world demands release schedules...

    ReplyDelete
  2. One of the dreadful injustices foisted upon managers-to-be is having been managed by individuals (or within organizations) who behaved as if the only way workers would "produce" was by applying external motivators. By extension, this applies equally - perhaps moreso - to parents who have similar ideas about raising children. You know the kind I mean. The ones who believe that if they're not constantly watching, their child(ren) will get into all sorts of hellish trouble. (Whereas that might be true to some extent, the unsustainable and short-term nature of such a strategy makes it of questionable value as a mode of guiding others.) As a result, though it may not have been at all desirable to be managed thusly, it nevertheless can easily emerge as a familiar pattern after becoming a manager.

    Pavlov would be proud. As with other forms of conditioned response, making a change from mimicking an undesirable template of action requires the ability to place a separation between stimulus and response, allowing the conscious mind to evaluate and choose - perhaps an alternate behavior. That's what you're doing right now: pondering the matter with a view to considering alternatives.

    You mention "awesomeness" and align it with a need to "move fast". Are these the same? Does awesomeness require break-neck speed? Does rapid movement ensure awesomeness? Let's assume for sake of discussion that most endeavors require a meaningful blend of the two - perhaps call it "effectiveness". Ok. So, is it a manager's responsibility to make his people effective? I suppose some of that depends on the point of view of the manager's boss. However, is it reasonable - or even possible to "make" someone effective?

    Again, for the purpose of discussion, let's oversimplify matters and say that there are only 5 types of things that would cause a person to be ineffective.

    1.) Trauma
    2.) Personality
    3.) Deficiency
    4.) Environment
    5.) Mismanagement

    Trauma
    From time to time, everyone encounters things in life that suck. Sickness, death, accidents, etc. Stuff happens. Move on.

    Personality
    This aspect should usually become apparent during the interview process. Figure out ahead of time what talents are needed and craft the hiring process to identify people who have them. If things unexpectedly change for the worse after what looked like a great hiring move, you can try to guide for improvement. Ultimately, it may be necessary to make a personnel change. Act promptly with integrity.

    Deficiency
    If there is a lack of experience or skill, find ways to provide learning opportunities. Be creative and supportive.

    Mismanagement
    Don't imitate the a$$holes - past or present - who have demonstrated their lack of managerial competence (Manager Fail!). Learn what not to do. Pay attention. Take notes. Ask those you trust for feedback to help you remain aware.


    The fundamental underlying question is: What is the role of a manager? Bus driver? Slave driver? Pile driver? It seems to me that it's similar to that of a band manager. Does he play music? Probably not. Does he drive the tour bus? Maybe not. Does he write the music or control the sound or lighting? Not necessarily.

    His job?
    1.) Organize and coordinate things related to time, money, and resources (enabling success).
    2.) Eliminate distractions and threats (averting failure).

    If these are handled - and with the right people in the band - the music (awesomeness) will come naturally.

    ReplyDelete