20 June 2017

Building a Team: Different!

By: Russ Olsen In: People

The eternal question of our profession is how do you build good software? We talk endlessly about methodologies, about languages, about IDEs. What are the right programming techniques? Which technologies are the best? Should we use RUP or XP or Scrum?

They are all important questions, but if we are talking about large scale systems, they are the wrong questions. The right question is, how do you build a good software team? I'm convinced that a good team can build anything; a good team can make bricks without straw. And a bad team, well it doesn't matter. Give them straw and a bad team won't be able to produce bricks. Heck, give them straw and a bad team won't be able to produce straw. If you have some kind of leadership role and you need to build a development team, how do you do it? Well it ain't easy.

We are not all the same

A key part of building a software team is to remember that not everyone is the same. Some of us think in pictures. Some in words. Some of us like to talk, we could talk all day, while others seem to get an allotment of exactly 647 words each morning for use through out the day. Some of us did our homework with the TV blaring, while my son must have absolute, please don't tap your foot to your iPod music Dad, silence.

We all know that everyone is different, and yet we go on treating software engineers as interchangeable, plug replaceable units. You can hear it in the management jargon: we talk about resources when we mean people, about full time equivalents, about needing a architect, two mid-levels and a few grunts. Well guess what: it really doesn't make much difference which architect you pick, which full time equivalent you use, what particular resources you move onto a project. It is just the difference between success and spectacular, debris spewing failure. I'm not talking about good people vs. bad people here: you not only need good people to succeed, you need the right good people.

Calm and chaos

One of the key differences between people is how well they stand up to chaos. Every project has a certain level of chaos, some low, some medium, and some this is your new team that has never worked together we don't have any requirements, the schedule is tight so get busy coding, high. There are people who love to work in chaos, but don't know how to move chaos to order. There are people who love the challenge of beating down the chaos into something orderly. And there are people who will just fold up under the pressure, passing out while muttering, Where's the spec? I can't believe there is no spec.

If you have a chaotic project and you staff it with a combination of the I like chaos but don't know how to change it and I need structure types, you, or rather your project, is doomed. Similarly, move a chaos wrangler onto a CMMI Level 4 project and they will just wilt for lack of insanity.

Introverts and those other people

To look at another dimension, some people solve problems by talking them through. Give them a willing listener and a whiteboard and they could write the Great American Program. Others deal best with knotty problems in solitude. A good team should accommodate both styles.

Something of a confirmed introvert myself, I once worked on a software team peopled almost entirely by extroverts. They were nice enough, they were bright and they worked hard. They also drove me up a wall. No, I don't want to talk through this bug right now. No, I don't think getting someone else, or two someone elses in here to look at it will help. Just give me one hour of uninterrupted silence and I will have an idea of what to do. No, you can't wait over there.

I've also been on teams where nobody wanted to talk about anything, ever. Obviously a good software team needs both kinds of people, but less obviously, the team culture has to support both styles. As a leader you need to coax the introverts out into pair programming and free wheeling design sessions. But you need to recognize that they are likely to find these things exhausting and make allowances. You also need to encourage the people people to do their thing but also to give it a rest sometimes.

I once attended a week long course in agile techniques where the instructor announced that if someone couldn't pair program all day, everyday, he didn't want that programmer on his team. Well send the solo person to me, they might be introverted but brilliant. Capable people also come in all sizes, shapes, colors and sexual orientations. Capable people come with all sorts of political views, religions and gaming preferences. Some can run a 100 meters in a day, some in a week and some not at all. You should be making room for them all. The key to a great team is to make room for all the people that you need to be successful.

Ways of understanding

Then there are the different ways that people learn, the range of techniques that we use for coming up to speed on a new topic. I have, over the years, horrified various of my you start at chapter 1 and read through to the index colleagues by explaining my favorite technique for picking up a new technical subject. You see, I like to read books from the inside out. I start in the middle, and if the middle part makes sense to me I read from the middle to the end, jumping back to the beginning to pick up the missing details where required. If the middle doesn't make any sense, I start again, this time closer to chapter 1. Only if I can't make any sense of it any other way will I start at the beginning, and even then all of that hopping around is not wasted since I will have some idea about what the book is trying to say as I open chapter one.

As I say, this technique tends to make some of my coworkers turn green, which is fun. But it does work for me. Learning the way that I do does not make me smarter or more Bohemian or anything. It just works for me. But given the looks I've gotten over the years when I've described this technique, I'm pretty sure that it would not work for everyone. And that is OK. But what it says about building teams is that not everyone is going to get the same thing out of a training session, a book or a presentation. Whenever you can, you need to tailor these things to the person.

So there it is: remember, all those engineers out there, they are really are not all interchangeable. You cannot behave as if they all are and be successful.