Hey everyone. I'm interested in learning how others are structuring their PE teams and what roles exist within your org. I'm mostly interest in understanding how folks are handling operations? Do you have SREs, separate "Ops" peeps or do you have the same platform engineers who build also handle ops.

it depends on the size of the business and what stage it is in

I've seen SREs serve this "prod support" role even in startups. I guess it's just defining what a role looks like and it may or may not include ops responsibilities? In my mind I'm trying to figure out when does it make sense to separate the ops responsibility out of platform engineering (build vs operate) or if it should still be part of it and just have dedicated folks covering that?

Thank you @Roberto Quezada for asking this question. And Thank you @Jordan Chernev for thr article

I’m over simplifying, but as I interview, I’ve seen a few orgs where DevOps focuses on Shift Left and SRE focuses on Shift Right. PE reduces cognitive load and provides golden paths. Lots of collaboration between the three as the diagram above points out.

At what point in a startup evolution do you guys hire SRE/platform/infra specialisits?

@Tapan, I think it would be great to have a conversation sometime next week. You have my contact info. In the meantime, here are some general thoughts I’d like to share with the group: • T-Shaped Generalists: In a startup environment, it’s beneficial to look for candidates who not only have the technical skills but also align with your startup’s culture and can thrive in a fast-paced, evolving environment. • Financial Resources: Ensure you have the resources to support these hires long-term. These roles often command competitive salaries and may not immediately contribute to revenue. • Growth Stage: Many startups consider these roles when they reach 20-50 employees or when infrastructure becomes a significant bottleneck. • Series A Considerations: With Series A, it’s time to plan for substantial growth and consider scaling teams and operations. • Internal Development Platform (IDP): Develop an IDP to onboard new hires effectively. This could include standardized development environments, documentation, and automated processes. This requires lead time because when the flywheel gains momentum, scaling happens quickly. Looking forward to discussing this further!

This is a really interesting thread, and I'd really like to stay involved in any future discussions on this. Along with SRE, Platform Engineering, and CloudOps/Infra, I think there's an extra layer to consider—where does Security fit into all of this? I'm curious how the above article might change if it were focused on DevSecOps. Right now, I’m leading my team through a transition/evolution from being a traditional DevSecOps-focused Infrastructure team to a Platform Engineering team, where we focus on the 3 core pillars of any Engineering function: Security, SRE, and DevEx. Doing this in a Series B startup with a tight budget is definitely challenging, finding the right balance between all these priorities is not easy at all!

@Aurora Brignola good callout. My opinion is that Security is cross-cutting and a layer as you suggest. It should be an integral part of the platform. Dev(Sec)Ops needs to Shift Left with automation early in the development process and SRE needs to Shift Right with monitoring and incident response to minimize blast radius. Cost is definitely a concern and part of the risk/reward business calculation, but lack of controls and processes is Tech Debt and it must be repaid eventually. It’s harder to retroactively add. It’s toiling when Security is operating in isolation (siloed) and you get surprise attacks from DAST tools in Production. It’s important to be secure. However, the lack of communication can create far more work, wild goose chases and expose gaps in process for already overwhelmed teams.

Absolutely! The tricky part is making sure security isn't just an afterthought. We need to enable our developers to shift security left in an automated and seamless way. We want to avoid adding more complexity, context switching, and new skills to overwhelm even more the developers, so we need to make security feel like a natural part of the process instead of an extra hassle.