Why do some teams require filing a ticket to review our change?

Plugin model is a good idea. We can certainly take deeper look into that. On the surface level, we make changes all over the places, so it's not very straightforward to make it plugin. On the deeper level, maybe it's possible.

Last year, my team actually tried to carve out some business components so those could be entirely owned by us, but it experienced lots of push backs.

I would say one can’t have their cake and eat it, too. If there is a clear business reason for outside teams to contribute to your code, that needs to be manually supported or a model of co-ownership via plugins or whatever is really critical. Saying no to both, or making it difficult, isn’t really feasible.

I think that this “we have to touch so many places, so a plugin won’t work” is totally understandable as the system wasn’t designed for extensibility like this. Wiring a plugin instance to all of these different places assuredly feels impossible. This is a bit chicken-and-egg. One can say that extensibility is needed first, and wait, or wire a proto-plugin setup first then push toward the goal that way.

In the latter case, for each distinct behavior you modify, I would make a functional interface or whatever that describes what happens there, I.e. userUpdateInterceptor or onSubscriptionDeletionResponder. You may have a dozen of these, but if you scope this properly, it will be very clear what each piece is for and what it’s doing. The plugin itself can have Optional elements for each of these, and only provide what is needed for each feature. Then you provide a multi binding, where you register your plugin, and whenever these behaviors are needed, a List of nameOfBehavior is passed in. I am thinking in Java but this can be adapted. pluginList.stream().map(PluginType::getCoolBehavior).flatMap(Collection::stream).collect(toImmutableList());

That could also be abstracted to a generic method that takes the PluginType function for extracting the needed behavior, so that boilerplate is hidden and you just see calls to getBehaviorForPlugins(plugins, PluginType::myBehavior). Then in the code that runs this, you determine an execution style, isolation levels, etc. Do you need to count errors per plugin, etc, make sure a plugin can’t crash you, determine if plugin behaviors run on the critical path or on another thread, etc.

For the first go ‘round to try it out you don’t need to do all of that, but would set up any places you modify to have a list of the behavior interfaces passed in, even if you’re just going to pass the reference in explicitly.

When it comes to new plugins needed new behaviors, the plugin interface itself should be updated, with every behavior-yielding method having a default that returns an empty optional. That way, all existing plugins will just have an empty version of that behavior and none of them break.

It doesn’t mean no reviews ever, but essentially you write you whole plugin for a new feature in your own code hive, get it reviewed and approved by your team, then the add to the registry (with an experiment that controls if it is added or not) is what the other team reviews, along with new behavior injection/addition. There must be rigorous testing, but it changes the place where the teams intersect.

This wasn’t your question, but I just hate when engineers are essentially set up to conflict because investment is being made in these cross-org away team model tasks and not in removing that need.

I have also found luck, when things can be async, to just publish a signal to a queue in the host system, then subscribe in a completely separate service your team owns, and do whatever work you need. This relieves even more testing burden from the host team, because no matter how much work you do or how often it fails, that’s irrelevant. They ship signals, the rest is your problem.

They actually reviewed our design doc and already signed off. The ticket is for reviewing the changes only. The point on having connections is spot on. Actually my team had a privileged channel with them last year so everything gets prioritized (about 2 days turn around time) and now this year we lost the privilege :( not sure what happened during planning season

For this Taro question, I intentionally tried to hide some backstory to give the other team as much credits as possible. Let's call the partner team A. A few more stories:

1. We previously had a few escalations with team A, some got resolved at m2 level while some got resolved at d1+ level :)))
2. We competed for a design doc ownership. We proposed a design to change something in the package Team A owns. After two weeks of discussion, team A threw out another design doc saying that's the final design doc of the project and our design docs were not needed. Then we started escalation and we won. The lead engineer in team A was so mad that he revoked our read permission of his design doc and then we informed managers and our access was restored. The lead engineer is now transitioning to a manager in Team A.
3. My teammates have the same not good feeling with team A, so it's not only me :) My team works across the orgs, so it's interesting / easy to see how differently helpful each team is.
4. There's a blind post saying our org is terribly political. One comment says team A is the worst; another says team B is the worst; another says so does team C. The comment on team A got the most likes (significantly more). The 3 comments are posted around the same time so they should have about the same audience exposure :) There seems to be an anonymous consensus

My personal suspicion is team A wants to slow down partner teams as best as they can, because they don't get credits for our changes. On the other hand, I don't know why they can't get credits if business team successfully work with them and launch projects. They of course will never state evil thoughts and only say good things of why a ticket is required to review a change.

Just to be clear, I'm empathetic to the people in team A. I was in a team of similar culture before I transferred out. I'd summarize the culture to be strong opinion on things not so important. When you are in that environment, it's difficult to jump out and see how things could be done differently.

