Category Archives: Product Management

If you don’t know why you’re doing something, stop and ask!

Leave a reply


Picture this: after a long day at work, you arrive home (or close your laptop, as the case may be) and your partner is frantically packing their suitcase. “I’m leaving,” they say, before exiting the house, getting into the car, and driving away.

Alone in the kitchen, you realize how little you know about what just happened. Is your partner dealing with a work emergency? A family crisis? Do they need to get to a store before it closes? Did they just … leave you forever?

Regardless of the answer, your partner is gone. But without context, it’s impossible to know how to respond. Should you call your family? Start cooking dinner? Pack your own bag? Create a Match.com profile? How can you solve the problem if you don’t know what it is?

This happens at work all the time

Fortunately, this doesn’t happen too often in our daily lives – if it did, we might find more communicative partners. But somehow this scenario plays out at work all the time, every single day. Here’s an example to help illustrate my point – apologies if it hits too close to home:

Jane is a product manager, whose boss tells her to “remove the banner from the landing page immediately.” Jane understands that this “request” is urgent, and she chooses not to irritate her manager or slow things down by asking lots of questions. The request is clear, so Jane writes it up and injects it into the sprint. The banner is removed within the hour. Everyone is happy – for now.

Three days later, the team has enough data to assess impact of the change: as a result of the banner being removed, landing page conversion has improved by 50 bps, but nobody (literally nobody) takes advantage of the special offer, which was intended to incentivize multiple purchases. We no longer have a signup problem – now we have retention problem. Why?

As it turns out, Jane’s boss wanted the banner removed because it was covering up the email field, creating enough friction to negatively impact conversion. Removing the banner altogether was an extreme response to a simple problem, like using a sword to cut a fingernail. A more nuanced approach (like repositioning the banner instead of removing it) could have achieved both of the company’s goals. The problem was that nobody knew what the company’s goals were: no one offered them, and no one asked.

Every company I’ve ever worked at employs smart, highly motivated people. As I pointed out in my post about aligning product and engineering teams, smart and motivated people are used to delivering what’s being asked of them day after day, and they’re very good at it. Still, they crave context for their work, and they’re ready to use it to solve real business problems in smart ways. That’s good news, and there’s more: effective leaders actually want their teams to think this way. Why treat a chronic illness if you can cure the disease?

Curing the disease

Curing the disease isn’t as easy, but you can make progress today. Here’s how:

Create a culture of empowerment
If you treat your people like order takers, that’s how they’ll behave – until they find new jobs. Creating a culture of empowerment requires that we spend time thinking about problems and opportunities before proposing solutions, and recognizing that many problems have more than one perfectly acceptable solution. It means taking the time to discuss goals and provide context instead of telling people what to do, leaving space for questions, comments, and alternate approaches. There are lots of things a team can do by taking a bottoms up approach, but creating a culture of empowerment starts at the top.

Spend more time truly understanding the problem
In the wise words of Abraham Lincoln, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” I haven’t done the math, but my years of experience tell me that every hour spent providing context to engineering teams saves between 2 and a million hours of development time. Don’t fall for the mistake of thinking hands on keys is where the magic happens. Give your teams plenty of time to understand what they’re doing and why, and they will amaze you. As you may have heard, slow is smooth, and smooth is fast.

Go out of your way to make people feel comfortable expressing their ideas
A point of view might be worth 80 IQ points, but you’ll never hear one unless you make it clear that’s what you want. In most work situations, the sad truth is that it’s safer not to argue with the boss. If you want your people to challenge you with new ideas, questions, and solutions, you have to let them know explicitly. And if your company is entirely remote, you need to remind them regularly, because it will take longer to sink in.

If you don’t know why you’re doing something, stop and ask!
The suggestions above are aimed at team and company leaders who want to create a culture of context. But once it’s clear that asking questions is okay, the responsibility belongs to everyone. I’ve seen lots of people and teams deliver the wrong work because they didn’t want to “bother” someone else, even with something as innocuous as a Slack message. If we’ve ever worked together, you’ve heard me plead: do not suffer in silence. And yet, it happens all the time. If you don’t have what you need to deliver great work, it’s your responsibility to get it. In most cases, the people responsible for providing context will think they already have, or don’t know what you need. Assume good intentions and set yourself up for success.

What do you think?

I once worked at a company that refused to provide context as a matter of policy: they felt it was more efficient for leaders to turn decisions into requirements, and to cascade those requirements to individual contributors. The way they saw it, context led to discussion, and discussion led to debate, and debate slowed things down. Simply put: they wanted less talking and more coding. You won’t be surprised to learn that this resulted in frustrated teams and failed projects.

Still, I’d love to know what you think. Have you worked at a successful company that operated differently? If so, how did you make it work? If you agree that context is important, how have you made it part of your team or company culture? Have you tried any of the suggestions above? Do you have any of your own? Please let me know!

“Healthy tension” between Product and Engineering? No thanks, I’d prefer alignment.

2 Replies


