In this AMA session, exclusively for MTP Leaders, Nate Walkingshaw reveals some of the tough leadership lessons he learned early on in his career, how to build and scale a culture of trust, and why he wishes we’d all stop using the word ‘failing’. If you missed it, you can watch the whole session again, or read on for a transcript* of selected questions and answers.
About Nate Walkingshaw
Formerly the Chief Experience Officer at PluralSight, Nate is currently on the Advisory Board at ICONIQ Capital, and the Board of Directors at Pura. Previously, Nate served as the Chief Experience Officer for Pluralsight, the largest providers of online technology learning, where he built a user-centred product team, and oversaw Product Management, Development, Content, and Product Marketing.
Menu
- How did Pluralsight evolve?
- How do you take seven or eight different cultures and merge them into one and build one organisation?
- Within a senior leadership team, how do you convince people to really empower and trust teams?
- When you’re scaling quickly, it’s easy to mess up. What do you do if you mess up? How do you recover from that and how do you rebuild that trust?
- How do you scale trust in an organisation?
- How did you transition from thinking about product all day to thinking about the culture of the team?
- Do you need to fail in order to learn hard product leadership lessons?
- What are some proven steps to convert a team of mercenaries into an empowered, customer-focused team?
- In periods of rapid scaling how do when it’s time to start splitting teams and dividing responsibilities?
- How do you scale that middle management in terms of ownership?
- Recommended Resources
*Questions and answers have been edited for clarity
How did Pluralsight evolve?
Pluralsight is the largest online technology learning company in the world. It builds amazing skills development courses and has 2000 authors that are all independent experts in their own domain. We video them in their context on how to build these product offerings, and people love their content.
Pluralsight was probably sub 100 employees in Q4 2014 / Q1 2015 which is when I really got to take the reins and start thinking about how to build a scaling product, and a scaling team. We had acquired either seven or eight companies but they were all working independently, generating their own revenue lines, and we really didn’t have a product management, user experience, or an engineering team. I think there were eight engineers at that point at that time, about 96/97 employees. We were sub 40 million in ARR, and it was really in its infancy. I think you could akin it to a startup culture. We were trying to figure out. We didn’t even have HR. Instead we had a culture coach to navigate employee issues. It was super fun. We didn’t have budgets, so it was a case of you decide what your domain is, build a team, and then go figure it out.
From there we had, David Platt was our first product manager, he was there just a few months before me. We had one UX designer and two PMs with Kyle and Mitch, Tony Corrado and David Platt that was the core and then you had like eight engineers or so. From there, we started to build what I would consider like an enterprise where we were primarily business to consumer. We had some business to business focus […] and from there it was well ‘how do we go build and scale?’.
One a human-centred team we really wanted to make sure that the customer breaks the tie. This wasn’t coming down from the top of the organisation, this was really a bottom-up build. And then we also had the influence of the leadership team to help and shape and influence our three year, and five-year strategy. And that was 2015 – we were just building and growing that team. By the end of 2015, we were 40 so we hired fairly quickly and that was engineering, product management, user experience design, and then we had our content organisation as well. All three of those organisations at that point in time were a separate entity, we had not combined them into what was called the experienced organisation. We were pretty immature on how to actually do product management, user experience design, or how to engineer our product offerings and so we really let the functional leaders be the domain experts and to help these teams grow and scale before we could really bring and codify those teams together.
How do you take seven or eight different cultures and merge them into one and build one organisation?
Psychological safety. I think this is what you have to know.
I’ll probably get really really ridiculed for saying this but building products candidly is easy. Building people and building teams is actually the hardest thing to do. It is in your ability to relate with other people and with other cultures – you have to transverse to other peoples’ worlds and to their experiences. You don’t have to do that indefinitely. Honestly, you only have to do that for 30 seconds to truly understand their truth, their world and their experience. And I think that’s the muscle that we really shaped well at Pluralsight, not only myself but the rest of my team. What we wanted to teach everyone is that in order for us to combine these teams and combine these cultures and combine these people, you have to understand or be able to relate with what their world was like. And from there we, we really really did a great job of I think bringing those teams together.
Within a senior leadership team, how do you convince people to really empower and trust teams?
The way I always frame my response to this is that as the leader, it’s you who is accountable and it’s you whose job it is to transform and bring teams together, and to manage across up and down the business.
It’s therefore really helpful to know where you are and your origin story. A lot of the things at Pluralsight were fairly immature, so we didn’t have well defined KPIs and metrics – we were like, ‘oh we’re a startup I can’t do this’. Well, the reason why you can’t do it is because you haven’t defined success criteria.
Our job is to create some success criteria, organise human beings around it and then stretch the teams to go achieve it. Sometimes it’s totally misdirected, not intentionally, but sometimes you just blow it completely. But then a lot of the time, the intention, and the behaviour and the feeling and the emotion of moving together, gets a lot of the team to gel.
And so at the management team level you have to communicate often – and when I say, often this is weekly.
This is every week in a town hall, to not only your team but the team that’s around you – marketing, sales, finance, everyone who’s around your circumference. You need to communicate to them all what you’re doing and what your strategy is. When you really think you’ve said it too much, that’s when people start to listen. That’s always a cliche statement but it’s so true, at least it has been for me.
I use this term KT Velocity which is Knowledge Transfer Velocity, and it really is dependent on how many humans you have in the business. When we were 40-50or 80-90 people, we transfer knowledge across the business so fast.
When you’re scaling quickly, it’s easy to mess up. How do you recover from mistakes and how do you rebuild trust?
When you openly make a mistake, I think ownership and accountability around that mistake is probably the most critical thing to get right, right out of the gate.
You have to acknowledge and own that mistake so that the whole team knows that you’ve stepped in it. Time and time again, I see mistakes getting swept under the rug. We ignore this big, ugly thing over here. We don’t address it. We move people through the pain of it, and it just becomes kind of festering over time. I think a really good indicator is that I have four sons, and I always like to give an analogy to my kids. If my kids continue to bring up things over and over and over again, it’s because I actually one haven’t heard them. I haven’t handled whatever it is and until I do that, we’re not going to get the family back on the same page. I see it the same way at big companies. At big companies, there are broader issues that we want to make sure we address head-on. We have to try and manage these leaders. I really think the most important thing is that you have to do is to let people know that you don’t know what you’re doing.
When you’re growing and scaling a team, there are a lot of decisions that you’re making in completely uncharted territory, and you just don’t know. So, I think as long as you’re well intended and you communicate your heart and your mind and what the vision of it all is, it just makes people a lot more calm. It’s about owning the fact and saying, ‘look we’re gonna go through this together’.
How do you scale trust in an organisation?
One, I was afforded the opportunity at Pluralsight to move my team from this place to another place, which I consider to be super lucky.
Two is that we started out as what I would consider a very raw product and technology. As you grow and scale through leadership, you actually have to put the tools down, and then allow those people to pick the tools up. Then you lead and manage. And I think what happens with leaders is a yo-yo – you go through this psychological strain of like needing to act like the leader that still knows how to use the hand tools and be credible on the ground. You need to be seen to be able to do these things but then to yo yo back up and manage across the business. I call this the Martha Stewart magic – you know, Martha Stewart can still bake you one of the best damn cookies you’ve ever eaten but she can also manage a billion-dollar company. I think it is a leader’s ability to know when to come down and bake a set of cookies and get into someone’s kitchen, but also to know when to fly back up and manage the business.
So, when you ask how to create trust culture – it was through leaders.
How did you transition from thinking about product all day to thinking about the culture of the team?
The nice thing about this session today is that we get to look at the Pluralsight success. What you don’t get to see is like an absolute disaster in the early part of my career, and the early part of my career was, being an EMT into building my own products, and then building my own products into my first startup. Then, I spent the first year and a half of that startup, drilling it into the ground, like dead bodies everywhere, I absolutely was a tyrant.
In fact, the actual phrase was a social anarchist. I just did not know how to build culture and I think the main reason why is that I was so emotionally spun into my own idea as a product manager that nobody else could have had a better idea than mine.
For example, I’d been working as an EMT in Salt Lake City, Utah, and I had to go into two-storey buildings where I didn’t want to carry patients down flights of stairs. So, I built this track system that mounted to the bottom of an ambulance cot – the point of the product offering was to reduce injuries and back pain.
Fast forward a couple of years and I was in New York City in front of a group of paramedics – my peers. I couldn’t wait to unveil this unbelievable invention. One of the first paramedics that popped out of the back of the ambulance looked at this ambulance cot and laughed me off this street. He was like, ‘dude, I can never use this, I live in brownstone apartments’. I said let’s give it a shot but we got halfway up a flight of stairs, and we had to come back out.
New York brownstone apartments, no way and Dakota’s winter temperatures are so low that the high-density polyethylene just shattered when you pulled it out of the back of the ambulance. I didn’t think about my customers or about any of the environmental conditions. I didn’t think about any of the behaviours that they use, all the stuff we’re supposed to think about. And then I was a tyrant to my team saying ‘no no no you can’t you can’t inject that idea, this is my idea’. I shut teams down for so long and as soon as I realised, at that moment, that was the moment I decided I wanted to dedicate my life to human-centred design, that the customer sits at the centre of everything we do and that the customer ultimately breaks the tie. During this time I really struggled. It took a year to recalibrate my own ego and to think ‘do I actually have what it takes to be someone that could build a scalable team and product. All of this was a super hard lesson for me to learn.
Do you need to fail in order to learn hard product leadership lessons?
Firstly, I wish I could rephrase failing as learning. Secondly, do you have to learn to succeed? Yes. 100%. Does it look like failure? Yep, it does. It looks like success looks like a lot of other things.
Again, I wish we could just try on failing as learning. The reason why is because failing and yes, I think you need to fail. If failing was reshaped as learning you wouldn’t make teams or yourself and others feel less. It’s already hard enough to organise human beings to go take down a product, but organising the behavioural and the cultural aspect of those teams through learning through failure, id actually like you’re trying to keep the team on the rails, all the time. It’s like saying ‘hey look, you’re good enough and that seems good enough’. It’s a blast to people’s egos and it is what we’re trained to do it’s what kind of we live for.
What are some proven steps to convert a team of mercenaries into an empowered, customer-focused team?
The analogy I give is about what it’s like when you’re a paramedic or an EMT.
You are called on all these situations and they were in the environment they were in. For example, I’d be working on motor vehicle accidents trying to start IVs on arms that I didn’t know if they were attached or not. And then I would bring this patient to the hospital, and the doctors like ‘what the hell dude, you blew their main artery in their left arm and this over here is a disaster and you didn’t really do spinal precautions’. I was like ‘hey, where I was when I did this was not in some controlled environment under air and lights, I was in a really tough environment’.
I want to set this as the mental model for the answer to this question and that answer is that when you make this decision, you better make sure that the mission, the vision, and the core values of this company align for you before you join it.
You can choose what you want to go do, even if it’s a single choice. We’ll write stories to ourselves like, ‘well, this is the only job I can get’ but where you get the strength to continue to, to evangelise, and to bring people along with you is when you’re totally bought into the company’s mission, vision, values and culture. You have to have a platinum spine too. To be able to navigate your truths, your world, and your experience to your teams, and that’s managing up to the board on the executive team, all the way down to individual contribution.
Individual contributors across the team, they can come to talk to you about any one of those issues that don’t work, and you as a leader have to emulate. Every step of those values, all the way through your entire tenure at that business. People watch you very closely. They listen to every word that you say and they want to make sure you don’t deviate or are inauthentic.
And I think that’s the way that you run the sturdy course. Like I said, early in my career was messy. I was so messy with my words, messy with my language, and then later in my career, I understood ok, the thread of consistency and the conviction to my own values (even if they were unpopular) we’re the material things that made a huge difference for me.
The last thing I’ll say is that every major leader that we’ve looked up to – RGB Gandhi, Martin Luther King – they are all people that are significant figureheads across the world. And, if you think about the moment at which they were leading the world, in my mind, I see millions of people running one direction, and I can just see Martin Luther King running the other way, against the grain. And that is what it feels like to be a leader. You have to be able to position yourself maybe against the popular vote.
In periods of rapid scaling how do when it’s time to start splitting teams and dividing responsibilities?
When to split teams and how to split teams is actually an architectural decision first. Essentially, if it’s a monolithic architecture or a microservices architecture, the decisions that I would make around team split is code sprawl. Like, can we actually manage the code and the customer base? We chose a microservices architecture, we were coming from a monolith and then we agreed that for six, eight or 10 engineers, and then a product management and user experience designer, we had data science and engineering – all of those pieces later. Then once the code base got unmanageable, outside of the four, we moved to six, moved to eight and moved to 10. Max was 10. Then, once the codebase was greater than 10, we decided to split the codebase up and those features or experiences that needed to be managed. Some of those things we just blew up or they were features that weren’t getting used. So we still used the metrics […] we were chunking, the most important parts of that codebase into these microservices environments and that’s how we made the team decision – architecture and data first, then the team side.
How do you scale that middle management in terms of ownership?
The first answer for me is, do you have a really good clear articulation of your customer personas? Do you actually understand the surface area of your product and who uses your product? You know, those cohorts of people that are producing ‘the core’ as I call it. The reason I called the core is that these are the most engaged users of our product. The second thing is, from there, what is the current state of the product? What does the future state of the product look like? Aa an example – Pluralsight were business to consumer and we wanted to go enterprise. Once we stepped out of enterprise, you know, apps, we wanted to extend our apps into platform as a service. This was not a customer facing UI. This was new emerging technology. How did we make those decisions? Well, we had to make those decisions based off the next three years and then where we wanted to break up and move those teams. That’s how we navigated those changes and it shouldn’t be any different than the first conversation we started with today, which is that of your product and your user base. Right? It’s full circle for me. I’m not going to have some new conversation at 400 million in ARR. No, it’s the same conversation – what products are we building? Who are we building them for? And do they love what we’re building? That should never change culturally throughout the whole place.
Recommended Resources
- Chasing Confidence: Transforming Ideas into Impact
- Improving Outcome Through Psychological Safety
- The Heartbeat of Product by Nate Walkingshaw
Comments 0