It’s no secret that engineers can be hesitant to participate in product trios. They might feel anxious about taking on tasks that are new to them and outside their regular routine at work, like speaking directly with customers. They might fear that any time not spent coding is time when their technical skills are falling behind. Or they might question how doing discovery is going to serve their short and long-term career ambitions.
But just because you encounter some initial resistance when trying something new, that doesn’t mean that it’s not worth doing.
Just because you encounter some initial resistance when trying something new, that doesn’t mean that it’s not worth doing. – Tweet This
Today’s Product in Practice demonstrates how important it is to understand why people might be resistant to making a change and why having the right culture in place creates an environment where overcoming this resistance is possible.
We’ll hear from several members of the product team at Ramsey Solutions about their not-so-smooth transition to working in product trios, especially when it came to getting engineers to participate. We’ll dig into why the engineers were hesitant to get involved, the solution they came up with, and some of the lessons they’ve learned along the way.
Do you have a Product in Practice story you’d like to share? You can submit yours here.
Intro to Ramsey Solutions
Ramsey Solutions provides common-sense education about money and personal finance. You may be familiar with some of their media such as radio shows, podcasts, and books, or their tools like the EveryDollar budgeting app. The overarching goal of Ramsey Solutions products?
To help people win with money.
Within Ramsey Solutions, there is a department called RamseyTrusted that works as a two-sided marketplace connecting Ramsey’s fans to vetted pros. They define “fans” as the people who engage with the radio shows and podcasts and “pros” as the vetted professionals who give advice that’s consistent with what Ramsey Solutions teaches.
Pros can come from various backgrounds and industries. Ramsey Solutions has opinions about how people should go about selling a home, purchasing insurance, or investing. For each of those areas, they work with a network of providers whose philosophy aligns with Ramsey Solutions’ teachings.
For example, their network of realtors will give advice that’s consistent with what they teach and won’t encourage fans to buy homes they can’t afford. Similarly, their network of insurance providers will not sell insurance products that Ramsey Solutions does not recommend because the company believes they’re not in the fans’ best interest.
Putting this all together, Sergio Cruz, Senior Director of Software Engineering, says, “We create experiences that connect our fans with our pros, taking into account our fans’ desires and our pros’ constraints.”
Meet the Continuous Discovery Champions at Ramsey Solutions
The product team at Ramsey Solutions is 40+ squads strong. Each squad consists of four to five engineers and a product trio made up of a product manager, a designer, and an engineer. Some squads have additional designers who focus on design work that falls outside of discovery.
Our continuous discovery champions for this story work within RamseyTrusted, the two-sided marketplace we mentioned earlier that connects fans with vetted pros who help them walk the path of financial security in their insurance, taxes, and real estate.
You’ll hear from Sergio Cruz, Senior Director of Software Engineering and leader of this squad, as well as every current and former member of the product trio: Product Manager Tim Montie, Tech Lead (at the time of writing) Justin Leggett, Product Designer Kristy Sullivan, and Josh Friend, who was the Tech Lead prior to Justin.
From left to right, Sergio Cruz – Senior Director of Software Engineering, Tim Montie – Product Manager, Justin Leggett – Tech Lead, Kristy Sullivan – Product Designer, and Josh Friend – former Tech Lead in the product trio
A Quick Overview of Continuous Discovery at Ramsey Solutions
At Ramsey Solutions, the initial inspiration to adopt continuous discovery came from product and engineering leadership. The Head of Product Coaching Matthew Ensor and CTO Brendan Wovchko partnered up and decided this was the way they wanted their teams to work together.
The company brought in Marty Cagan’s team to do some training and required all product squad members and leaders to read Continuous Discovery Habits. Sergio says this was really an inflection point when it came to putting continuous discovery into practice: “Things really went to the next level when Teresa’s content was introduced to us because it became much more practical. There’s a framework. It’s not prescriptive to the point where there’s no room for creativity—it’s the opposite of that—but we knew the steps to take to do product in a healthy way.”
Continuous discovery really went to the next level when Teresa’s content was introduced to us because it became much more practical. There’s a framework. – Tweet This
Because Teresa is a strong proponent of working in product trios, they knew they wanted to start organizing their teams that way. But it wasn’t quite that simple.
The Challenge: Engineers Were Resistant to Take the Role as Tech Lead in the Product Trio
Sergio says they initially believed that the tech lead role would be permanent, based on how it’s defined in Marty Cagan’s book, Inspired. But when they took this approach, they encountered some resistance from engineers.
At this point, it’s worth looking a little more closely at what it means to take on the tech lead role in a product trio at Ramsey Solutions. Sergio explains that engineers who are tech leads dedicate the majority of their time to discovery work. “They are primarily responsible for discovery along with the rest of the trio, occasionally shipping code to production to help with delivery. There are natural ebbs and flows in discovery activities, so when they’re in between discovery tasks or things like that, they’re still a normal engineer like anyone else, but their primary responsibility is to be involved with discovery.”
Because Ramsey Solutions encourages open communication (we’ll talk more about that a little later), one of the tech leads from a different squad in the division told Sergio that he had started to miss the growth of engineering. After he’d been tech lead for over a year, he said that while he loved having the chance to work closely with customers as part of the trio, the code base was evolving so fast that he was having a hard time keeping up.
Whenever Sergio would discuss the possibility of taking on the tech lead role with other engineers, he’d hear one of two responses: Either the engineer was really into it or they weren’t interested at all.
Sergio wanted to understand why tech lead had turned into such a polarizing role, so he continued speaking to more engineers about it. Through these discussions, he had a few realizations.
After speaking with several engineers, Sergio started to understand why there was resistance to joining the product trio.
First, the term “tech lead” itself was somewhat confusing to the engineers at Ramsey Solutions. “People were seeing some hierarchy that we really didn’t want to be there that was associated with the title. It doesn’t actually imply that you’re leading the team, but it was starting to be understood that way,” says Sergio.
But Sergio didn’t want people to take the role because they thought they’d be gaining more authority. “I wanted people to do it with the right motivation. I wanted them to do it because they wanted to be part of that trio, they wanted to be doing discovery, they wanted to be very empathetic towards our customers, but not because it would be leading the charge.”
I wanted people to join a product trio because they were motivated to be part of it, they wanted to be doing discovery, they wanted to be very empathetic towards our customers. – Tweet This
However, this wasn’t the only reason why engineers were hesitant to step into the role. Through his conversations with engineers, Sergio also began to realize that engineers viewed the decision to become tech lead as a fork in the road career-wise. He says, “It felt like, if I start doing this thing, then some number of years from now, I won’t be able to become a senior. I won’t be able to become a principal. I won’t be able to become a staff engineer.”
Because technology moves at such a fast pace, engineers were worried that it was an either/or decision—if they focused on discovery skills like interviewing customers and mapping opportunities, it would be at the expense of developing their hard technical skills.
At this point, let’s take a brief interlude to hear from Justin Leggett, an engineer who’s currently in the tech lead role on Sergio’s team. Justin was willing to openly share some of his concerns when Sergio approached him about becoming tech lead.
Justin says there were a few reasons why he didn’t automatically jump at the opportunity to become tech lead. “My resistance mostly comes from the fact that I really like engineering and I’ve been doing it for five years. It’s definitely been a little scary to have this conversation that I would do engineering at a different level and focus more on communicating with people and wrestling through problems as a trio.”
The Aha Moment: Turning a One-Way Door Decision Into a Two-Way Door Decision
Conversations like the one he had with Justin led Sergio to a realization: For engineers, taking the tech lead role felt like an irreversible, one-way door decision.
If they could remove that feeling, maybe engineers would be more willing to try out participating in a trio and be able to enjoy the benefits of that experience.
Sergio says, “It felt like a fork in the road. It felt like a big decision. So we started asking, ‘How do we make it not feel like a big decision?’ And we decided that instead of it being a role, it could be a hat that someone’s wearing.”
He continues, “For these engineers, they’ve had a whole career in engineering, and we’re asking them to work in a completely different way, so I completely understand where they’re coming from. The idea of rotation is instead of trying to fight that perspective, let’s just embrace it and work within it, because there’s some merit to it as well.”
It took some thinking to land on the right tenure for the tech lead role. Sergio explains, “There’s a lot of value that comes from trust. There’s a lot of value that comes from them having that shared context and having been through those customer interviews together and riffing off of each other when they’re maintaining the opportunity solution tree (OST). I didn’t want somebody changing that hat every day or every week. That didn’t feel productive, but once a quarter, once every other quarter felt more sustainable.”
There’s a lot of value that comes from trios having shared context and having been through customer interviews together and riffing off of each other when they’re maintaining the opportunity solution tree. – Tweet This
Reflecting on this evolution, Sergio says, “We have changed how we think about the permanence of the design and engineering roles in the trio. While durability is important, we focus on durability at the squad level. We believe that having a healthy, durable squad (in which the trio exists) creates the opportunity to rotate out the two roles with minimal negative impact. Because the squad around the trio is durable and participates in the discovery process, the cost of ramping the new trio member up is minimal, and the benefits are worth it.”
There was another bonus of introducing this idea of rotating into and out of the tech lead role. Sergio says, “It removes that hierarchy type of concern because everyone gets to practice it. Everyone gets the opportunity to do it, but we’re still promoting that durability within the sqad, so it checked a lot of boxes.”
And for Justin, this was what ultimately convinced him to say yes. He explains, “The unlock for me was when Sergio said, ‘You don’t have to do this forever. You can just do this for three months, six months, whatever, and we can figure out if this is something you want to do.’ That was a huge unlock because before it felt like a door that once I walked through, I really didn’t have a choice. If I walked through the door and I didn’t like it, my career would have taken an irreversible turn and I may have to keep doing the thing that maybe I don’t really want to do on a day-to-day basis.”
Experimenting with the First Tech Lead and Passing the Torch to the Next One
How did it actually work to rotate tech leads in and out of this role? For the next part of the story, we’ll catch up with Josh Friend, the engineer who was the first one to step in as tech lead.
Josh explains that prior to adopting continuous discovery, it’s hard to even remember how they approached their work. As best as he can recall, they’d simply opt to pursue anything that sounded like a good idea or anything a customer requested.
As the trio started to adopt more of a discovery approach, he says, “It was a lot of learning and figuring out how to apply what’s in Continuous Discovery Habits to our discovery process.”
Many of these early tasks were things like getting involved in customer interviews and conversations with the third-party providers Ramsey Solutions works with.
They also began to run small tests to learn how customers would respond in different situations. Josh continues, “This led to me finding ways to build something in production that did not impact our actual delivery work—either something like Optimizely Web or Hotjar—and talking with the rest of the trio about what was technically possible or not.”
Some of his other early tasks in the trio involved doing research into the data they had available and learning how to query databases. “We have a data analyst and I was working with him trying to learn some of the things that he did so that in one-off conversations we could do quick data research items,” says Josh.
Sergio says that having durability on the squad level through regular meetings and touch points makes it possible to rotate members out of the trio with minimal impact.
In the early stages, Josh says the trio was also learning how best to work together and what sort of cadence to give their discovery work. “There was a lot of learning to align calendars. For a while, I think we were doing two hours a week of discovery. That was too little. Then Sergio gave us a goal of 12 hours a week of full-on discovery time. And that was too much. Eventually we learned that we can actually split out some of these things and we didn’t all have to be together for some of that work.”
There was a lot of learning to align calendars. For a while, I think we were doing two hours a week of discovery. That was too little. Then we had a goal of 12 hours a week. And that was too much. – Tweet This
Now let’s hear from Tim Montie, the product manager who has been with this trio the whole time. Here’s how he characterizes Josh’s time as tech lead: “I think of it as two chapters. In the first chapter, we were just closing all the gaps so that we could do discovery at all. Josh as an engineer was uniquely positioned to help us close those gaps of data and integrations. Then, we had all the resources in place to actually do the discovery work in the next chapter.”
Describing some of the work he did once they actually got into discovery, Josh says, “We had gotten seven layers deep into assumption testing on this one critical assumption. Kristy and Tim and I had done some work on how we could actually ask customers this question to know if we could know it. And we just wrote up some quick questions, we built it in Hotjar, and it turned out that 90% of people filled out all the questions. So then the next step was to try to de-risk it by building a prototype of it and seeing if we could have these questions earlier in the process.”
At this stage, because the trio had gotten to the point where they were working well together and making progress, they’d invited Justin to start shadowing Josh with the idea that he’d eventually take over as the next tech lead. So Justin added some more features to this prototype that wasn’t in production or the normal code. This allowed them to run another assumption test to reduce a critical business viability risk. Josh says this was part of the warm hand-off where he transitioned his tech lead duties to Justin.
Sergio says that at the time, they were imagining that the tech lead to step into the role after Josh would be taking that role on permanently. That’s part of the reason why they felt the warm hand-off was so important: “We’d do a warm hand-off so that the discovery work continues and the trail doesn’t stop.”
But this was when those fork in the road career conversations began to surface. Justin wasn’t sure he wanted to permanently alter his career trajectory by becoming a discovery engineer. So Sergio came up with the solution of making the tech lead role temporary.
Justin says this is what convinced him to participate in the rotation. “The idea that it wasn’t permanent was what unlocked it for me. I realized this was just a thing I could try and see if I enjoyed.”
Justin also took the opportunity to reread Continuous Discovery Habits at this stage. He explains, “I read Continuous Discovery Habits when I was just an engineer on this team. And if I’m being really honest, when I read that book the first time I was like, oh, this is a book for the people in the trio. I’ll read it because my company’s asked me to, but I can’t say that I got a ton out of it the first time I read it. And then when Sergio and Josh started talking to me about becoming a member of the trio, I read it again because I had a fresh perspective on it. It was a great experience to have Josh as my guide to explain how we’ve interpreted things and how we’re doing it here at Ramsey.”
Why did Sergio think it made sense to rotate Justin in as tech lead? He had faith that the combination of Josh’s guidance and the fact that Justin already had a lot of context from being part of the same squad would make it possible.
Sergio explains, “It’s the engineers within that squad who are getting to practice the tech lead role, which is different from, ‘Oh, new person that I’ve never met, let’s try to go do some deep work together.’ No, like there’s tons of context that’s still shared with the rest of the squads and you’re not starting from scratch at that time.”
Josh agrees this is a critical point. “We’re actually embedded in the squad. We also do a weekly kickoff where we set some goals and we also share all of the context from discovery with the whole team and ask questions about where things are at, what you learned last week, and what you’re doing this week.”
Justin is candid about the fact that it hasn’t always been easy. “It still has its bumps. I’ve worked with many of these people for five years now, but there was still a little bit of a transition from me going from an individual contributor that’s just writing the code to exercising these people skills and wrestling through problems and solving them together. It’s stretched me to places that I never knew I could stretch. But so far it’s just been a joy. It’s been fun.”
Key Learnings and Takeaways
First and foremost, Sergio stresses that the team considers their approach to product trios a work in progress. “It’s a gigantic experiment and it’s easy to sit here and sound like we all know what we’re talking about, but the reality is we’re still learning.”
That said, Sergio and the product trio members had a few learnings and takeaways they wanted to share.
You have to be intellectually honest about the cost of the rotation.
Tim cautions that it does take time (and therefore money) to get new product trio members up to speed. “It’s not free. It’s not like there’s not going to be any difference between this and just having the same engineer in the trio all the time.” Because they’ve only gone through one hand-over so far, Tim believes there’s a lot to be learned about how to smooth this transition and accelerate ramp-up time for the new tech lead. But ultimately, he does believe the benefits outweigh the cost: “We are making a trade-off here on purpose because we believe that the net gain is going to be greater than the cost.”
We are making a trade-off here on purpose (having tech leads rotate in and out of the product trio) because we believe that the net gain is going to be greater than the cost. – Tweet This
The tech lead rotation would fail miserably without a really well-connected team.
Tim says that the sense of cohesion on their entire product squad is a huge reason for their success in this experiment. “You cannot do this if you don’t first have a healthy team that understands how to work together and knows each other’s strengths and weaknesses.”
He believes this foundation helps compensate for the bumps you’re likely to experience when rotating members in and out. “The squad that we work with, I feel no closer to Justin and Kristy than I feel with any of the members of our team. The only reason that I—as the only member who won’t rotate out of the trio—feel it’s worth it is because we’ve already included the rest of the squad in the discovery process. We think of the squad as the chief problem solvers and the trio as the chief problem finders, but we’re always sharing insights with them, including them in customer calls, etc. This means when we do the changeover, it can be pretty quick—it’s just a matter of context switching from ‘I’m primarily delivery’ to ‘I’m primarily doing the discovery work now.’”
We think of the product squad as the chief problem solvers and the product trio as the chief problem finders. – Tweet This
There’s a lot of work that goes into building a strong, healthy team.
“It will 100% break if you don’t focus on the squad being healthy that’s around the trio first,” reiterates Tim. But how do you build a healthy team to begin with? Sergio says their squad regularly refers to The Five Dysfunctions of a Team by Patrick Lencioni. They revisit the book as a team a couple of times a year, which helps ensure that they’re willing to have healthy conflict that’s based on ideas rather than personality.
“The weekly kickoff they do leads to accountability. And the accountability leads to an attention to the collective results of the team,” says Sergio. Kristy believes that Sergio’s commitment to team building with regular meetings—like their weekly Thursday breakfast—has had a huge impact on the sense of trust. “We talk about things going on outside of work, we talk about things going on in our families and everything else. And that actually helps us have empathy for one another.”
The product squad meets weekly, which is an important ritual for committing to their goals and sharing their progress.
Here’s Tim’s take: What are the signs that you have a healthy team?
- There’s healthy conflict where people don’t come away from it feeling backstabbed.
- There’s a mutual ownership of results.
- Everybody knows what’s going on.
- There’s accountability.
- People feel safe to ask questions.
Sergio sums it up by saying, “It’s worth it to invest in the team, because a team that’s healthy gets a lot done.”
Are you new to the product trio concept? You can learn more about why teams are shifting from working in silos to a more cross-functional collaborative approach with product trios in our comprehensive guide.
The post Product in Practice: Why Ramsey Solutions Rotates Engineers in Their Product Trios appeared first on Product Talk.
Product in Practice: Why Ramsey Solutions Rotates Engineers in Their Product Trios was first posted on August 14, 2024 at 6:00 am.
© 2024 Product Talk. Use of this feed is for personal, non-commercial use only. If you are reading this article anywhere other than your RSS feed reader or your email inbox, then this site is guilty of copyright infringement. Please let us know at support@producttalk.org.