I remember the situation like it was yesterday. I was leading the Product and eCommerce team for a large retailer, and Black Friday was only four weeks away. At our October check-in with the executive team, I’d told the CEO we’d be delivering several features to improve checkout conversion, which would increase revenue by as much as a million dollars.

I wasn’t just trying to make myself look good. Like any competent leader, I’d made the commitment only after discussing the situation with the appropriate teams, and my partners in Engineering were in lock step. Within a week of my meeting with the CEO, though, things had changed. During a load test, a scalability issue had been discovered, and it would require the full focus of our Engineering team.

The Engineering leader asked what I wanted to do. Should we continue to focus on the features we’d promised, or pull the team off of feature development to focus on system stability? I don’t remember it being a hard decision. “Those features aren’t going to do a lot of good if the system is down,” I said, “let’s shore it up.”

Healthy Tension?

A lot has been written about the importance of “healthy tension” between Product and Engineering teams, and on the surface, it makes good sense: if one team is focused on building new features and the other is focused on code quality and stability, the tension between them might encourage discussion and debate, and neither team will lead the company off a cliff. In fact, the theory goes, this “healthy tension” might lead to compromise, somehow delivering the best of both worlds. I disagree.

The problem, I think, is in the assumption that Product and Engineering teams inherently have different goals. They don’t – or at least they shouldn’t. Both teams are responsible for the growth and stability of the company, for revenue and scalability. Neither can succeed without the other.

When we assume otherwise, we sell each side short. Any good Product Manager will tell you there are times when addressing technical debt is the smartest use of development resources, that the push for new features needs to be balanced with a view towards system health. And any good software engineer will tell you that the world’s most performant system is useless unless it drives business results, that sometimes it’s worth taking on tech debt to take advantage of a market opportunity.

Think of it this way: if you were building a house, you wouldn’t expect your architect and your builder to simply hand off their work, you’d want them to collaborate around shared goals to make sure they were in agreement. A good architect would never design a house that couldn’t be built, and a good builder wouldn’t build a house that was poorly designed. We should expect the same from Product and Engineering teams.

A smart and logical group

“At a basic level,” according to this AHA.io blog post (and many others), “product managers should tackle the ‘why’ (product strategy) and ‘what’ (features) for the product. Engineers should determine the ‘how’ — the technical implementation of features.” While this may be true at a basic level, it’s not the way great Product Development teams work.  In my experience, great teams – the ones that are most engaged and produce the best work – are the ones where Engineers are involved in defining the “what” and Product Managers weigh in on the “how.”

This is because Product Managers and Software Engineers are often among the smartest, most logical employees a company has, and they tend to be very capable of both understanding business goals and coming up with creative ways to achieve them. When we neglect to give our teams the full context of what we’re trying to achieve, we make it harder to solve the problem, and also to commit to the solution.

This takes time up front, of course, but when a Product Development team has conviction that they’re solving the right problem in the right way, they can move fast with trust and confidence. And when something goes wrong, as it inevitably will, the team members have the context they need to address the issue in a way that still meets the goal of the project.

Product Development teams

I’m not saying there’s no place for “healthy tension” at a company. As this Product Plan article points out, “there’s a reason you don’t see titles like Vice President of Innovation and Compliance. A little tension is good.” For a company to be successful, it needs to have people with different perspectives, and there needs to be lively debate.

But tension between departments is different. I prefer to think of Product and Engineering teams as combined Product Development teams, making sure they’re in lock step as it relates to goals, strategies, and priorities. As this Martin Fowler article points out, “aligning these two disparate organizations [Product and Engineering] into cohesive team units removes organizational friction and improves time to value.”

I’d encourage all of us to adopt more of a Product Development mindset, acknowledging that Product and Engineering teams cannot thrive unless they’re joined at the hip.

A note on org structure

In my current role (as in my last few), I’m responsible for Product Development, which includes Product, Engineering, and Product Design. Despite my own experience, I don’t have a strong bias for all of these functions reporting to a single leader – I’ve worked with great CTOs and VPs of Engineering, and without the right leader, combining teams can be a mistake. My point in writing this post is not about having the right org structure, it’s about having the right mindset, which can exist in any structure.

6 Reasons to Listen to the Things We Don’t Want to Hear

4 Replies

It was years ago, but I remember it well. I’d been at my company for less than six months, and had spent a good deal of that time trying to figure out how the Product and Engineering team could deliver an enormous system that had been promised to a large client 18 months ago anywhere near on time. The team and I had spent hundreds of hours meeting with the customers, understanding their requirements, discussing system architecture, estimating our work, and building the foundation, but we were at a loss. If each of our engineers worked hundred-hour-weeks for the next five months, we’d still be late.

My boss, who had closed the deal, is one of the smartest, hardest working people I’ve ever known, but he could be scary. Much of his career has been spent willing impossible things to happen and then working tirelessly to make them possible. I dreaded telling him that the project would be late, and since I was relatively new in my role, I sought advice from other members of the Executive team. “I wouldn’t do that,” our VP of Engineering said, “it’s going to make him angry, and it’s going to make you look bad.” “Avoid that discussion at all costs,” our CFO told me, “find a way to deliver.” But I’d done the math, and there was no way. I had to let him know.

