Category Archives: Leadership and Management

Five rules for letting someone go without being a jerk

Leave a reply
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

Leave a reply

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. 

I 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

Leave a reply

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

2 Replies

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?

The glue that holds teams together

11 Replies

My previous post, That time I was fired, generated a lot of feedback and conversation. In it, I described two things: undermining my former company’s leadership, and getting fired for it. Here’s an excerpt:

We felt the new owners were dismissive of our ideas, and the direction they were taking the company was wrong-headed and stupid. I let the new CEO know he was wrong, again and again. I questioned most of his decisions, undermined him in company meetings, and made sure my coworkers knew we were headed down the wrong path.

My smart friend Jeanne Lakso, Marketing Programs Manager at National Co+op Grocers, said an amazing thing when we met for coffee last week. She said:

“Bitching is the glue that holds teams together.”

Jeanne was speaking in general terms, drawing on years of experience – not about her current work or team. Still, she’s really good at telling things like they are. And when I re-read the above excerpt from my last post, one sentence jumped out:

I questioned most of his decisions, undermined him in company meetings, and made sure my coworkers knew we were headed down the wrong path.

Part of the reason I complained about my boss was that it felt good – I got lots of positive reinforcement for doing it. My coworkers and I were in the trenches together, fighting the good fight. We were united against a common enemy, and we bonded over each of his dumb comments and failed ideas.

Much has been written about excessive complaining at work, how it can ruin your reputation, make things worse than they are, kill innovation, put blame on other people, and dramatically decrease productivity. (I’ll add that complaining is much less interesting than trying to help solve a problem. I’ve got some tolerance for complaints, but if they’re not followed by potential solutions, my tolerance goes waaaay down.)

Still, we often gravitate towards those who bring out the worst in us. Why?

02_01_16_d_echo_point_cartoon_666_800_80

The Echo Chamber

In his recent blog post, The Echo Chamber, noted philosopher and former Talking Head David Byrne writes:

We would like to think of the web as a place to find out what wonderful and unexpected stuff exists that is different than anything and everything you already know […] but as market forces increasingly take effect, the diversity of voices is now so filtered and targeted that you may only hear echoes of what you already believe. 

David Byrne’s post is about the web, and it covers politics, terrorism, and social media. It could be about work as well. Belle Beth Cooper writes:

If we agree with someone’s beliefs, we’re more likely to be friends with them. While this makes sense, it means that we subconsciously begin to ignore or dismiss anything that threatens our world views, since we surround ourselves with people and information that confirm what we already think.

We like people who think like us, and we dismiss those who don’t. When we think something’s screwed up, we seek out others who agree. These people help validate our thoughts and make us feel smart.

Does it have to be so negative?

Why do we especially gravitate towards people who share our negative beliefs? One reason may be the negativity bias. From Wikipedia:

Even when of equal intensity, things of a more negative nature have a greater effect on one’s psychological state and processes than do neutral or positive things.

In addition to the negativity bias, the generally accepted thinking seems to be this: it takes hard work and focus to stay positive, but being negative is effortless and fun. Or this: positive people are hiding something, while negative people tell it like it is.

Maybe this is why bitching is the glue that holds teams together?

Nightmare at my office

Have you seen the episode of “The Twilight Zone” called Nightmare at 20,000 Feet? In it, William Shatner’s flying on an airplane with his wife when he looks out his window and sees a gremlin on the wing, mucking around with the engine. Every time someone else looks out the window, the gremlin disappears, and after a while, Shatner’s wife and the flight crew think he’s insane. At the end of the show, Rod Serling shows us the damaged airplane engine and we know that Shatner was right all along, that the evil gremlin did exist. But it doesn’t matter, because Shatner’s gone insane and is hauled out in a straightjacket anyway.

Has your work ever made you feel like Shatner in the Twilight Zone? Have you ever worked on a project that clearly had no value, no matter how many times your boss explained it to you? Have you ever presented something you don’t believe in, even though you’ve made it clear you didn’t want to? If you haven’t, you’re either extremely inexperienced, or extremely lucky.

When we identify a problem, voice our concerns, and are told they don’t matter – we need to do the work anyway – feeling angry is one thing, but feeling insane is far worse. Others who share our thoughts can soothe our fears, commiserate, and assure us we won’t be hauled away in a straightjacket. Sometimes it turns out that finding people who see what we see is incredibly valuable.

