The importance of being present

being-present

Whatever you’re doing, right now, learn to focus completely on doing that one thing. Pay attention: to every aspect of what you’re doing, to your body, to the sensations, to your thoughts. (Source: Zen Habits)

Being completely, totally present is an incredibly important – and often difficult – task. My spouse and kids (and yours too, I’m guessing) will tell you it’s nearly impossible to keep my attention when work’s busy and my phone’s buzzing, and that it’s only slightly less challenging when work’s not busy and my phone’s not buzzing, because who knows what fascinating information might be delivered to me or my Facebook stream at any moment. I’d tell you the same thing about them, of course, and they’d agree.

Being present may be more challenging than ever, but distractions were not invented by Apple. I don’t know what my parents did when I was on the playground as a little boy, but I know it wasn’t giving me their undivided attention. Maybe it was reading magazines, or etching words into stone tablets.

What in the world did people used to do when they were waiting in line – just wait?

At work, being present for our co-workers requires a similar focus. I’ve gotten good at asking co-workers to “wait just a second while I finish this email so I can give you my full attention,” and it’s helped a lot. But as a leader, being present means something a little bit different, a little bit more, which I want to explore.

What does it mean for a leader to be present?

Did you ever notice how easy it is to say negative things about someone who’s not around? “My boss is completely disconnected from the business,” you might say, or “she wouldn’t make those decisions if she wasn’t so clueless.” When the object of our scorn is in another office – or on vacation, or in a board meeting – it’s easy to assume the worst. Things are different – and more complicated – when our target is around, because it’s much harder to dislike a real person than it is to dislike a caricature of one.

When leaders are hidden away in their offices, teams start talking. They assume their leaders are focused on spreadsheets or board decks or expensive trips or golf. They assume their leaders are uninterested in the day-to-day workings of their business, or in the people on their teams. They assume their leaders are clueless.

When times are good, this can be just a minor annoyance: the people in the trenches tend to feel supported, empowered, and comfortable in the knowledge that they’re working towards a larger goal. They’re less concerned about their work being recognized because they know they’re part of a winning, growing team, and trust isn’t that big a deal. They’re also likely to get better raises and bonuses, which tend make people feel better, even if just for a little while.

When times are bad and leaders are not present, it’s a recipe for disaster. Without context, workers tend to assume the worst about their company and its leaders. They assume management is clueless, focused on all the wrong things and making bad decisions. They assume their own excellent work is not being noticed, and the message that “we need to do more with less” falls on frustrated ears. They may even assume their jobs are at risk.

Did you ever notice how easy it is to say negative things about someone who’s not around?

Bad news doesn’t have to be bad

I give my team bad news all the time. Here’s why:

Context helps teams make better decisions
When business is bad, I may need my team to think differently, reprioritize work, be more creative, or collaborate with others throughout the company. Without the overall business context, they might not know how or why.

Sharing bad news builds trust 
Every company has its ups and down – pretending yours doesn’t won’t fool anybody. When we trust employees enough to give them bad news, they trust that we’re telling the truth when things are good. They may ask hard questions, and we should want them to. Hard questions give us an opportunity to address real concerns.

People rise to the occasion
Every company I’ve been at, from those with 100K+ employees to those with only 4, has had a “rise above” moment. Adversity can bring out the best in people and teams, but only if they understand the context, the goal, and what needs to be done. Most people want to help, and will work much harder when they’ve been challenged appropriately.

Get out of your office!

Being present means being seen, and that means leaders need to get out of their offices, especially when work is hard. When we’re physically present, our teams know we’re mentally present too. Even if our jobs require us to travel often, we can – and must – make our presence felt.

This is hard to do! When things are bad, we don’t want to go on a “world tour” to tell people about it. We don’t want to tell our teams that we might have layoffs, or that we might not get our bonuses. We want to retreat to our offices and avoid hard conversations that will make people unhappy. What if they’re demotivated? What if our best people get freaked out and quit?

