4 ms·

I did not read the article that way. But then I've been a manager for a while now. Implicitly, there is a discussion about phases of team/product. My experienc

by cdavid 4y ago

I did not read the article that way. But then I've been a manager for a while now. Implicitly, there is a discussion about phases of team/product. My experience is that the way to build great software is by small teams, with skilled programmers. Aka your artisan model. Unfortunately, at least in my experience again, that does not scale as a company grows and the demands grow. You need more features, more people get involved, you can't just build/maintain the product within a single team. And you really want to avoid relying on specific individuals because it is too risky. So that tension between craftmanship and commoditization of skill is definitely there. I wish there were a way to see a workable scalable model that does not involve commoditization in one way or another. I have not had the chance to see one yet.

sanderjd 4y ago
I have. Or at least closer to it than you seem to have seen. The way it works is to do the talented artisan / engineer thing within small teams, and the managerial / communication focused thing across those teams. The really hard part is drawing and maintaining the right lines between teams, within which each team can work independently.
dasil003 4y ago
The way you scale is not to disregard artisanship, it is to design the right interfaces and abstractions, and allow for ownership at the lowest possible level with a hierarchy of “artisan leadership” that has equal power to managers and other paper pushers. Easier said than done, but it is the only way. The commodification approach is the blind leading the blind, where the gears get more and more gummed up until someone realizes they need to call in expert help. And when they do, it will inevitably be—surprise!—a small team.
- cdavid 4y ago
  Getting the right interfaces/abstractions between teams is kind of what's hinted in the article, no ? It is needed both at the code/architecture level and at the team/org level In my mind, commodification does not imply getting people who don't know what they are doing. But you need to move away from individual ownership as the main model, which at least in my mind is implied by artisanship. You need to be able to replace almost anyone by somebody else as you grow.

by cdavid 4y ago

sanderjd 4y ago

I have. Or at least closer to it than you seem to have seen. The way it works is to do the talented artisan / engineer thing within small teams, and the managerial / communication focused thing across those teams. The really hard part is drawing and maintaining the right lines between teams, within which each team can work independently.

dasil003 4y ago

The way you scale is not to disregard artisanship, it is to design the right interfaces and abstractions, and allow for ownership at the lowest possible level with a hierarchy of “artisan leadership” that has equal power to managers and other paper pushers. Easier said than done, but it is the only way. The commodification approach is the blind leading the blind, where the gears get more and more gummed up until someone realizes they need to call in expert help. And when they do, it will inevitably be—surprise!—a small team.

cdavid 4y ago
Getting the right interfaces/abstractions between teams is kind of what's hinted in the article, no ? It is needed both at the code/architecture level and at the team/org level In my mind, commodification does not imply getting people who don't know what they are doing. But you need to move away from individual ownership as the main model, which at least in my mind is implied by artisanship. You need to be able to replace almost anyone by somebody else as you grow.