nightmare-at-20000-feet

Complaining v. undermining

Let’s face it, there are times when we’re going to be negative at work or someplace else. This is just being human – in small doses and at the right times, complaining to others can even be therapeutic. But undermining your coworkers – making it hard for them to get their work done, making them look dumb, slowing their career progress, etc. – is something else entirely. Complaining is temporary. Undermining can last a lifetime.

All things must pass

Daniel Gilbert‘s Stumbling on Happiness is a terrific book, mostly focused on how bad we are at predicting the things that will make us happy. According to Gilbert, human beings are incredibly resilient animals:

… within a couple of weeks even earthquake survivors return to their normal level of unfounded optimism.

Is it possible our boss who’s completely clueless today will turn out to be a little bit smarter tomorrow? Is it possible the presentation we have to give today will be a distant memory next week? Is it possible the project we’re dreading because it has no value will turn out to have value next month, or that if it doesn’t, we’ll get over it? Maybe, just maybe, that thing we’re so frustrated by today won’t be such a big deal tomorrow.

If earthquake survivors can get over it, maybe we can too?

That time I was fired

15 Replies

I love Ben Horowitz‘s book The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers. It’s a quick read, full of memorable business ideas that stick, gleaned from Horowitz’s experience with Loudcloud and other ventures (plus a handful of choice rap lyrics). Horowitz sets the tone right from the start:

imgresEvery time I read a management or a self-help book, I find myself saying, “That’s fine, but that wasn’t really the hard thing about the situation.” The hard thing isn’t setting a big hairy audacious goal. The hard thing is laying people off when you miss the big goal. The hard thing isn’t hiring great people. The hard thing is when those “great people” develop a sense of entitlement and start demanding unreasonable things. The hard thing isn’t setting up an organizational chart. The hard thing is getting people to communicate within the organization that you just designed. 

One of my favorite chapters is “When Smart People Are Bad Employees.” Here’s an excerpt:

Sometimes a really smart employee develops an agenda other than improving the company. Rather than identifying weaknesses so he can fix them, he looks for faults to build his case. Specifically, he builds his case that the company is hopeless and run by a bunch of morons.

In my first ten years of employment, I’d been laid off or outsourced three times. Each time this happened, I was offered a new job or an extended severance package. I was reassured that my work was solid, and that the decision was based on math – nothing else. When I lost my job at the startup, it was something entirely different.

I’d joined the company as Chief Experience Officer, employee number six. We were a small but mighty team in Minneapolis, building something great that didn’t exist in the market. Within three months of our launch, Silicon Valley investors came knocking. They convinced our Founder CEO that they’d crush us if he didn’t take their money, and that their investment, experience, and relationships were exactly what we needed to make the company grow. We took the money.

With the money came a new CEO, based in California, an Entrepreneur In Residence (EIR) with the kind of pedigree investors dream about. Our Founder CEO was demoted to President of his company, and none of us were thrilled. We felt that the new owners were dismissive of our ideas, and that the direction they were taking the company was wrong-headed and stupid. I took it upon myself to stand up for the Minneapolis office.

I let the new CEO know he was wrong, again and again. I questioned most of his decisions, undermined him in company meetings, and made sure my coworkers knew we were headed down the wrong path. When my customer experience research was questioned, I got angry. When my coworkers felt undermined, I challenged the CEO to do better.

When I was fired, ten months after the new CEO started, I was enraged. Didn’t he know I was the one holding this thing together? Didn’t he understand that I was very, very right, and that he was very, very wrong?

If you don’t like something, change it. If you can’t change it, change your attitude.
– Maya Angelou

I’ll go to my grave knowing that our CEO was wrong about a lot of things, but he wasn’t wrong to fire me. I’d stopped looking for ways to fix the company, for ways to rally around the new product and leadership. I’d started focusing on making sure everyone knew the company was run by morons. I couldn’t change the things I didn’t like, and I refused to change my attitude. How did I last ten months?

I had to go.

