Leader Spotlight: Structuring teams to minimize dependencies, with Nick Ehle

---

Nick Ehle is Senior Vice President of Product at TeePublic and Redbubble. He started his career in advisory at Ernst & Young before moving to product management at Dstillery (formerly Media6Degrees). From there, Nick transitioned to Amazon, where he worked on analytics products, custom research, and measurement methodology for Amazon’s largest and most strategic advertisers. Before joining TeePublic and Redbubble, he served in product leadership roles at littleBits, Jet, and Walmart Labs.

In our conversation, Nick talks about minimizing dependencies by designing teams and organizations to be as empowered as possible. He also shares best practices for building high-performing teams, such as instilling trust and setting clear expectations.

---

An evolution in leadership style

First, could you say a little about TeePublic and RedBubble to provide readers with some additional context?

Absolutely. TeePublic and Redbubble are sister companies and marketplaces for independent artists. The artists on our platforms sell merchandise bearing their art. The most popular items are t-shirts, hoodies, stickers, phone cases, and prints. We offer billions of products across both platforms.

You have extensive experience in companies from a variety of industries, sizes, and stages — for example, you were previously at Amazon, Jet, and Walmart. Reflecting on your career, how has your leadership style evolved through those different experiences?

I’ve been in product for over 14 years, and my first supervisory role was 12 years ago. When I first started managing a team, I was too focused on driving the right processes. As I’ve matured, my focus has shifted to outcomes. What are the teams and individuals producing? Are they doing the right things for the business, our customers, and our stakeholders?

From there, I focus on creating an environment where people can do their best work. As opposed to dictating process, I do what I believe helps my team be as successful as possible in their roles — both for them as individuals and for the business.

Do you find that you adapt your leadership style based on individual team members to help them be the most successful they can be?

Yes, my leadership style ultimately depends on the person. First and foremost, I try to understand their motivations. This comes from building trust and enabling them to be open and honest. Some people are motivated by moving up the career ladder, for example, while others may want to grow into a people leadership position. Others just want to do interesting work and remain an individual contributor. More than anything else, I want to understand who they are as individuals and what motivates them to do their best work.

Of course, there’s a dimension of performance built into that. I have expectations in terms of skill sets by level, i.e., what people should be able to do in their roles. Someone who is underperforming versus overperforming is going to require a different leadership style. Finally, in terms of assignments, I try to match the person to the role based on their expertise and motivations.

Setting expectations and clear outcomes

You talked about creating trust as being critical to building a high-performance team. Are there other aspects you focus on to promote that culture?

It’s important to set clear expectations. For example, while leading product management at TeePublic, I built a level framework with a career ladder. From there, I set expectations per level across job traits. I got great feedback on that — people said that what was expected of them in their role was much clearer, and that they better understood what skills were required of them to advance.

I also think that high-functioning, highly effective PMs operate well when they’re given a lot of autonomy. Then, if they are set up to succeed, there will be a high level of trust. I give people a lot of autonomy to drive the priorities of their team, as long as they’re going in the direction of our corporate strategy.

Finally, I focus on open and honest communication. I’ll be the first to admit when I don’t know something or when I make a mistake. That builds trust and creates an environment of open communication — if I lead with a low ego, am open about when I’m ignorant about something, or talk about when I’m making a mistake, that opens the door for other people to do that as well.

What’s your process for checking in with your PM leaders to find out if they’re meeting those outcomes? Are there certain metrics or KPIs that you rely on to make sure your team is performing at the level that you’d like?

Absolutely. My team and I are very data-driven. For example, I look at my dashboards every morning to understand the performance of the business and visitors on the site. I have the same expectations for the people in my organization. They might be looking at the same KPIs I am, in addition to KPIs that are beneath that or much more detail-oriented to their area.

We’re an ecommerce platform, so conversion rate is one of my core KPIs. A couple of core drivers of that KPI is the conversion rate of people who search on the site and the overall number of people who search. The product managers for the search function therefore look at all kinds of dimensions of search on a daily, weekly, and monthly basis to validate that things are trending as expected.

As an example of the effectiveness of teams, if I see something moving in the wrong direction or in a way that I don’t expect, I need the person who owns that area to know why. Because I’ve set that expectation with them, they’re always ready with insights to explain why this is happening. I’m also a big believer in operating rhythms. I have weekly 1:1s with all of my direct reports, and they set the agenda.

It’s one thing to create this high-performing team, but maintaining it can sometimes be something else entirely. Do you have any insights there, particularly in a fast-paced, intense environment?

Absolutely. Maintaining our operating rhythms as I just mentioned is a big part of that, but we also have a strategic planning process. I like to do this by having the executive team set annual goals, which are KPI-based. We’ll generally set one or two at most, and then we’ll have an idea of how we’re going to move those KPIs through OKRs.

We set a handful of these OKRs at the company level, and they ladder down to individual teams. Each product manager, in partnership with their engineering leadership, determines what they believe their team’s OKRs are. For the most part, they’re in the best position to decide what work they need to do and what leading metrics they need to achieve to move those company-level goals.