But the alternative is much worse. If we don’t tell our teams what’s really happening in our business, they’ll assume the worst, and they’ll make things up. When we miss plan, they’ll think it means that the company is going out of business. When we go on business trips, they’ll think we’re flying on private jets and drinking champagne. When a board meeting lasts an extra hour, they’ll assume layoffs are coming.

Worst of all, our teams won’t keep these thoughts to themselves. They’ll share their negative thoughts with others on the team, and with their friends at other companies. They’ll share their negative thoughts with recruiters, and at networking events, and with their buddies and their families. They’ll post their feelings on Facebook, and Twitter, and Glass DoorComplaining can be cathartic, but a workforce of people out airing their dirty laundry in public can be disastrous.

Notice when people do good work

Finally, being present isn’t just about being there physically, it’s about truly understanding what’s going on. Sometimes that means ignoring the big picture and focusing on great work that’s happening within the teams. I used to have a boss who got so distracted when overall business was bad that he couldn’t even see they great work my team was delivering. This was extremely demotivating. Hey! Over here! We just climbed Mount Everest! We increased conversion by 20 basis points! (Mom, get off of your iPhone! I lost a tooth!)

It’s a marathon, not a race

When we’re present for our teams, we acknowledge their problems, clear roadblocks, and celebrate their successes. We’re honest about business challenges that lay ahead, even if we’re selective when sharing specifics. We trust our teams to understand and to rally around our goals. We pay close attention to the specific work our teams are doing. When the work is great, we tell them, and we connect their success to the success of the company. We make sure they know it matters.

Business is a marathon, not a race. Most employees can’t (and don’t want to) change jobs each time things get hard. They’ve already bought houses and organized their schedules, so they’re placing a bet on the company – and it’s leaders – for the long haul. The best thing you can do to honor that commitment is to show your face. That way your team knows that you’ve placed the same bet.

We need to talk about locker room talk

locker-room03fo2

Just a few weeks ago, more than 62 million Americans voted for the presidential candidate who said this:

When you’re a star they let you do it. You can do anything … Grab them by the pussy. You can do anything.

I don’t believe that most people think it’s okay to “grab them by the pussy,” at work or anyplace else. And yet, 62 million is a lot of votes, so there are things we need to talk about. Here’s the above quote with a small tweak that’s more real than we’d like to think:

When you’re the boss they let you do it. You can do anything … Grab them by the pussy. You can do anything.

Make no mistake: “the boss” I’m referring to is a man. In today’s Fortune 500, only 4% of the CEOs are female. According to Fortune, “for women at the top levels of American business, it can sometimes feel like every step forward is followed by two steps back.”

No kidding! I recently had the pleasure of meeting with Nancy Lyons, the amazing CEO at Clockwork in Minneapolis. “I’m so sick of hearing about the glass ceiling,” Nancy said, “it’s not glass, it’s concrete.”

Grabbing them by the whatever 

As the “you can do anything” comment traveled through the media this past October, Trump was forced to explain himself:

“This was locker room talk. I am not proud of it. I apologized to my family and the American people,” Trump said. “I am embarrassed by it and I hate it, but it’s locker room talk and one of those things.”

“For the record, are you saying that what you said on the bus 11 years ago, that you did not kiss women without consent or grope women?” Cooper said.

“Nobody has more respect for women than I do,” Trump replied.

For the sake of discussion, I’m going give our president-elect the benefit of the doubt and take his comments as crass, rather than predatory. But I’ve still got questions. Can someone both respect women and say these kinds of things at the same time? And does saying these things, even as a joke, sometimes lead to doing them? In Malcom Gladwell’s terrific 2015 New Yorker article “Thresholds of Violence,” the author writes: 

What explains a person or a group of people doing things that seem at odds with who they are or what they think is right? […] Social processes are driven by our thresholds—which [Stanford sociologist Mark Granovetter] defined as the number of people who need to be doing some activity before we agree to join them.

In other words, we might not jump off a bridge just because one friend is doing it, but if lots of friends are doing it, that bridge might not look so bad after all.

Consider “locker room talk” in this context. One man saying crass things is an anomaly. A group of men in a locker room saying crass things creates an environment in which people start to say things “that seem at odds with who they are.” A locker room like that would not be a safe place for a woman.

