3 ms·

In addition to your points, with which I agree, it also depends a lot on team culture. If you do your best to hire responsible adults and then treat your employ

In addition to your points, with which I agree, it also depends a lot on team culture. If you do your best to hire responsible adults and then treat your employees like adults most of them act like adults. When there is a healthy team culture of shared responsibility people who aren't pulling their weight tend to stick out. The best way to avoid people gaming the system is to hire honest, hard working people who don't want to game the system. Then get out of the way and let them work.

solatic 9y ago
You're right, of course, but hiring for culture fit is easier when you're a small company and you only have to hire for a few distinct roles. When you're a large company and you have a hiring quota of hundreds of engineers a year to deal with expected development requirements, well, that's where you start to need to "corporatize" and come up with good metrics.
- jdbernard 9y ago
  I've never run a large company, or been high enough in management to try this, but I still think there is a better way: In code we work in layers of abstraction. Large projects can be healthy when every layer is small enough to fit in your head. In the same way, I think we could build a large company in layers of teams. Each layer should be manageable in the way discussed above. Good modularity in code allows us to keep the whole problem in our head. Good team structure (requires good management) allows us to keep the management decisions at the tribe/human level that we are good at and not need the kind of mass, impersonal systems that lead to burdensome bureaucracy. Of course, this kind of leadership and culture has to come from the top. It also requires that leadership explicitly avoid micromanagement, breaking the team boundaries. And requires continued commitment to treating your employees at every level like adults. Of course, people are not code, but I think this organisational system of managing complexity can be applied to both. It would be interesting to do some case studies, but I believe there are several large companies that have done this successfully, until top leadership changes (founder dies, etc.) and the new leader doesn't have the same trust of and commitment to employee/team autonomy. The dynamic changes, people notice and either leave or start gaming the system, etc.

solatic 9y ago

You're right, of course, but hiring for culture fit is easier when you're a small company and you only have to hire for a few distinct roles. When you're a large company and you have a hiring quota of hundreds of engineers a year to deal with expected development requirements, well, that's where you start to need to "corporatize" and come up with good metrics.

jdbernard 9y ago
I've never run a large company, or been high enough in management to try this, but I still think there is a better way: In code we work in layers of abstraction. Large projects can be healthy when every layer is small enough to fit in your head. In the same way, I think we could build a large company in layers of teams. Each layer should be manageable in the way discussed above. Good modularity in code allows us to keep the whole problem in our head. Good team structure (requires good management) allows us to keep the management decisions at the tribe/human level that we are good at and not need the kind of mass, impersonal systems that lead to burdensome bureaucracy. Of course, this kind of leadership and culture has to come from the top. It also requires that leadership explicitly avoid micromanagement, breaking the team boundaries. And requires continued commitment to treating your employees at every level like adults. Of course, people are not code, but I think this organisational system of managing complexity can be applied to both. It would be interesting to do some case studies, but I believe there are several large companies that have done this successfully, until top leadership changes (founder dies, etc.) and the new leader doesn't have the same trust of and commitment to employee/team autonomy. The dynamic changes, people notice and either leave or start gaming the system, etc.