Summary: A transcript of Boyd Multerer's video
Building a Great Development Team The original video can be found here:
http://channel9.msdn.com/ShowPost.aspx?PostID=16309
BM: I have some ideas about how to go about building an effective development team.
When you look at the releationship between developers on a team and also between your development team and your test team there are certain personalities that really stand out, and the thing to remember is that people on the team are
people and they have to communicate with each other and they suffer all the normal problems that people have when they are communicating.
So, when I think of building my team. It starts by reminding my of an old guitar player joke:
- What do you call a guy who hangs out with three musicians?
- The drummer.
So, the guitar players are looking down on the drummer and they are thinking "this guy is not a real musician, we're musicians". But if you didn't have the drummer in the band you totally lose the beat and they would be all over the place and it would be a mess. If the band was all drummers, they would have a great beat but it wouldn't be very musical.
You need to have all the elements, all the musicians, in the band in order for it to be cohesive, have a good groove and make some really good music and a development team is the same way. You need to have the guy who is really good at double checking his work, really good at double checking everyone elses work and really good at doing schedules. You need to have the guy who is really good at "Gee this is a really vague and ambiguous problem, we don't have a clear answer and there are competing interests in it" and he's able to listen to the various sides of the story and he's able to come up with some good directional answers. But maybe that's not the person who's going to spit and polish the schedule and make sure you're going to deliver on time. You need to have the person who goes really deep, the engineer who you give a specific really hard problem to. You know they don't care about all the other stuff that's going on but they can go deep and they can get that piece of code. You need the person who, maybe they don't go deep all the time, but they sit at a high level and they survey all the technologies across the team and make sure they fit together.
Now, the challenge is that these different people are bringing different skills to the table and they probable don't appreciate the other people. Everyone has this tendancy where they say "Well, I'm good at this and everyone else should be good at the same thing I'm good at and they're not so they suck". And part of my job as the development manager is that I keep them from beating each other up. If they appreciate each other and they say "Okay, well, you are better at the schedule than I am so I'm going to ask for your help" That works really well and trying to get people to leverage each other's skills instead of complaining about each other's weaknesses is what really makes the dev' team coherent and more effective. Especially at Microsoft where we spend so much time with process and getting our tools in place to track bugs, and here are the rules of making a check in, and we neglect the part about getting communications done and getting people to work well that way.
It gets worse when you start talking about dev and test teams. Testers are people who are good at telling you what is wrong. The devs tend to be really good at coming up with solutions and they tend to get mad at each other because of it, but they shouldn't. They should be leveraging each other's skills. It is kind of hard to do. But if you get it working right, then you increase your effectiveness a lot.
