For transparency, this is the first titled architect position I have held, and it is a relatively small organization. My career path has led in this direction. (I've been responsible for all aspects of most products I've worked on. But it has taken some time to learn and recognize the best choices for various scenarios.)
There are two small teams and I am on both of them, and everybody is all in the same room together. In addition to working out the plumbing code, I implement normal features on both teams -- especially first-of-its-kind features that might need infrastructure support. We have ~5 different service/product software offerings, and nearly double that many individual applications. I imagine if we were larger, I would be on a separate team for providing infrastructure services to the other teams. And the teams individually would have tech leads or senior devs who trail-blaze unfamiliar techs.
I spend a bit of time doing whiteboarding sessions and code review. This is on request, not a required process. I find that most of the time the value I bring to these discussions is focusing in on the business factors and less on the technical details. Although sometimes tactics are needed for the details as well. Another major thing I advise on is UX (user experience), which has been a problem in our products.
I don't dictate implementations. When asked I explain, share experiences, suggest, etc. My advice is frequently taken. But ultimately the person working on the feature has the best information, so it is their choice. I like to use tools (like Functional Programming) that make change easier. So there's no need for me to micro manage every implementation. It's far more important to give the teams an accurate understanding of the business concepts.
The teams trusts me to pick tools (languages, IDEs) and infrastructure designs that will help them and not get in the way. I try to analyze infrastructure from many angles, but especially: dev surface area, ops complexity, and cost. Since we are small, solutions with high ops requirements (e.g. 5 different kinds of databases, micro-services, etc) are less desirable. Of course we have legacy systems too, where yesterday's choices have bitten us. So I'm also responsible for devising ways (and doing some of the core work) to push our legacy systems in the right direction.
I guess you could say I am the maintainer of the technical vision of our products. I talk with the customers, our internal staff (who are customers for some products), and anyone else I need to in order to understand the value proposition of backlog items. Then I help teams work out what that could look like in the software. I prioritize the backlog for one of the teams.
This all sounds like too much (and sometimes it feels that way), but I don't do all of these things every day. I'm basically an "old" dev who gets asked to help with various things at any given time. We are all just trying to do our best for the customer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For transparency, this is the first titled architect position I have held, and it is a relatively small organization. My career path has led in this direction. (I've been responsible for all aspects of most products I've worked on. But it has taken some time to learn and recognize the best choices for various scenarios.)
There are two small teams and I am on both of them, and everybody is all in the same room together. In addition to working out the plumbing code, I implement normal features on both teams -- especially first-of-its-kind features that might need infrastructure support. We have ~5 different service/product software offerings, and nearly double that many individual applications. I imagine if we were larger, I would be on a separate team for providing infrastructure services to the other teams. And the teams individually would have tech leads or senior devs who trail-blaze unfamiliar techs.
I spend a bit of time doing whiteboarding sessions and code review. This is on request, not a required process. I find that most of the time the value I bring to these discussions is focusing in on the business factors and less on the technical details. Although sometimes tactics are needed for the details as well. Another major thing I advise on is UX (user experience), which has been a problem in our products.
I don't dictate implementations. When asked I explain, share experiences, suggest, etc. My advice is frequently taken. But ultimately the person working on the feature has the best information, so it is their choice. I like to use tools (like Functional Programming) that make change easier. So there's no need for me to micro manage every implementation. It's far more important to give the teams an accurate understanding of the business concepts.
The teams trusts me to pick tools (languages, IDEs) and infrastructure designs that will help them and not get in the way. I try to analyze infrastructure from many angles, but especially: dev surface area, ops complexity, and cost. Since we are small, solutions with high ops requirements (e.g. 5 different kinds of databases, micro-services, etc) are less desirable. Of course we have legacy systems too, where yesterday's choices have bitten us. So I'm also responsible for devising ways (and doing some of the core work) to push our legacy systems in the right direction.
I guess you could say I am the maintainer of the technical vision of our products. I talk with the customers, our internal staff (who are customers for some products), and anyone else I need to in order to understand the value proposition of backlog items. Then I help teams work out what that could look like in the software. I prioritize the backlog for one of the teams.
This all sounds like too much (and sometimes it feels that way), but I don't do all of these things every day. I'm basically an "old" dev who gets asked to help with various things at any given time. We are all just trying to do our best for the customer.