Why we shifted to a product engineering organization at Sqreen
At Sqreen, our ability to move fast and deliver with confidence is one of our biggest strengths. It’s part of what’s brought us to where we are today, and one reason we’re growing so rapidly. The thing about scaling however is that it requires you to routinely rewrite the rulebook on your processes and habits. At Sqreen we keep a critical eye on the way we structure, from processes to teams, to ensure that they’re optimized and moving us in the right direction.
Here are some lessons from our journey.
In the early years at Sqreen, we operated with a flat, but distinct technical organization structure. We had a product team and a tech team. Product and design were focused on which problems we should tackle and what the experience should look like. The technical team was focused on making and implementing the right tech decisions to deliver features to our end users. Both teams however, had the same goal: to make Sqreen a great product and experience for our users — like shipping our Application Security Management platform.
Squads or feature teams?
Our previous organization was a good fit for us at the time. It allowed us to be agile and to align on projects easily. As we grew though, reaching consensus went from easy to hard. It was time for the next stage of our organization.
On the engineering side, we first tried to implement two mission-driven squads. Squads by their nature are mission-driven. It’s what separates them from normal feature teams. Feature teams are more temporary — groups come together over a feature, then drift apart to work on other features.
We started with a protection squad and an application security monitoring squad, corresponding with the two main missions of the Sqreen product. The squad model was a good fit for Sqreen because we believe product engineers should understand the business side of things — our mission and the why of what we’re building. This helps engineers build business expertise on top of technical expertise, and connects them more to the company as a whole. The temporary nature of feature teams didn’t allow for this to happen.
So there we were with our squads, when we realised we had a problem. We didn’t have the resources or maturity to make multiple squads work just yet. We didn’t have enough product management time to focus deeply on multiple squads. At this stage, I was the only Product Manager supporting two squads. So we decided to take a slightly different tack and merge the two squads into one: the Product Squad.
Introducing the Product Squad
Our mission at Sqreen is to make security accessible to everyone. In order to make security more simple, the product itself has to be technically complex. This requires deep expertise across the team, and an organizational structure that fosters communication and a shared vision.
The guiding lights for designing our product engineering squad were around breaking down silos, creating a shared vision, and ensuring that every person on the squad felt a deep sense of ownership and autonomy.
We merged two functional product tracks (monitoring and protection) into one single squad, and wove them more tightly with product and design. As an added bonus, when it comes to keeping the platform up and running, having extra resources in the team helped to distribute ownership.
Why product engineering is a better fit for Sqreen
Organizing ourselves into a product engineering squad is a great fit for our size and stage. It provides better coverage and helps everyone on the squad get a better understanding of the business side of things. Your traditional engineering role is all about technical knowledge. With product engineering, you also need to be fluent in a business area so you can execute on your work in the way that best supports that business.
For Sqreen, feature teams weren’t helpful past the super early stage — we found them to be too ephemeral and to lack the larger context and ownership that helps you scale. Additionally, spinning new ones up and tearing old ones down have overhead as well. Squads have the product fully embedded, which provides context and helps the team align and understand deeply what they’re working on.
Good for Sqreen, good for Sqreeners
Product engineering is not only the best setup for Sqreen at our stage; it’s also proved positive for our Sqreeners. For engineers, it’s a way to have a greater impact on the business, and not just be execution-focused. Engineers are more involved in the decisions of what we build and how we build it with this structure than they used to be. They understand the stakes at play for the business, which helps them make better decisions within their direct work, and align it with the end goal of the team. This provides them with more ownership, which is a key element for us.
As Sqreen is a tool that developers use every day, our developers represent in part, our users.
Directly related, Engineers are often the best to talk and understand our users and we’ve been making sure every product engineer at Sqreen get in fronts of them often. For instance, when working on a specific product initiative, it’s super useful and rewarding to speak with target customers.
For product managers, product engineering is about being able to work with the direct input of engineers. This creates a lot less back-and-forth, leads to fewer iterations and helps everyone stay in closer alignment. We’ve seen fewer conflicts, less wasted cycles and delays since making the shift.
What we learned while making this transition
The number one takeaway: to achieve a transition such as this, you need to bake it into your culture. You need to have buy-in at every level — including your recruitment team, so that the engineers you hire are motivated by and interested in the business and product of Sqreen, and not just the tech.
Organizational structures are a journey, especially for startups. Make it clear to everyone that the organization will change and continue to evolve — and that’s a good thing! It will be a process with iterations. Basically, treat your organization like a product.
Back to the future
This is not the end state for our product engineering org structure. We will continue to evolve and iterate our org structure as the work and our size demands.
Today, we have a nine-person squad that covers the whole scope of our product. As our team growing, we will move back to several squads and specialize further as we grow, in order to keep our mission-driven focus and maximize the sense of ownership for everyone — following the popular “Two Pizza team” Amazon’s rule. But even as we specialize, there will be bridge topics that cross squads. We will need synchronization across teams to keep everyone aligned and working together.
The last word
Scaling is a tricky thing. Don’t be afraid to iterate and revisit your org structure as you grow. Once you add people, especially at a small stage, what works changes. As few as one or two additional people can create the need to change to a whole different set up when you’re small. Regular iteration in your org structure is not a weakness, but rather a strength.
If you’re thinking about your own engineering and product team structure, we hope this overview has been helpful for you. And if you’d like to help design the next phase of our product engineering organization, we’d love to meet you!
