QUOTE(Find The Way @ Jan 12 2021, 06:52 PM)
Haha... I removed details as the question is already pretty long, can be sleepy to read
Complexity wise, the product team consists of multiple project teams, reporting to multiple managers. Project team size was usually 4-5 engineers, for duration 3-6 months. Larger projects were less common, can go up to a year. Most of our team's components are web services and event subscriber/processor. Within the company, there were other products that depending on ours, and we too depended on some other product teams' works.
Context of problem can be lengthy... I'll try to shorten it by commonly observed pattern. It usually went like... project team implementing design halfway, discovered certain things do not work per expected. Investigation often ended up that part of design was based on assumptions, which turned out to be invalid. Assumptions fall under three areas:
1. Ambiguous area in requirements ==> this was solved after the team adopted diff strategy. After received design, engineers will redo requirement analysis to identify potential gaps between understandings of product manager and architect.
2. How chosen library/tool/framework works ==> we didn't change this kind of dependency after the first three years, once stabilised this pain was gone
3. How upstream/downstream product dependency work (technical aspect) ==> this was usually discovered during integration test
4. Current state of system (gap between ideal design vs workaround designs that were actually implemented in the past)
After the first three years, we were left mainly #3 and #4. #4 was probably whole product team's issue rather than architect alone's, no one (including me) had motivation to keep track on those gaps.
@bumpo
For uncontrollable factors such as underfunded projects, they occurred to us occasionally, not on regular basis. Normally project team will be told upfront about it, they are understandable, never heard any of my teammates making noise about it (sigh doesn't count as noise ). In my opinion, if uncontrollable factors happen regularly and causing engineers to be burn from time to time, I reckon it is more of "environment" issue - product specific, org specific or industry specific. So the only two options are accept and find mitigative workaround, or move on to different environment. It has nothing much to do with competency of architect or manager. Just my two cents
Earlier when you mentioned promoted to manager, are you talking about product manager? or manager for the dev teams?Complexity wise, the product team consists of multiple project teams, reporting to multiple managers. Project team size was usually 4-5 engineers, for duration 3-6 months. Larger projects were less common, can go up to a year. Most of our team's components are web services and event subscriber/processor. Within the company, there were other products that depending on ours, and we too depended on some other product teams' works.
Context of problem can be lengthy... I'll try to shorten it by commonly observed pattern. It usually went like... project team implementing design halfway, discovered certain things do not work per expected. Investigation often ended up that part of design was based on assumptions, which turned out to be invalid. Assumptions fall under three areas:
1. Ambiguous area in requirements ==> this was solved after the team adopted diff strategy. After received design, engineers will redo requirement analysis to identify potential gaps between understandings of product manager and architect.
2. How chosen library/tool/framework works ==> we didn't change this kind of dependency after the first three years, once stabilised this pain was gone
3. How upstream/downstream product dependency work (technical aspect) ==> this was usually discovered during integration test
4. Current state of system (gap between ideal design vs workaround designs that were actually implemented in the past)
After the first three years, we were left mainly #3 and #4. #4 was probably whole product team's issue rather than architect alone's, no one (including me) had motivation to keep track on those gaps.
@bumpo
For uncontrollable factors such as underfunded projects, they occurred to us occasionally, not on regular basis. Normally project team will be told upfront about it, they are understandable, never heard any of my teammates making noise about it (sigh doesn't count as noise ). In my opinion, if uncontrollable factors happen regularly and causing engineers to be burn from time to time, I reckon it is more of "environment" issue - product specific, org specific or industry specific. So the only two options are accept and find mitigative workaround, or move on to different environment. It has nothing much to do with competency of architect or manager. Just my two cents
For now I'll just assume you're meaning product manager, so correct me if I'm wrong with my assumption.
Moving from a dev to roles like product manager or solution architect is not a binary thing. These roles may overlap depending on the environment, and I personally will encourage ppl to explore outside of their dedicated job area despite them not wanting to move to those role types.
Like for example, devs can get actively involved in architecture discussions, or can also get involved in business analysis work too. This greatly helps with breaking down of the walls between the roles, and very much avoids the 'not my responsibility' issue. And it also helps to better identify who are the candidates that can be moved to other role types, as well as allow these ppl a better idea if they'll even like these other role types or not.
Looking at the role of the architect, my take on it is that the role is more focused on managing the architecture rather than coming out with the architecture. by that what I mean is, he can come up with an initial draft, but finalizing is done together with the relevant dev team members. his role after that will be to check in with the devs if the adopted architecture is giving any issues along the way, and try to anticipate any future issues based on reports from the devs too. the key important thing is collaboration rather than total segregation of responsibilities. Tracking the issues you mentioned in 4) should be the entire team helping to do it, but the architect needs to be the one to drive it (assuming he's also playing the role of the team lead)
For 3) the way we address this is to automate integration tests as early as possible. Then do nightly runs so there can be early alerts should there be any changes to upstream/downstream that's not announced. but this does require collaboration with the different teams as well.