Wednesday, June 08, 2005
The ideal team
In my last post, I talked about an employee having an Army of One mentality. Imagine an entire company: hundreds--even thousands--of people strong, every single one of which is working in their own area as an Army of One--building, perfecting, honing, even expanding their area.
"I'm imagining that," you say, "and all I see is chaos."
Ah. But you need to see it with the team structure superimposed on it. But that sounds pretty traditional, doesn't it? Not much innovation here at Bruce's Company, after all, eh?
Well, yeah, I'm not really looking for innovation here; I'm looking for what works. And I'm not here to say toss away all structure or management hierarchy. To be sure, things should be relatively flat and flexible, but somebody's got to be the boss (more on that in another post).
The main trick is to keep the Army of One mentality in each employee of the company while keeping everyone moving in the same direction. So let's talk about the next unit up the structure hierarchy: the team.
The ideal team should be small. 3-5 people, I think, is about right. (The founder of my first full-time company, TenFold, Jeff Walker, said that a 2-man team wasn't really a team; they were just "buddies.") This is the first and most critical aspect of a team. It must be small enough that everyone feels themself a critical part and cannot get lost in the shuffle. If a team is much larger than 3-5 people, then it simply needs to be broken up into smaller teams, where each team has a defined role. Obviously, multiple teams can then be combined into a larger unit, with its own manager over the multiple teams, if necessary, but the sovereignty of the individual teams must be respected.
If a team is small enough, and its sovereignty is respected, then it effectively becomes an Army of Five, or whatever the number is. That is, it collectively has the same mentality that each individual person has as an Army of One. The manager divvies up the overall responsibility of the team among the different members of the team--according to area, remember, not task lists. Each member of the team views himself as master of his domain, with the view toward presenting the best possible performance to the manager. The manager makes sure that all of these efforts mesh together to form the best possible product to be presented to the rest of the company, or to his manager, or whatever.
It is essential that the team members be answerable to primarily their own manager, and not anyone else. If other managers at the team level have a problem with our team, or even a specific member of our team, they complain to the manager of the team. If the manager's manager is not pleased with the performance of the team, he talks to the manager to find out what the problem is. He does not pick out individual members of the team and complain that they're not doing a job.
Here we see why it is so important that the team be small. Beyond 3-5 members, a manager can't possibly truly evaluate how well an individual employee is doing. Having a team of 8-10 members is dangerous, because a manager probably thinks that he can do effective individual evaluation, but he can't. He can't, because at that level, he has to resort to analyzing numbers, and numbers typically are meaningless, especially if not backed by an intimate familiarity with the process that produced them.
In the software development business, effective employee evaluation means that the manager needs to be able to look at the code that each programmer produces. It is not enough to just look at short-term results, because the results may just be a facade concealing fundamental problems that may not pop up for a very long time. The company that is intent on long-term success will care deeply about the condition of the underlying code, and the only way to ensure that is to have team managers that reward good code done "the right way."
This, of course, implies that the manager must be technically proficient. And this is the Second Great Commandment of the ideal team: the manager must be technical. Ideally, he should be familiar with all the code in the team's product. On my first team at TenFold, the manager was one of two people who wrote the original product, and you couldn't get away with putting any bad code in that product, period.
Admittedly it is not always possible to have a manager who is so well-versed in the product. Sometimes you just have to bring in somebody from the outside. But the new guy should still be someone who has previously done the job that his underlyings are doing, and, in software development, he should still try and familiarize himself with the code and review new code as much as possible. The manager must get his hands dirty!
Now, I am sympathetic to the protest that actually, the short-term results could very well be more important than the computer scientist's aesthetic view of the beauty of the underlying code. I've known many programmers who over-engineer their code and allow their obsession with doing things "the right way" to slow their real productivity down to a crawl. Believe it or not, I would even allow that this could very well be just as big a problem as shoddy code that comes back to bite a company in the long term. Ultimately, it's the manager's job to decide and direct the level of abstraction that should be assumed in writing code and how important the long-term view is for a given project. This is, in fact, possibly his most difficult job, and yet another reason why the manager must be technical.
Now let's go back and talk about the sovereignty of the team some more. When I was at Digital Harbor, there were basically two teams working on the PiiE product (yeah, great name, I know), which we'll call the client team and the server team. I was on the server team. We shipped a new version of the product about every six months or so, and every single time, without fail, when we got down to the last couple of weeks before shipping and we were just trying to clean up the last several bugs, it was the client team that was swamped with bugs while the server team had nothing to do.
(There was no shortage of excuses for this state of affairs, of course: the client team had a harder job, the nature of the client's product was more prone to bugs, etc. Nobody ever suggested that, regardless of what the excuses were, the client team really ought to start adjusting their project estimates from the beginning.)
So, faced with one team working and the other team largely done, what did the managers' manager who was over the two teams do? Well, he did what any manager would do: he grabbed people from the server team and assigned client bugs to them.
Now, this sounds perfectly reasonable. And it is possible that it is justified, given the circumstances. But let me point out the harm that this does, and then you decide if it's really reasonable.
First of all, I cannot overemphasize how painful it is in software development for a programmer to be asked to fix a bug in someone else's code, that he has never seen before, and that he will likely (hopefully) never see again after fixing the bug. Particularly if the guy who wrote the code is sitting right over there--he's just busy with yet another bug. It's not so much that the programmer is doing somebody else's job--onerous as that is. The truly exasperating thing is that it will take that programmer at least ten times longer to fix that bug, because he's not familiar with the code. Maybe a hundred times longer! He could very easily spend all day, or even days, trying to fix this bug that the original programmer could find in ten minutes. I am not exaggerating. Any software developer will say the same.
Second of all, grabbing someone from one team to work on another team's bugs violates the sovereignty of the first team. It disincents the first team from completing their product on time. If you have a choice between (A) working hard to finish your product on time, or early, and thereby earning the reward of fixing somebody else's code for the next few weeks, which as I mentioned above is about as pleasant as passing a gallstone; or (B) taking it easy and making sure that your code is done with all bugs fixed at exactly the same time as everyone else's; which choice would you take?
On top of all this was Digital Harbor management's slavish devotion to these ridiculous bug numbers that the process produced. In brief: the more bugs you fixed, the more you were rewarded as a programmer. If you checked in code that was relatively bug-free nobody cared--there weren't any numbers that tracked that. On the contrary, you were now at a disadvantage because you weren't going to be able to fix very many easy bugs in your own code. In order to build up your bug-fixing numbers, you were going to have to go fix them in someone else's code. If you complained about having to do so, of course, you were not a "team player."
Hence, for release after release after release, despite the fact that the client team always ended up with more bugs toward the end of the process, it was that same client team that ended up coming out of the process smelling like a rose because it had these fantastic bugs-fixed numbers, while the server team looked like they weren't "team players" because they complained about having to fix someone else's bugs--and oh by the way, they didn't even end up fixing that many bugs either.
So we see that while reallocating resources to fix a temporary problem may seem like a sensible thing to do, there are all kinds of long-term disadvantages to such an approach. The sovereignty of the team must be held sacred, because each time it is violated, it damages the whole Army of One mentality that is essential to overall company productivity. And the team should be judged by the quality of their own product, period. Over time, a successful team will develop their own personality, a reputation for quality, and increasing pride in what they produce. The "team" mentality follows individual achievement, not the other way around.
I can hear the bureaucrats saying already: "The employee should be willing to do whatever it takes to make the company succeed! We're all in this together!" First of all, we're not all in this together. That's your point of view. This is the classic mistake that companies make when they fail to look at things from the employee's point of view. The employee is not "in this together" with his boss. He's "in this" for his family, period. Or, if he's single, for himself--and there's nothing wrong with that. If you want to run a company where you demand every employee's complete and utter devotion as the #1 priority in their life, then be my guest. But that's not Bruce's Company.
If you're not convinced, then look at Digital Harbor. They thought they could straddle the line and say that "we're all in this together" while simultaneously denying that the company demanded that they be the employees' #1 life priority, and the morale there was the worst of any company I've ever worked at.
Respect your teams' sovereignty. If they do a good job, pat them on the back and tell them to go home. If they don't deliver, make them deal with the consequences themselves.
"I'm imagining that," you say, "and all I see is chaos."
Ah. But you need to see it with the team structure superimposed on it. But that sounds pretty traditional, doesn't it? Not much innovation here at Bruce's Company, after all, eh?
Well, yeah, I'm not really looking for innovation here; I'm looking for what works. And I'm not here to say toss away all structure or management hierarchy. To be sure, things should be relatively flat and flexible, but somebody's got to be the boss (more on that in another post).
The main trick is to keep the Army of One mentality in each employee of the company while keeping everyone moving in the same direction. So let's talk about the next unit up the structure hierarchy: the team.
The ideal team should be small. 3-5 people, I think, is about right. (The founder of my first full-time company, TenFold, Jeff Walker, said that a 2-man team wasn't really a team; they were just "buddies.") This is the first and most critical aspect of a team. It must be small enough that everyone feels themself a critical part and cannot get lost in the shuffle. If a team is much larger than 3-5 people, then it simply needs to be broken up into smaller teams, where each team has a defined role. Obviously, multiple teams can then be combined into a larger unit, with its own manager over the multiple teams, if necessary, but the sovereignty of the individual teams must be respected.
If a team is small enough, and its sovereignty is respected, then it effectively becomes an Army of Five, or whatever the number is. That is, it collectively has the same mentality that each individual person has as an Army of One. The manager divvies up the overall responsibility of the team among the different members of the team--according to area, remember, not task lists. Each member of the team views himself as master of his domain, with the view toward presenting the best possible performance to the manager. The manager makes sure that all of these efforts mesh together to form the best possible product to be presented to the rest of the company, or to his manager, or whatever.
It is essential that the team members be answerable to primarily their own manager, and not anyone else. If other managers at the team level have a problem with our team, or even a specific member of our team, they complain to the manager of the team. If the manager's manager is not pleased with the performance of the team, he talks to the manager to find out what the problem is. He does not pick out individual members of the team and complain that they're not doing a job.
Here we see why it is so important that the team be small. Beyond 3-5 members, a manager can't possibly truly evaluate how well an individual employee is doing. Having a team of 8-10 members is dangerous, because a manager probably thinks that he can do effective individual evaluation, but he can't. He can't, because at that level, he has to resort to analyzing numbers, and numbers typically are meaningless, especially if not backed by an intimate familiarity with the process that produced them.
In the software development business, effective employee evaluation means that the manager needs to be able to look at the code that each programmer produces. It is not enough to just look at short-term results, because the results may just be a facade concealing fundamental problems that may not pop up for a very long time. The company that is intent on long-term success will care deeply about the condition of the underlying code, and the only way to ensure that is to have team managers that reward good code done "the right way."
This, of course, implies that the manager must be technically proficient. And this is the Second Great Commandment of the ideal team: the manager must be technical. Ideally, he should be familiar with all the code in the team's product. On my first team at TenFold, the manager was one of two people who wrote the original product, and you couldn't get away with putting any bad code in that product, period.
Admittedly it is not always possible to have a manager who is so well-versed in the product. Sometimes you just have to bring in somebody from the outside. But the new guy should still be someone who has previously done the job that his underlyings are doing, and, in software development, he should still try and familiarize himself with the code and review new code as much as possible. The manager must get his hands dirty!
Now, I am sympathetic to the protest that actually, the short-term results could very well be more important than the computer scientist's aesthetic view of the beauty of the underlying code. I've known many programmers who over-engineer their code and allow their obsession with doing things "the right way" to slow their real productivity down to a crawl. Believe it or not, I would even allow that this could very well be just as big a problem as shoddy code that comes back to bite a company in the long term. Ultimately, it's the manager's job to decide and direct the level of abstraction that should be assumed in writing code and how important the long-term view is for a given project. This is, in fact, possibly his most difficult job, and yet another reason why the manager must be technical.
Now let's go back and talk about the sovereignty of the team some more. When I was at Digital Harbor, there were basically two teams working on the PiiE product (yeah, great name, I know), which we'll call the client team and the server team. I was on the server team. We shipped a new version of the product about every six months or so, and every single time, without fail, when we got down to the last couple of weeks before shipping and we were just trying to clean up the last several bugs, it was the client team that was swamped with bugs while the server team had nothing to do.
(There was no shortage of excuses for this state of affairs, of course: the client team had a harder job, the nature of the client's product was more prone to bugs, etc. Nobody ever suggested that, regardless of what the excuses were, the client team really ought to start adjusting their project estimates from the beginning.)
So, faced with one team working and the other team largely done, what did the managers' manager who was over the two teams do? Well, he did what any manager would do: he grabbed people from the server team and assigned client bugs to them.
Now, this sounds perfectly reasonable. And it is possible that it is justified, given the circumstances. But let me point out the harm that this does, and then you decide if it's really reasonable.
First of all, I cannot overemphasize how painful it is in software development for a programmer to be asked to fix a bug in someone else's code, that he has never seen before, and that he will likely (hopefully) never see again after fixing the bug. Particularly if the guy who wrote the code is sitting right over there--he's just busy with yet another bug. It's not so much that the programmer is doing somebody else's job--onerous as that is. The truly exasperating thing is that it will take that programmer at least ten times longer to fix that bug, because he's not familiar with the code. Maybe a hundred times longer! He could very easily spend all day, or even days, trying to fix this bug that the original programmer could find in ten minutes. I am not exaggerating. Any software developer will say the same.
Second of all, grabbing someone from one team to work on another team's bugs violates the sovereignty of the first team. It disincents the first team from completing their product on time. If you have a choice between (A) working hard to finish your product on time, or early, and thereby earning the reward of fixing somebody else's code for the next few weeks, which as I mentioned above is about as pleasant as passing a gallstone; or (B) taking it easy and making sure that your code is done with all bugs fixed at exactly the same time as everyone else's; which choice would you take?
On top of all this was Digital Harbor management's slavish devotion to these ridiculous bug numbers that the process produced. In brief: the more bugs you fixed, the more you were rewarded as a programmer. If you checked in code that was relatively bug-free nobody cared--there weren't any numbers that tracked that. On the contrary, you were now at a disadvantage because you weren't going to be able to fix very many easy bugs in your own code. In order to build up your bug-fixing numbers, you were going to have to go fix them in someone else's code. If you complained about having to do so, of course, you were not a "team player."
Hence, for release after release after release, despite the fact that the client team always ended up with more bugs toward the end of the process, it was that same client team that ended up coming out of the process smelling like a rose because it had these fantastic bugs-fixed numbers, while the server team looked like they weren't "team players" because they complained about having to fix someone else's bugs--and oh by the way, they didn't even end up fixing that many bugs either.
So we see that while reallocating resources to fix a temporary problem may seem like a sensible thing to do, there are all kinds of long-term disadvantages to such an approach. The sovereignty of the team must be held sacred, because each time it is violated, it damages the whole Army of One mentality that is essential to overall company productivity. And the team should be judged by the quality of their own product, period. Over time, a successful team will develop their own personality, a reputation for quality, and increasing pride in what they produce. The "team" mentality follows individual achievement, not the other way around.
I can hear the bureaucrats saying already: "The employee should be willing to do whatever it takes to make the company succeed! We're all in this together!" First of all, we're not all in this together. That's your point of view. This is the classic mistake that companies make when they fail to look at things from the employee's point of view. The employee is not "in this together" with his boss. He's "in this" for his family, period. Or, if he's single, for himself--and there's nothing wrong with that. If you want to run a company where you demand every employee's complete and utter devotion as the #1 priority in their life, then be my guest. But that's not Bruce's Company.
If you're not convinced, then look at Digital Harbor. They thought they could straddle the line and say that "we're all in this together" while simultaneously denying that the company demanded that they be the employees' #1 life priority, and the morale there was the worst of any company I've ever worked at.
Respect your teams' sovereignty. If they do a good job, pat them on the back and tell them to go home. If they don't deliver, make them deal with the consequences themselves.
# posted by Bruce Hansen @ 2:41 PM 
