Accidentally in Code

Tag: successfully derailed product

Creating Success, Together
This is the final part of a 6-part 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, part 5.

We want to be careful how we create process. The fastest way to a mediocre team is to define your process around mediocrity. A slow but sure way to a mediocre team is to define your processes to gradually push them towards putting their own self interest front and centre – like the conclusions the guy drew from the promotion process we talked about earlier.
- Incentivizing complexity is terrible. When you incentivize complexity, you get a lot of it. Most of it unnecessary.
- Impact is contextual and subjective. Time in app is a good example – is it good if people are spending more time on your app if it’s also making them more miserable? Are there longer consequences from that?
- People leave when they don’t grow. Not all people, but still – if people don’t see a way to learn, or increase their impact, or whatever growth means to them, they will leave in search of it. Remember career development was the top thing developers were looking for in new jobs.
- And people leave when they feel unappreciated. When the work they are doing doesn’t seemed valued in whatever definition of value they have – financial, or recognition (or both).
- If you don’t feel like you can be successful somewhere, why would you stay? Which is why we need to understand what people think of as success, so that we can give them a path – or encourage them to find that path elsewhere.
There’s a Japanese concept called ikigai – the intersection of what you love, what you care about, what the world needs, what you can get paid for. The question this inspires, for me at least, is how do you bring out in people what they love, and how they are most excited to contribute to what’s around them.

One thing that we talk about in my current team, is the idea that a senior engineer makes the whole team better. Which whilst it has the problem of subjectivity that many things do, it’s clear when it’s happening, and clear when it’s not. The person who does a lot of great work hiring or onboarding, or the person who spends a lot of time on architecture or code review – their impact goes beyond lines of code of features shipped. But the person who doesn’t work with others, or who leaves things unfinished for teammates – it’s clear they are not contributing in that way.

As we approach the end, what can we take from all this?

The dysfunctions of your organization become the dysfunctions of your product. Dysfunctional teams of mean, insecure people, build shitty products.

I have this idea I think of as the hierarchy of kindness. Essentially, we’re kind to ourselves. And on top of that we are kind to our teammates. Kindness to the user sits above both of those. If you can’t show empathy to the people you work with every day, how can you show empathy to someone you will never meet?

Or: Resilient individuals -> strong teams -> towards a purpose (the user).

But strong teams are necessary but not sufficient. All organisations have their quirks. It’s fun and entertaining to talk about extremes, but things don’t need to be extreme to cause problems.
- When you don’t make decisions: product features don’t get clearly prioritized, leading to stagnation or bloat.
- When teams can’t work together: your UX becomes disjointed. This is Conway’s law – Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
- When you incentivize complexity: you get a lot of unnecessary complexity.
- When you are too into shipping fast: what you ship is mostly unfinished.
- When you are too into long, complex architecture projects: what you ship is few and far between.
- When you have to do a rewrite: you have failed. How do you not fail again?
- When you get disconnected from how people really operate: you create a very rigid product.
Here’s the thing about organizational dysfunction. Sometimes it’s created by political machinations. But often it’s created through good intentions and deliberate process.

Arbitrary characteristics of early team members become enshrined in the hiring process and don’t evolve as needs change. The things that make small teams successful are still lore and aren’t revisited as teams grow. An elaborate promotion process gets defined in the name of fairness as a preventative measure against fiefdoms. We experience poor managers and then we become poor managers ourselves – or just devalue the whole concept. We pattern match, but we don’t really know what the patterns are.

I love what this snippet of David Bowie captures. The idea that in art, a piece is not finished until it is experienced. This is so true for products. This is where we live – in the grey space in between.

Thanks for coming on this journey with me. It’s left me with more questions than answers in many ways, but also with a strong conviction that this is the work – understanding those motivations, and creating that alignment. I leave you with three thoughts.

A sense of accomplishment is personal. Ask someone what gives them that for a potentially fascinating conversation.

