10 ms·

I think the more accepted title these days instead of architect is "staff engineer". If you read older architecture books like "the software architect elevator"

by larve 4y ago

I think the more accepted title these days instead of architect is "staff engineer". If you read older architecture books like "the software architect elevator" or "12 essential skills for software architects", most of the book is about technical leadership, driving change, personal skills, delegation. Building some theoretical construct and having other people build it is by itself bad architecture, resulting in bad team culture and bad systems.

blub 4y ago
If the architect from your second paragraph works closely with the dev team for prototyping and iterates on their feedback I don’t see anything wrong with that approach.
- larve 4y ago
  yes exactly. I was referring to what I think the OP was rejecting, a rigid top down approach to software engineering, with the architect and their UML at the top, and the grunts and their editor at the bottom.
- oaiey 4y ago
  I agree. The architecture profession is radically different today than 20 years ago. However, there is a scale where that does not work anymore. Once you plan at the scale of 20 or more teams, "working closely" is very relative.
angarg12 4y ago
I agree that Staff engineer is in practice the closest thing to the old Architect title. I still think this approach is better. If nothing else it's a shift in the responsibly of architecture. In the most rancid organizations there are silos where devs only code and architects only design. The joke of the Ivory Tower Architect is real. On the other hand as a dev II (between junior and senior) I was asked to design and implement a large scale green field distributed system that interacts with other teams. Our ladder and job titles not only allow this, but it's encouraged and sometimes expected.
random3 4y ago
+1 staff/principal etc. is the same thing. Agreed on fractal model with healthy room for mistakes that should be carved in for everyone - it's the only model that can enable healthy growth. Non-practicing architects are 0, and non-architectign engineerign is 0 too. This said, as much as I hated the architect idea earlier in my career (because I was architecting regardless of my title) - the concern and ability to architect things is a very real one. It can only be learned by taking responsibility and having room for mistsakes.
majormajor 4y ago
In my previous roles in larger orgs, the architect vs principal eng distinction was a breadth-vs-depth thing. Are you planning or aligning broadly across 10 teams, or are you helping both roadmap and do longterm planning but also diving deep into the hardest technical problems for just 1 or 2 teams, say.

by larve 4y ago

blub 4y ago

If the architect from your second paragraph works closely with the dev team for prototyping and iterates on their feedback I don’t see anything wrong with that approach.

larve 4y ago
yes exactly. I was referring to what I think the OP was rejecting, a rigid top down approach to software engineering, with the architect and their UML at the top, and the grunts and their editor at the bottom.
oaiey 4y ago
I agree. The architecture profession is radically different today than 20 years ago. However, there is a scale where that does not work anymore. Once you plan at the scale of 20 or more teams, "working closely" is very relative.

angarg12 4y ago

I agree that Staff engineer is in practice the closest thing to the old Architect title. I still think this approach is better. If nothing else it's a shift in the responsibly of architecture. In the most rancid organizations there are silos where devs only code and architects only design. The joke of the Ivory Tower Architect is real. On the other hand as a dev II (between junior and senior) I was asked to design and implement a large scale green field distributed system that interacts with other teams. Our ladder and job titles not only allow this, but it's encouraged and sometimes expected.

random3 4y ago

+1 staff/principal etc. is the same thing. Agreed on fractal model with healthy room for mistakes that should be carved in for everyone - it's the only model that can enable healthy growth. Non-practicing architects are 0, and non-architectign engineerign is 0 too. This said, as much as I hated the architect idea earlier in my career (because I was architecting regardless of my title) - the concern and ability to architect things is a very real one. It can only be learned by taking responsibility and having room for mistsakes.

majormajor 4y ago

In my previous roles in larger orgs, the architect vs principal eng distinction was a breadth-vs-depth thing. Are you planning or aligning broadly across 10 teams, or are you helping both roadmap and do longterm planning but also diving deep into the hardest technical problems for just 1 or 2 teams, say.