Snyk Leadership & Management

How do product leaders translate company strategy into actionable goals for their teams?

Company strategy sits, for valid reasons, at a much higher altitude than what’s immediately actionable for an on-the-ground team. As product and team leaders, it’s our job to walk that fine line of bringing the strategy down a level to something tangibly relevant for our teams without being so prescriptive that we take away their freedom to innovate.

The best way I’ve found to do that is through objectives and key results. I start with the company strategy and determine which elements of it my teams can influence. Then, I work out what we’d need to accomplish, and by how much, to move those elements meaningfully. Those become the objectives and key results I write down and share with the team.

OKRs work well because they specify the outcome and leave the solution to the team. My teams own how they get there, and I coach them to run the same exercise one level down for their own areas, and so on.

One of our pillars this year is regaining developer trust in remediation. The part of this that my teams influence is whether a recommended fix gets merged, so that became the objective with a target merge rate attached, and the “how” was up to the team to pick.

What does collaboration between product, engineering, and design look like at Snyk?

I’ve always seen product, engineering and design as equal and complementary leaders of any workstream worth doing. At Snyk, product owns the “why,” engineering owns the “how,” and the three of us share decision-making and ownership of the “what.” As the voice of the customer and closest to the field, it's the product team’s job to make sure the team is prioritizing what matters most and building, at a high level, the right solutions. Design takes signal from product on what jobs need to be done, then owns the workflows, cross-company consistency and whether the experience makes sense. Engineering keeps product and design grounded in what’s realistic to build, helping their partners understand tradeoffs and prioritize accordingly. They also, of course, make sure what we build will scale and stay maintainable.

Even with AI blurring those lines, I’ve found this split keeps things moving with the most clarity. Now, if product is swamped, I’ve seen success having design take on customer research with an AI plugged into Slack or Google Workspace. Product often takes the first stab at wireframes, and design still owns the call. Keeping that clear stops the blurring from becoming drift.

How do you maintain alignment and creativity while scaling or launching new initiatives?

AI’s scrambled this one. Before, everything happened systematically. While speed differed depending on the passion of the team, there was a relatively well-known sequence to how software was developed. Now, teams can iterate as fast as their LLM tokens allow, so by the time teams align, they’re already off in different directions.

Clearly defining ownership boundaries is what’s worked for us. The spirit of it isn’t a wrist slap or turf building (at least ideally). The necessity is really one of capacity — We only have so many people, and we need to duplicate as little work as possible. If a team anticipates jumping into another team’s area of expertise, the goal is to open a conversation. If that team has already built something similar or is in the middle of building it, then we’ve just established a new partnership. If they’re prioritizing other initiatives, the first team gets the blessing to build what’s required with their guidance. This way no one is blocked from building what they think is right, but everyone at least feels consulted. When you’re covering a lot of ground with a lean team, there’s no room for ego. Build, iterate and learn in public. That’s the ballgame.