And this kind of behavior is not confined to the locker room. According to the Trades Union Congress (TUC):

More than half (52%) of women, and nearly two-thirds (63%) of women aged 18-24 years old, said they have experienced sexual harassment at work, according to a new research from the TUC in collaboration with the Everyday Sexism Project published today [August 10, 2016].

In the vast majority of cases (88%), the perpetrator of the sexual harassment was male, and nearly one in five (17%) women reported that it was their line manager, or someone with direct authority over them.

The survey says that:

  • nearly one in three (32%) of women have been subject to unwelcome jokes of a sexual nature while at work
  • more than one in four (28%) of women have been the subject of comments of a sexual nature about their body or clothes at work
  • nearly a quarter (23%) of women have experienced unwanted touching – like a hand on the knee or lower back at work
  • a fifth (20%) of women have experienced unwanted verbal sexual advances at work
  • around one in eight (12%) women have experienced unwanted sexual touching or attempts to kiss them at work.

I don’t need to find additional sources to confirm what the TUC has found; these results will surprise nobody. The show “Mad Men” is not a time capsule, it’s a mirror.

15361-jessica-pare-pieza1

A few more words about locker room talk

Lots of men who spend lots of time in locker rooms have responded to Trump’s claim that his comments were just the usual “locker room talk.” From Time Magazine:

Many athletes condemned Trump’s caricature of the locker room. For example Robbie Rogers, a midfielder for the Los Angeles Galaxy, wrote on Twitter: “I’m offended as an athlete that @realDonaldTrump keeps using this “locker room talk” as an excuse.” Former NBA star Grant Hill wrote, “I’ve been in a lot of locker rooms, and what Trump said is not locker room banter.” Cleveland Cavaliers guard Dahntay Jones wrote, “Claiming Trump’s comments are “locker room banter” is to suggest they are somehow acceptable. They aren’t.”

This gives me hope, especially the part about this kind of talk not being acceptable. But even if these athletes have never heard this kind of talk in a locker room, it’s not enough, because a locker room is really just a proxy for lots of other places where men behave this way: bars, clubs, man-caves, and other places we’d rather not acknowledge – including offices.

The thing about these kinds of places is that women aren’t welcome, comfortable, or safe in them. So while we need to make sure we don’t treat our businesses like lockehemanwomanhatersclubr rooms, I’m not sure why we need to treat our locker rooms like locker rooms either. If we’re serious about equity and safety, we can’t.

Here’s what we can do, for a start: We can refuse to put up with people objectifying women or making crass jokes at work. We can stop saying things we wouldn’t want our wives to hear when we’re with “the guys.” We can refuse to look the other way, even when things are uncomfortable.

If this all sounds like yet another person arguing for political correctness, I’m okay with that. I’m not naive, and I know I have my own biases and behaviors. But I’m working on these things, and I’m going to fake it until I make it. I hope you will too.

The C-suite is largely reserved for men

So far, I’ve written about women feeling safe in the office, but this is a low bar – what we really want is for the office to be fair. A fair office is safe, of course, and includes gender equality in both career opportunities and pay. According to USA Today:

A survey by consultancy McKinsey and Facebook executive Sheryl Sandberg’s LeanIn.org group found that men are 30% more likely than women to be promoted from entry level to manager.

At the entry level, 54% are men and 46% are women. But at the manager level, 63% are men and 37% are women, and at the vice-president level 71% are men and 29% are women.

By the time they reach the C-suite — which includes positions like chief financial officer and chief operating officer — 81% are men and 19% are women. Representation is even worse for women of color, according to the study.

The fact that women are more likely to be sexually harassed at work and the fact that women are less likely to be promoted than their male counterparts may not be directly related. But these facts together help tell the story of a culture in which women are treated unfairly at work, and we need to do better.

There’s so much more!

I haven’t even scratched the surface of this issue. More stats:

A woman has a right to work in a safe place, free of harassment. She has a right to be treated fairly, to have opportunities to advance her career. She has a right to equal pay for equal work.

