Leader Spotlight: The balance between assertive and kind leadership, with Josh Schoonmaker

---

Josh Schoonmaker is Global Vice President, Product Management, Commerce at Optimizely. Josh started his career at HP, where he worked for just over a decade, and then transitioned to working at eBay as a program manager. He served in product leadership roles at Tozny and Consolidated Supply Co. before joining Optimizely in 2020.

In our conversation, Josh shares his approach to balancing two key leadership traits — assertiveness and kindness — and knowing when to apply each. He also discusses the importance of doing “crazy things” for his team to build trust and rapport, such as pulling in a product owner and covering the team’s Jira tickets for the week.

---

A different lens toward leadership

To start, can you talk about your method of leadership in modern tech?

There’s been a huge evolution in business leadership that’s been really crucial. Back in the day, leadership books were informed by military experience. They’d study strategy as if it’s a battle. And that approach is not very viable or relevant in the modern age. What we’re looking for is a much higher level of collaboration — getting interesting things coming from many people, watching our edges, and identifying new opportunities.

We really need to take a different lens toward leadership, and I love some of the stuff that’s come out, like servant leadership and thinking about how you do strengths-based leadership.

For me, one of the most important balances is the idea of being assertive and being kind. And these two things aren’t often thought of as going together, but the best leadership in product is about how you have enough focus on being assertive that you are driving the product, that you are getting stuff done, getting stuff out there, and making it happen. And then balance that by having genuine care for the people. Once you do that, you create a sense of loyalty and camaraderie. You see people actually growing.

How do you go about that balance of being a kind leader but still running a tight ship?

I’m in this to help people be a better version of themselves. For me, it’s so important to be able to bring a leadership perspective that’s about how I help create people who are happier and doing better in their lives overall because they’ve had the opportunity to experience my leadership. To do that, you have to think past the business outcome, and assertiveness is very much a part of how I do that.

You can ask any of my team members — I have too many things on their plate. I’m making rough deadlines and pushing them, but I’m also the one who’s going to show up and be with them late if needed, or go and buy the pizza. Or, I might even say, “You guys just did a great herculean effort. Let’s give you two days off. Just make sure that you’re taken care of.”

You’ve got to create environments that are actually conducive to their growth, happiness, and success as part of what you’re doing, not just trying to extract value from them. That kindness piece is so critical to how we get a more humane, modern-informed view of leadership.

When to lay down a hard line

Do you have frameworks for when you think someone’s being too kind and could push harder?

Figuring out where to apply assertiveness and where to apply kindness isn’t just figuring out when you’ve overdone one or the other. A lot of it is knowing when to apply each, not just the magnitude of what to apply.

In a modern business context, you know that you’ve gone too hard on assertiveness if you’re having to yell. There just isn’t a realistic place in software engineering and tech that needs yelling.

One of the things I’ll call out is that I almost always have my full-on assertive personality when we’re doing quarterly roadmap planning. It is a really important time for me to not back down. When we’re setting stuff for a quarter, I’m going to push hard because that’s the right opportunity for us to have that impact. If we do that well, my ability to then spend the rest of the quarter leveraging kindness is very high as long as we have set the ambitious goals and gotten people on board with it.

There are a lot of tight deadlines in product management, so how do you find that balance in those situations?

Laying down the hard line is important. You’re actually doing everybody a favor by getting clarity and not getting squishy when times are tense. After you get there, you say, “Is there anything I can take off your plate? Are there resources we could bring to bear?” That’s where kindness comes in. I’ve had a lot of success with engineering teams when they see my willingness to do crazy things to help them.

For example, one of my teams was behind and frustrated from all this grunt work on Jira tickets. I said, “Great, I’ve got that solved. I’m pulling in a product owner. Nobody has to do their Jira tickets this week. We’re just going to cover that for you. It’s not the most efficient way to do it, but I don’t care as long as you are focused on what you need to be.”

They start seeing these ways that I’m bending and flexing for them, and it gets them to a point that, when I do lay down that hard line, they’re like, “All right, we don’t like it, but we’re going to do this for the team.” So much about this is them seeing that they’re doing this for their other team members.

Do you find that teams are highly motivated by helping each other in the same way that they help their customers?

I believe in customer centricity, but in the modern world, most of us are far enough removed from our customers’ experience that, on a day-to-day basis, that isn’t our full motivation. When we get back to doing our monthly review or get together for an all-hands, that focus back to the customer and the customer stories is vital. But if you want somebody at 3:30 p.m. on a Friday to care about having something done, it’s because they’re helping their teammates.