At our next touchbase, I approached the conversation with my boss cautiously. “We’re going to be late,” I said, “by at least six months.” It was not a situation where we could force people to work more. There were more hours of work to do than there were hours remaining on the calendar. I’d push the team as hard as I could to deliver quickly, but we needed to start resetting expectations with the client. I knew it was terrible, but we had no choice.

I don’t remember all the things my boss said, but I remember the overall message: we were in this situation because the team didn’t fully appreciate the commitment they’d made, because they weren’t wiling to put in the work, and because I wasn’t pushing them hard enough.

“Everyone warned me not to tell you this,” I said, “but whether or not you want to hear it – or are able to hear it – doesn’t change the situation we’re in. The only thing it changes is what we do about it. If we’re going to work together,” I continued, “I need to be able to tell you these things. I need your help.”

It would be a gross oversimplification to say that everything changed in that moment, or that my boss suddenly accepted what I was telling him without asking lots of hard questions, pushing back, and fighting like hell to stay on schedule. He did all those things, and he was right to do them. But from that day on, we were a team, in it together. And what more could I want from one of the smartest, hardest working people I know?

Clear communication and active listening are good too

Communicating clearly and listening actively are critically important skills, both at work and in the rest of our lives. This post isn’t about either of those things. This post is about why leaders need to listen to their people specifically when they don’t want to hear what they’re saying. When the news is bad.

I could write endlessly about how our inability to face facts that don’t align with our preconceived notions is hurting our relationships and our country, or about how social media creates an echo chamber that threatens to destroy democracy and the world. Fortunately, lots of books and articles on these subjects already exist, saving me an enormous amount of time and energy. 😉 Instead, here are a few thoughts on why listening to the things we don’t want to hear makes us better, more effective leaders.

Reason 1: It Helps Us Build Better Teams

Several years ago, I wrote about Google’s Project Aristotle and the importance of psychological safety at work. People who are free to communicate openly, without fear of criticism or attack, are more likely to tell you what’s really happening. They’re also more likely to take chances.

Blameless postmortems, which Google describes as those that “focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior,” get at the same thing: when people can openly discuss issues without fear of being berated or losing their jobs, they can be less afraid, more truthful, and more creative.

Reason 2: It Builds Trust

Relatedly, have you ever tried to trust someone who only wanted some the facts? How confident can you be that, when things get tough, your boss – who only has half the story – will have your back? Trust requires openness, and openness requires listening to the things we don’t want to hear and responding in open, helpful ways.

Reason 3: It Makes Us Smarter

The conversation I had with my boss provided the perfect entry point for lots of gnarly, detailed conversations about the business and how my team worked. Through those, I learned more about my company’s sales process and the seasonality of our business, which helped me get better at planning our work. And my boss learned more about the system limitations and people issues I was dealing with. This information made each of us smarter, and – as a result – better at our jobs.

Reason 4: It Makes Us Proactive, Not Reactive

There are very few good surprises at work – even bonuses generally come on a schedule. Typical work surprises involve things like projects being late, expenses being too high, and people leaving. I can’t think of a situation in which I wish I had less to time to understand an issue, formulate a plan, and react appropriately. Can you?

Lots of surprises happen because employees are afraid to share bad news. Which leads me to my next point…

Reason 5: It’s Probably Something We’ll Have to Have to Deal With Eventually

Some problems go away with time. Most don’t. On the morning of March 11, 2020, I told our division leader that I’d been reading up on Covid-19 and I thought we were going to have to go to remote work sooner than we’d expected. He angrily dismissed my concerns and sent me away. Four hours later, corporate headquarters shut us down. The lesson is clear: if you don’t deal with it now, someone else might deal with it for you later.

Reason 6: It Makes Us Part of the Solution

You know who the team turns to when things go south? People who genuinely want to help. When my teams tell me something’s gone wrong, my first question isn’t “how did this happen?” but “how can I help?” (We’ll have time for the blameless postmortem later.)

What Do You Think?

Those are a few of my thoughts. Now I’d like to hear some of yours. Does my experience match yours? Do you disagree? Have you ever had a boss who was great at receiving bad news? What did they do that made them great?

And what about you? How do you respond when somebody tells you something you don’t want to hear? I’d love to know.

Donald Trump, Job Applicant

4 Replies

Screen Shot 2020-08-17 at 9.00.38 AM

I’m not the first person to point out that if Donald Trump had a “normal” job, he’d have been fired by now. No HR policy would allow his behavior, and no Board of Directors could withstand the scrutiny, regardless of how much money he was making the company. A recent Business Insider article titled “What if Your Boss Acted Like This?” put it this way:

Imagine your boss did this: 