635965425787100211870840293_equal-pay-day

Equal pay for equal work

Here are a few ideas to help ensure that our businesses promote equal pay for equal work:

  • If you’re a people manager or in HR, review the salaries of your employees, their skills, and their experiences, and fix any disparities you see. If the disparity is due to poor salary negotiation, fix it anyway.
  • When it comes to promotions, go out of your way to make sure qualified women get the chance to prove their worth.
  • Consider replacing your company’s maternity leave policy with a parental leave policy. Maternity leave suggests that caring for the family is a woman’s job. Parental leaves evens the playing field, and implies no judgement.

This Quartz article  has a few more good ideas, specifically related to pay:

What the law could do
The law can mandate equal pay. For instance, in the US, equal pay regardless of gender was signed into a law by president John F. Kennedy in 1963, with the Equal Pay Act. It will be a while before equal pay for all is a reality.

What employers should do
Employers can adopt strict rules to ensure fairness, and effectively run businesses that guarantee equality of treatment. But, this is something society can’t count on. The obvious reason is that employers often perceive increasing wages beyond the minimum they have to pay someone to be against their economic self-interest, even though such a view is short-sighted at best.

What employees must do
Salary transparency is knowledge, and knowledge is the ultimate weapon to address pay inequalities from the inside. Do you know if your company pays you fairly? In that knowledge–knowing how much everyone around you makes–lies the key to know your value, and the fairness of your treatment. 

Will it cost companies more to compensate people equally for equal work? Absolutely. But what’s the alternative? Working for a company that relies on a gender discount to turn a profit? One more time:

When you’re a star they let you do it. You can do anything … Grab them by the pussy. You can do anything.

This kind of talk is not okay, whether it’s shared in the locker room or the board room. But it’s not just the talk that needs to stop. Whether we like it or not, we have institutionalized discrimination in the workplace. We can do better.

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

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

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?

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.

8 reasons my team is great (and keeps getting better)

quote-you-cannot-make-an-omelette-without-breaking-eggs-proverbs-309526

My current eCommerce team is among the best I’ve ever worked with. In the past year, we’ve launched four mobile apps, re-platformed three eCommerce sites without any downtime at all, made major strides towards continuous deployment, and much, much more. (Even if you don’t know what any of these things are, you’re impressed by now, right?) Much has been written about building great teams, of course, and this is in no way meant to be definitive. Still, I want to share a few of the reasons my team has succeed so far (in no particular order), and why we’ll continue to get better:

1: Everyone on the team is a business owner

It would be an exaggeration to say that everyone on the team is motivated by our KPIs in the same way, or that each developer, user experience engineer, and Product Owner feels the same passion for driving revenue. Still, we do a lot of work to make sure each person on our team understands what drives our business, and the items on our product roadmap can come from any person or team. We understand both what we have to do and why.

2: We define our own priorities

Continuing on the above theme, our product roadmap is largely driven by the team. Because we understand what drives the business, we have the flexibility to work on the projects that are most impactful, in the order that makes the most sense. There are times we have to justify our priorities – and we review them with our senior executives each month – but we own the roadmap, no question about it.

3: We like to solve hard problems

Being intellectually curious is a big deal. Our team is smart, and intensely focused when it comes to finding sustainable solutions to big, hairy business and/or technical problems. Sometimes this leads to frustration – we don’t always have time to do things right, and we all despise increasing technical debt – but, by and large, our team strives to do things right, and we’re up for any challenge that comes our way.

4: We persist!

We like solving hard problems, and we don’t give up. When we can’t figure something out, we keep at it. Sometimes we wrestle with a problem for weeks – or months – before finding the answer we were looking for. Sometimes we need to try a lot of things before getting something right.

5: Our leaders push us in the right ways

When we need a kick in the pants, we get one. When we need some space, we get that too. From top to bottom, our company and team leaders understand that empowering the teams to do our best work is critical to our success.

6: We test and measure everything we do

