My previous post was about starting out with a small team, and some ideas on leading it. The next few posts will talk about a few useful tools that I use in developing and shaping a team.

I didn’t do well in either macro or micro-economics in college. I was working my way through the liberal arts to find out what I was good at, and it turned out not to be econ. In college, however, I always enjoyed reading P.J. O’Rourke’s books. I was too young to see the cynicism, and so I read pretty much everything he wrote for several years, laughing out loud all the way. It wasn’t until I read Eat The Rich that I finally found one thing in economics that I can use practically daily: Ricardo’s Theory of Comparative Advantage. Now, I can’t do O’Rourke’s writing on this justice (Eat The Rich, Page 104-123), and I highly recommend reading it (along with all his books published before around 2000 – I haven’t read any since then), but I think it’s useful to discuss.

Comparative Advantage

Ricardo’s theory was applied originally to trade, but it has application to managing a team. What he says is that if you have two people, and each is able to do the same two things, albeit at different rates, you are best off having each person only do what they are best at.

So if Alice and Bob can both write C# and JavaScript, in the following ratios:

	C#	JavaScript
Alice	30 lines/hr	20 lines/hr
Bob	20 lines/hr	30 lines/hr

You can see that the best way to spend a day is to have Alice and Bob each do what they do best. That way you get 240 lines of C# and 240 lines of JavaScript (assuming 8 productive hours). That’s the most the system will allow, and that’s the theory – specialization is desirable.

But…

Bur the real world isn’t this simple. Obviously, this is a ham-fisted example using a very simplistic metric. You can’t just use a raw measurement of code, stories, use cases, or procedures written. Here, as a leader, you have to know your team members’ skills and abilities very well, and then use that to establish comparative advantage.

So you may be better off saying that Alice has a comparative advantage in middle-tier work , and Bob has a comparative advantage in UI development. And the comparative advantage is not an advantage of quantity – the entire model falls apart if a person’s work has to be thrown out or isn’t robust.

So given a project, you are better off using your developers’ skills in such a way as to maximize the productive output, but to do this you need to really understand each of your developers’ work. This takes a fair amount of time and observation. Code Reviews are a way to do this, but I don’t always like them. I personally prefer to read code diffs in source control so that I can see a developer’s thought process as they make a change. I think this provides good insight into how people work (of course, there are myriad others).

Maximizing Team Advantage

Once you know a developer’s skills and how they solve problems, you get back into the Role Playing Game metaphor. As a leader, your job is to raise the stats of your team. As you mentor, review, coach and help, you are trying to increase the total productivity of the team, while also helping your team members along their careers.

In our example above, is it worth improving Alice’s JavaScript skill? Given a pure view of comparative advantage, it’s probably not. Unless she can become better that Bob, the team will improve most if Alice and Bob both increase what they are best at. But what if they have other ideas? What if Alice wants to do more JavaScript work?

Here, we get into our first bit of ethics. I never thought I’d actually use Kant’s philosophy (I wasn’t good at this either. I learned most of what I know from from what was essentially a graphic novel), but here goes. Kant (among other things) said you should use people as ends in themselves, and not as means to some end. So you shouldn’t just use your team members to further the net productivity of the team; you need to take their needs and desires into account. I think that this, mixed with a complex view of comparative advantage, gives the right amount of complexity. So I’d sum this thus:

You need to work to maximize the potential of your team. Do do so you need to understand each person’s skills in terms of their comparative advantage in building good products. However, you can’t just treat each person as a cog in the machine, because it’s not ethical (and they will eventually quit). You need to take their abilities and development as individuals into consideration as you craft a plan to make your team become more productive.

This is a fairly complex bit of calculus. In fact, it’s a system optimization task above all else. There are probably actually several maximizing solutions to the problem of how to best allocate and develop team resources, but there is no single solution that applies to all teams.

Next: A little Process

P.S. Another awesome book about philosophy that is really accessible is Sophie’s World. It’s excellent and readable.