I’m no fan of “professional meeting attendance” as a career path, but at least that limits the damage it inflicts on an organization. Meetings can be skipped or at least you can bring a laptop and work through them. Sometimes, they’re actually useful. But I’ve never seen anything bring development to a grinding halt like having an external team demand the authority to oversee, and overrule, product decisions made by the teams that are supposed to own those products. When that happens, there’s a step in the development process that literally consists of “come to a full stop and beg permission to do your job.”
Just so we’re clear, I’m not talking about integration testing between teams and their respective services to make sure interoperability works, although the more you can automate that the better. I’m talking about people whose systems or products are tangentially impacted (at best) by a release demanding full oversight over your team’s ability to release code. In the handful of times I’ve seen this in companies, it’s looked like a power play of some sort. Specifically, it’s seemed like people have a little piece of turf that they’re going to enforce and protect at all cost, or another team seems like they’re trying to demand that they never be inconvenienced by having to compromise with other teams.
Here’s a real-life example from back in my government contracting days – for every code change (and I mean Every. Single. One.), we had to submit a proposal for what we wanted to do to a Change Control Board. For each ticket you were going to work, you had to submit a description of the issue and what you wanted to do, which were then compiled and reviewed in a weekly meeting. This write-up was emailed to all the participants about 30 to 60 minutes before the meeting. Plenty of time to go through a 10-20 page report of every change developers were asking to make, in paragraph form with little to no code. For fun, most of the people on this committee weren’t involved in the codebase day-to-day (because it was DBAs, an architect, and project manager more so than tech leads), and larger projects had their own project plans that had their own reviews (by most of the same people as this committee).
Basically, for every minor change or bugfix, we were checking out an issue branch, making the code change and doing some local testing to make sure what we were proposing would address the issue, then writing up what we already did, getting our proposed changes rubber stamped, and then walking back to our desk and getting most of our work for the week checked in within about an hour after walking out of the meeting. There were a few instances where someone offered a relevant point that would cause someone to go back and re-work their proposal, but I could have counted those and still have fingers left over.
I’ve also seen instances where before 1 team can release an update to their app or service, another (tangentially connected at best) team would demand time to do their own round of testing. Keep in mind, this is a completely different team, with their own set of work to be doing, and their own priorities, and now development teams are blocked until their applications and services (that their QA teams tested) are tested again by another team that has a completely different set of priorities. These tests (and their scopes) are negotiated in advance, and if the external team decides they don’t have time to duplicate work the original team’s QA process did, that work (often a fix for a recently-found bug) gets ripped out of a release at the last moment.
The biggest problem with this, aside from the coordinating an unnecessary step with a third party, and the potential extra work being dumped on your team, is the message that gets sent to your team. It creates an official policy of “we don’t trust you,” regardless of what management actually says. That’s incredibly demoralizing, and completely avoidable by simply making a policy that teams cannot block the releases of other teams for anything short of a backwards incompatibility. Otherwise, you’re expected to maintain productivity, somehow, in spite of arbitrary work stoppages and new items added to your release when you’re trying to finalize it because other teams are demanding you make changes just to make their lives easier.
Software teams are supposed to be the ones in charge of their software. That means they’re the ones in charge of the change management process and release testing. Having unrelated teams with the power to override those decisions, regardless of whether they’re all “architect-level” or just another team that claims they could be impacted by issues in your applications or services, destroys that sense of autonomy, and ironically, the commitment to quality that comes from the code your team ships being your code from beginning to end. When you have to get approval from external teams to ship software, you’re deploying code that is subservient to other groups’ business goals and priorities, not code that focuses on your users and their experiences. That’s not a good way to ship software, both in terms of process and schedule.