You send him a memo about a life-or-death issue for the company, and he doesn’t read it. He has regular calls with firms you’re doing deals with, but he doesn’t prepare for them, and instead spends the whole call talking about himself, or insulting the person he’s talking to. He commits an egregious, humiliating screw-up one morning, then turns his phone off and plays golf, leaving everyone else to clean up the mess.

These are not hypothetical examples. This is quite literally an account — taken from a single day! — of how Donald Trump does the job we hired him to do, and that we pay him to do.

But Donald Trump doesn’t have a “normal” job, and the only way he can be “fired” is if the American people vote him out. In fact, Donald Trump has never actually even had to  apply for a job (if you think running for president counts, compare that with any job interview you’ve had). So I started to wonder: what would happen if he did?

An interesting resume 

Imagine it, if you can: Donald Trump, fresh off his tour as President of the United States, sending out resumes in the hopes that one of the companies he’s considered buying over the past 50 years might hire him instead. The jobs I hire for, typically team leaders, product managers, product designers, and software engineers, are somewhat specialized, and require a fair amount of experience, but let’s face it: Trump’s resume is pretty interesting, so I might bring him in regardless.

The Interview

The interview here is, of course, imagined. Trump’s words are his own, pulled from interviews and statements he’s given in the last five years, with links to their original sources. My questions aren’t actual interview questions, but I think they get the job done.

Lee: What makes you a the best candidate for the job?

DJT: ….Actually, throughout my life, my two greatest assets have been mental stability and being, like, really smart. I went from VERY successful businessman, to top T.V. Star…to President of the United States (on my first try). I think that would qualify as not smart, but genius….and a very stable genius at that!

Lee: That sounds impressive. And that makes you the best candidate?

DJT: So great looking and smart, a true Stable Genius!

Lee: Um, okay. Accountability is a big deal to me. Tell me about a time when you took responsibility for something that didn’t go well.

DJT: [Silence]

Lee: Maybe related to the coronavirus?

DJT: I don’t take responsibility at all. This horrible disease was sent to us by China. It should not have been sent. They should have stopped it. They could have stopped it.  They didn’t. And the entire world has gotten infected, and a lot of countries are going through a lot right now.

Lee: Once it was clear that coronavirus was here, and that we needed to deal with it, how did you see the role of the federal government versus the states?

DJT: The states’ testing is up to the states to do, which will implement the test and logistically coordinate the tests.

Lee: “The states’ testing is up to the states to do”? That’s not really saying anything at all.

DJT: Similar to the situation with ventilators, states need to assess their complete inventory of available capacity. Some states have far more capacity than they actually understand. And it is a complex subject, but some of the governors didn’t understand it. Not simply ask the federal government to provide unlimited support.

Lee: So the states should not ask the federal government for support?

DJT: The authority of the President of the United States, having to do with the subject we’re talking about, is total.

Lee: I’m not sure that’s true, but let’s assume – just for a minute – that it is. How would you rate yourself in your handling of the coronavirus? I mean, the U.S. has already had more than 5.5 million cases, with more than 170,000 deaths.

DJT: Nobody has done anything like we’ve been able to do. And everything I took over was a mess. It was a broken country in so many ways. In so many ways. We have done a job, the likes of which nobody has ever done.

When I took this over, it was an empty box. We didn’t have testing. We didn’t have anything. We had a broken system there. We had a broken system with stockpiling. We had a lot of broken systems. And I’m not just blaming President Obama. You go long before that.

Lee: I’m still trying to figure out which role on the team might be the best fit for you. Your responses don’t exactly scream “engineer.” What job on the team do you think you’d be best suited for?

DJT: I don’t know if you know this but probably 10 years ago I was honored. I was the man of the year by I think somebody, whoever. I was the man of the year in Michigan, can you believe it? Long time.

Other countries come to see me, all of their leaders they say, sir, first thing, sir, congratulations on your economy. We’re trying to do the same thing. Congratulations sir. And I say you think Hillary could do this? I don’t think so.

Lee: Are you talking about Hillary Clinton? I’m not sure what this has to do with her, and we don’t have an opening for “man of the year,” but since you’re focused on the economy, maybe a job in Finance? Although it’s been extensively reported that, under your leadership. the US economy is suffering its biggest contraction in 75 years. That doesn’t make it sound like you’d be an asset to our Finance team.

DJT:  It was just put out that the United States economy added almost 5 million jobs in the month of June, shattering all expectations. The stock market is doing extremely well, which means, to me, jobs. This is the largest monthly jobs gain in the history of our country. The unemployment rate fell by more than 2 percentage points down to just about 11 percent. We started at a number very much higher than that.  As you know, we broke the record last month, and we broke it again this month in an even bigger way.

Lee: This certainly seems like good news to me. All this talk about jobs makes me think you might be a fit for our HR department. Like other companies, we’re working hard to be anti-racist, and as a Minneapolis-based company, we were sickened by the murder of George Floyd.

DJT: All Americans were rightly sickened and revolted by the brutal death of George Floyd. My administration is fully committed that for George and his family, justice will be served.