Measuring allows everyone to see where we meet expectations and where we don’t. New functionality is AB tested until it “wins” and we’re confident we haven’t introduced new problems into the system. We’ve got dedicated testing and analytics teams, and our Agile development teams wouldn’t even think of introducing new functionality without their involvement. Of course, we still make mistakes, but when we do…

7: We learn from our mistakes

You can’t make an omelette without breaking a few eggs. Building and running our own web platform is hard, and despite all the great testing and measuring we do, mistakes are inevitable. Because we encourage continuous improvement and innovation, we also favor blameless post-mortems and retrospectives during and after all projects. These allow us to truly understand where we’re most effective and where we still have opportunity to improve. We’re going to make mistakes, but we really don’t want to make the same ones twice.

8: We genuinely like each other

Who wants to spend all week, every week, with people they don’t know or like? Not me. Work is a big part of our lives, but it’s not everything. People go on vacations, have babies, experience loss, and root for baseball teams (they often do those last two at the same time). And people who like each other are there for each other when they need support – in their work and in their lives.

We’re not perfect

If some of this sounds a bit aspirational, it is. My team is far from perfect, and we don’t always get these things right. We get crabby, and frustrated, and annoyed by each other. We argue, we have egos, and we break more things than we’d like. Sometimes we focus on the wrong things, and we’ve been accused of moving too fast. But the foundation of our team is strong, and our core philosophies don’t change.

Do any of these ideas resonate with you? Are you part of a high performing team? If so, what makes your team great? If not, how can you get there? I’d love to hear from you.

Five rules for letting someone go without being a jerk

debbie

Debbie Fischer

In March, I wrote about the time I was fired. In April, I wrote about the kinds of behavior that can lead to getting fired. In May, I wrote about how to fire someone badly. It’s not that I’m obsessed with the firing process, it’s just that I’ve seen it done badly, and it turns out a lot of my friends have relevant experience in this area. Plus, it’s a part of work, like it or not. And it’s important.

Continuing on the theme, I recently had the chance to sit down with my super-smart friend Debbie Fischer, current therapist and former HR executive with 20 years of experience (Target, Disney, Campbell Mithun). Debbie’s got lots of experience letting people go, both for performance reasons and for layoffs, so I was especially interested in her thoughts on how to do it well. Here are a few tips from someone who knows:

Rule #1: Be efficient, but fair

Nobody in the history of the world has ever said they wished they would have waited longer to fire someone. And yet, when it comes to letting someone go, efficiency doesn’t have to be the primary goal. Debbie shared several examples of situations in which a firing manager was desperate to make a move immediately, but hadn’t ever taken the time to communicate issues or set expectations with their employee. Nobody likes performance improvement plans, but that doesn’t mean people don’t need a heads up when they’re not performing. Take the time to communicate with your employee. Let them know that things are not going well before you let them go.

Rule #2: If your company’s big enough to have an HR team, let them do their job

Yes, sometimes working with HR means extra paperwork, extra process, extra time, and what can feel like jumping through hoops. But HR plays a critical role in letting people go, and can help the situation go much more smoothly by providing guidance, coaching, structure, and experience. If the HR team is good, they can do it efficiently. They can also keep you and the company out of legal trouble.

There’s another good reason to include HR: professional courtesy. If you don’t keep your HR team in the loop, you’re telling them their expertise doesn’t matter, and you’re creating a lot more work for them, after-the-fact. Nobody likes being left out, and if your HR team has to clean up the mess you made, they won’t be happy. And – trust me – you want HR on your side.

Rule #3: Acknowledge that the situation sucks

Whether you’re laying people off or firing someone for performance-related reasons, letting someone go is a drag for everyone involved. In some ways, letting someone go is an acknowledgement of failure – failure to grow or develop an employee, failure to acquire new skills, failure to hire effectively, failure to keep a business unit afloat, failure to stop making racist jokes (you get the idea) – and acknowledging the reality of the situation can be a good thing. We may all find perspective over time, but getting fired is a major life upheaval that impacts people’s families, friends, and finances. We don’t have to pretend it’s easy.

Rule #4: Shut up!

