Ugh.<p>I just finished reading "Staff Engineer" book [1] and it listed "Architect" as one of four archetypes. The architect there is very different from the one in this article, and I'll support the book than this article.<p>Simply put, the architect in this article is probably too micro-managing and tyrannic. Although that isn't stated explicitly, the lack of arrows across devs is symbolic, as well as the "surgeon" metaphor.<p>The team I'd like to be in is more loosely coupled and less hierarchical, and I'd love an architect to be more ambient than opinionated.<p>Many architects would disagree and that's fine. I just want to drop my 2c here.<p>[1] <a href="https://staffeng.com/book" rel="nofollow">https://staffeng.com/book</a>
This kind of content is good food for thought, but it always makes me think back to an article that I read 15 years ago (and cannot find again), that said in short, "Tech teams are full of smart people that will self-organize. They will ignore your org charts and team visions, and fall in line into the best working team they can, based on their own evaluations of each others skills and knowledge.... so long as you just leave them alone to do it."<p>And my best teams have been the ones where the leadership let us do exactly that. They might talk to us about their ideas of how we should do things and how we should organize ourselves, but ultimately they did what most good leaders do, which is to hire smart people, task them with what needs done, and then leave them alone.
Surgical teams work under very specific constraints such as a tight time limit, mostly repetitive/practiced tasks, limited concurrent work (only so many hands can fit inside a patient), team size limited by physical constraints of operating room, etc. Trying to apply this approach to other domains with different constraints, even if only philosophically, seems inherently an ill fitting idea.
Office suites and email clients don't handle correspondence or finish documents. Stack Overflow and Google only propose changes when people know what to ask. Static analyzers don't replace knowing the language and libraries in depth. Good requirements need tight cooperation.
We have a friend who is an actual architect. Her children sleep on the second floor of a house she designed herself and built (with her husband). I wonder how many self-described software architects would have the confidence in their skills and the quality of their work product to put their money where their mouth is in the same way?<p>Team concepts which put one person in the center as the single source of all knowledge have a lot of advantages if that person is really good, but carry a lot of risk if they are not. There's a reason you train to an extremely high level before you become the chief surgeon in an actual surgical team.
I disagree in the sense the architect should be hands off and a source of good practice, recommendations, and an all round enabler. But the dev at the coalface? They own the solution.
I don’t think the updated concept in this article is an improvement. It seems to be a regression to the hog butchering style but with a chief butcher who draws a few lines on the pig and then tells his team to go at it while he makes a few of the more delicate cuts.
<p><pre><code> I stand on the position that hierarchy is innate to human beings.
</code></pre>
im not sure, but isnt he conflating "division of labor is necessary for well-functioning projects/teams" and "human nature" ??<p>maybe im missing something...
The article states that hierarchy is innate to human beings and links to Jordan Peterson as a reference?! This is a core belief of conservative thinking and is a political posture, not a scientific truth.<p>Hierarchies are a characteristic of agricultural societies and almost completely absent in hunter gatherer societies that precede it. Hunter gatherer societies are typically egalitarian.