Lee: I’m so glad to hear you say that, I was nervous you were going to say something about there being “fine people on both sides.”

DJT: Hopefully George is looking down right now and saying, “This is a great thing that’s happening for our country.” This is a great day for him. It’s a great day for everybody. This is a great day for everybody. This is a great, great day in terms of equality. It’s really what our constitution requires and it’s what our country is all about.

Lee: How on earth can this be a great day for a man who was brutally murdered by police?

DJT: What we’re announcing today is a tremendous tribute to equality. We’re bringing our jobs back. When we had our tremendous numbers. And when we had just prior to the China plague that floated in, we had numbers, the best in history for African American, for Hispanic American, and for Asian American and for everybody. Best for women, best for people without a diploma, young people without a diploma. I mean so many different categories. Our numbers were the best in almost every category.

Lee: I notice you mentioned women.

DJT: You know, I’m automatically attracted to beautiful — I just start kissing them. It’s like a magnet. Just kiss. I don’t even wait. And when you’re a star, they let you do it. You can do anything. Grab ’em by the –

Lee: [Interrupting] So definitely not a job in HR. Wow, look at the time! Thanks so much for coming in. We’ve got a few other candidates to talk with, but you should expect to hear from our HR team within a few days.

Screen Shot 2020-08-25 at 7.59.43 AM

Unqualified for any job

There you have it. My imagined interview, with answers pulled from real interviews, speeches, and Tweets. My goal was not to be comprehensive – I barely scratched the surface – but you get the idea. You can’t make this stuff up.

And yet, much of what Trump has said, even here, is made up. Recent data shows that the President tells more than 23 lies every day, a number that has increased since the start of COVID-19.

Setting aside the bluster, Trump’s record as a President is clear, consistent, and public. So is his record as a businessman. A quick internet search will give you the facts related to his handling of race relations, the coronavirus, his record on job growth, the state of the economy, what he’s done to the environment, the company he keeps, and who has benefitted from his policies. It will also reveal that Trump has golfed 135 times since taking on the presidency at a cost to taxpayers of approximately $140 million, and that he has openly used the highest office in our country to line his own pockets.

If, after all of this, you’re still feeling good about a second Trump presidency, consider this: if Donald Trump showed up at your place of business (office, fire station, convenience store, restaurant, etc.) for an interview, what job would he be qualified for? What job would he be good at? What job would you give him? If your answer, like mine, is not a single one, then is he the right person to run our country?

A quick word about estimating work

2 Replies

issues-facing-project-managers-cartoon

A Google search for “creating accurate estimates for development work” yields more than 121 million results. A Google search for “why are teams so bad at estimating development work?” yields more than 47 million. If there’s one thing we all know about estimates, it’s that they’re almost always wrong. The reasons for this are well documented:

  • No two developers have exactly the same skill set or develop at exactly the same speed
  • Code issues are difficult or impossible to predict
  • Availability of other project resources (UX, QA, etc.) can be an issue
  • And so on (this article does a good job of outlining more)

And yet we continue to estimate, to make promises and commitments, and to convince ourselves that these wildly optimistic guesses (because they’re always wildly optimistic and they’re always guesses) are more than just that. I don’t need to add to the many millions of Google search results on this topic, but I do want to highlight the clear and direct connection between the commitments we make and our ability to give our teams work that’s both achievable and manageable.

Every product leader I know actively tries to avoid setting deadlines and making commitments, partly because we know our estimates are inaccurate, and partly because we know that deadlines don’t help teams create better products. And yet, making commitments is often unavoidable. When we’re in this situation, I like to remind my team of one very important fact: nobody outside of our team actually knows how long it takes to do our work.

There are lots of strategies for padding development estimates (a Google search for “how much should we pad our development estimates?” yields 35 million results), but this isn’t my point. My point is that, in an effort to force our estimates into pre-determined timelines, we sometimes leave out things that are critically important, like QA and UX. Instead of estimating what it would take to deliver a quality project, we jump right to how we’ll hit a deadline. When we do this, we miss all sorts of great opportunities to negotiate – we give up before we even get started. We also make it impossible for our teams to deliver a quality product on time.

Nobody outside of our team actually knows how long it takes to do our work. This gives us the power to estimate our work as it should be, and to include all the critical pieces that are sometimes thought of as nice-to-haves. It also gives us the chance to bring our business partners along, to help them understand what it takes to build great software, to enlist their help when making trade-offs, and to get their buy-in and support for the recommended approach.

Let’s not forget to take advantage of it.

 

Feeling overwhelmed? Channel Kurt Vonnegut and get to work.

Leave a reply

Screen Shot 2018-07-03 at 10.02.35 AM

Every company I’ve been a part of has had more work to do than people to do it. (Has there ever been a company with too many people and not enough work to do? Not for long.) Sometimes the gap between need and output is relatively small, and a team can almost keep up, but more often – especially if a company is aggressive about identifying opportunities – the gap is much, much bigger.