Zoom out for clarity. The disconnects appear when we step back – from the individual to the team, from the team to the users the product is meant to serve, from the feature to what the person is trying to do.

Say thank you. If you liked something that someone did or built or wrote, tell them. Impact matters to people, but people don’t know they have had an impact on us unless we let them know.

Thanks to my colleague @folletto who helped me turn a collection of disjointed thoughts into a coherent structure and introduced me to Campbell’s law, and @mattmiklic who made my slides beautiful after I destroyed everything.
May 8, 2018
How Should We Define Success?

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.

May 1, 2018
How Do Users Define Success?
This is part 4 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.

Let’s take another step back and talk about how users define success.

Because really – we’re building software to do something, right? For actual humans to use. So why wouldn’t we talk about them when we talk about success.

Working on WordPress.com, we talk about this a lot. It turns out people mostly don’t want to “make a website” or “choose a theme”, they might talk about wanting to “make my site look the way I want it”. But really, they want to be found by potential clients, sell things or just take payments, share their ideas and perspectives – in the hope of reaching a community or potential clients. They love their stats, because it’s a metric that shows them how they’re doing on their goals. There’s a framework for thinking about this called “jobs to be done”, which is essentially the idea that people “hire” software to do “a job”. So when they talk about the software they want, they’re talking about what they think will do the job. But we’ll design better experiences if we focus on what job they want the software to do.

A fascinating article from basecamp about people requesting a calendar view was one of the two user focused articles I found in my research on teams.

So if we think about the job to be done for an On demand app, they might be around:
- Convenient way to get what (or where to) I need.
- Faster than alternatives.
- Cheaper or comparable.
- More choice.
But on demand apps are two sided market places, so what kind of things might the providers of on demand services be thinking about?
- Be discovered by new people.
- Make more money.
- Flexibility about when to work.
And then you can think about things like surge pricing as balancing that tradeoff – more money, for less flexibility for the driver. More expensive, but more convenient for the rider.

If we thought about Social networking, there are some well documented adverse effects – like depression and low self esteem. But what might be the job to be done?
- Connecting with friends, or new people.
- Building an online presence (in pursuit of some goal). Although someone told me the other day his kid wanted to be “a youtube star” so…. I guess that’s a job now.
- Finding relevant, real time, information.
But! Social networks are also a two sided market place, and the other side is the advertiser. So what are they trying to achieve?
- Selling their product, which they quantify by return on ad spend. So per dollar spent advertising in some place, what amount of sales are generated.
One thing that starts to be clearer here is how products can align their success with the user’s idea of success. So if someone can achieve the goals of their website – if they can connect with people, or sell their product or generate leads for their business, it’s doing it’s “job” and they will be happy to keep paying for it. What’s good for the user is good for the business.

You can see that with an on demand app too, if it’s a better experience for the customer, and allows the service provider to make more money, it’s a win for the platform because more business flows through it. Let’s just leave out bending employment law and potential monopolies for now.

With things like social networking though, it’s much harder to align the interests of both sides of the marketplace. I did not join Instagram thinking I wanted to be sold random shit, I joined to for the constant stream of raccoon pictures. And yet Instagram shows me as many advertisements for random shit I don’t want – and yet so compellingly I often wonder for a minute if I do – as adorable raccoons.

There was a study recently from a company called Moment (an app to encourage you to use your phone less, oh the irony), that showed the apps we like most are the ones we spend the least time using.

What’s also noticeable to me is how many of the apps that make people happy are ones where they are more clearly serving some kind of purpose, rather than things used to pass time. Those tend to make us unhappy.

There was a period where we talked a lot about “delighting” users, and this by and large seemed to be a conversation about aesthetics and animations. But what I take from this is the value of thinking about how we serve users. What do we make possible for them? What do we make easier? Because if we’re not building what I would term “digital crack” user success is product success, and product success is team success.

