3 ms·

Those feature request intakes occur because otherwise infra teams become bombarded with multiple requests per day. In isolation they're not much work, but the c

Those feature request intakes occur because otherwise infra teams become bombarded with multiple requests per day. In isolation they're not much work, but the cumulative requests could take years and truly need prioritization. Being a recently acquisition, I recommend scheduling time with their manager to talk directly about your situation and trying to get on as part of their primary priorities. If that doesn't work, then your manager should be doing a better job getting other teams to be ready to support you.

johnyzee 5y ago
It sounds pretty standard, and it doesn't sound like the OP has put a lot of work into considering why it works the way it does. Know that annoying executive who likes to come to the development team and ask them for work? That's what the OP is doing. And how he then loudly laments that he will have to follow some process to have his request added to a backlog, before, at some opportune time in the future, it can be considered and possibly scheduled for being implemented? Yup, OP again. We hate it when process hits us, but you'd hate it even more if there was none.
chomp 5y ago
I was an ops manager at $big_company like the one described; your response gets it pretty right. There were many many groups that all wanted a slice of our team's time, and it added up to probably a 6 month lead time on all requests. Bringing in skip levels was almost necessary as we sometimes had to have upper management fight over who wants their subordinates' tasks done first. We didn't care who's tasks got done first, we just needed to know what the enterprise's priorities were. It wasn't uncommon for these tasks to have to snake through multiple groups for a couple weeks so that they can each give their input on what should be prioritized before it even hit our backlog. If their parent company is publicly traded, giving access to the codebase is a huge SOX no-no. All of these gripes are just big company issues. I suspect OP is a better fit for smaller, non-public companies.
- Cederfjard 5y ago
  > If their parent company is publicly traded, giving access to the codebase is a huge SOX no-no. Could you please elaborate on this?
  - chomp 5y ago
    Sure. So while Sarbanes Oxley doesn’t contain anything like “thou shalt not commit to a repo”, it’s pretty clear about separation of duties. This means that the person who commits code cannot be the same as the person who deploys (or has access to deploy) the code. There’s many ways to implement separation of duties that are all valid, but the compliance industry has settled on the concept of least privilege as a framework to enforce this requirement. So if a person external to a dev team wants to write to their code base, the hard rule of least privilege keeps the regulatory train on the rails, so to speak. Keeping that wall between external teams reduces risk in the company, at the cost of increased friction and reduced agility. Consider it a part of the price to pay for investor money. If you have any other questions I’d be happy to answer!
    - Cederfjard 5y ago
      Very interesting, thank you. I’m not based in the US, so was unaware of these regulatory requirements. I can certainly see how it increases friction, as you say.
    - deleted 5y ago
      [deleted]
gorbachev 5y ago
Agree 100%. However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling. Now, if they don't have a roadmap, and their prioritization sucks, that's another matter, and entirely possible, of course.
- isbvhodnvemrwvn 5y ago
  We see the matter from the OP's perspective only, who knows what he was told.
- throwaway19937 5y ago
  > However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling. My impression of the OP is that he expects other teams to drop everything and make the change. He may have been told about the roadmap but feel that his project is more important. That seems more likely than the following excerpt from the post. > 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.
pvarangot 5y ago
But what's not allowing access for compliance reasons and that's it? There should be a form where he can request access if he thinks he can pull off an implementation in days of something that takes months otherwise. I worked in big and very big corporations and cut through PCI, HIPPA, and lots of those with requests like that. That they have forms and scheduled for a month in the future (assuming second half of December doesn't exist which is reasonable) is good. But that there's no process to get access to their code and figure our what's going on is not ok. Specially if they are an infra team.

johnyzee 5y ago

It sounds pretty standard, and it doesn't sound like the OP has put a lot of work into considering why it works the way it does. Know that annoying executive who likes to come to the development team and ask them for work? That's what the OP is doing. And how he then loudly laments that he will have to follow some process to have his request added to a backlog, before, at some opportune time in the future, it can be considered and possibly scheduled for being implemented? Yup, OP again. We hate it when process hits us, but you'd hate it even more if there was none.

chomp 5y ago

I was an ops manager at $big_company like the one described; your response gets it pretty right. There were many many groups that all wanted a slice of our team's time, and it added up to probably a 6 month lead time on all requests. Bringing in skip levels was almost necessary as we sometimes had to have upper management fight over who wants their subordinates' tasks done first. We didn't care who's tasks got done first, we just needed to know what the enterprise's priorities were. It wasn't uncommon for these tasks to have to snake through multiple groups for a couple weeks so that they can each give their input on what should be prioritized before it even hit our backlog. If their parent company is publicly traded, giving access to the codebase is a huge SOX no-no. All of these gripes are just big company issues. I suspect OP is a better fit for smaller, non-public companies.

Cederfjard 5y ago
> If their parent company is publicly traded, giving access to the codebase is a huge SOX no-no. Could you please elaborate on this?
- chomp 5y ago
  Sure. So while Sarbanes Oxley doesn’t contain anything like “thou shalt not commit to a repo”, it’s pretty clear about separation of duties. This means that the person who commits code cannot be the same as the person who deploys (or has access to deploy) the code. There’s many ways to implement separation of duties that are all valid, but the compliance industry has settled on the concept of least privilege as a framework to enforce this requirement. So if a person external to a dev team wants to write to their code base, the hard rule of least privilege keeps the regulatory train on the rails, so to speak. Keeping that wall between external teams reduces risk in the company, at the cost of increased friction and reduced agility. Consider it a part of the price to pay for investor money. If you have any other questions I’d be happy to answer!
  - Cederfjard 5y ago
    Very interesting, thank you. I’m not based in the US, so was unaware of these regulatory requirements. I can certainly see how it increases friction, as you say.
  - deleted 5y ago
    [deleted]

gorbachev 5y ago

Agree 100%. However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling. Now, if they don't have a roadmap, and their prioritization sucks, that's another matter, and entirely possible, of course.

isbvhodnvemrwvn 5y ago
We see the matter from the OP's perspective only, who knows what he was told.
throwaway19937 5y ago
> However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling. My impression of the OP is that he expects other teams to drop everything and make the change. He may have been told about the roadmap but feel that his project is more important. That seems more likely than the following excerpt from the post. > 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.

pvarangot 5y ago

But what's not allowing access for compliance reasons and that's it? There should be a form where he can request access if he thinks he can pull off an implementation in days of something that takes months otherwise. I worked in big and very big corporations and cut through PCI, HIPPA, and lots of those with requests like that. That they have forms and scheduled for a month in the future (assuming second half of December doesn't exist which is reasonable) is good. But that there's no process to get access to their code and figure our what's going on is not ok. Specially if they are an infra team.