Creating correlations to the North Star metric

Can you speak to how the team is structured at Optimizely? What does your team look like today?

We form teams and divide work based on pods. As we define day-to-day work, often the people managers aren’t involved in that. We have people who are leading the work and the people managers are there to take care of people’s problems to ensure that their career growth is going well, the administrative things get done, and that people defining the work aren’t overtaking or using that.

Often, the people who are defining the work are based in these collaborative teams. So it’s this hybrid matrix with reporting structure that comes together, but we have a much tighter group of people working together. Matrix structures often failed because everybody worked on different teams — they were shared between teams, so they never felt team loyalty. By creating a fairly cohesive team and having people management be that matrix element, we find a lot of good effects.

And how are you using data and metrics for better decisions and motivation within those teams?

One of the most important things is finding the top metric. All of us are making management decisions with numbers, but what’s far more meaningful and important to people is to say, “Here is the metric; this is what I’m going to bring to you every time we talk.”

For us, because we do a commerce platform, it’s the number of transactions people have run on our platform. We’re going to change that key metric next year to average transactions per customer because product team members feel like they can influence that more than the raw transaction number.

By having that one metric, I sometimes have to work harder when I want to talk about something like COGS. I can’t just say, “We should save money.” I have to talk about how, by saving money, we empower things that will drive transactions. By doing so, everybody knows that’s how we know we’re winning.

Another thing is finding ways of creating correlations or leading indicators to that North Star metric. It’s important to relate things to it and make sure you’re bringing that back consistently into how you’re talking to your teams, whether it’s going well or not. The approach of showing the number when it’s going well and hiding the number when it’s not doesn’t drive trust.

How did you think about that decision to have one North Star metric vs. one per team? Do you think one works better than the other?

I think there’s value in looking at both of them. By having one, I definitely created some levels of disconnect. Some teams are two or three steps away from hitting the North Star metric, so it’s harder for them to connect to it and that is a disadvantage. Having a metric per team would resolve that.

On the other hand, we create more cohesion across teams and a much stronger group. One of the things we were working on was creating career paths for our engineers to move between teams. We want our product people to be able to cover each other better when somebody’s out for an extended vacation. To do that, we have to feel much more invested in what’s happening across the product portfolio rather than in the individual microservice you’re managing.

Removing yourself from the details

How do you balance that big picture that you were talking about vs. having to get into details as the product leader?

This is a difficult one because I think we often talk about the right way or what a good leader does, but the lifecycle of a business is a hyper-relevant conversation point for what type of management is successful. For instance, at a startup, if your product leader isn’t making decisions about the specific features that are going in or isn’t aware of which features are getting delayed, that is a problem. But, just because it worked in the past does not mean future performance will work the same way. There’s a point at which you actually need people to remove themselves from the details.

The negative consequence of micromanaging is twofold. One, you can discourage team members who are trying to prove that they can own and take care of something. Two, you get smart leaders who see the big picture and who can see how all these things connect, but if they’re spending six hours a day in meetings, you’re losing the value they could add if they could say, “I’m not worried about that. What I am worried about is if every team delivers on what they’ve said they would, where is that going to put us and what do we do?”

Finally, when you’re adding features or experimenting, how do you measure its success and conclude that something’s not going as you intended it to?

We all naturally over-focus on the features that get a lot of usage. And that’s important to understand, but what we miss is that some of our best opportunities are watching the things that are not getting high usage and saying, “Are there very small changes that could very massively impact this experience and get us there?” The fail fast movement is extremely useful but has some negative consequences.

One of the worst/best examples of this is from a product friend of mine. Talking about a feature, they said, “We watched the metrics and nobody used it. We went like three weeks into the beta and nobody had used it.” So they canceled it and moved on. Later, they sat down with an advisory board and someone asked if they had fixed the login problem for that feature. They were confused.

As it turns out, nobody could log in with the feature, so they were watching the result metric without digging into why are users failing to use it. It led them to dump something that we’ll never know if it was a hit or a dud because they didn’t solve some of those basics.

I like watching metrics and seeing if we have something that’s failing to get adoption; that’s a good place to drop a fast A/B experiment. Or to give your designer free rein for a redesign. You’ve gone through the process of having a product manager identify if we think this is valuable and you’ve taken the time to build it out. I know there’s the fear of a sunk cost fallacy, but there’s also throwing the baby out with the bathwater. If you actually have something valuable on your hands that can be fixed with small efforts, it is worth it to do that.