This can lead to lots of frustration. In my last post, I wrote about how great leaders help their teams win by defining success in ways that are achievable. In this post, I’ll focus on getting to work and making it manageable.

My current product organization is responsible for a lot more products than we have teams, including nearly a dozen products built by companies we’ve acquired over the past two years. Inevitably, at any given time, there are products we’re not working on, or even thinking much about. This can be hard to stomach. But the reality is that we’ll never have enough people or time to adequately address all of the issues and opportunities in front of us. In order to wrap our heads around the challenge, we need a different way to think about it.

That’s where I turn to Kurt Vonnegut.

In his article, On the Work to be Done, first published in the May 28, 1998 issue of Rolling Stone magazine, Vonnegut writes brilliantly in the topic of getting to work. Although he’s writing about building a better world, Vonnegut’s words apply to building better software too. Here goes:

As I read the Book of Genesis, God didn’t give Adam and Eve a whole planet.

He gave them a manageable piece of property, for the sake of discussion let’s say 200 acres.

I suggest to you Adams and Eves that you set as your goals the putting of some small part of the planet into something like safe and sane and decent order.

If God had given Adam and Eve the entire world, what would they have done? It’s easy to imagine them running naked through the jungle, shaking their fists, fighting back tears, screaming, “we’re not ready to take care of all these animals – we don’t even have clothes yet!”

In Vonnegut’s telling, God doesn’t overwhelm Adam and Eve, he gives them “some small part of the planet” – just as much as they can handle.  Adam and Eve weren’t responsible for the entire planet, I remind my team, and you’re not responsible for the entire platform. You’re divided into product teams for a reason, so that one group can focus on financial management while another focuses on mobile applications and so on. If you try to eat the elephant (or the forbidden apple?) in one bite, you’ll get sick. Vonnegut continues:

What painters and sculptors and writers do, incidentally, is put very small properties indeed into good order, as best they can.

A painter thinks, “I can’t fix the whole planet, but I can at least make this square of canvas what it ought to be.” And a sculptor thinks the same thing about a lump of clay or marble. A writer thinks the same about a piece of paper, conventionally eleven inches long and eight-and-a-half inches wide.

A product manager is responsible for creating an awesome product. A user experience designer is responsible for creating an awesome experience. A software architect is responsible for creating an awesome technical architecture. And so on. Often this work happens incrementally, over time. The good and bad news? The work is never done.

So here’s the challenge: take your 200 acres (or lines of code) and put them in decent order. Make them exactly what they’re meant to be, or make them even better. After that, there’ll be another 200 acres to worry about, and then another 200 acres after that.

That sounds manageable, right?

Google’s Project Aristotle and psychological safety

4 Replies

stressed_2580348b-large_trans_NvBQzQNjv4BqpJliwavx4coWFCaEkEsb3kvxIt-lGGWCWqwLa_RXJU8

After 18 months, the team was still struggling with the project. Lots of work had been done, but most of it was unfocused, and even at this late date, no one could articulate a clear set of requirements. Hitting the deadline, an aggressive goal from the start, was starting to feel like an impossible task. The team knew they were in trouble.

As the team started to miss internal deadlines, the rest of the company began to get concerned too. Meetings were called, presentations were given, and more deadlines were set. Unsurprisingly, these new deadlines – piled on top of old deadlines that were already being missed – were missed too.

People from across the company offered to help the team in any way they could – time, expertise, snacks – but the team politely declined. They knew that failure was not an option, but they didn’t know how to accept the help that was being offered. Worse, they were scared. In order to avoid painful conversations, they pretended they had a plan. What the team really needed was to talk with the customer, to establish a definitive set of requirements to deliver. But how could they tell the customer 18 months into a 2 year project that they still didn’t know what they were supposed to be building? They decided they couldn’t. Better to keep their jobs for the next six months than to risk being fired immediately.

The Emperor has no clothes

Everything changed when a new Product Manager came into the mix. On day one, he said the emperor had no clothes. On day two, he said we were back at square one. Then he started working with the team to gather a definitive set of requirements.

“How is it possible you’re just doing that now?” stakeholders asked, “this should have happened months ago.”

“You’re right, the new Product Manager said, “it should have. But since it didn’t, we’re going to do it now.” On day five, we had a meeting scheduled with our customer to make sure we had the requirements right.

One week after our new Product Manager was hired, we had a plan. Somehow, throughout the interview process and his first week, nobody told our new Product Manager he was supposed to be too scared to do his job. As a result, he wasn’t.

Google’s Project Aristotle

I recently re-read Charles Duhigg’s terrific 2016 New York Times article, What Google Learned From Its Quest to Build The Perfect Team. Here’s the setup:

Five years ago, Google — one of the most public proselytizers of how studying workers can transform productivity — became focused on building the perfect team. In the last decade, the tech giant has spent untold millions of dollars measuring nearly every aspect of its employees’ lives. Google’s People Operations department has scrutinized everything from how frequently particular people eat together to which traits the best managers share.

