Fluid Labour

(Yes labour has a 'u'. I'm Canadian dammit! Without 'u', there can be no honour!)

Companies go to amazing ends when it comes to finding the right person for a job. They'll spend hours creating a job description, they'll post it in hundreds of spots. They'll take it to universities and trade conferences. They'll parse through thousands of resumes. Then there's the dozens of phone interviews. Then a handful of candidates are flown across the world to spend a whole day getting quizzed and questioned on their appropriateness for the job. They're asked about their skill set, their interests, and their previous experience. The top candidate gets a offer, and then negotiations begin to determine if the candidate can be hired for what he's worth. Sometimes the offer keeps going around trying to find the right candidate at the right price. If all goes well the new member gets a relocation package, a signing bonus, and sometimes an immigration lawyer.

The total cost of all this is tens of thousands of dollars for each position, so a small team will cost hundreds of thousands to bring together. Finding a stellar manager to lead this team is even harder, with head hunters, employee referrals, and even larger bonuses all increasing the cost.

In the end though, this well designed machine will be perfectly designed to finish the job at hand. Sure there's never a guarantee that they'll be able to succeed, but if they can't do it, no one can! ;)


So what do we do with this team after the project is a resounding success? Do we thank everyone for their time and effort and then make them cash out their stock options? Tell them to apply for a job on a new project?

Of course not. These people were expensive to hire, so we'd like to reuse them if possible. But how does Corporate America do that?

Most corps are horribly inefficient about allocating labour for their next project. Instead of building a team around a problem, an existing team is given a problem. This project is usually similar to the old one, but will always have differences. Some members of the team will have specialties that don't apply to the new work, while there may be a new need for specialties that no existing member has. The old manager may not no how to lead the new type of project.

The existing members have also gained experience, and want advanced and challenging work to reflect their new abilities. Corporations usually resolve this by promoting the top couple of employees to supervisors, and hiring some new people so they have enough people to fill out two teams. The management pyramid begins. The new hires are selected to be a good fit on the new project, but they are also selected to be inexperienced juniors because they'll be working under a young supervisor.

More often than not, one of these new teams gets the project: "Maintain the last project!" Fun! Granted, the people with the greatest knowledge about the project are exactly the people who made it, so this group contains qualified people. But most of them are over-qualified. The type of team necessary to build a project is usually far stronger than the team that maintains it. Companies are tempted to keep the most prolific programmers on the old project because they understand the most code. But of course it is these members who are the most over-qualified to stay on the support team.

For the other team, half the strength of the old team will now be gone to maintenance, and in their place will be a handful of juniors. The great old manager has also been lost to the bureaucracy and the team is now lead by the a new supervisor. How was this super selected? Usually he was promoted because we was the best programmer. His management skills may be non-existent, but they couldn't promote a lesser member without fear of upsetting the new super.

Management will now select a project for this team to work on. Read that again! We've gone from selecting the perfect team for a project, to finding a project for a team. The makeup of the team is determined by office politics, and the make-up is fixed even before the project is selected.

If a project suits a certain mix of employees, it is highly improbable that the new team will have all of those skills. Sometimes a new employee can be brought in, but obstacles such as unexperienced supervisors can make this difficult. In many ways it's even harder to bring a skilled employee from another group within the company than it is to hire one from outside. No team ever wants to give up a "headcount". You can't even trade for the employee because he's typically more senior than who you can offer.

The size of the team is also determined almost exclusively by office politics and irrelevantly to the project. Companies feel obliged to reward well done projects and seniority with new "headcount", and would never think of shrinking a team because it would send the opposite message.

Occasionally the teams and projects will get so out of touch with reality that the company does a "re-org". For the first time, the company considers firing people who are bad performers. Unfortunately they don't fire employees who have done good work in the past, but are not relevant to current projects. Large teams are built up under strong managers for big projects, and newer supervisors are given little teams and projects to grow under. Ideally this "re-org" would be the same as building a team from scratch, but far too often existing teams are largely kept together and moved around the bureaucracy. Most managers though will not lose significant "headcount". Instead they will take on multiple, unrelated projects that happen to have a total number of team members close to the old "headcount". Small teams get treated especially harshly as they can be easily "traded" between managers to balance "headcount" disparities.



Now I've certainly glossed over a lot of the reasons companies do what they do. They can't fire people without due cause or they'll get sued (unless they re-org, in which case they just pay a severance(?)). New college grads are initially quite useless but get put on teams so they'll learn and grow. And sometimes you've got a strong employee who you expect to need in the future and you want to keep them around so you toss them on someprojectoranother.

These reasons are valid, and some are due to regulations and social norms that are outside the control of the company. Many though are easily fixed by changing the corporate atmosphere. When a project completes, let the team dissolve, and let new projects find them. Tell people in advance that they will have to find a new position every product cycle. If someone has developed the skills to be a supervisor, let a project in need of those skills find them. Let a senior developer move on to a new exciting project. Form a new team to maintain the old project and try to recruit from the old team's members, but pick them according to needs, skills and willingness to work on it.

The hardest step for management: Some managers will end up with fewer "headcount", and some managers may not be able to find new projects. Which leads too...

And the real hardest step: If someone can only find positions the value him less than his current compensation, give him a pay cut. If no team needs someone at all, let them go.

This is easy for deadwood employees who aren't worth a thing, but it's incredibly hard to do for specialist employees, which includes some managers. A company might have spent a quarter million dollars looking for the right XYZ specialist, but if that project is done and no project needs XYZ right now, let them go. If you force them to do maintenance, or make them a supervisor, or any other waste of their talent, they'll just leave anyway.

This system doesn't lessen the value of specialists, but rather makes them incredibly important. Instead of running a project with the team you've got, you can build the team you need. You're free to hire a specialist from an existing project, or outside the company.



The opposite system to Corporate America is the start-up system and it too has its flaws. There's certainly a great flexibility to try to hire the best specialist for the position, but while there's a will, there aren't the means. A start-up simply can't afford to spend many tens of thousands of dollars plus the likely more valuable time required to hire these individuals. They also usually can't offer the same level of compensation, instead offering stock options (read: lottery tickets). Much of their flexibility is reduced because they can only attract a limited number of candidates and can only spend a limited amount of time reviewing them.


Ideally then, a system would exist where a company has large resources available to try to recruit individuals into the company, and then within the company there would be fluid labour system that allowed members to move to where they are needed.



On the surface Microsoft has a system that resembles this. They have hundreds of teams, and they "hire" internally, and when a team is dissolved the employees are given a month of paid internal job search time.

There are a number of crippling limitations however. The first is that teams usually only dissolve when a project is canceled. A project like Windows is never going to be canceled, so the normal bureaucracy of "headcount" and promotions ensues. Even teams making one-off products like video games are likely to move on to a sequel without really disbanding the team.

This bureaucracy then taints even the otherwise agile teams. Compensation becomes directed from the central bureaucracy so that people on different teams at the same "level" are given similar compensation. When a project starts up, they are allocated a certain budget (which makes sense) but they can't chose the salary to pay internal candidates, so you can't pay a premium to try to attract specialists.

The only way to reward hard work is by promoting employees to the next level, but the number of promotions available is a fixed percentage of the team size rather than being dependent on the quality of the team. This can cause employees to not get promotions they deserve. Then, having not been promoted, they aren't at a high enough "level" to apply for jobs for which they are now qualified.

This problem is worst in teams that require the highest quality engineers. Since these teams end up with so many great people, some inevitably get screwed out of promotions. These intelligent people then figure out that to game the promotions system they need to work on teams full of idiots so they stand out and can get lots of promotions quickly. But they tire of working with idiots (especially since idiots are usually hired on to less challenging projects). And eventually they quit, and the strongest teams are forced to reduce their quality in order to give qualified promotions.

If Microsoft opened up their compensation system to be as fluid as their labour system, they would likely find that the hardest projects would attract the best engineers for a premium. And if they worked harder to reduce the "headcount" and perma-team effects most groups have they might find that the make-up of teams becomes more suited to the projects.


Heck, I might even go back...