People who are good at letting employees go are good at saying only what they need to say, nothing more. Debbie’s seen lots of managers drone on and on about their own experience, trying to provide perspective to someone who can barely hear the words. The best way to let someone go, according to Debbie, is directly. (In fact, she’s often coached managers to read their part from a script and then leave the room, leaving the tactical parts to HR.) Managers who keep the conversation going after letting someone go may be trying to make themselves feel better, but they often end up making the situation worse.

Rule #5: Remember that this is a small town

This is true in Minneapolis, and it’s also true in New York City: your town, your industry, and your network are smaller than you think. While I have conflicting thoughts on whether or not it’s okay to burn bridges, I have no conflicting thoughts about being kind and respectful at work and in life. Naturally, this includes letting people go. If you do it humanely, you stand a chance of saving a relationship. And in your town, your industry, and your network, there’s no guarantee you won’t be on the other side of the table next time around.

What do you think?

Do these rules match your own experience and ideas? Did I leave anything out? Have you got pointers based on your experience on either side of the table? Please let me know – I’d love to hear from you.

How to fire someone badly

File photo of Republican presidential candidate Drumpf gesturing and declaring "You're fired!" at a rally in Manchester

A few weeks ago, I posted about getting fired and why I deserved it. (I followed that up with a post about the need to complain at work, and how it can go sour.) In this post, a couple of smart friends share their experiences related to letting people go – and how it can go horribly wrong.

Laura Zabel, Executive Director at Springboard for the Arts, recounts a particularly challenging experience – her first firing:

It was a disaster. I let the person stay way too long and even convinced them to stay when they wanted to leave because they had been a great, engaged, high capacity staff person and I was certain they could get back to that place. I learned that just because a person was great at their job once doesn’t mean they are great at their job now, especially when it’s affecting other staff.

I ended up having to fire this person in the moment – I realized that they had been interfering with other people’s work, unloading a lot of unhealthy emotional weight on other staff members and disrupting partnerships and meetings with emotional outbursts. I had absolutely let things get out of control and the rest of the staff was suffering for it. So I had to ask the person to leave in the middle of our conversation. It was really hard, but I honestly felt in the moment like I didn’t have any other choice.

As I read Laura’s comments, I’m struck by her explanation of the “disaster” and why she chose to classify it that way. “I let the person stay too long.” “The rest of the staff was suffering.” “I didn’t have any other choice.” The disaster, as it turns out, was waiting too long, letting things get out of hand, and firing someone “in the moment.” The firing itself? Not a disaster at all. It was absolutely necessary. In fact, Laura continues:

What finally pushed me to realize I needed to fire someone was seeing clearly how detrimental the person was to the health, satisfaction, and engagement of the rest of the staff. I was really worried other staff wouldn’t understand or would think I hadn’t tried hard enough to find a workable situation, but the staff was relieved in a way that made me feel like I should have taken care of the problem sooner.

Anna Peterson, Director of the STEP-UP Youth Employment Program in Minneapolis, had very different experience, also bad:

The employee had made some really egregious errors over a few months that could no longer be coached through or ignored. I remember coming into the organization as a new managing director. They waited until I arrived and then asked me to fire her. That was wrong and lame. 

had a similar experience several years ago, inheriting a problem that had existed for ages and was ignored. As in Laura’s example, the most difficult thing about the situation was that it had gone on for so long.

Letting these things linger can cause several problems. When behavior issues aren’t addressed, teams suffer in a variety of ways – productivity slows, frustration mounts, and a sense of hopelessness creeps in. And for the person being fired, the experience can be genuinely baffling, because the very same behaviors that were tolerated in the past are suddenly unacceptable.

Opportunity?

It’s hard to let an employee go. Even the worst leaders know it’s a big deal, not to be taken lightly. But nobody ever says they wished they waited longer to do it.

The first time I let someone go, I was a mess. After I’d made the decision, I revisited it frequently, wondering if I could somehow make things work. But I had no choice – my employee was having a negative impact on the team and the company, and the current situation couldn’t continue.

When I finally let the employee go, my team’s attitude and performance improved immediately (I felt much better too). Eventually, even the employee in question acknowledged that he needed a change, and that I’d made the right call. Turns out that what seemed like a terrible situation turned out to be a great opportunity for all involved.

