Tag Archives: eCommerce

Encouraging people to stop the line with both carrots and sticks

2012-02-10-Carrot-and-stickIn my last post, I described a work challenge around delivering high quality products, noting that despite repeated encouragement, members of my team were reluctant to stop the line, even if that meant sacrificing quality for speed. I offered a few thoughts on why this was the case, including mixed messages from leadership, aggressive deadlines, our tendency to fall in love with technology, and peer pressure.

In this post, I’ll describe a few things we’re doing to try and correct the situation. Some of these things are what I’d call “carrots,” or rewards that come with stopping the line to focus on quality. Others are “sticks,” or penalties.


Celebrating line stoppers
If someone stops the line, we celebrate it publicly. At our all eCommerce team standup this week, we discussed a project that didn’t go as planned, thanking the person on our team who stopped the line and slowed it down, helping us avoid a big mistake.

Using numbers
Products that are well-designed and well-executed tend to outperform those that aren’t. Regular KPI reviews encourage our product teams to do their best work. Sometimes this requires stopping the line.

Holding design review meetings
Last month, we instituted design review meetings with our team’s leaders (it’s a riff on Ed Catmull’s “Braintrust” idea). At first, our teams were afraid they’d be micromanaged.  But a month into the new process, they see the value and appreciate the attention. And they’re quickly becoming more detail oriented.

Showcasing great design
When something is designed well, we share it, far and wide. Being a team that focuses on quality products is becoming a point of pride for all of us. Building “good” things is boring – our products should be great. We want our people to be able to tell the difference between good design and great design, and to aspire to create the latter.

Finding evangelists within the team
I’m actively recruiting people on the team to promote the value of stopping the line. I started with our UX people, who seized the opportunity to get the rest of the team focused on the user experience. (As you’d expect, it was easy to get them on my side.) By now, the entire team has heard the message, and we’ve got lots of evangelists – and converts.


Requiring rework
One great way to ensure someone on the team stops the line is to make it clear that the whole team will be starting over from square one if they don’t. When faced with the prospect of removing functionality from our sites and rebuilding it from scratch, stopping the line starts to feel like the much faster option.

Public shaming
This is a route we haven’t really gone down, since one of our core principles is to celebrate failure. Still, when we see poor customer experience, sloppy design, or performance issues, we let the team know. We favor blameless postmortems, but we also favor paying attention to details.

Instituting sign-offs
Our team knows that when they release code into the wild, they’re implicitly saying it’s ready to go. If we need to, we can make this explicit. This would be a last resort – sign-offs aren’t part of the culture we’re nurturing – but it’s an option if we need it.

These are just ideas, of course. If stopping the line and focusing on quality are important to you, you’ll need to work with your team to figure out how to make it happen, and you’ll likely need to revisit the conversation over time.

As leaders, we also need to model this behavior. This means there are times we need to stop the line ourselves, even when it’s our own work we’re doing and our own deadlines we’re missing. We need to make the same trade-offs we ask our teams to make, and have the same tough conversations we ask them to have with stakeholders.

What do you think? Have you had similar experiences as it relates to stopping the line to focus on quality? How have you addressed them? I’d love to hear from you.


Deliver business value, not projects

About 2 years ago, my eCommerce team was working on a project that would allow Web Merchandising to more easily add content to our sites’ Product Detail Pages (PDPs). After working on the project for three months, we decided it was complete. We delivered the good news to our Executive team in our monthly update and waited for the accolades to come. “Fantastic,” our CEO said, “let’s take a look.” But when the Execs took a look at the PDP, they saw empty spaces where content should have been.

“No, no, no,” we said, “the functionality is complete. It’s just that you won’t see the project’s benefits until the Web Merchandising team adds the content. Probably in about two months.”

Guess how “done” the Execs thought we were. Not very.

It ain’t done ’til it’s making money

The idea that our work is incomplete until its business value is realized doesn’t thrill my team, and it doesn’t particularly thrill me either. It means when we work on a projects with dependencies (pretty much all of them), we can’t really move on without another team’s help. It means instead of thinking of new ways to drive value for the business, we’re finding creative ways to influence schedules we don’t own.

But what’s the alternative? Meetings like the ones described above? Lots of completed projects and no business value realized? A false sense of accomplishment shared by developers and product owners who hit their goals while the company suffered?

Service providers and agencies – the good, successful ones – get this. That’s why, before it gets close to contract renewal time, they’re showing me usage reports and asking if I need help getting more value out of their products. They’re offering consulting services (sometimes even free!), holding quarterly business reviews, and showing me all kinds of cool charts and graphs. They know that creating a terrific platform for generating user reviews or product recommendations is only half the battle. In order to justify renewing the contract, I need to see more reviews or a higher conversion rate – I need to see business value.

In a corporate setting, with so many levels, layers, and inter-dependencies, this message can be harder to land.

Setting the right goals

One way I’ve found to land the message is to give employees goals related to the amount of business value they drive. Within my team, everyone is accountable for at least one – and usually several – business-focused goals related to their work. For example:

  • The PDP conversion rate must improve by 10 bps, or
  • We’ll generate 10% more product reviews for our owned brands

This helps ensure that employees take ownership of the results they drive, and that work continues long after a project goes live. (In fairness, I also include a goal related to each employee’s individual and/or team output, so they’re not completely out of luck if another team falls down on the job. I call these quality and quantity goals – the quality of work is expressed in terms of business value, while the quantity is expressed in terms of sheer volume.)

This is simple, but effective. In cases where employees are focused only on project delivery, I’ve found that – more often than not – their goals are not tied to business outcomes.

I’d love to hear from you

I’ve described what I’ve found to be true time and time again: that employees need to be held accountable for business outcomes, and that business-focused goals are a great way to make it happen.

Now I’d love to know what you think. Do you agree that sharing accountability for business outcomes is critical? How have you solved the problem? Please let me know.