This article is part of our Stories of Tech Leadership series where we explore challenges, thoughts, and struggles of courageous leaders in technology.
Product Owner @ Cimpress
In my job, I do a lot of convincing - what we should work on, how to care about users more. It’s not always easy.
In one of my previous companies, I worked with audiologists. One of our developers was working on a new diagnostic system. As I watched his presentation, it became clear to me that it just wasn’t going to work. I knew this because I had already spent a lot of time in many audiology clinics . We had a conversation. I tried to tell him - can you imagine, can you put yourself in a situation where you have a patient talking to you and you’re not even looking at the screen? How would you see all these messages? I wasn’t really getting through, so in the end I said, let’s organize a test. I created a scenario, invited one of our in-house audiologist in, and asked the developer to be a fly on the wall and watch the audiologist use his system, in a simulated clinical setting. It didn’t go as well as the developer hoped. After the audiologist walked out of the room at the end, the developer turned to me and said “You had to pick the dumbest audiologist in the whole building!” I looked at him and I’m like “She’s got a PHD in audiology, she’s not dumb!”
I get this so many times, developers saying “Our users are stupid!” They’re not stupid - they just don’t think like you. Convincing developers to recognize that and to think more like users is really hard. It has to do with thinking in absolutes. A lot of us engineers like to have all our questions answered until we think we understand everything rationally.
When I was a developer, I was like that as well. I remember developing the front-end for this big project and I couldn’t get the answers I was looking for in terms of how to build it and how to design the UI. Both my line manager and project manager insisted that I just put something together quickly, but I refused. I was very clear that I just didn’t think this was going to fly - if nobody can answer my questions about the UI and how it will be used, then I’m not going to just slap something together. I must have made my line manager’s life hell, and honestly, I still don’t know why they didn’t fire me.
Nowadays I encounter developers who are like I was back then. I’m still a bit hard-headed too. As a product owner, I work in a collaborative way, where I might prioritize something, but I like us all to agree on the why. With some teams, it’s really straight forward, in other teams there’s more back and forth, more negotiations. And it’s fine because they can convince me to change my mind too.
Teams I currently work with are all different, their cultures are very different, what motivates them is very different. It’s been a big learning for me, having to apply different modes of motivation to convince people. It’s a good challenge, even though it’s frustrating at times.
In one team, team members care very much that they’re adding defined value, so when talking to them, I make sure whatever they’re working on contributes to our key results (OKRs). It’s one of the easiest teams to work with. Another team has people who don’t agree with the key results, they say that “OKRs are too vague”. So I can’t use that method of convincing, and instead focus on what the gaps are between what we both want and take it from there. With one of the team leads, when I come to him with a great new idea, he usually questions for the completeness of the solution and the edge cases - so we have to convince each other whether there’s enough information to begin with, and it slows everything down.
I’ve been asked by my manager at various times to show more authority, to just tell the teams what to do. Sometimes I’m perceived as soft, that I listen too much to my tech leads. But in the long term, I really wish for the teams to be passionate about the product, and care about it. I don’t think I’m going to achieve that by simply telling them what to do.
I also don’t think I should have the only say in a product, because ultimately it’s the team who maintains it. I convince them what to work on, but if they tell me that the system is going to break down, I’m going to listen to them. While I know my product, it’s the team who knows their health and technology best. I know my limitations and I really trust the leads on my teams, so when they say “We need to spend 2 weeks to address performance issues”, I tend not to argue with them on that although I may question it.
I’m really lucky that my teams have very mature team leads, and that’s one reason why I trust them. If you’re a product owner for a very junior team, then the dynamics are a lot different. If that was the case for me, I probably would go more for a project management type of approach and direct the teams more. Right now, I don’t pull any rank because I don’t need to.
Truth is, there’s pretty much some form of convincing, a negotiation in almost every human interaction. It’s just that the flavor of negotiation can be different. You have to know who you’re negotiating with, know what makes them tick and know what they value. It’s about getting a baseline for common understanding. Motivating developers to care about users is also a form of convincing, long-term convincing, because while user-centricity should apply to everyone, it means different things for different people.
Have any stories to share? Reach out to email@example.com to get featured on our blog!