@alana I’m devops, and I’ve worked extensively with both traditional PMO and scrum product ownership. Ask away! I’ll try my best to answer usefully.
@alexis oh awesome!! i'm trying for a job that involves being the PM for a decently-mature infrastructure "portfolio" that has never had a PM/PO (other eng teams at the company do.) i'm trying to envision potential differences between managing ops product portfolios, vs devops or dev.. and just generally think through any gotchas. i'm thinking infra needs to move more slowly and methodically than i might be used to? but.. what else
@alana @alexis i think pm's can really help ensure that devs and ops are working together on what's actually expected from a deployment, since it's often the case that each of these groups doesn't really "get" what the other one needs or would benefit from. There's a huge human problem to solve in between this that isn't really covered by just "add devops" since it literally requires more hours of someone doing that human bridge work
@June @alana Agreed! I’d expand on this to say that an ideal imo worth working toward is for the 90-99% case of deployment being no infra team involvement - solid CI/CD tooling and infrastructure does an incredible amount to free infra engineers to plan for and proactively implement for future needs, which imo is their most effective role.
@June @alexis oh thank goodness, that's totally in line with my observations. i generally see my role between team and company as "buffer/guardian-of-team/ambassador/translator/promoter/advocate", and my role within the team as "organizer/negotiator/guardian-of-roadmap/cheerleader". sorta.
with ops, i imagine that roadmap needs to be communicated out 5000 times instead of 500 times. and i'll probably need to creep on a lot of other eng team meetings, so i can mitigate incoming crap
@alana @alexis i mean I'm biased to ops but it honestly seems like ops delivery is seen as arcane magic or something and it really shouldn't be. pm's should make it a priority to ensure knowledge is actually shared in the larger group and that usually means fighting with cowboy techbros who guard their work because of fear
@June @alexis at my last gig, i was kind of wistfully looking over at the ops team all the time. because executives didn't bother them as much as they bothered the "general-release customer products" teams. i love UX, but unfortunately so does everyone in sales (for example). current goal is to take a hard left away from products with GUIs and see if it gets less... foolish
@hirojin @June @alexis i think this is so old school and weird. when i've seen managers keeping teams from communicating, it was 100% just to keep everyone reliant on them for information. it's like they think PMs are obsolete if we aren't controlling the information flow between ppl who can already easily talk to each other 😅 which is such a... dare i say worthless?... way to spend one's days
@alana Mm. That’s a big question - let me study on it a while and ask around, I’ll see what I can come up with and try to have something for you today!
@alana I am managing an engineering and an ops team, and we have product owner roles, but not product managers. You can ask questions, and I _might_ be able to answer them.
@oliof have you noticed any differences between how the product folks need to work with the ops folks, as opposed to how they’d work with a different sort of engineering team?
@alana sure -- ops people are mostly driven by unplannable and untimely events. Product people that try to apply cycle based processes to their interaction with ops people will see those processes fail. This usually changes when the product people start seeing ops as stakeholders for product features, and you involve them like that.
@oliof what an interesting response, thank you! it hadn't yet occurred to me that the cycle-based processes product is normally steeped in would be a misfit for ops, but it seems obvious now that you've said it.
I wonder about the differences between ops teams maintaining legacy infrastructure vs ops teams building new infra.. perhaps the latter would still use product's methodologies, at least initially.. what do you think?
@alana as soon as you have an interrupting source of incoming tasks, the immediate feedback cycle of that breaks the disintermediated one of something like SCRUM for example. If you can plan 50% of your time _at best_ the overhead for cycle based processes (and also timeline based processes like waterfall) kills any possible added efficiencies. It also frustrates the ops people.
I have more thoughts about that but they do not fit within the margin of this reply (mostly about CMMI and tooling).
@oliof yes, it’s a complicated subject since there are so many variables that might be endemic to one organization or another. fascinating to me, honestly
@alana I'm in Operations, questions welcome.
@June can you tell me about some of the best and worst things you've seen PMs do, when working with Operations folks? e.g. i know at my last gig, the infra team paid the price for anything another product team hadn't foreseen, so that was rough. their PM had to be really tough, to keep from being steamrolled.
@alana ya, so, I've worked in a place where PMs had no idea technically about either side of things, and were really only focused on timelines and meeting outside objectives (like, we're on the line to get this button thing on the live site by Saturday etc) and that of course was horrible, and left zero room for anything that would improve the product in non-visible ways or keep teams healthy and happy with their work product. Compare that to...
@alana ... where the PM is a technical person who isn't actually responsible for tech output: this is the best imho cause they can see what's useful to work on and advocate for it to the non-tech stakeholders
@June technical person who doesn't contribute code but goes around explaining it to everyone else so the people writing it don't have to is totally me!
Sister instance for https://giant.horse messageboard!