The company’s top executives long believed that building the best teams meant combining the best people. They embraced other bits of conventional wisdom as well, like ‘‘It’s better to put introverts together,’’ or ‘‘Teams are more effective when everyone is friends away from work.’’ But, ‘‘it turned out no one had really studied which of those were true.’’

In 2012, the company embarked on an initiative — code-named Project Aristotle — to study hundreds of Google’s teams and figure out why some stumbled while others soared.

28mag-teams1-facebookJumbo-v2

The article goes on to describe how the test was constructed and how challenging it was for researchers to identify which group norms consistently characterized successful teams. After studying hundreds of groups over several years, however, researchers made a breakthrough:

They noticed two behaviors that all the good teams generally shared. First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’

Second, the good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues. 

Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety, or ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up. It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

This finding is both intuitive and incredible. The highest performing teams, it tells us, may not have the smartest people, or the clearest goals, or the most inspiring leaders, or the clearest focus. The highest performing teams are those in which people feel “comfortable being themselves.”

Learning from failure

Psychological safety is not the only thing that makes a team great – according to the Times article, “there were other behaviors that seemed important as well – like making sure teams had clear goals and creating a culture of dependability.” But can a team be great if they don’t have each other’s backs? Can a team be great if they’re afraid to take chances? Can a team be great if they blame each other when things go wrong?

Google’s research is aligned with lots of great writing about learning from failure. Great teams take big swings, and when they miss (which all teams do), they learn from their mistakes and move on together. The conclusion is clear: as leaders, our job is to make sure our people feel safe enough to take chances, to challenge each other in productive ways, and to bring their very best ideas to work without the fear of being wrong. That’s the way we’ll build high performing teams, and the way our high performing teams will do amazing things.

Ed Catmull’s “Creativity Inc.” and one of the best work things I’ve ever done

Leave a reply

41xs4vbcTPLI’m not alone in my love for the book Creativity Inc., written by Pixar President Ed Catmull. Others have called it “the best business book ever written” (Forbes) and “the most practical and deep book ever written by a practitioner on the topic of innovation” (Harvard Business School). I read the book several years ago and have returned to it lots of times, determined to figure out how to leverage more and more of Catmull’s thinking to make myself and my team not only more creative, but better in lots of ways. (I won’t, however, be incorporating all of Catmull’s past business practices.)

Of all the great ideas in the book, the one that struck me most immediately went I read it was something Catmull calls Notes Day, a day when all of Pixar’s projects stop, and all employees share their thoughts on how the company operates – and how they can do it more effectively. The need for this arose from what Catmull describes as an environment in which “more and more people had begun to feel that it was either not safe or not welcome to offer differing ideas.” He goes on:

Increasingly, we sensed that our people, having enjoyed years of success, were under a great deal of pressure not to fail […] As a company, our determination to avoid disappointments was also causing us to shy away from risk […] One of our greatest values – that solutions could come from anyone and that everyone should feel free to weigh in – was slowly being subverted under our watchful eyes. And only we could correct it. (p. 279 – 280)

Recently, I had the good fortune to attend a conference where Continuous Delivery expert Jez Humble was speaking. Jez said that, while we tend to copy the things successful groups are doing, it’s not the things themselves, but a team’s ability to problem solve that creates real change within an organization. When Catmull looked around, he saw teams of people who were suddenly afraid to problem solve. And so Notes Day was born.

I recognized my own team and situation in Catmull’s words. We were an organization that valued transparency, debate, creativity, and continuous improvement, and we’d incorporated lots of best practices into our normal operating rhythms, including daily standup meetings for each product team and retrospectives after each release. Still, it was inevitable that we’d have to find ways to revisit and reinforce these ideals – to get people talking about the things that weren’t working well. We were widely recognized throughout the organization as high performers, and nobody wanted to mess that up. To make matters worse, although I spent lots of my days working at a table with my team, I was still missing out on too many important things. People tend to “protect” the boss.

When I read about Notes Day, I wondered if it was something that could work for my team. When I approached key leaders in my area, they loved the idea – we hadn’t yet tried a Retrospective of Retrospectives with our team, but since we were all very comfortable with post-release retros, this felt like a great way to frame up the activity. In a Retrospective of Retrospectives, teams come together to share their successes and opportunities, focusing on how to improve performance across the entire team or overall program. It was exactly what I’d been looking for.

My cohorts and I started to frame up an offsite for our team (about 65 people at the time, including developers, product managers, system architects, BAs, QA analysts, project managers, and UX engineers), knowing that if we did it right, we’d both gather critically important information and give the team a shot in the arm. What we came up with was a two-day conference of sorts. It turned out to be one of the best work things I’ve ever done.

One of our two days was spent recapping the year, discussing new project ideas, hosting guest speakers, presenting “Lightning Talks” (5 minute presentations on anything the presenter chose), and participating in a Q&A session with our CEO. The goal of these sessions was to celebrate our successes, tie our work to company goals, learn new things, laugh together, and get pumped up for the new year. Our other day was dedicated to the Retrospective of Retrospectives.

