Building a Culture of Ownership and User Empathy

Problem

A couple of years back, I moved to Singapore, which was my first job outside Silicon Valley. I joined a company that was the Uber of SouthEast Asia; therefore, my past experience at Uber was exceedingly valuable. I took over a marketplace engineering team that consisted of three teams, each prospectively responsible for pricing strategy, supply shaping, and demand shaping.

As soon as I took over the team totaling 45 people, I learned that there was no sense of ownership or user empathy and that people on the team were completely disconnected from end-users. That was in stark contrast to what I was experiencing in Silicon Valley, where people were passionate about their product(s), opinionated, eager to advocate for and push back different solutions. In my new company, no one would even challenge my proposal.

Furthermore, I witnessed an acrimonious tension between the engineering team on one side and the data analytics and business operations team on the other. As cross-functional non-technical teams, they were well-versed in understanding different aspects of the market, but their knowledge was of no use because of the petty quarrels between the teams.

Actions taken

For starters, I had a lengthy conversation with a UX manager who explained to me how they would conduct user studies in a controlled environment. They would be traveling across the region and recruiting participants who would come to our office to participate in their surveys. I didn’t find a controlled environment particularly appealing and wanted to do something different. After discussing the problem far and wide, we decided to do an immersion followed by a hackathon.

I paired up members of all non-tech cross-functional teams with members of my team and then split them, as it turned out, into 21 small groups equally distributing technical and non-technical people. Since we were operating in seven major cities of Southeast Asia, groups have been dispersed across the region to cover all of those seven major cities. Then I tasked all of them to do a guerilla-style immersion in these seven cities. No controlled environment, no predictable answers.

I paired them carefully to have at least one local speaker in each group. Then I instructed them to go to malls, restaurants, bus terminals, and everywhere else where they could stumble across our users. They would have to approach at least five of our users and ask them a set of questions. I handed them a list of marketplace-related questions that should help them frame their conversation.

After they would complete their field investigation and would come back, they would submit their findings. Following on that, we organized a hackathon to provide them with an opportunity to develop and implement their solutions based on practical ideas that would improve the lives of users they had met during the immersion.  

At first, I encountered quite a resistance. Some people claimed that they were shy or introverts, but I would be okay if they would just tag along since what I cared about was for them to connect with users. However, I was beyond pleased with their results. Every single proposal of theirs was actionable and could improve user experience. For example, a group that went to Jakarta learned that a delivery person would pay a parking fee and proposed that the company manage the issue. A group that went to Thailand saw firsthand how small delivery scooters were and proposed redesigning their food-carrying bags.

Finally, besides the empathy towards users, people from different teams also started to develop empathy toward other people in their group. After some time spent together, they started to better understand what each function was doing and what their pain points were. In addition, they also understood the product and business much better. As a result, from then on, people became more vocal and passionate about their ideas. In heated discussions that started to be associated with our quarterly planning, people started to refer to their field experience and close interaction with end-users to defend or reject a proposal.

Lessons learned

• By focusing on developing ownership around key marketplace challenges, we tangentially strengthen cross-team collaboration and empathy towards people on other teams. That made everything else possible.
• Perhaps, I came too late to nip the problem in its bud. If it was identified earlier, efforts could be made to make the team more engaged in the planning process instead of telling them what to do. But, a couple of quarters later, we were able to correct that, and they became rather involved in the planning.
• I am a big believer in an approach “Make your problem, their problem,” that engages people to “feel” as their own a problem they are working to solve. When a PM joins a team and starts telling the rest of the team what should be implemented, that fails there and then.
• Having a clearly defined team charter is critical. Though team members went to the ground and got to know users, they were not aware of where the team was going in terms of its strategic orientation. Many of them thought that what they were doing was writing some algorithms that would spit out pricing. I wanted them to understand how what they did, impacted the livelihoods of the drivers and other users. That mission has to be imprinted in the charter so each person on the team knows how important their work is.
• Empower people on the team to make decisions, push back, propose… Give them all the insights about the product they would need to know, and empower them to react. Earlier they would only do what they have been told to do. I empowered them to disagree and push back, challenge my proposal and thus arrive at the best solution possible.