3 ms·
> Finally, after many rounds of arguing about why this needs to be done in the first place (ahem: you told us to migrate to your platform, and it literally does
by dpark 5y ago
> Finally, after many rounds of arguing about why this needs to be done in the first place (ahem: you told us to migrate to your platform, and it literally does not work for our app), they quote us a delivery timeline of end of Q1 in 2022.
This is where your manager (and if necessary their manager) needs to get involved. Is this actually important and urgent work? If so, they need to work with this other team’s management to get this done. If not, it can wait.
What you’re describing sounds like a particularly dysfunctional and bureaucratic corporation, but dealing with politics like this (and that’s exactly what this is) is part of being in a large company. Cynical people will say that everyone is just trying to protect their fiefdom, but most people are just trying to do the most important work.
That team you’re asking for work probably has hundreds of feature requests every quarter. The process is intended to protect the engineers from being randomized constantly by low value requests. But yeah, the trade off, especially if taken to extremes like this, is that it can slow collaboration to a crawl.
- gwbas1c 5y agoExactly, and: > I'm working on migrating our apps to the parent company's VM launching and deploy platform Who asked you to do this? They should be "going to bat" to make sure that you're getting what you need to do this. If it's some high up in your acquiring company who asked for this, that high up should be talking to the other team and making it known that they need to cater to you. But: If this is some initiative from your team because you're good team players, expect whoever wants this done to put in the political grind. ("You asked for xyz, you need to do the politics if you want this donw.") Otherwise, it's best to move to a different task.
- hardtke 5y agoIf you need it now to do your job, one strategy companies use is to escalate the request to the common point of reporting (even if it is the CEO). You and the person you are in conflict with (the other manager) need to write an escalation doc describing the conflict. It won't get to the CEO as there will be increasing levels of embarrassment up the report chain. If it does hit the point of common reporting and she says end of Q1 2022 you've got to accept her decision
- fma 5y agoEeeeexacly. Working at a big company is a skill itself. I mean lets face it...we all can code, but can you code in a big company and work around bureaucracy and try to deploy at the speed of a startup (or close to it)? I know people may laugh, but it's a question to ask. For example you can't plan your infrastructure a week before you deploy because you gotta have the infrastructure team approve your requests (which requires architectural and security approval), and you gotta have the allocation for your project in the first place (of course the trick is if you forget you get a resource from an existing parallel project on your team!) In ops case there is a disconnect. Whenever I had something high priority and I get red tape...there's 2 solutions 1) Escalate escalate escalate. Their manager doesn't help? Their director will. If their director isn't helpful...then sorry it's not really a high priority. I've NEVER had to gone above a director for escalation because the entire org was aligned with what was a priority. You might face a manager trying to protect their team but if their director says jump, they ask how high. Perfect example is a firewall rule takes 2 weeks to open up (security approval, firewall engineer allocation, etc etc). Guess what...I got like 3 open up with 24-48 hour turn around time each (kept getting blocked at different hops) for a high priority project. 2) If you've been around long enough and you have a good track record, you know people on a personal level, you do favors for them...people will do favors for you. You ping them, add a few emojis, reminisce about old times...and an hour later it's done. The other week we had a deploy and we forgot to contact an infrastructure team to let them know they had to promote something in production. Usually your deployment is dead in the water, because a new prod change request needs approval, yada yada. Well, of course there's a deviation for that (In Big Corp. there is ALWAYS a deviation for something). And I know their team lead, their manager and their Project Manager...we were back in business after negotiation what we needed to do to do it 'properly' and not get flagged for an authorized change. 1) Learn the skill of cutting red tape which a lot of times is escalation, planning ahead or being creative. 2) Be nice to people. If you're the new kid on the block and already pissing off people...you're going to get enough red tape to wrap everyone's Christmas presents at the company. Use your new found knowledge sparingly. You don't want to be the boy that cries wolf.
- fma 5y agoOh yeah - I've also been on the other side of the boat. Our big corp company sold off a division...we had a certain amount of time (months...) to split everything off and hand everything over. In some cases we had to rewrite entire applications to work with their xyz software/infrastructure/tech stack, whatever. If we don't meet the deadline, company pays a penalty per day or whatever. In other words - high priority. We had to realign projects, drop projects, carve out resources. This also means anytime we had any requests as OP is mentioning, we get in front of the line if we mention the magic words. My point is - if something is important at Big Corp, it gets done. If it's not getting done, it probably isn't as important as you think it is. Another example is - this recent log4j security vulnerability. You think people sat around waiting for approvals? Hah. Every application had a few days to fix test and deploy. People were called back from vacations. Deployment freezes were magically unfrozen.