Better late than never.

Home

08-411072+26PAISLEYrjs042216Like lots of other people on LinkedIn, I hear from a good number of recruiters. All over the world, amazing job opportunities exist for me – well-established companies and start-ups, hugely profitable companies and those that hope to be. Apparently, there’s a big need out there for people who do what I do. And, although my current gig is fantastic, it’s hard not to be intrigued sometimes. (When I say “me” and “my,” I really mean “us” and “our” – I know I’m not all that special.)

Whether the new opportunity is local or not, it’s important for recruiters to know if I’m open to relocation, because if I am, the number of potential opportunities expands exponentially. If I’m serious about my career, which I am, I know that my answer should be yes.

I’m thinking about this while staring at the photo above, from an all night gathering/party in Minneapolis last night outside First Avenue, where Prince went from local phenomenon to national star. Prince traveled the world, and you could argue that New York or L.A. would have provided more opportunity for him – more producers, more gigs, more talent to surround himself with. Prince had recruiters calling, no doubt, and he dabbled in other locations over the years, but he kept coming back to Paisley Park, to Chanhassen, MN – to Minneapolis.

There are other artists and bands that are tightly linked to their hometowns – Bruce Springsteen, Billy Joel, Jon Bon Jovi, and X come to mind – but this kind of connection is becoming more and more unusual, as music “scenes” are replaced with digital music and YouTube videos. Lots of professionals – musicians, TV anchors, eCommerce professionals – wonder whether being associated with a particular place is a good thing, dropping their accents and answering yes when a recruiter asks if they’re open to relocation.

There’s nothing wrong with this! I left my hometown, and I may leave Minneapolis at some point too. If I worked in certain industries, in fact, I’d have to. But when I look at the photo above, at all the people gathered overnight to celebrate a local hero, it reminds me that there’s no shame in being rooted to a community, surrounding yourself with people you love and who love you, and feeling connected to where you’re from. Prince left home, sharing his immense talent and joy with people all over the world for more than 30 years. I, like many people here in Minneapolis, are happy, grateful, and proud that he always came back.

 

Moving from projects to products

Brian de Haaff, Founder and CEO at Aha!, writes lots of smart things about product roadmaps, Agile software development, and the role of product managers within an organization. Here’s an excerpt from The Product Manager v. Project Manager, published by Huffington Post last fall, explaining the difference between products and projects:

A product is what you are providing to a group of users. It can be anything: a physical product that you hold in your hands, a software application, or a service that you are delivering.

In contrast, a project is a plan with a series of activities that has a defined outcome and a fixed start and end date. The project is completed when that outcome is accomplished.

So, let’s assume that your product is a new mobile application. It might contain many projects before it is ready to be launched. These projects all have their own unique starting and ending points. The mobile application, however, is a product which will continue to be improved as long as it is being sold to customers.

Simple, right? Products last forever, while projects have a beginning and an end. Then de Haaff goes on to describe the roles of product and project managers:

What is a product manager? Product managers are often described as the CEOs of their products. They set the strategy, prioritize releases, talk to customers, and clearly define features. A product manager’s goal is to deliver a lovable product.

What is a project manager? Project managers oversee a fixed project from beginning to end. A project manager’s goal is to work with a broader team with a diverse set of skills and to complete a project on time and under budget.

I love these definitions because they’re so simple and straightforward, and I agree with them completely. And yet, practically speaking, it can be really, really hard to maintain such a clear separation between these roles and functions. Here’s what I mean:

Let’s say your product is website search, and your product manager is its CEO. She’s on the hook for, among other things, prioritizing releases and delivering a lovable product. How will she do that?

If your team works like mine, your product manager will have created a vision of some sort and a list of things that can be done to realize it. The vision will be long-term enough to be aspirational rather than tactical, and it’ll provide a north star by which your product manager can vet new ideas generated by product team members and others throughout the company.

For the sake of example, let’s keep the vision simple. Since our product is website search, our vision is:

To get customers to the right product faster than Amazon.