The Retrospective of Retrospectives

Preparation for the Retrospective of Retrospectives started weeks before the event itself, with some pre-work – we asked each team member to bring a list of things that went well throughout the year and things that didn’t. On the day itself, we split the team into pre-determined groups of 8-10 people, ensuring that each functional area (devs, product managers, etc.) would be represented and that none of them would dominate the conversation. Then we asked each group to conduct their own, smaller retrospective, identifying successes and opportunities, voting on which opportunities were most pressing, and coming up with potential solutions. Finally, these solutions were presented to the larger group, and team members signed up for the opportunities they were most passionate about. We were careful not to gloss over the hard things – in order to be successful, this needed to be a warts-and-all conversation. We were looking for problems to solve and ways to be better. Over the course of the next year, each group was responsible for updating the entire team on their progress.

After just two annual meetings, we’re still tweaking the formula for both the retro and the followup. For the retro, the challenges include creating a structure that allows for cross-team sharing and finding the right areas of focus. For the follow up, the challenges include trying to find the right balance between holding people accountable and giving them the freedom to change course as new, bigger opportunities arise.

I know we’ll be refining our Retrospective of Retrospectives this year – our team has grown, and we need to find new ways to engage and empower people across multiple capabilities. But it’s only September, and the team is already looking forward to the event. We’re gathering our thoughts, reflecting on this past year’s successes and challenges, refining our roadmaps, and lining up guest speakers. Best of all, we’re getting ready to have hard discussions about what’s not working well and how we can improve as a team, warts-and-all.

I can’t wait.

 

Encouraging people to stop the line with both carrots and sticks

2 Replies

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.

Carrots

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.

Sticks

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.

 

Why is it so hard to stop the line?

3 Replies

taiichi-ohno-lean-manufacturing-1

Those of us who’ve adopted (and adapted) Lean software techniques owe a debt to Eiji Toyoda, and especially to Taiichi Ohno, who developed the Toyota Production System (TPS) and forever changed the way manufacturing – and eventually much of software development – works. According to Wikipedia:

TPS is grounded on two main conceptual pillars:

  1. Just-in-time – meaning “Making only what is needed, only when it is needed, and only in the amount that is needed”
  2. Jidoka – meaning “Automation with a human touch”

Core to jidoka is the concept of “stopping the line,” which means that when someone at Toyota identifies a problem, they’re required to stop production and resolve the issue. This ensures problems are addressed immediately, when they’re easier, less expensive, and less frustrating to fix.

Our eCommerce team has embraced this way of thinking. Our agile product teams are familiar with the Toyota story, and they understand the importance of identifying problems early. They sit together at tables, which makes collaboration easy, and they have daily stand-up meetings to make sure everyone’s on the same page. Best of all, they’re aligned around common goals, so they have the same motivation to improve the customer experience and their KPIs.

So why won’t they stop the line when they see an issue?

Stopping the line is really, really hard

Recently, my team released a couple of new features that weren’t up to our usual standard – experiences that were a little bit clunky. In both cases, after the projects were complete and the new functionality was deployed into production, we removed the new functionality from our site, sending the teams back to the drawing board. Weeks later, we’re still in the process of rebuilding these features, and we’re going through the work in great detail as a team to make sure we get it right.

Every single member of the team knew – weeks before launch – that the experience was less-than-perfect. And every single member of the team had been coached multiple times to stop the line. Even further, if you asked any member of my team if they understood the importance of stopping the line – if they agreed with it conceptually – every one of them would have said yes. And yet, nobody did it.

I asked three people why, and they all said some version of this:

Our team is working on becoming a well-oiled machine, and I don’t feel comfortable slowing things down.

The machine

Earlier this week I attended DevJam’s excellent Product Conference, and I was glad to hear its founder David Hussman discuss how product and agile are evolving. “We’ve gotten really good at building the wrong thing faster,” he said, and I couldn’t agree more.

My team was built for speed, and although I kept telling them to stop the line, I also told them a lot of other things:

  • “This new functionality is going to add a lot of revenue for our business.”
  • “You’ve got a long backlog.”
  • “If we get this done pre-holiday, it’ll be great for the bottom line.”
  • “Our Marketing team really, really wants this now.”
  • “It’d be great to get both of these projects done next quarter.”

By now you get the idea, and hopefully you see the problem. And it wasn’t just me. My team supports a lot of brands, and the brand owners, marketers, merchandisers, technology teams, senior executives – everyone, really, was in some way or other telling our product team to do more, faster.

In response, we became a machine built for speed. We got good at getting a lot of projects done, and we found a way to set and meet the goals we had before us. We implemented Test Driven Development (TDD), built automated tests, and found ways to get closer and closer to continuous delivery. And I’m convinced that every one of these things was – and is – the right thing to do.

The problem is that we did them at the expense of building great things.

In my next post, Encouraging people to stop the line with both carrots and sticks, I’ll describe what we’re doing about it.