For example, one of our company-level goals is customer retention. We want people to come back and purchase more than once. That retention goal is targeted differently by each team. We’re currently in the middle of redesigning the checkout experience on TeePublic. We now ask for an email during the first step of checkout, rather than the last. We do that because we found that people who give us their email and permit us to market to them have a higher retention rate than those who don’t.

Hiring for grit

When you’re recruiting for your team, beyond professional experience and education, are there certain traits or characteristics that you tend to look for or you try to tease out in the interview process?

Yes. I talked a lot about being data-driven, and when I’m interviewing, I’m not just looking for people to understand statistics or how to pull metrics. Instead, I’m looking for examples where they’ve learned from data. I like to see people running experiments to learn rather than to validate a viewpoint.

Inherently, this comes down to asking about a time when they did something and failed. I want to hear about an experiment that went in the wrong direction and what they discovered through quantitative or qualitative data.

Another thing I look for is leanness. For me, this means that when someone is scoping projects, they’re not just trying to prioritize things that result in quick wins, but want to realize 80 percent of the value for 20 percent of the effort. Can they take the scope of a project, whittle it down to its core value, and end up removing unnecessary effort? The point of that isn’t to build half-baked experiences but to create development velocity and product delivery.

Lastly, I look for a sense of grit. This is hard to measure, but I like to ask, “How have you overcome an obstacle or a failure in your career?” I want to see that someone has taken on a role or a challenge that they were not quite ready for, for example, but through hard work, ambition, help from others, and mentorship, persevered.

As the company grows, do you feel that by having people who are data-driven, lean, and have the grit, you have what you need to be able to scale those teams?

Those factors are extremely important. I also find it critical to have leaders within the organization who embody those values and understand them. I’m proud that everyone in my organization — from PMs to senior directors — embodies those traits.

Another thing I’ve noticed is that it’s very easy for teams to get stuck on projects that have a lot of dependencies. As a result, product and engineering teams need to be structured in a way that has as little dependency on other teams as possible. For example, I don’t have any teams that are responsible only for user experiences because, at some point, they’ll become dependent on a backend team to build a service. If the backend team building that service is separate from the team building the frontend feature, that adds more complexity — we’d need to plan two teams’ work instead of one.

Structuring teams around autonomy

How do you prioritize minimizing those complexities and dependencies?

In general, you need to plan for that intersection. My goal is always to build full-stack teams — teams that are responsible for every part of the technology stack in their product. So, if they’re building a UI, they are responsible for the service layer, the database layer, and any other data layers in that area.

I mentioned our search team previously. They’re responsible for the user experience of our search function. They’ve got their own services, database, and data layer, and that enables them to move quickly so they can ship and release features within days instead of weeks or months. As our teams get larger and products get more complex, we’ve found that one team can’t own the entire customer-facing product. In that case, I try to find vertical slices of responsibility.

For example, at TeePublic, one team does not own the entire user experience. Instead, we have one team that owns the search experience, another that owns the cart and checkout experience, another that owns the product details and home pages, etc. So, when each of these teams makes changes to those aspects of the site, they can move as quickly as possible because they own the entire stack.

Not every team can completely avoid dependencies — sometimes, they have to exist. But we design teams and organizations to be as autonomous as possible.

Are there ever any conflicts with that model or small overlaps?

Of course, there are always challenges. For example, if you have individual teams focused on different aspects of the customer experience, the customer journey can feel disjointed. That is certainly a trade-off, but I manage that through KPIs. We try to look at the end-to-end customer journey as much as possible. I encourage rhythms of collaboration across product managers so they don’t live in silos. As much as possible, they’re working in their domain without dependencies, but from a cultural point of view, there’s a lot of interaction between teams.

Also, because we’re a marketplace, we focus on both our artist and customer’s journeys, even if we’re working in silos. The other reality is that a lot of teams work horizontally across teams. Our data and analytics teams are good examples of this. They are working at the data layer and have more dependencies than anyone else. Often, their work starts when another team’s work ends. That one is unsolvable, but we try to minimize it as much as possible.

You’ve talked a lot about the collaborative nature between different teams. Do you have any other strategies to encourage communication and feedback and help promote a culture of innovation?

In my mind, velocity is the most important factor for innovation because it lowers the stakes of projects. If you’re able to deliver something in a week, that inherently frees up your ability to innovate. You can try something and it can fail, but it’s not that big of a risk or cost at the end of the day. In terms of innovation, Redbubble and TeePublic both have introduced hackathons within the last few years. These are opportunities for engineers, product managers, and product designers to partner on ideas or chip away at novel ways of solving customer problems.

At Redbubble specifically, one idea we took out of a hackathon is within the Redbubble iOS app. We’re going to create an opportunity for customers to make their own personalized stickers based on photos from their phones. That’s probably not something that we would traditionally prioritize as a part of our day-to-day work, but the idea came out of a hackathon and is fairly easy to implement. We’re excited to work on it and see where it goes.