Now that we’ve got a vision, we can start putting a high-level roadmap together. Our high level roadmap shows that we’re going to work on search accuracy in Q1. Our more detailed roadmap shows this:

  • Move search to the cloud
  • Build user tools to improve backend efficiency
  • Automate the process of building shops
  • etc.

Hopefully you’re starting to see the issue here. Whether we call these roadmap items projects or simply “work,” once they’re identified, delivering them tends to become our sole focus. Other product management tasks, like setting the strategy and talking to customers, take a backseat.

Shifting focus

Although we’ve got business analysts, delivery managers, and user experience experts on each product team (not the typical Silicon Valley approach, I know – I’ll discuss this more in a future post), our product managers often have the clearest sense of our overall strategy and business context, and they’re the ones who are on the hook for delivering the business value they promised. That means our product managers are personally invested (which we want them to be), and that keeping them closely tied to our projects is critical to our company’s success.

Our challenge is this: how do we keep product managers involved in each effort while still protecting their time for things like strategy, talking to customers, and long-term thinking?

Here are a few ideas:

More context for everbody
Product managers can’t be the only people on the hook for delivering business value. We need to work harder to make sure each member of each product team understands what drives the business and has a clear understanding of what success looks like. We need to work more collaboratively and share common goals. Beyond sharing ownership of the project’s goals, everybody on the team needs to understand their role in the context of the overall business.

Expand job definitions
Once everyone’s got enough context, delivery managers, business analysts, and UX experts can more fully own their roles in each project, moving product managers towards a more strategic, consultative role – and out of the role of “gatekeeper.” This can be as simple as a delivery manager making the call to delay a release without consulting with the product owner. (Informing? Yes. Asking? No.) To make this work, product managers have to give up some control, which is a big challenge.

Reward product managers for being strategic
People tend to focus on the things they’re rewarded for, so if we want our product managers to more effectively empower their teams, we need to reward them for things like providing context, delegating responsibility, and thinking long-term. We need to make it okay for other people on the team to be on point sometimes, and we need to provide the training and structure to ensure our products won’t suffer for it.

Protect your peoples’ time
Providing context, training people, thinking strategically, and talking with customers all take time. We need to acknowledge that time is a limited resource, and we need to actively, continuously, help our teams prioritize their work. We can’t tell our product owners that strategy is important without figuring out how to give them time to do it.

Physically separate the team
Part of the reason our product managers get sucked into every small decision around requirements, timelines, and user experience is that they sit directly across from the people working on those things. What would happen if we physically separated our product managers from the rest of the team? Might 20 feet of distance change the dynamic considerably? Might less collaboration lead to more empowerment?

Get feedback and revisit regularly
Change is hard, even for people and teams that do it well. Protecting people’s time, shifting responsibilities, providing context, and expanding roles make people uncomfortable, and sometimes some of these things just won’t work. If we’ve done it right, we’ve created an environment in which our teams are comfortable telling us what works and what doesn’t.

Even more than that, we need to actively solicit input, we need to be open to it, and we need to be willing to revisit our assumptions. The things that worked for us last year, last month, or last week may not work for us today, tomorrow, or next year. Like building great products, building great product teams requires time and focus.

Building trust

I’m a control freak by nature – I like to see everything my team is building, weigh in on the user experience, gather direct feedback, and provide my own. In my experience, there’s only one thing that cures this tendency: trust. In order to be comfortable that I don’t need to weigh in on every small decision, I need to trust that I’ve got the right people in the right roles, and that they have the skills and context they need to make solid decisions and create great products. They don’t need to make the same decisions I’d make, but they need to make educated decisions that they can defend.

Moving our product managers from project to product requires an enormous amount of trust – trust that teams will make the right decisions, trust that each person can handle their part, and trust that we’ll have each other’s backs when things don’t work out. Building that trust requires that we create an environment in which people can learn, experiment, and change. It requires that we allow our teams to challenge each other and to be challenged. It requires that we give every person on the team what we think we need in order to be successful, and that we understand that sometimes they’ll fail anyway.

How does that sound, control freaks?