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.

  • 1
    who is doing the complaining? – user1666620 Jan 17 '19 at 19:37
  • The production team is doing the complaining. Management is listening and reporting that back to us. – ShameWare Jan 17 '19 at 22:05
  • What quality controls are on your work? What readability and code quality standards? When I've been on the development (as opposed to strategic development or architecture) team, it seemed to me that the other team had very low standards for what we were supposed to put a final polish on and get into production. – David Thornley Jan 18 '19 at 18:54

I'm wondering if anyone has worked in a similar structure...

Yes, I have seen something similar. I endured it for several years, but it was (and sounds like it is for you) a fundamentally dysfunctional way to run a development team. The "architecture team" have all the fun (new projects, new code, new tech, green field design) but never see how the code they write actually behaves in the real world, so never learn from their mistakes and never improve as developers. The "bug-fix team" spend their days tidying up the mess left behind by the architecture team, who have long since moved onto something else, which is both horribly inefficient and leads to severe morale problems (I bet the bug-fix team has a much higher turnover than the architecture team?). It's a terrible way to run a company.

...and if they have any advice for evolving this.

What is it that you are trying to achieve? It's not clear from your question what it is that you want to make better when this "evolves".

Do you want to make the bug-fix team happier? Reorganize the company such that teams are based on product, not development/maintenance, and so that all developers get the chance to write fresh code and the responsibility to maintain existing code. But it sounds like you're not a manager, so you probably won't be able to do this (and the architecture team will fight it hard if you try).

Do you want to make the architecture team members better at what they do? Introducing or improving the company's CI/CD, unit tests, static analysis, coding guidelines, code reviews, training, etc. would be the usual way to achieve that, and some of it you can do as an individual contributor. But it still leaves the inefficiency of an entire team doing nothing but fixing bugs, and some of the architecture team may not be receptive (the code they write has always been good enough until now, they'll say, so why should they change?).

Do you want better software and happier customers? Combine both of the above.

Or is it something else? I realize I'm biased based on my previous experiences (which might not be the same as your experiences), but IME a company organised this way is inherently dysfunctional. The people with the most influence (that is, the architects who have been there the longest and are not held to the same expectations as newer staff like you) will resist change because they have got themselves into a comfortable position, and have an entire other team doing the work they don't want to be bothered by. Whatever change you want to make - even if it would improve the company and its software - will have to fight against those influential people. I tried to make changes for five years before finally realizing it was hopeless (I should have quit much earlier)... perhaps it will be different to you, but to begin with, you will need to be very clear about exactly what you want to achieve.

| improve this answer | |

You brought up two issues. First that

Some members in architecture [...] are not held to the same deadlines/expectations as newer members like myself.

and second, the fact that

[your] company has always separated their development team in two groups [which] creates dissatisfaction on the production team [though the production team] are generally favored [by the management].

These are really separate, in as much as if you solve one of them, the other would still remain.

The second is the result (presumably) of a deliberate management decision. If the management doesn't see this as an issue (because it hasn't caused them too many problems regarding staffing that team, etc.) there likely isn't much to be gained by bringing this up to them.

Is that a good way to structure a team? Well, the answer is subjective. If I were the common manager of both groups, and I was worried about staff retention, I would try to integrate the teams a bit, first by having cross group meetings where each side presented what they worked on (etc.), rotating people from one team to the other, or having the maintainers of A be the developers of A's replacement, etc., but this isn't always possible.

Regarding the first issue: from your context, its hard to tell if there is a real issue here or not.

For some expectations, meeting them is subjective. For instance, let's say I'm the manager and I mandate a design review for anything which we expect is more than a man-week worth of work. If you are a brand new member of the team, generally speaking, I will spend much longer on reviewing your design than the design of someone I've been working with for 5 years. Similarly, if I know how productive you are (after a few years of working together), I'll assume a missed estimate was due to the work being more complex than estimated, rather than a lack of production on the developer's part, so I'll spend less time trying to probe into why we missed the estimate.

On the other hand, certain expectations are objective. If every piece of code is supposed to be reviewed before it is merged, or we have requirements about documentation, test cases, etc., it doesn't matter how long you've been there - I hold everyone to the same standard. In fact, I will expect MORE of the old-timers, as they've had the time to learn exactly what I expect of them.

| improve this answer | |

If it's just some disgruntled peers in the production team complaining to you, tell them "oh yeah, I'll bring it up with my team/manager" and forget about it.

If it's management complaining, work with them to address their concerns. Just remember that decisions come down to money - if there is a financial benefit to make a change then it will happen, otherwise it probably won't.

At the end of the day, so long as management are happy then it doesn't matter what other teams think. You're there to collect a paycheck, not to make people you don't report to happy.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged .