Maximise success

Many processes and organisational controls are set up to minimise failure. They are set up to minimise the number of times a team releases bad software; minimise the number of customer complaints; minimise the server crashes or minimise the failed product launches.

What if instead of trying to minimise failure, your organisation focused on maximising success?

What would it do for your product or consumer offering if instead of trying to minimise the bad software releases, you focused on maximising good ones? What would it do for your organisation if instead of focusing on minimising failed product launches, you focused on maximising good ones?

The problem with focusing on minimising the bad is that it creates roadblocks instead of opportunities. When a conversation starts with the question “do we have a reason to not ship this?” it sets the expectation that not shipping is okay. A focus on bad minimisation discourages risk taking and rewards the status quo.

The easiest way to minimise bad releases is to not release anything at all – so when you incentivise and reward the act of not shipping bad releases, either nothing will get shipped, or what does get shipped will be safe and unremarkable.

There will always be a reason not to ship if you look hard enough. Instead of focusing on trying to find it, try investing that energy into shipping it the best way you know how.

Not my job

Not my job
Not my job

One of my first jobs was as a bartender in a pub. My supervisor, Ted, had what I then thought was a compulsive neatness habit. If he saw a chair was out of place, he would straighten it. If there was an empty glass on the table, he would take it. A cigarette on the floor, he would pick it up. He couldn’t abide it if the other staff didn’t do this too. He’d say to us “don’t just turn a blind eye because you’re a bartender and not a cleaner. We work as a team here; your job is everything.”

The bigger your organisation becomes; the more distributed your team or the more defined the roles, the easier it becomes to think “that’s not by job”. Just like the guy driving the line-marking car in the photo above, who figured getting out of the truck to move the branch was not his job.

What would you think of a striker who stood by and let the ball roll into the goals because the goalkeeper was on the ground? It’s not his job to protect the goal, right?

If you are working on a team building a product or an experience for a customer, then your job is to bring them that experience, and to have it be the best experience it can be. Your job is not just testing or writing code; it’s not just writing the help copy or managing the DNS configs. They are just things that you’re good at – your job is the product. If you see something that’s broken, then it’s your job to fix it. Your job is everything.

So when you see that crooked stool or that empty glass – what will you do?

Pay off your debt

Photo from here.

In Agile development teams we talk about technical debt. A debt is basically anything you owe the codebase; anything you need to pay back. When you make a decision to ship less-than-pefect code to meet a deadline, the less-than-pefect code is the debt you have to pay back. When a junior programmer is left alone and writes poor code in a different style, their code becomes a debt – something you need to fix later.

You can build up debt outside of your codebase too. Every team, every product and every project accumulates debt every day.

Every band-aid you put on a broken process is adding to your debt.

Every time you avoid having a hard conversation with an under-performing employee it’s adding to your debt.

Every compromise you make is adding to your debt.

You can ignore debt, but you can’t avoid it forever. And debt earns interest and generates yet more debt – and it’s probably generating more than you think.

Debt is a weight around your neck; it’s a burden, it’s baggage, and it gets in your way. Instead of ignoring it, start paying off your debt.

Adam Smith once said: “What can be added to the happiness of a man who is in health, out of debt, and has a clear conscience?”

Communication in standups: watch the team, not the speaker

You can gain a lot of insights about people’s mood and reaction to news and disucssions just by watching them.

One habit I have picked up is during the daily standup, instead of watching the person speaking, I look around and watch the other members of the team. If I know the speaker is discussing a topic that’s particuarly relevant for someone, I’ll watch them to try to gauge their response to it.

You can get a sense of how effective the standup is overall simply by watching the faces and responses of the other people in the room. If the team seems bored or restless, then it might be a sign that the format of the standup or the way things are being discussed could be improved. If someone seems to respond negatively to a particular point or topic, you might take a note to catch up with them 1 on 1 after the standup to follow up.

Try it in your next standup; you will likely be surprised what little insights you get out of it.

Software’s worst enemy: consensus

A vote for everybody is a vote for nobody.

A committee (parliament) voting on something

Photo from here.

The best software and products dazzle out of the box. They set new boundaries and exceed expectations. And they don’t settle for less than outstanding.

Designing software with lots of stakeholders is complicated, but when the product manager prioritises reaching a compromise between all the stakeholders instead of pushing for unique, beautiful and remarkable, the result is more often than not unspectacular.

Worse still are product teams that are set up without a clear product leader – product teams comprised of a group of ‘area’ product managers, who are each responsible for their own product piece, but who together, and in a purely democratic way, are supposed to come up with one aligned, cohesive and most of all compelling end-to-end product proposition. This is called ‘design by committee’, and nearly always ends in mediocrity.

The problem here is that each area product owner is focussed on his or her piece of the overall proposition, and each have their own priorities, visions and strategies. Just packing these guys together in a room is not going to result in them coming up with a remarkable and balanced product proposition. What this scenario often results in is some kind of portal; it’s at best a mash-up of separate products – something that tries to do everything and ends up doing nothing particularly well.

A product needs a product leader – someone who is willing to make decisions that displease some people and to fight for the ultimate product vision. Michael Arrington, founder of Techcrunch, says:

“Product should be a dictatorship. Not consensus driven. There are casualties. Hurt feelings. Angry users. But all of those things are necessary if you’re going to create something unique.”

A product team should not be a democracy. A product team needs a leader; it needs someone who calls the shots and makes the decisions that will displease, disappoint and delight.

Consensus-driven teams often have challenges understanding and agreeing on what is important now (prioritisation) and what is important overall (scope). A product team made up of area POs have by definition conflicting objectives. The PO for component X believes that part is the key product proposition; the PO for component Y sees it differently. The result of the ensuing debate is often a compromise; “ok, let’s build it all”. In their fantastic book Getting Real, 37 Signals founders share their view on software design:

“Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit.”

Of course, there are important requirements that the ‘master’ Product Owner needs to fill. He or she needs to understand the product and be able to present a compelling vision. He or she needs to be able to make difficult decisions and disappoint some people, but be convincing and considerate in the explanation. Most of all, he or she needs to understand the product extremes that make the product unique and remarkable, and not compromise on them. In other words, they need to be a leader.

I’ve seen product teams try to fill this role with a Program Manager. It doesn’t work: a roadmap slide is not a product vision. I’ve seen product teams try to fill this role with a Requirements Manager. It doesn’t work: a requirements list, or even a product backlog, is not a product vision. I’ve seen product teams try to fill this role with senior managers who poke their heads in every so often. It doesn’t work: a day’s worth of rash, under-informed decision making does not substitute consistent and detailed thought.

A product needs a product leader. And if that’s you, then my tip is: don’t give in to consensus, and don’t settle! You will never please everyone… not all users, not all colleagues, not all bosses. So please, give up trying. Sometimes innovation comes from having the courage to disappoint people (and the wisdom to know when!).

Focusing on your product vision

In agile we promote working in small iterations, and building just enough to solve your problem today. I try to encourage my team to avoid designing a problem to the very end, but to focus only on what is necessary to solve the first; most basic problem.

BUT: focus and iterative execution should not be confused with a lack of vision…

Vision (why are we doing all this? What direction are we heading in?) is long term, far reaching and top-level, and vision is crucial to help you make the right decisions about what is important today, and what will be important tomorrow.

The execution against the vision however is based on small increments; small, little steps that move you towards what the vision looks like today. I say today, because the vision can change. In fact, the vision should change over time; it should adapt and adjust to evolving competition and user/customer feedback. Building in iterations allows your vision to adjust, and allows you to adjust to your vision.

Working in agile is no excuse to forget your product vision. Agile is all about taking small steps and adjusting along the way: but you still need to know where you’re going.