Treat ops like the product it is

It's been a few years since I posted my thoughts on Twitter about how there tends to be a significant gap between how we productize internal solutions versus customer facing solutions and so I thought I should go pull those tweets up and repost it here on LinkedIn.

I've been doing ops for a bit now (over 20 years), and there are a few things we need to accept and normalize for these teams - particularly the ones servicing internal needs. We see certain roles as a no-brainer when we look at selling a product to customers. These roles augment our Product and Development teams, but Operations teams can and should be supported by them as well.

Product Manager/Owner When it's one of the company's products that you sell this seems obvious. However, you need that same level of care and feeding internally as well. Requirement gathering? Prioritization? User engagement? Yes, please! They're advocates for the work and the users.

Project managers This typically becomes the responsibility of the team manager, but they already have as much or more work on their plate than their development counterparts. I know it's common to chafe at this, I used to. But you know what? Ops requires lots of effort and planning, and someone good at this makes your life sooo much better. Scrum master, PM, whatever. Find what works and take care of them.

User Experience/Research How does it get used? What does the workflow look like? How many steps does that take? Why doesn't anyone use this thing we built - it's amazing! If you've asked that question, you could probably at least use some consulting help from someone who gets this.

Tech writers We should all be contributing to our documentation, but we also know good tech writers make it better.

Marketing Selling your solution can be hard, particularly with focus on building and supporting your product. It's also not a skill set that many engineers excel at. This doesn't need to be dedicated, but allocate some of those resources to help ensure there is internal brand consistency and awareness.

SDET/QE "Why wasn't that process or script better tested?" Because you expect blood from stone and dedicate all of your testing resources elsewhere?

Software Engineers/Developers Not all operations teams have people with dev experience. If they don't, make sure you support them with some! This may look like contributing upstream to open source projects to address bugs, customizing integrations between systems, building user interfaces, or a plethora of other activities.

Onboarding engineers (Post-sales like) Someone that focuses on helping people use the platform/infra/tools. Onboarding typically requires a significant time investment and it's worth it. (Credit for this one goes to a great conversation I had when I originally posted this - not my original idea.)

Here's the thing: Internal systems and operations are typically cost centers. Getting these types of resources regularly and consistently enough to be productive can be hard. Which leads people who notice the gap to fill it with varying levels of success. And since it's often not their primary skill, any reorg or job change can throw the whole thing off course.

So sure, maybe you can't commit to a cool million a year on full-time resources for all of this. But you can focus on the ones that provide day-to-day value and then share your primary company resources for the others in bursts around initiatives. Set up an official process to request the assistance. Don't hide them or cordon them off. If they're busy and it's all work-related, prioritize the work and staff accordingly. An extra 1-2 people on a shared resource team helps you distribute the work and cover time-off situations better anyway.

Your operations teams are building and maintaining critical infrastructure. Treat them like the product teams they are.

If this resonates with you or you are fighting for these resources already or want to discuss this for your teams, feel free to reach out directly!