What’s next? How might we define success.
April 24, 2018
How do Developers Define Success?

This is part 2 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.

With the caveat that how we define success comes from various places, and any collective definition is most likely nonsense. I set off to understand the ways in which developers, and particularly individual contributors think about success.

I started with the Stack Overflow survey. Caveat: I hate it and I think it’s riddled with bias. For example, women make up ~fifty percent of the population, around ~twenty percent of technical roles… and 7.2% of the respondents to this survey.

So let’s start by looking at how developers feel about jobs and careers. Developers tend to be pretty satisfied with their career, a bit more so than their current job.

This slideshow requires JavaScript.

When looking for their next job, the top priorities are professional development, compensation, office environment and technologies.

The most valued parts of compensation are vacation time, remote options, health benefits and expected work hours.

Most developers check in code multiple times a day. And the more often they check in, the happier they tend to be.

This slideshow requires JavaScript.

Success metrics developers would choose are: customer satisfaction, time and budget, peers rating and product performance. It’s interesting that manager ratings and self ratings are considered about as useful. Not a ringing endorsement for managers there.

So to rounding out the quantitative data riddled with bias, I got some biased qualitative data in the form of posting a question on twitter.

Question mainly for ICs, what does success look like for you? What is a successful day? Week? Month? Year? Do you set goals for yourself? What are they?

So many questions but what it comes down to: I want to know what gives you a sense of accomplishment.

(RT for reach? 💕)

— cate // @hachyderm.io (@catehstn) March 17, 2018

I got some interesting responses. But I’d also love to know what you think. (Leave your answer in the comments or tweet at me).

Many of the themes from the Stack Overflow survey showed up here – shipping code, learning and developing, autonomy.

There was also a theme of recognition – including financial. Which makes sense, because as as society money is the usual mechanism by which we communicate value.

People also talked about the way the sense of accomplishment changes (or has to change) as your job evolves and you take on more responsibility.

Another theme, though, was the theme of impact. People using what was built, benefitting others in some way.

The graphs show trends, but people’s personal definitions show that success is personal. We see the baggage people bring with them from previous (external) definitions, the way that definition changes over time, or that what we believe is important conflicts with what makes us happier in the moment.

It was noticeable to me that women who responded seemed much more likely to talk about the supporting others in some way – whether their teammates, or people using what they worked on. There are a number of different observations we could make here – one is that the patriarchy trains women to consider others in a way that is not as true for men. But also it hints at what might be different about those survey results if they were more representative of the demographics of the industry – and what could be different if the industry were more reflective of society as a whole.

What’s next? A look at the way we talk about team success.

April 10, 2018
Whose Expectations are Those, Anyway?

This is part 1 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.

Credit: ToRange

There used to be a joke at a company I worked for that went “how many test frameworks do we have” and the answer was “how many SET5s do we have?” It was “funny” because an SET was a software engineer in test, and to get promoted to Level 5 they would have… written a test framework.

How often have you have seen those kind of things? Where the things that get incentivised for individual success turn out to be a joke at scale? Because clearly when it comes to testing frameworks, more is not better. It’s pretty orthogonal to the goals of testing – which are generally around continually shipping with confidence.

This isn’t to say that promotion processes are inherently bad, or that individuals shouldn’t desire and work towards professional advancement. Just that the processes and goals that we define profoundly affect our organisations, the environment it creates for people who work there, and the things we are able to ship as a result. Your processes define your culture, and your organisational dysfunctions show up in what you ship and when you ship it.

This isn’t to say that goals are bad. Goals are good… it’s well documented that we make more progress when we know what we’re aiming for. But if we set the wrong goals, or we set goals that aren’t compatible, then what? And when we agree on the goals we should be setting… are they supported or sabotaged by our processes?

Let’s talk about what “success” even is. Take a moment, and think about some goal in your life. What is it? (Leave it in the comments or tweet at me).

