If you want that invariant to remain true, it is logically necessary to leave.
> Unfortunately, the deploy tooling isn't entirely compatible with our app
I'd say that apps have to adapt to existing deploy tooling, not vice versa.
Platforms are historically slow to adapt to applications not written for those platforms; almost invariably, the motivation to work on some platform, and the subsequent porting, comes from the application side.
> Is this how it's like at all large companies? What should I do?
I'd say that it's a bit of a Dilbert caricature of how it is, but in some aspects it is representative. In a big company, there are other divisions and teams which have entirely different priorities from yours. They have their own work items and milestones; and it is a fact that managers protect engineers from taking on work from side channels. This can be a good thing: in a big company you can take advantage of that to reduce distractions and stay focused on something.
Just because your idea is approved and scheduled for sometime in 2022 doesn't mean they are just twiddling their thumbs, but it does seem as if they don't share your view of how urgent the feature is.
Source code repos not all being open company-wide is also not unheard of. The ownership boundaries tend to be clear.
If you were to work on that software to submit a patch, one of two things would happen: it would be something like a customer request, where an engineer has to be assigned to that patch and be responsible for integrating it: getting it to pass all reviews, and do additional work on it like test cases, documentation and whatever. Or else, you would have to effectively be joined to their team to particpate in all that: get the associated ticket assigned to you, have access to all their systems (repos, bug databases, code review, documentation, ...).
Probably best to just let them own it.
Any sort of priority shift (your application A being an important payload for their delivery platform D) will have to take place at the management level. Your management convinces some higher management (that is above both of you) that this is important, and then that comes down as a mandate to their team: please give your cycles to A.
If you want that invariant to remain true, it is logically necessary to leave.
> Unfortunately, the deploy tooling isn't entirely compatible with our app
I'd say that apps have to adapt to existing deploy tooling, not vice versa.
Platforms are historically slow to adapt to applications not written for those platforms; almost invariably, the motivation to work on some platform, and the subsequent porting, comes from the application side.
> Is this how it's like at all large companies? What should I do?
I'd say that it's a bit of a Dilbert caricature of how it is, but in some aspects it is representative. In a big company, there are other divisions and teams which have entirely different priorities from yours. They have their own work items and milestones; and it is a fact that managers protect engineers from taking on work from side channels. This can be a good thing: in a big company you can take advantage of that to reduce distractions and stay focused on something.
Just because your idea is approved and scheduled for sometime in 2022 doesn't mean they are just twiddling their thumbs, but it does seem as if they don't share your view of how urgent the feature is.
Source code repos not all being open company-wide is also not unheard of. The ownership boundaries tend to be clear.
If you were to work on that software to submit a patch, one of two things would happen: it would be something like a customer request, where an engineer has to be assigned to that patch and be responsible for integrating it: getting it to pass all reviews, and do additional work on it like test cases, documentation and whatever. Or else, you would have to effectively be joined to their team to particpate in all that: get the associated ticket assigned to you, have access to all their systems (repos, bug databases, code review, documentation, ...).
Probably best to just let them own it.
Any sort of priority shift (your application A being an important payload for their delivery platform D) will have to take place at the management level. Your management convinces some higher management (that is above both of you) that this is important, and then that comes down as a mandate to their team: please give your cycles to A.