Getting fired – for reasons that were entirely within my control – was terrible. I’ll never forget it, and I don’t recommend it. But the lessons I learned from the experience were valuable. Falling in line isn’t anyone’s favorite thing to do – many of us are paid to think critically, and we want to know that our opinions are heard and valued. But after we’ve said our piece, when the dust has settled and we didn’t get our way, our choices are clear: we can change our attitude, or we can change our scenery.

Building good things is boring

4 Replies

goodthingsWhen I arrived at a new job several years ago, things were looking good. Work/life balance favored life, the dress code was non-existent, and employees were on track to get bonuses yet again. Our website was usually up, returns were usually down, and customers were generally pleased.

So it surprised my new boss when I stormed into his office telling him that things needed to change – the org structure was wrong, we lacked focus and purpose, and our product was just okay.

“Take a deep breath,” he said, “things are pretty good.”

“I don’t want things to be good,” I countered. “Building good things is boring. I want to build something great.”

My boss was intrigued, and he knew I was right. If we continued on our current path, we’d collect our bonuses, make lots of money, and still be home early for dinner. But there was a downside.

Why be great?

When “good enough” is good enough, all sorts of bad things happen. For example:

  • Innovation and risk-taking are discouraged
  • Top performers tend to underperform (or find new jobs)
  • We settle for mediocrity
  • People are promoted based on tenure instead of the value they bring

Incremental improvement can be terrific, but it can also get in the way. When we try to turn something good into something great, we get just the opposite:

  • Innovation and risk-taking are encouraged
  • Top performers are fully engaged, and pushed to do their best work
  • We never settle
  • People are promoted for adding business value

When an organization strives for greatness, inspired employees are rallied around a common goal, and everyone brings their best ideas and energy to the table. Sometimes we work long hours or forget to eat a meal, but it never feels that way. Trying to build something great feels fantastic.

A cautionary tale

A few years ago, I took a job at a small, well-funded internet startup. The founder had recruited experienced talent, and the team rallied around our “big hairy audacious goal“: to change the way people consumed information online. We worked hard to produce something great.

Along the way we started to run out of capital, and our BHAG took a backseat to our need to say afloat. We built a series of mediocre products that we tried to monetize, and we struggled to find an audience. Some would argue we were being pragmatic, that we couldn’t afford to build something great – we needed to build something good instead.

But when we stopped trying to build something great, we lost our focus. We started coming to work late, leaving early, and spending too much time worrying about lunch. Our focus turned from work to work/life balance, and we were no longer inspired to bring our very best to the office every day. A few of my co-workers loved it.

“This is the best job ever,” I remember one of them telling me.

“Not for long,” I warned.

In a few weeks, we were looking for new jobs. Would we have stayed in business longer if we stayed committed to building something great? We’ll never know. But I do know this: I would have felt a whole lot better about it.

Secrets of the Superbosses: let them go

Leave a reply

imgres-1There are all sorts of great ideas contained in Sydney Finkelsteins’ Harvard Business Review article Secrets of the Superbosses, things like hiring unconventionally; seeking out people who are smart, creative, and flexible; focusing on “unlikely winners”; and adapting the work to fit the talent. I especially love the part about helping employees move on the bigger and better opportunities:

Smart, creative, flexible people tend to have fast-paced careers. Some may soon want to move on. That’s OK with superbosses. They understand that the quality of talent on their teams matters more than stability, and they regard turnover as an opportunity to find fresh stars.

I hope to keep my best people on my team forever, I really do. But there are great reasons to embrace the fact that I can’t. Here are a few:

  • I’d rather keep a high performer in the company than lose them entirely: I’ve got people on my team who will deserve to be promoted in the next 1-3 years, maybe more people than I have opportunities. If I can grow my employees’ careers by helping them find a role on a different team, I might be able to keep them within the company.
  • New talent can be a great thing: Smart, motivated, new employees will bring new energy and ideas to the party. Adding people to the team is a huge risk, and I don’t take it lightly – it can be a disaster. But adding the right people can elevate everyone’s game, including my own.
  • It’s a small world after-all: My current employer is not my first, and more than likely it won’t be my last. There’s a very pragmatic reason to support my best people moving on to bigger and better roles, even at other companies: when I’m out looking for a new job, I’ll be glad to have good friends in high places.

Towards the end of the article, Finkelstein writes:

