I work for a company with roughly 20 developers, maintaining collateral management systems written in .NET. Historically this company has always separated their development team in two groups - architecture/long-term projects vs patching/bug fixing developers.
I'm on the architecture team. Some members in architecture have been with the company for some time and are not held to the same deadlines/expectations as newer members like myself. Generally people in architecture have it better, and personally I'm very grateful not to be working in the "ticket machine." This creates dissatisfaction on the production team, who see us as not pulling our weight. The split is intended to make it easier to introduce new technologies while not delaying time sensitive projects in production.
The production team is servicing our clients directly with fixes and short-term projects. Their efforts and purpose are more transparent to the management staff, and are generally favored.
Some have argued this structure breeds isolation and lack of communication. Personally I know that my team needs more accountability for everyone who commits code into our repository, regardless of seniority.
I'm wondering if anyone has worked in a similar structure and if they have any advice for evolving this.