This is part 5 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3, part 4.
What we’ve covered up to now is how the ways in which we define success don’t work, or break down when they come into contact with other people and their definitions of success. It’s okay to be despondent at this point – me too.
One thing we haven’t talked much about until this point is company success. If we want to stay employed, we hope the company we work for will be successful. When a company does one thing, in a very focused way, company is like a superset of team. We can go through the same exercise.
As companies get bigger, and do more things, the company becomes the context. The processes become more relevant to individuals and small teams than the mission.
(which is why you need to be very careful what they are)
“My first denied promotion taught me the wrong lesson. I thought I could keep doing the same work but package it to look good for the promotion committee. I should have done the opposite: figure out what the promotion committee wants, and do that work exclusively.
I adopted a new strategy. Before starting any task, I asked myself whether it would help my case for promotion. If the answer was no, I didn’t do it.
My quality bar for code dropped from, “Will we be able to maintain this for the next 5 years?” to, “Can this last until I’m promoted?” I didn’t file or fix any bugs unless they risked my project’s launch. I wriggled out of all responsibilities for maintenance work. I stopped volunteering for campus recruiting events. I went from conducting one or two interviews per week to zero.”
~Michael Lynch, Why I Quit Google to Work for Myself
I’m sympathetic to this guy’s conclusions – the post is a story of how someone wanted to be a diligent engineer and a good teammate, but the promotion system, and their personal desire for promotion (and recognition!) meant what they personally felt incentivized to do made them a bad teammate. You don’t want to work with that person, and you don’t want to be that person. But this is what the system told them “success” looked like.
Running engineering teams like this definitely impacts product – which impacts users too. For internal users whose service becomes unreliable or unmaintained once someone gets promoted (or because it won’t help someone get promoted), or external users who live with things that aren’t great, because improving or fixing them is not promotion worthy – so no-one wants to do it.
The end of this story, by the way, is that he figured out how to play the system, got great review scores… but his teams kept getting re-organized which made promotion impossible – and that wasn’t a gameable system. So he quit.
One of the reason why I was looking to see how many articles mentioned users in my research around teams is that studies show that people are more motivated when they see how their work impacts real people. Fundraisers for scholarship donations were more motivated when they had contact with scholarship recipients. Lifeguards were more vigilant after reading studies about people whose lives had been saved by lifeguards. When cooks see who will be eating their food, they feel more motivated and work harder.
Are we doing that in development teams? Well if we are, we don’t seem to be talking about it that much. I ask everyone I interview if they have any experience with user testing, and the overwhelming majority say no. But – those who have that experience talk about how impactful it has been on them.
So this is really not about how teams should define success – but about how we can align team success with user success. This changes our definition of what success is, and it’s also good for motivation.
But – we have to be careful that we actually do understand what users consider to be success. I used to work on a carpooling app, and we talked about how people wanted a way to organize their car pools and exchange money more easily. But I used to read every support ticket, and the what I ended up suspecting was that really what people wanted to do was track their carpooling in order to qualify for company eco incentives. Which… sounds a lot less like a viable business model. So you know… I don’t work there anymore, and neither does anyone else.
One thing we do on my current team, is a quarterly “empathy challenge” where we attempt to connect more to how people use the WordPress apps – there are options, like joining a call with a new customer, or running a user test, or blogging ourselves from a mobile device. We collect case studies of people who are regular users of the apps and ask them about their website, what are they trying to do with it, how do they use the app. Everyone on the team starts with three weeks in support and spends a week each year doing support – and it’s important to listen to user pain and frustration. But we’re trying to balance that by also listening to people who are happy. It’s important that we understand what’s broken, but it’s also important we understand how we’re helping people reach their goals. It’s also much more uplifting. And it reminds us that whatever we ship is measured not in lines of code, or how technically interesting or challenging it was… but how useful real people find it.
Because despite what the aliens may have concluded – we don’t run teams to run teams. We run teams to do something.
Keeping this mindset also changes the way that we talk about our work and focuses on impact rather than the details of what. It doesn’t necessarily change what we do – but it does communicate the why more effectively. And it does make the “finish” line clearer – because that’s around the impact – something that we can share as a “this is a new thing for you”. If we don’t feel proud of talking about what we’re doing in that way, then maybe it’s not yet finished, or maybe it’s not worth doing at all.
As a result, we rebranded “Networking refactor” to Full Jetpack Support, “New Editor” -was rebranded to talk about accessibility and performance, and being a building block for Gutenberg. We rebanded “Async” to be about not waiting for media to upload when you’re ready to publish. Finally we rebranded “Bug fixes and improvements” to #NoMoreBrokenWindows – making it a point about how we wanted to improve the polish and overall experience.
These things can seem silly, or manipulative, like they don’t result in more being done as a team, but regardless of what is objectively true – and how would we measure it anyway – tying our success to user success gave us a sense of meaning, which I think translated to momentum and focus. Our support people tell us they spend less time helping people with basic things that shouldn’t confuse them, and out app store ratings have crept upwards.
Now we’ve aligned the team with our users, what about individuals?
Maybe now you’ve gathered, I’m not really big on “should”, so this is really: how can you create success for people in a way that aligns with your team? Because even though individual success is personal, people respond to the expectations – and incentives – we create for them and those can work against what’s best for the team and the product if we’re not careful.
What’s next? How we can create alignment.