Do you have something in mind? Now I want you to think about where it came from.

Hard part over: how do you measure it and how do you report on it?

Example 1: I have a goal of increasing the monthly actives in the app. My boss gave it to me. I measure progress on it using analytics and report on it every two weeks.

Example 2: I have a goal of clarifying the “vision” for my team. I got this from my team in various ways – surveys / direct feedback about this being something people want. I measure it quantifiably using surveys, and less quantifiably from the kind of questions that get asked in our monthly townhalls or in the regular skip 1:1s I have with everyone on the team. I report on it quarterly – in that we have a document outlining the longer term plan for the team, and this is how often it gets updated.

There’s a framework by Gretchen Rubin on how people respond to expectations, called the Four Tendencies. She describes it in Better than Before (Amazon) and goes into more depth in The Four Tendencies (Amazon). Essentially, there are four ways in which people respond to expectations.

Obligers respond to expectations from other people. They struggle meeting their own expectations.

Upholders respond to all expectations – including those they define themselves.

Questioners question all expectations, and respond only to expectations they think make sense.

Rebels resist all expectations.

https://twitter.com/alexisylchan/status/975048974032814086
Obliger Goals, 2018

So how does this relate to goals? Well obligers probably got their goals from other people, upholders might be making great progress on things they don’t actually want, questioners are trying to ignore things they can’t make sense of, and rebels are opting out of the very thought.

Meanwhile, obligers often feel unappreciated because they’re so busy putting other people ahead of themselves they can’t get their own stuff done. Upholders don’t understand why people don’t just do what they are asked or say they will do without complaining or asking so many questions. Questioners are annoyed by all the arbitrary things that other people want (and also, ironically, by being questioned) and rebels just want to be free to do whatever they feel like and resent all the interference.

All these things are playing out around us. But a lot of the time we don’t have a way to articulate it so we don’t talk about it.

Currently, I manage five managers, and we started talking about it towards the end of last year, in part because reading the book I realised that I was not great at managing obligers. I’m a questioner, and I was completely mystified by the behaviour of taking on arbitrary things and then resenting them. So you know, an obliger gets overwhelmed, and my response is along the lines of “why are you doing that anyway”, which, you know, they don’t find helpful… and then they feel resentful and I feel confused. It’s great working with obligers because they are so nice and helpful. But because of that it’s very easy for people to inadvertently create expectations and take advantage of them. Meanwhile upholders can lack empathy for people who aren’t as effective. This gave us a shared language to talk about how we are creating and responding to expectations with each other.

On a more organisational or social level, there’s an idea called Campbell’s law.

“The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.”

~Campbell’s Law

Bit abstract, right? A good example of teaching to test. Standardized testing can work for measuring attainment, but once students are taught to pass the test, both the teaching and the test lose value.

You can think about this in terms of promotion processes. You define a system which makes sense, but then people work to the system, and both the work and the system become less useful.

Another place you can see this is the tension around shipping culture and something that might be called a “quality culture”. When you define a process to incentivise shipping, shipping becomes the goal and what is actually shipped tends to become secondary – and not very good. Then in a “quality culture” the quality is the most important thing, and so nothing gets shipped at all…

…But if it does ship, it will be perfect.

Credit: Pixabay

(As an aside, this is why I like to talk about shipping as a habit rather than as the goal itself. I think this is something where release cycles help, because it can force shipping on a cadence rather than shipping specific things).

One way to phrase Campbell’s law is that we work on the definition of the thing. And the result is that definition is probably nonsense.

I find all this pretty fascinating, but what does it all mean? How do these things connect? Well when we define systems, we create incentives – or expectations. Individuals take these expectations and it influences their goals (even if they’re rebels – just in the opposite way).

Essentially – defining systems is fraught with risk of derailment, because teams are not made up of rational actors, but rather: people.

What’s next? A look at the way individuals define success.

April 3, 2018