181–190 of 464 posts
Earlier quoted context omitted.
The explanation given above is that you aren't the priority you used to be.. it doesn't take a month to get something done, it takes a month to do all the things in the queue in front of you. If there is a lesson here it might be that companies quickly lose focus and try to do too many things. Then there are giant queues of things to do and important things are held up by unimportant things. Your thing might be impor…
The judgment, however, is that while one is not the same priority any longer, one's priorities are necessarily devalued, due to the a competition for resources, namely, time. I see the common explanation here is to just shrug at the state of affairs. Is this the best management can do? I can see why Fortune 500 companies die now.
It's not that this thread advices to shrug it off. They try to explain why some things can't go faster that easily and what seems cloggy and stupid can still be an effective machine at scale.
Not good ones or at least good team's within big companies.
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.
> So I reach out to the manager and ask what is going on. This is a simple task, I said. Why does it take an entire quarter for your team to deliver? He doesn't have an answer. Your simple task, which you think would only take a few days to implement, is probably one request in a long queue of requests that team is dealing with. That means they won't be able to start on it for a long time. That team probably set up t…
> Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I've been in the same situation multiple times. Sometimes I've been allowed to do the work and sometimes not. In the cases where I was allowed to do the work, I certainly took longer…
It sounds like OP is moving a bunch of the startup's systems onto bigcorp's infrastructure. Usually you can't "just do" stuff like that in a public company since there are laws and regulations surrounding access control, change management, data security, etc. For example PCI, SOC2, SOX, GDPR, ...
It's usually not the case that the bigcorp people just want to prevent the fast-moving Startup Superstar! from moving quickly. Bigcorp operates in an entirely different context from startup, and needs to protect itself from employees with incomplete information making reckless decisions.
I agree that OP should find a job that's better suited to their preferred style of working.
Earlier quoted context omitted.
> Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I've been in the same situation multiple times. Sometimes I've been allowed to do the work and sometimes not. In the cases where I was allowed to do the work, I certainly took longer…
> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I believe the manager explains it right after that. They have compliance reasons that not just anyone can access this codebase. It's also possible that the manager has acquiesced to types of requests before and it was a mess — new engineer doesn't understand they system, requirements of its scale (note that this is a new engineer f…
If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use.
Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.
(Said having worked at both companies with global read visibility & access scoped to team only)
Have you never worked on a team that had work planned out months in advance? Usually IME the team will only plan out the next quarter in any detail since things always change. But the product team and managers often have a roadmap (high level plan) extending out a year or more.
Most likely this team has already planned their Q1 and has given commitments to stakeholders, etc. For your work to jump to the head of the queue it would need to be more important than what they've already planned. Yes, maybe your request only takes a few days, but odds are that the team has dozens of requests on their backlog that are just a few days worth of work. If you want to try to get them to prioritize this work then someone from your team (typically PO, PM, or manager) needs to reach out to the other team and communicate what the impact to the company will be if your team is blocked for the entire quarter.
P.S. - Sort of a tangent, but this scenario is one where a good scrum master is worth their weight in gold. Once you communicate to the team that your work is blocked the SM can take on figuring out who needs to talk to who to try to prioritize the work, and will stay on those people to follow through so that you know when you'll be unblocked and the team can adjust plans accordingly. It may sound like a small thing, but it's wonderful not having to deal with it yourself as an engineer.
> So I reach out to the manager and ask what is going on. This is a simple task, I said. Why does it take an entire quarter for your team to deliver? He doesn't have an answer. Your simple task, which you think would only take a few days to implement, is probably one request in a long queue of requests that team is dealing with. That means they won't be able to start on it for a long time. That team probably set up t…
Also: they're likely understaffed, there's no division of responsibility - anyone could get a task for anything - and because of this, simply can't handle the volume of requests or route the requests to people who already know what's going on (and would be able to handle it more efficiently than someone with zero knowledge). Infrastructure teams often seem spread thin.
Dev teams are lucky that not every other dev team relies on them, usually. This reduces communication for that team significantly. Every dev team relies on infrastructure, so lots of communication overhead for them.
Earlier quoted context omitted.
I think OP was an employee at a startup got acquired. Which may or may not mean they got a huge financial windfall from it
I get where you are coming from, but even if you don't get huge financial windfall, there is just no point in sacrificing yourself anymore. It's not going to make as big of a difference anymore.