Ryan Salsman is Vice President of Digital Product at West Shore Home, a technology-enabled home improvement company. He began his career as a software engineer at ZEMNOTT and Key Systems North America before moving to Design Center Inc., a strategic technology solutions and digital transformation company. At Design Center, Ryan transitioned to operations and product-oriented roles and, after a decade-long tenure, moved to West Shore Home.
Ryan sits down with us and discusses his leadership principle of “optimizing for happiness” and how he realized, stemming from his own life, that maximizing employee happiness at work yields the best results. He shares his “Workplace Bill of Rights” — a framework for his team to guide decision-making in the workplace — and how it gives people autonomy within that structure. Ryan also talks about how rituals at work play a key part in optimizing for happiness and building a great team culture.
Our goal is to become America’s most admired home remodeling brand. My role is to remodel the digital customer experience, and that’s what we’re doing. We’re building products and tools to not only improve our internal operations, but give our customers a better experience in the home, on the website, and for the full scale of their customer experience. This will allow us to scale in a predictable manner down the road.
One of our biggest differentiators is that we don’t subcontract any of our work. This allows us to control the quality from the start to the finish. From beginning to end, we control the whole experience, and that allows us to do a lot of things that our competitors can’t.
I work better when I’m happy. I think everyone does. As a company, we get the most out of people when they’re happy and their day is filled with activities that match their personal needs and motivations. So, happy people perform better. There are fewer interpersonal conflicts — especially when there’s change, which, in the modern age, we see daily. Overall, the quality of the software and the product that we’re creating improves as well. The proof’s in the pudding.
Something I look at is our retention rate. Our average tenure is about five years. Overall, if people weren’t happy, they wouldn’t be here and they wouldn’t stay here that long.
This philosophy came from my realization of my own life. I spend a third of my life sleeping and then another third at work. If I’m trying to get the most out of life and the most out of the time we have, I think I should enjoy the people I work with. And then it cascades to them.
The biggest challenge that I’ve had was when we were acquired a year and a half ago. Change is hard, regardless of what change it is. But telling a tight-knit group that they’re going to work for someone else now if they want to keep their job was a real challenge. Not only that, we were given a challenging project to build. We replaced the tools that everyone was used to. We had to learn the new business and build new relationships. We had to scale the team and the project that we were working on needed an amount of people working on it that we weren’t used to. I learned a lot about myself in the last year and a half. It was equal parts rewarding and challenging.
Fortunately, we were used to doing that work. And we were used to dealing with ambiguous requests and changes. On the product side, we’d sort of been “forged in fire.” The real challenge was integrating into the new culture and changing every process. There wasn’t anything that didn’t change for everyone. And then in the background, the product was changing too.
One of the first things I did was map our old core values to our new core values to show people that even though they are different, there’s some strong overlap. For example, our old company was great at just being accountable for things, but we didn’t have a core value there that said we’re accountable. And in the new company, there’s a core value of extreme ownership. Those two things actually mesh well together. So, while it wasn’t perfect, I made my best effort to try to show people that we’re not really that different at all. I also made time for intentional activities to induct people into the new system, the new core values, and things like that. It’s still ongoing.
The Workplace Bill of Rights was a response to a problem that I wasn’t keen on solving in the way that it was presented to me. We were all going to come into a new office that was designed and created for us. We were going to work a few days a week in the new office, and, of course, with COVID and everyone working remotely or hybrid, we hadn’t all worked together. We had lots of new people, a new space, etc. I was getting peppered with questions like, “Are you going to make sure people clean up?” and “Are you going to make sure people wash their dishes?”
It was a list of rules that people wanted me to put out there. But no one wants to be told a list of things they can or can’t do, so I used the theory of Jobs-to-be-Done. The first step in that is to figure out what that job is. In this case, it was to communicate that, as a group, we have a duty to treat our members with respect and allow them to thrive within the environment that they’re working in. But a list of rules isn’t really the best way of doing that. So I came up with the Workplace Bill of Rights.
It provides everyone with a framework for making their own decisions. It’s not about rules, it’s about how someone has a right to a clean workspace. Someone has the right to focus, so if you’re talking next to them, don’t. Someone has a right to collaborate. Some of these bubble into each other in the real world, so providing that framework lets people make their own decisions and have autonomy within that structure. It’s not to say that we never have to make rules, but I can back them by saying, “This is an infringement of this specific right.” It’s worked well so far.
Incentives drive behavior, but the wrong incentives can drive the wrong behavior, despite having the best of intentions. You could track this number thinking it’s going to be a proof of success, performance, or productivity, but because humans are human, they’ll figure out how to make a number look, which might have the opposite impact.
A really great example is a software company that had new leadership. They decided they were going to give money to people if they closed a bug. They hoped to improve the quality of the software — fewer issues, fewer defects. What happened was that instead of fixing the bugs during software development, devs would have a fix ready but push the code live with the bug. They would coordinate with a tester so that they both could share the reward when they “fixed” the bug they had already known about.
That’s anecdotal, but I prefer, to the highest extent possible, objective software quality metrics. For our software team, that means I look at code coverage. For quality assurance, it’s escape defects. And for product management and design, it’s both internal and external customer satisfaction. We also look at business metrics for the product itself. Obviously, we want to see those business metrics improve, but if they don’t, it’s not the fault of the people doing the work. It’s that our assumptions were wrong or something else was wrong, and we need to iterate.
I try to avoid decision by consensus. It’s hard enough to get two people to agree on where to go to dinner, much less, “Let’s all decide what we’re going to do for this brand-new product.” That’s really difficult when writing software, especially when requirements change.
I read a book recently called Crucial Conversations that defines four types of decision-making: command, consult, vote, and consensus. And we’ve found a lot of success in describing the process of making the decision at the beginning. Ultimately, it’s really difficult to get everyone to agree. You have to hear everyone out. And if you have to make a decision, everyone has to leave the room and back that decision.
There are very few times we use command, but sometimes it’s necessary. There’s also a time and a place for voting and consensus. But most of the decisions that I make are consultation decisions. I like to make sure I hear out everyone who has an opinion and will be affected by the decision, weigh all the options, and then decide.
That’s actually one of the harder things I’ve had to learn as a leader: sometimes, you just have to make the decision. And sometimes, in front of you are what you believe are wrong decisions. But, for the good of the team, you need to make the decision and own the results. If you’re wrong, you have to own that. But action is better. I think consensus can get in the way and inhibit action. In the scope of product development, it’s better to make a decision, learn, and then iterate.
One of the most influential books I’ve ever read was Getting Things Done (GTD) by David Allen. And I’m very rigorous in the tasks I take on and commit to, as well as how I prioritize those tasks. I make sure people understand that’s how I work. I follow a lot of the core GTD principles. The biggest one for me is that the mind is for having ideas and not holding them. So, my goal is to get every thought and every task out of my brain and focus on one task at a time.
That’s been very successful for me, regardless of what I’m doing. Because your mind is constantly trying to make sure you remember this thing. It’s tugging at your brain. David Allen calls them open loops. So it’s about getting all those things out. Now your brain is free to focus on the task at hand. And that applies to any task. Anything at all.
I think the biggest thing is the importance of rituals in building a strong workplace culture. While I do enjoy the taste of nice craft beer, it’s not about the beer so much as the ritual that surrounds the experience, like getting to the brewery and looking at all the beers, ordering, the pour, talking with people, etc. The whole ritual is what interests me. And rituals at work play a key part in building that optimization for happiness and workplace culture that we’re aiming for. It provides a sense of belonging that you’re a part of this new thing. And it also can indicate the group’s values.
If you have a fun ritual that you’re doing at the start of standup, you can show that we like to have fun even though we’re serious. Another company may have a different ritual that reflects that they’re really tactical and don’t mess around. Neither of those is right or wrong, but it’s important to communicate to the leaders — whether they’re people managers, culture leaders, scrum masters, etc. — to communicate the roles that rituals play. Show people the existing ones and what the intention was behind them so that they can implement them with their own intentions and goals, and we can all serve each other’s needs.
We do nominations after each sprint retrospective for a sprint hero. Anyone can nominate anyone for anything. And we have a somewhat objective process to select a sprint hero. Then at the next weekly meeting, we announce the sprint hero from the past week. And we play a new song each week. People listen to the song and then we say, “So-and-so won sprint hero.” We give that person a special background that they can use in Teams. For two weeks, they can rep that.
The intention behind that works into the optimized for happiness thing. We have a strong culture of recognition. We have lots of mechanisms to recognize people for their contributions to the team, both long and short-term. And that’s one of our real difference-makers.
There’s an old-school mentality that you shouldn’t reward people just for doing their job. And I think that’s really outdated. It costs nothing to tell people they’re doing a good job, and it has an outsized benefit. Recognition is free and it should be a leader’s primary resource. It’s bottomless. You can use it as much as you want.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Value has many forms outside of the exchange of money for products/services. It can be in the form of saving time, increasing revenue, etc.
Concept evaluation bridges the gap between what seems like an out-of-the-world idea and what users truly need.
Nick Ehle talks about minimizing dependencies by designing teams and organizations to be as empowered as possible.
Value-based pricing is about using the perceived value, also referred to as willingness-to-pay, to set the right price points for the product.
Learn more →
