Managing developers is an art, just ask anyone who ever had to manage me before. I cringe at the thought.

Much is on instinct, sure. Some is just calibration, keeping an eye and ear out for things that people do or say, even their eye and body movements if you are into that stuff. But this is quite different when the person is remote and you may never see them face to face, even for several years working closely together.

What Have You Done For Me Lately?

There are many different approaches of course. I could just manage the task and just let the person doing it become a non-issue in my mind. This has it's merits of course, if Jimmy or Johny had some favorite distraction such as Grails or Groovy or going cycling on nice days, I would just manage his work and ignore any other conversations.

if 	
the developer shows any humanity that doesn't matter to the task
then
I simply ignore it, and him, until he is back on topic

This is a very powerful approach for the short term. May not be much for building rapport, but it may not hurt much either, if it's not rapport that you are after, it's results, right?

It is also a bit passive aggressive, any sentence with "ignore" in it can be pretty dangerous at times. Power, though, is there.

I'd rather not use this approach if managing people, because I'd rather not be managed this way. At least not as a default.

Metrics?

Sometimes it seems to me that Metrics is the Judo of task management. In that you don't fight the energy of your opponent, you attempt to convert that motion into your next response. Very efficient, mechanically.

Even Agile approaches seem quite metrics oriented, though they use terminology like sprints and tests to define metrics. In this vein, the manager neither ignores nor pays attention to distractions and human elements. He is so focused on metrics that anything else is viewed in the perspective of the metric, and if it falls out, appropriate grief is noted.

if
    there is a metric that the manager is focusing on
    there is a distraction such as groovy/grails
        that the developer wants to bring to the table
then
    the manager laments that it doesn't help
        this one target task
    the manager indicates interest for some
        future task using groovy/grails

Alas this is a perfect example of how to get to know the guy you might be managing, and planting the seeds for later dissolusionment.

if
    the manager indicates interest in something
that later proves not genuine
then
    the developer quickly learns to distrust
the guy as being insincere and a fake

This creates a whole fakey management culture, the guy is gone in a year or two because by then it's all a shell game.

Rapport ?

if
    the manager takes whatever time it takes to get to know the guy
then
    the guy may be totally willing to set aside his distractions
and stick to the manager's goals   
   the schedule may fall a little bit behind because all
that touchy-feely time was spent? Dunno

To be truthful, this is still a bit hypothetical for me as a manager because I am not always as practiced at listening as I need to be sometimes. If it's not about results, I'm just not interested. That is going to change because it produces bad results.

And this "time it takes" thing is entirely amorphous to me? How much time? If it's too much, I won't do it. How to know, and how to regulate? Hmm.

Stephen R. Covey does a really good job of talking about this in his book on The SPEED of Trust: The One Thing That Changes Everything.

The Narcisstic Approach: Me Me Me

Another approach to getting to know the people you manage is to do all the talking. I've tried that for years. Tell everything about yourself. Make them listen. Good, now we know each other.

Ouch.

Maybe I can just leave this blog as the part of me that I expose to the public. If they want to get more of my flavor, then there it is, if they are not interested, all the better.

Patience and Rhythm

OK, most people already know this. Just shut up, watch the rhythm of the situation, and be patient. I will get to know everyone that I would manage by just paying attention to the rhythm of the communications over time.

One of the best object lessons I have ever had on this is my friend and mentor Michael Nash. We worked together for years, sometimes he led, other times I led. We only became friends out of respect. And it tooks us I think 3 years to ever even hear each other's voice or see each other's face for the first time, it was all by email and sharing code.

The big win in this approach is humility. I won't know everything the first day on the job. That is good. Such a task deserves to take a longer period of time. Trust develops, and with that the speed I need to get results. Seems kind of a contradiction, doesn't it?