Teams and Comparative Advantages

Jun 1st 2019

Years ago I was asked to manage an engineering team. I kept turning down the job as I told company owners that "You can find a good manager, easier than you can find a good engineer."  After they went through two managers, they asked me again.  I was reading a book about comparative advantages.  Specifically the idea was that when you are working with a team it is not always best for you to do what you are the best in the world at doing, but rather where you have the most comparative advantage among your team members.  The example I like to use is a special forces team, where you are the worlds best sharp shooter but you also a medical doctor.  If your team has good sharp shooters and no doctor then you play the role of the doctor because that is where you have the most competitive advantage.  As a result I went into management.. 

If you were to build a tactical team from your coworkers who would you want to be on your team and why? 

When managing people this is not a hypothetical question but a reality. You might pick people on your team to play certain roles based on their comparative advantages. However the easiest way to make a team fail is to put someone on the team that is well above or well below the skill set of everyone else. If someone is so good that they get frustrated with the other team members the best you can hope for is that the other team members rally against that one person and as a result bonds together against him until he leaves. If someone is really bad relative to the other team members the situation is far worse. That is the team members not only see that the person is well below them, but they see that this is accepted by management. So they start averaging down to the lowest team member's performance.

The irony is that pay does not matter. If you are paying two people to dig ditches and one is paid half the rate of the other, than from an economic perspective they lower paid guy could do half the work of the other guy. However the two guys working together do not know each other's pay and so the top paid guy will sink to the lower paid guy's output. If you are really lucky and got a good hire then the lower paid guy will rise to the other guys output. However you have to have a really good hires for this to happen.  

The point I am making is that low performers are a cancer to the organization. The coworkers will drop quality and productivity to that person's level and then they will test management to see if they care. They will do this subconsciously, until they are frustrated and do not know why. I have seen this kill more than one engineering team.

Contract engineering design firms go through this cycle. The owners are usually great engineers and branch out on their own. Then they hire a couple of guys. They start getting in lots of work as owners are great engineers. They hire more people to do work. They end up having 2-3 great guys, and then a hand full of burners. The burners work on projects and burn them down until they are critical. Then they put top guys on the project and try to pull it out of the ashes. The top guys soon learn they have to throw away all the prior work and they are constantly working overtime trying to get projects done with minimal over budget costs. They then learn management was in such a hurry to get going they missed doing requirements discovery.  So when the project is done it does not meet customers needs, everyone is unhappy. Eventually the top guys realize they are working too much trying to fix problems (like bad requirements) they have no control over fixing the root cause that they have to leave.

The only way contract engineer firms make it is if their founders realize that work gets done by people, processes and tools. That is if they get the right people, get them the tools they need, and then implement good processes they can succeed. When they have no processes, no tools, and mediocre people they are doomed.

For example, my process was very simple and followed two rules:

1. Stakeholders have a right to know the status of a project at any point in time. You must also tell them the moment a project is going to be late or over budget the moment you know it so they can adjust their schedules. 

2. Release early, release often, first release on paper. The idea is that each release of the project was incremental investment by stakeholders. The paper release is the cheapest and easiest to change, so you want to nail down all the details you can on paper before you ever do any design work. Then you do incremental design builds until it is good enough for customer. 

I am sure I missed a few rules, but following these two rules will allow you to excel above most.