Superbosses employ practices that set them head and shoulders above even the best traditional bosses. They seek out talent differently and hire them in unusual ways. They create high expectations and take it upon themselves to serve as “masters” to up-and-coming “apprentices.” And they accept it when their protégés go on to bigger and better things, making sure to stay connected.

Superbosses think differently about their roles and responsibilities: they push their people, expect great things, and are confident in their own ability to grow and maintain talented teams. Part of this is acknowledging that, sometimes, to let a person grow, you have to let them go.

Shiny new objects rust over time

3 Replies

Many of us have worked in companies that prioritize work on an annual basis. In these organizations, it’s common to invest in a few things each year at the expense of everything else. “This is the year of search,” you might say, because “last year was the year of mobile.” On the surface, this makes total sense – you can’t make big investments in the same capabilities each year. Eventually, everything will have its day in the sun.

In reality, this is a terrible way of prioritizing work, completely ineffective, because it means that – until each program has its day in the sun – it’s essentially left to wither and die. Or to almost die, which is even worse. Don’t you see it? Look there in the corner – there’s site search, begging to be put out of its misery. It had its last big investment two years ago. It knows it’ll be the golden child again next year, but in the meantime, customers are mocking its uselessness, laughing at its broken experience. Poor thing. 

A few years ago, my company addressed this by implementing an Agile, product-focused approach. Within our organization, each product area receives some amount of ongoing funding, which allows the team to make consistent progress throughout the year. The amount of funding may change according to business needs, but the idea of making consistent progress across the business doesn’t.

Take the Search product for example. Several years ago, Search had its day in the sun. Replacing our old system was one of the company’s top priorities, and the project got all the people and money it needed to be successful. Once our new Search was implemented, the big project was over, but the need to make continual progress – to optimize the experience – was still there. (It will always be there.) So although the Search team got smaller and some resources were moved to new strategic priorities, the capability continued to exist – we continued to make it better.

Search is, of course, just one example of a large company initiative – a shiny object – that needs ongoing care and feeding. (I can’t think of a product that doesn’t.) Organizations built on a product management model get this. Before they build new functionality, they’re thinking about how to support it and what the long-term roadmap looks like. Organizations that are entirely project focused, on the other hand, are likely to face poor support and unexpected costs. That’s because they haven’t planned for the inevitable, and because rust never sleeps.

Related: How much of a problem can you buy away?

How much of a problem can you buy away?

1 Reply

My eCommerce team is world class – the best group I’ve worked with, capable of leaping tall buildings in a single bound. From top-to-bottom, we’re defining compelling visions, creating aggressive roadmaps, delivering innovation and quality, testing into winners, and measuring results. Even still, we can’t be experts at everything, and resources are limited.

This means there are times when we need to explore the vast vendor landscape to find tools that can help us solve our problems. We tend to focus in three areas:

  • Things that have been commoditized, because we don’t think they’ll help us differentiate.
  • Things that are really, really hard, because we don’t have the desire (or time) to build or maintain world-class-systems that we can easily buy.
  • Things that are outside of our core competencies, because sometimes the best way to get started with a new technology is to have someone else build it and then take it over.

In each of these areas, there’s a sense we’re buying a problem away, that by leveraging a vendor for ratings and reviews, or personalization, or search, or recommendations, or whatever, we can free our resources to focus on other things. And this is mostly true. But it’s never completely true.

It’s never completely true because there’s no problem that can be bought away completely. Even if we’ve “completely” outsourced a program (like ratings and reviews, for example), we need to define our strategy, manage our vendor, provide customer support and issue escalation, measure the program’s effectiveness, tweak the experience, and defend our budget. Despite our vendor’s promises, these things cannot be outsourced. Not effectively, anyway.

And who would want to hand all of these things over anyway? Vision? Analytics? Roadmap? I may want to leverage a vendor at times, but I never want to hand them my company’s strategy and ask them to drive it.

What does this mean? It means that when we consider buying a problem away, we need to understand that we can very rarely buy away the whole thing. We need to allocate both resources and dollars for the activities listed above, for ongoing support, and for the cost of potentially moving a capability in-house over time. We need to understand that there’s no such things as “hands-off” management or programs that run themselves.

Related: Shiny new objects rust over time