This is dysfunctional, but you are an active participant. No one is “winning” when engineers can’t discuss and choose the best approach and the only resolution is through escalation. You seem to be delighting in your team winning, the other lead having to reshare a document because you escalated without discussing it and coming to a resolution, etc.

You are on the same side. Fixing the dysfunction is the problem, you’re all worse off as long as it goes on, and it’s bad for the org and your users. You are part of the responsible parties in fixing this.

You are delighting in a Blind “vote”, one of the worst, most toxic places on the internet when it comes to our industry. That there are active discussions about this in an anonymous context, with people chiming in to slam other teams. Yuck.

There is no benefit to team A to slow you down for the sake of it. They are assuredly getting pressure to finish their own tasks, and they have cited away team support as an impediment. The easy move is to try to reduce that via process instead of developing technical approaches to shared ownership.

“Evil thoughts”. This is work. I doubt seriously anyone is trying to actively sabotage other teams. Even if they were, that’s not evil.

In the same paragraph you state you have empathy but then state they have strong opinions on trivial things and that they are incapable of thinking of other solutions.

How are you working actively with them to fix this? When are you deleting Blind? When are you meeting with your shared senior manager or director to ask for help improving the culture so everyone can work together more productively?

I’d request you to take another objective read. I tried to provide object data / evidence instead of feelings. Which part makes you feel I escalated without informing the other party? I was diligently working with the other parties in all hours and then my manager first said they were not likely engaging good faith negotiations and asked me to collect evidence of their inappropriate behaviors.

You are suggesting I come up with a solution to fix the organizational problem where there’s 3 senior, 3 m1, 3 m2 involved. This is beyond my comfort zone.

I’m happy to delete the thread if this is not what Taro is intended for

I may have misattributed tone in your message above. The list seemed to be enumerating how they are wrong, and how your team is right. More worrying is the us versus them attitude.

Maybe you are not comfortable soliciting help from your director, and working toward a solution that helps everyone. If so, talk to your lead, or the Team A lead and ask them to do so. This infighting between your teams is bad for everyone. I am really suggesting being on the side of fixing the problem, not perpetuating it.

I think this is exactly the kind of conversation that belongs on Blind. It started with a process question related to code changes and turned into a discussion of the real problem, which is this on-going internal conflict.

There's loads of misrepresentation in your previous statement. If you are genuinely curious, we can certain discuss. Texts certainly miss non-verbal communication, which could lead to misunderstanding.

Fixing organizational problem is not a hill I want to die on. In my short tenure, I've witnessed two front line managers got adverse action when they were trying to fix some cross org problems and it'd be out of place for me to fix the problem when there's so many managers involved. Plus, they definitely have lots of conversations going on behind the scene, which I don't have access to and miss context.

There's all kinds of problems in the corporate from stack ranking to return to office (whether you are proponent fully remote or fully in-office) to using number of lines changed in performance review. Are you suggesting I'm a perpetrator of those as well and responsible to fix those?

I'd say Taro (@Rahul) would ultimately decide what's appropriate for Taro. I'd also say discussion on internal conflict belongs to Taro. Ethan Evans (or is it the Databricks director?) onetime said there's competing for scope in all levels, from peer engineers to peer managers to peer directors to peer VPs. It's okay to acknowledge the competition.

I’m sorry if my replies made incorrect assumptions or mischaracterizations. Any discussion of these type of issues on Blind is certainly triggering, and the use of “won” describing a decision being made to use one design over another was also problematic for me. It is likely unfair to ascribe blame, my intention was based on a feeling that you were treating the situation as a competition with this other team. This reply of yours may be affirming that, and that’s fine.

If your org punishes managers for trying to make improvements that is worrying, and as you stated is maybe out of your scope. This was why I suggested involving a lead that may be in a better position to affect change.

Yes, a lot is lost in async text conversation. Happy to chat on the Slack. Obviously I can’t initiate such a contact.

If Alex or Rahul think any of this discussion is out of bounds I’m happy for them to request edit or deletion or do that themselves. I was stating my opinion of the appropriateness, but wasn’t claiming to be the last word.

Regarding “fixing everything” I guess I am overzealous on that and do try, but recognize that isn’t always practical.

Good luck, enjoy.

In some sense, we are similar that we are overly zealous on fixing corporate problems. That's why I care the problem we discussed so much and why it stays in my memory. That's why I know there is so many problems within my company. So many people poured their hearts into solving those problems and so many other employees signed their names supporting the fix, but it didn't go anywhere. Just to name another one on top of what I mentioned previously, my company requires one year of continuous employment to be eligible for parental leave (notice the "continuous", FMLA or STD would make a person ineligible). I don't have a child but I know it because others tried to speak up, fix the issue and got ignored. The ticket received lots of attention that it needed minutes to load and in the end the corporate needed to lock down the ticket to stop new comments. I saw their efforts and respect that. All I can do is to spread their words so their efforts at least get memorized and appreciated by someone