Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

An interview with Michael Lopp: Managing humans when the sky is falling

Since early 2002, Michael Lopp has been Writing about management, the tech industry, and corporate culture under his pen name and alter ego: Rands, which has grown into one of the internet’s most thoughtful and articulate voices on managing humans in the workplace.

Lopp has held key positions at Palantir, Pinterest, Apple, and since May 2016 has been the Vice President of Engineering at Slack. Coax Editor Marshall Watson caught up with Rands to talk about the trials and tribulations of managing people, the importance of “soft skills,” and what to do when the sky is falling.

Vitals



Occupation
VP of Engineering at Slack


Website
Rands in Repose


Twitter
@rands

Since early 2002, Michael Lopp has been writing about management, the tech industry, and corporate culture under his pen name and alter ego: Rands, which has grown into one of the internet’s most thoughtful and articulate voices on managing humans in the workplace.

Lopp has held key positions at Palantir, Pinterest, Apple, and since May 2016 has been the Vice President of Engineering at Slack. Coax Editor Marshall Watson caught up with Rands to talk about the trials and tribulations of managing people, the importance of “soft skills,” and what to do when the sky is falling.

First off, as a writer, I find it incredibly interesting to hear about the writing process of others. What is a typical day for you? How does your writing fit into your schedule?

I have concentrated writing periods about three or four times a week. I can’t write after about noon. By that time, my writing brain is gone. I’m not a morning person per se, but from 9:00 until noon is when I get my writing done. I’ve written a couple books and the writing that happens between 7:00 pm and 10:00 pm is just awful—it gets incredibly hard to pull things out of my brain.

The process is usually sitting at a computer. I have the thing I’m writing or I have an idea of what I want to write. And I kind of wander around the internet thinking about it, waiting for the caffeine to kick in, and then after about five or 10 minutes it hits me—like “Oh, that’s what it is I need to say.” And then there’s a sentence and then there’s a paragraph and then there are four paragraphs. I write a lot of blog-size entries—about 500-2000 words or somewhere around there. So once I get a decent first draft, I print it out and I edit it on paper. I don’t edit well through a screen. I need to see it in a different medium. So that’s the editing process. And I’ll share it with an editor that I have and I’ll share it with my wife. And then, usually, it ends up getting published. I probably have 10 to 20 different pieces going at any given moment with one or two that are actively being written.

Do you ever edit while you’re writing or…

The editing process and the writing process are, in my head, totally different. It’s a different part of the brain. When I’m writing it’s more of a flowing, zen state. Editing, which I’ve gotten better at over time, is more mechanical to me. I can edit at night. I can’t write at night. For writing, I need to be in my cave, I need to have my things. Writing requires a different state.

You’ve been thinking and writing about management for a while now. How has the concept of management evolved over the past 20 or 30 years?

20 or 30 years, hey? Wow, I must be old. [Laughing]

[Laughing] Delve into the archives for us.

Well, my dad gave me this book when I was a kid. It’s this big, red, hardcover book called Management by Peter Drucker. And it’s exactly like it sounds. It’s very prescriptive and Victorian in its approach.

I bet the title is in really bold, intense all-caps font on the cover. [Laughing]

[Laughing] Yeah. I think it is. But it’s actually a very interesting read if you’re into the Fordian assembly line command-and-control-type thinking. What’s changed since then, speaking as an engineer, is that this set of builders showed up—these knowledge workers. I hate that term, but they showed up and now it’s not an assembly line anymore. It’s this art of assembling thoughts into useful algorithms that produce these things that humans use and we can do this at an incredible scale and produce a huge amount of wealth. And managing or leading these folks requires a very different philosophy. You can’t just be this SVP and go: “Here are the numbers and we’re gonna blah blah blah…” You need to be able to speak the language—to know what the builders are talking about. I learned this at Apple. I’m an engineer, but I needed to know about typography because I was expected to have an opinion. Even when I was a director. You still need strong leadership in that domain but there’s been this blending—a co-mingling if you will—of the builders and the managers.

So as the work changes, as the role of the builders has changed, management has had to change also.

Absolutely. And I mean, I’m an engineer. I’ve only worked with software. I’ve never had to build a car. But I think the various new builder types has definitely changed the way management happens. There’s this other word that does speak to this philosophy: empathy.

There’s this piece, the mental well-being of the humans that you’re working with and understanding how they fit together is important. You can’t be their therapist. But we’re all humans, we’re flawed, we’re awesome, we have emotions and good days and bad days. Knowing that piece, as well, is something that has become more highly valued over the past decade. I’m biased though because that’s one of my superpowers—that ability to understand people and I know that a happy team is a productive team.

One of the things we’ve been talking about a lot in the Louder Than Ten Apprenticeship Program is the under-discussed value of what’s often called “soft skills”—empathy, awareness, the ability to hold space for difficult conversations—in relation to managing a diverse project team.

And we should be talking about them more. The joke I always tell is that we keep on calling them “soft skills,” but when you ask any engineer what the hardest part of their job is, they will say things like communicating, influencing, negotiating. All these things that are lumped under “soft skills”—are actually the hardest because sitting on the other side of the table is this beautiful chaotic snowflake of a person. You don’t know what they’re up to and you have to figure that out. That’s hard.

It’s a bit of a misnomer. It might be time to change that term.

Agreed. One hundred percent.

First off, as a writer, I find it incredibly interesting to hear about the writing process of others. What is a typical day for you? How does your writing fit into your schedule?

I have concentrated writing periods about three or four times a week. I can’t write after about noon. By that time, my writing brain is gone. I’m not a morning person per se, but from 9:00 until noon is when I get my writing done. I’ve written a couple books and the writing that happens between 7:00 pm and 10:00 pm is just awful—it gets incredibly hard to pull things out of my brain.

The process is usually sitting at a computer. I have the thing I’m writing or I have an idea of what I want to write. And I kind of wander around the internet thinking about it, waiting for the caffeine to kick in, and then after about five or 10 minutes it hits me—like “Oh, that’s what it is I need to say.” And then there’s a sentence and then there’s a paragraph and then there are four paragraphs. I write a lot of blog-size entries—about 500-2000 words or somewhere around there. So once I get a decent first draft, I print it out and I edit it on paper. I don’t edit well through a screen. I need to see it in a different medium. So that’s the editing process. And I’ll share it with an editor that I have and I’ll share it with my wife. And then, usually, it ends up getting published. I probably have 10 to 20 different pieces going at any given moment with one or two that are actively being written.

Do you ever edit while you’re writing or…

The editing process and the writing process are, in my head, totally different. It’s a different part of the brain. When I’m writing it’s more of a flowing, zen state. Editing, which I’ve gotten better at over time, is more mechanical to me. I can edit at night. I can’t write at night. For writing, I need to be in my cave, I need to have my things. Writing requires a different state.

You’ve been thinking and writing about management for a while now. How has the concept of management evolved over the past 20 or 30 years?

20 or 30 years, hey? Wow, I must be old. [Laughing]

[Laughing] Delve into the archives for us.

Well, my dad gave me this book when I was a kid. It’s this big, red, hardcover book called Management by Peter Drucker. And it’s exactly like it sounds. It’s very prescriptive and Victorian in its approach.

I bet the title is in really bold, intense all-caps font on the cover. [Laughing]

[Laughing] Yeah. I think it is. But it’s actually a very interesting read if you’re into the Fordian assembly line command-and-control-type thinking. What’s changed since then, speaking as an engineer, is that this set of builders showed up—these knowledge workers. I hate that term, but they showed up and now it’s not an assembly line anymore. It’s this art of assembling thoughts into useful algorithms that produce these things that humans use and we can do this at an incredible scale and produce a huge amount of wealth. And managing or leading these folks requires a very different philosophy. You can’t just be this SVP and go: “Here are the numbers and we’re gonna blah blah blah…” You need to be able to speak the language—to know what the builders are talking about. I learned this at Apple. I’m an engineer, but I needed to know about typography because I was expected to have an opinion. Even when I was a director. You still need strong leadership in that domain but there’s been this blending—a co-mingling if you will—of the builders and the managers.

So as the work changes, as the role of the builders has changed, management has had to change also.

Absolutely. And I mean, I’m an engineer. I’ve only worked with software. I’ve never had to build a car. But I think the various new builder types has definitely changed the way management happens. There’s this other word that does speak to this philosophy: empathy.

There’s this piece, the mental well-being of the humans that you’re working with and understanding how they fit together is important. You can’t be their therapist. But we’re all humans, we’re flawed, we’re awesome, we have emotions and good days and bad days. Knowing that piece, as well, is something that has become more highly valued over the past decade. I’m biased though because that’s one of my superpowers—that ability to understand people and I know that a happy team is a productive team.

One of the things we’ve been talking about a lot in the Louder Than Ten Apprenticeship Program is the under-discussed value of what’s often called “soft skills”—empathy, awareness, the ability to hold space for difficult conversations—in relation to managing a diverse project team.

And we should be talking about them more. The joke I always tell is that we keep on calling them “soft skills,” but when you ask any engineer what the hardest part of their job is, they will say things like communicating, influencing, negotiating. All these things that are lumped under “soft skills”—are actually the hardest because sitting on the other side of the table is this beautiful chaotic snowflake of a person. You don’t know what they’re up to and you have to figure that out. That’s hard.

It’s a bit of a misnomer. It might be time to change that term.

Agreed. One hundred percent.

I’m the manager and I’m in charge.

So given how roles in the workplace have changed, in your experience, what are the early warning signs that a manager is struggling in their role? What can you do in those situations?

I was actually talking about this with someone right before this call. New managers all do the same kind of things and those signs are really obvious to me. New folks coming into the workforce often display these same behaviours and it’s weird that new managers do it as well. Because people think “I’m the Manager and I have this title that says I’m in charge,” there’s this belief that they are responsible for all of the decisions. But nothing could be further from the truth in terms of leadership strategy because you don’t know all the things and your team is actually smarter than you because they’re doing all the work and have that broader context about the work that is or needs to be done.

So new managers who don’t acknowledge failure, who don’t listen, who don’t delegate, who do all the things themselves instead of giving them to the team to do, are usually the managers who struggle in their first couple years. And the way you see that is they get political—bad political, not good political. They start hoarding information or they start micromanaging. Micromanaging is always an indicator of bad decisions made months earlier. Those are the most common signs.

And what to do about it? You have to have hard conversations. I have a whole story about the delegation piece. This is one simple narrative. A new manager isn’t willing to delegate. What is he or she saying to the team when they are choosing to do that work as opposed to giving it to someone else. The team knows that suddenly they are no longer trusted to do that piece of work and it creates this us and them dynamic. Delegation builds trust and refusing to delegate does the exact opposite.

Let’s just say that the manager really knows that they can do this one part of the job really well—they have done it many times before and they are the best at doing that job, A+ every time. And anyone else on their team would get a B because they maybe haven’t done it before. But it’s still the right case in that story to give the job to the team even though it will get a B. Because you’re delegating, you’re demonstrating trust, and you’re teaching them how to get to an A eventually, and they watch you investing in their growth and so they trust you more. Especially for engineers who like to be the ones who do everything, that delegation piece is—once you learn to do it well—one of the biggest superpowers that managers can learn.

That leads us nicely into my next question which you’ve already started to answer. A common complaint about new managers is that they are often promoted simply due to tenure or success in a specific field (communications, programming, marketing). How do we cope with that?

First off, let’s be clear: it’s a gamble sometimes—you can’t always know whether someone will be successful as a manager or not. And the reason for this is the same thing I often tell new managers—this is a career restart. All of those things you did as an individual aren’t going to help you that much. There’s a whole new set of skills you’ll need and you’re going to need to use a whole new part of your brain. It’s going to be confusing, it’s going to be hard but I’m going to help you with this. Also, here’s this book I wrote. [Laughing]

[Laughing] Smooth.

Thanks. [Laughing] It’s a total restart and a lot of bad behaviour or bad judgment comes from new managers regressing to previous roles in stressful periods. When shit hits the fan, they go back to fixing bugs or they start going back to the things that got them there in the first place rather than delegating like managers should.

Their defense mechanism is to go back to the thing they are good at and comfortable with.

Exactly. And it makes sense because it’s a safe space for them, but that is exactly the time they should be delegating. When the sky is falling they should be saying: “Hey. Susan. The sky is falling. You gotta help me with this. I’m going to delegate these things to you.” And she’s going to be terrified. But you’re going to help her.

And it can be just as tough for a team to step up and try to help a new manager through that situation without overstepping or coming across as indignant or presumptuous. They may want to (and be able to) help out but it’s really up to the manager to let go and delegate.

Yeah. Very much so. That’s one of those hard conversations I mentioned earlier. But the more managers and their teams communicate about the easy stuff, about everything else, the more those kind of conversations become easier to have.

I’m the manager and I’m in charge.

So given how roles in the workplace have changed, in your experience, what are the early warning signs that a manager is struggling in their role? What can you do in those situations?

I was actually talking about this with someone right before this call. New managers all do the same kind of things and those signs are really obvious to me. New folks coming into the workforce often display these same behaviours and it’s weird that new managers do it as well. Because people think “I’m the Manager and I have this title that says I’m in charge,” there’s this belief that they are responsible for all of the decisions. But nothing could be further from the truth in terms of leadership strategy because you don’t know all the things and your team is actually smarter than you because they’re doing all the work and have that broader context about the work that is or needs to be done.

So new managers who don’t acknowledge failure, who don’t listen, who don’t delegate, who do all the things themselves instead of giving them to the team to do, are usually the managers who struggle in their first couple years. And the way you see that is they get political—bad political, not good political. They start hoarding information or they start micromanaging. Micromanaging is always an indicator of bad decisions made months earlier. Those are the most common signs.

And what to do about it? You have to have hard conversations. I have a whole story about the delegation piece. This is one simple narrative. A new manager isn’t willing to delegate. What is he or she saying to the team when they are choosing to do that work as opposed to giving it to someone else. The team knows that suddenly they are no longer trusted to do that piece of work and it creates this us and them dynamic. Delegation builds trust and refusing to delegate does the exact opposite.

Let’s just say that the manager really knows that they can do this one part of the job really well—they have done it many times before and they are the best at doing that job, A+ every time. And anyone else on their team would get a B because they maybe haven’t done it before. But it’s still the right case in that story to give the job to the team even though it will get a B. Because you’re delegating, you’re demonstrating trust, and you’re teaching them how to get to an A eventually, and they watch you investing in their growth and so they trust you more. Especially for engineers who like to be the ones who do everything, that delegation piece is—once you learn to do it well—one of the biggest superpowers that managers can learn.

Michael’s books are required reading for anyone who makes software with other human beings

That leads us nicely into my next question which you’ve already started to answer. A common complaint about new managers is that they are often promoted simply due to tenure or success in a specific field (communications, programming, marketing). How do we cope with that?

First off, let’s be clear: it’s a gamble sometimes—you can’t always know whether someone will be successful as a manager or not. And the reason for this is the same thing I often tell new managers—this is a career restart. All of those things you did as an individual aren’t going to help you that much. There’s a whole new set of skills you’ll need and you’re going to need to use a whole new part of your brain. It’s going to be confusing, it’s going to be hard but I’m going to help you with this. Also, here’s this book I wrote. [Laughing]

[Laughing] Smooth.

Thanks. [Laughing] It’s a total restart and a lot of bad behaviour or bad judgment comes from new managers regressing to previous roles in stressful periods. When shit hits the fan, they go back to fixing bugs or they start going back to the things that got them there in the first place rather than delegating like managers should.

Their defense mechanism is to go back to the thing they are good at and comfortable with.

Exactly. And it makes sense because it’s a safe space for them, but that is exactly the time they should be delegating. When the sky is falling they should be saying: “Hey. Susan. The sky is falling. You gotta help me with this. I’m going to delegate these things to you.” And she’s going to be terrified. But you’re going to help her.

And it can be just as tough for a team to step up and try to help a new manager through that situation without overstepping or coming across as indignant or presumptuous. They may want to (and be able to) help out but it’s really up to the manager to let go and delegate.

Yeah. Very much so. That’s one of those hard conversations I mentioned earlier. But the more managers and their teams communicate about the easy stuff, about everything else, the more those kind of conversations become easier to have.

Hey. Susan. The sky is falling.

Managing a project can be quite different from managing a company or a business unit even though the titles use the same word. What do you think project managers need to understand about managing people in order to better lead their often diverse project teams?

Well, let’s be clear about why it’s harder first. Project Managers and Program Managers are the horizontal, connective tissue roles. They can be totally awesome if they are really good at the job. But it can be so much harder because the nature of those horizontal roles is to influence rather than dictate. It’s a bad manager that dictates, but that’s the difference between those roles. Project Managers and Program Managers have to lead through influence. They have to connect with people on the same level but still guide them in a certain direction without having an established hierarchy to back them up. It’s almost like volunteer leadership. It’s like my dad leading his church. There’s a different approach required. Negotiations work differently. Empathy is really, really important.

The secret power that they do have—Project and Program Managers—is the reason they are there in those roles. It’s very complex, there are many different moving pieces. And it usually means there is some specific business metric which is the reason why that person is there. There’s a specific goal for that team or project.

I’ll give you a specific example. This was in a prior role, not here at Slack. We wanted to bring our AWS bill down but every single engineer is increasing the cost by adding more code. So how do we get the whole engineering team to pivot because of this one thing when they’ve got their own managers and directors asking for features and things and countless short-term “Get this thing done” requests. Meanwhile, I’m over here waving saying: “Hey, by the way, our bill is millions of dollars… So what are we going to do?” So Project Managers or Program Managers—they’re different but similar in that they are horizontal—are there and they have a very clear mandate related to a key part of the overall business (“Let’s be more efficient.”) If they become process people who are just nagging to get things done, the team is screwed. If they are the ones who are like: “Hey. We’re working on this amazing initiative to increase shareholder value by bringing the cost per quarter down,” that’s a much better way to frame it.

It is a very different skill set from the standard manager package.

Hey. Susan. The sky is falling.

Managing a project can be quite different from managing a company or a business unit even though the titles use the same word. What do you think project managers need to understand about managing people in order to better lead their often diverse project teams?

Well, let’s be clear about why it’s harder first. Project Managers and Program Managers are the horizontal, connective tissue roles. They can be totally awesome if they are really good at the job. But it can be so much harder because the nature of those horizontal roles is to influence rather than dictate. It’s a bad manager that dictates, but that’s the difference between those roles. Project Managers and Program Managers have to lead through influence. They have to connect with people on the same level but still guide them in a certain direction without having an established hierarchy to back them up. It’s almost like volunteer leadership. It’s like my dad leading his church. There’s a different approach required. Negotiations work differently. Empathy is really, really important.

The secret power that they do have—Project and Program Managers—is the reason they are there in those roles. It’s very complex, there are many different moving pieces. And it usually means there is some specific business metric which is the reason why that person is there. There’s a specific goal for that team or project.

I’ll give you a specific example. This was in a prior role, not here at Slack. We wanted to bring our AWS bill down but every single engineer is increasing the cost by adding more code. So how do we get the whole engineering team to pivot because of this one thing when they’ve got their own managers and directors asking for features and things and countless short-term “Get this thing done” requests. Meanwhile, I’m over here waving saying: “Hey, by the way, our bill is millions of dollars… So what are we going to do?” So Project Managers or Program Managers—they’re different but similar in that they are horizontal—are there and they have a very clear mandate related to a key part of the overall business (“Let’s be more efficient.”) If they become process people who are just nagging to get things done, the team is screwed. If they are the ones who are like: “Hey. We’re working on this amazing initiative to increase shareholder value by bringing the cost per quarter down,” that’s a much better way to frame it.

It is a very different skill set from the standard manager package.

I was so wrong about that.

You’ve been writing Rands in Repose for—what—15 years now?

Yeah. I think I started in about 2001.

That’s a decade and a half of reflection on this topic.

[Laughing] Yes. I’ve done a few other things, but yes. Wow.

So 15 years later, after all that time, what’s one piece of leadership advice that you think needs to go away?

Oh, I’ve written about this. I use to say managers shouldn’t code anymore and I was so wrong about that. And I think that applies to any industry. Distancing yourself from the work that is done and worrying less about understanding it is super bad advice. It creates hierarchy. It creates distance between you and the folks you’re working with. It’s a flattening investment when you continue to do the thing that your team does.

For me, writing is a bit of my ‘coding’ as a manager. It’s my reflecting, thinking, building a thing. It scratches that itch. I used to tell new managers not to do that, but it was such bad advice. Again, the primary job is the people. But it’s not good advice. Keeping those roles blurry, keeping yourself in touch with what people are doing gives you more empathy, gives you more credibility. And it’s fun to build things.

And it helps break down that somewhat false separation between the manager and their team or the manager and their unit.

Totally. Absolutely.

Speaking of empathy and how managing people is at the heart of these roles, how can companies or leaders in companies use technologies like Slack to be more inclusive?

This is a great question. I have a Slack channel that I run outside of Slack. I created it before I took over as VP of Engineering here. It’s a leadership Slack, surprisingly. [Laughing]

I would never have guessed. [Laughing]

[Laughing] Yeah. So there are like 4000 people on that Slack now, but it started small, obviously. At first, we had a couple hundred people in there and we were creating channels and just seeing what was emerging organically. And then someone brought up the idea of a Code of Conduct. My knee-jerk response was, a little ambivalent and I thought: “Why do we have to be prescriptive? Why can’t we just let it flow and just police ourselves.” But, boy was I wrong.

I was the guy running the Slack and I was this white dude in a secure job and all these other things that are true. But there were people on the Slack who aren’t the Slack operator, who haven’t published books, whatever. How do you make it a safe and comforting place for everyone? The act of just saying yes was profound. We borrowed another Code of Conduct from a conference and we wrote it and were thoughtful about it. And the ROI on that document is incredibly high. Because folks who do not automatically feel included read that and they understand that there’s a philosophy and supporting actions that we will take to make sure people feel included and treated respectfully.

I’ve never actually had to use it. I’ve never had to say, “Well the Code of Conduct says this…” at any point over the past two years. But it’s there and people are now starting to use it elsewhere. So that’s step number one. Defining what you believe and sharing that with the community and getting them to opt-in to that when they join. It’s a great way to level the field so to speak—to set a baseline philosophy related to inclusion.

There’s a channel there that’s private. I’m not on it. It’s called Lady Leaders I think. It’s huge. There are hundreds of women there talking about leadership. And the Code of Conduct encourages that and protects that and surrounds that with other people who encourage and protect that. I think that’s a good, low barrier way to start building an inclusive community with Slack. It’s awesome. Anyone can take that first step.

Simple, symbolic things like that can have a surprising effect on communities because they challenge or break down the assumption that these communities or teams lack any internal diversity—that they’re a unified whole without any diversity or disagreement.

Right. Exactly. When it comes to diversity and inclusion, what seems like a small step for you can impact others in a profoundly significant way.

Another thing we do with that external Slack is a specific entry requirement. In order to get in, you need to mail me—you need to take the time to send me your request. Some people send me long paragraphs, some don’t. And it may seem like a little thing but because you can’t just auto-join, it means that the people who join, really want to join. That simple little barrier has kept and created a coalition of the willing, to borrow a phrase. Everyone has a name, no one is anonymous, and each person knows that everyone else wants to be there for, more or less, the same reason.

I was so wrong about that.

You’ve been writing Rands in Repose for—what—15 years now?

Yeah. I think I started in about 2001.

That’s a decade and a half of reflection on this topic.

[Laughing] Yes. I’ve done a few other things, but yes. Wow.

So 15 years later, after all that time, what’s one piece of leadership advice that you think needs to go away?

Oh, I’ve written about this. I use to say managers shouldn’t code anymore and I was so wrong about that. And I think that applies to any industry. Distancing yourself from the work that is done and worrying less about understanding it is super bad advice. It creates hierarchy. It creates distance between you and the folks you’re working with. It’s a flattening investment when you continue to do the thing that your team does.

For me, writing is a bit of my ‘coding’ as a manager. It’s my reflecting, thinking, building a thing. It scratches that itch. I used to tell new managers not to do that, but it was such bad advice. Again, the primary job is the people. But it’s not good advice. Keeping those roles blurry, keeping yourself in touch with what people are doing gives you more empathy, gives you more credibility. And it’s fun to build things.

And it helps break down that somewhat false separation between the manager and their team or the manager and their unit.

Totally. Absolutely.

Speaking of empathy and how managing people is at the heart of these roles, how can companies or leaders in companies use technologies like Slack to be more inclusive?

This is a great question. I have a Slack channel that I run outside of Slack. I created it before I took over as VP of Engineering here. It’s a leadership Slack, surprisingly. [Laughing]

I would never have guessed. [Laughing]

[Laughing] Yeah. So there are like 4000 people on that Slack now, but it started small, obviously. At first, we had a couple hundred people in there and we were creating channels and just seeing what was emerging organically. And then someone brought up the idea of a Code of Conduct. My knee-jerk response was, a little ambivalent and I thought: “Why do we have to be prescriptive? Why can’t we just let it flow and just police ourselves.” But, boy was I wrong.

I was the guy running the Slack and I was this white dude in a secure job and all these other things that are true. But there were people on the Slack who aren’t the Slack operator, who haven’t published books, whatever. How do you make it a safe and comforting place for everyone? The act of just saying yes was profound. We borrowed another Code of Conduct from a conference and we wrote it and were thoughtful about it. And the ROI on that document is incredibly high. Because folks who do not automatically feel included read that and they understand that there’s a philosophy and supporting actions that we will take to make sure people feel included and treated respectfully.

I’ve never actually had to use it. I’ve never had to say, “Well the Code of Conduct says this…” at any point over the past two years. But it’s there and people are now starting to use it elsewhere. So that’s step number one. Defining what you believe and sharing that with the community and getting them to opt-in to that when they join. It’s a great way to level the field so to speak—to set a baseline philosophy related to inclusion.

There’s a channel there that’s private. I’m not on it. It’s called Lady Leaders I think. It’s huge. There are hundreds of women there talking about leadership. And the Code of Conduct encourages that and protects that and surrounds that with other people who encourage and protect that. I think that’s a good, low barrier way to start building an inclusive community with Slack. It’s awesome. Anyone can take that first step.

Simple, symbolic things like that can have a surprising effect on communities because they challenge or break down the assumption that these communities or teams lack any internal diversity—that they’re a unified whole without any diversity or disagreement.

Right. Exactly. When it comes to diversity and inclusion, what seems like a small step for you can impact others in a profoundly significant way.

Another thing we do with that external Slack is a specific entry requirement. In order to get in, you need to mail me—you need to take the time to send me your request. Some people send me long paragraphs, some don’t. And it may seem like a little thing but because you can’t just auto-join, it means that the people who join, really want to join. That simple little barrier has kept and created a coalition of the willing, to borrow a phrase. Everyone has a name, no one is anonymous, and each person knows that everyone else wants to be there for, more or less, the same reason.

The ghosts of management future.

We asked you to reflect on the ghosts of management past, and now I’m curious about the ghosts of management future. How do you think new technologies and automation will affect the way we manage or lead teams in the future? How might things be different five or 10 years from now?

I think distributed teams and workforces will be the future. This is Michael Lopp’s opinion, not Slack’s opinion. I think it’s inevitable. There are too many lovely cities full of all of these employable people while it’s getting really, really expensive in other places. I think the economics will push us towards a more distributed way of working. Hopefully Slack has a role to play in this transformation. I think it will be easier to do than it was five or 10 years ago. And I think this is what I hope will happen as much as I think the economics will just take us in that direction. That seems to be headed in our direction.

There’s actually a piece about that topic in last month’s Wired—tracking some of the other places where startups are emerging, how the workforce in those places is different, and how the work from funding to staffing and everything in between will have to adapt—or is already adapting.

Yeah. I think we’re going to see more and more of that.

Alright, last question. You’ve given great advice to hundreds of managers of the future. But what’s one piece of career advice you wish you would have got 10 or 20 years ago?

20 years ago? Twenty years ago?! Hmmm.

Is that too far back? Will it help if I sing the Cher song If I Could Turn Back Time?

[Laughing] No. It’s a good question. I’m just sifting through a list of tweets and articles and conversations. Um… I’m going to wish I could have crafted this better but I’ll say this: be aware of what political behaviour looks like in a team and nip it in the bid as quickly as possible. I’ve learned this through the school of hard knocks. I’ve been in a lot of companies where there has been rapid growth and with rapid growth you get silo-ization. You start with a small, cohesive core of people and then you get really large and, over time it gets political. It’s very normal to think or act like: “These are my things and this is my team.” And through no fault of their own, people try to recreate that sense of small, coherent team, except now there are many teams across the company all doing the same thing. And then hierarchies start to emerge and people start thinking about ‘us’ versus ‘them’ and weird, political behaviour happens because of these silos and the separation between them.

I now know the warning signs when this starts happening. And I jump on them and address this immediately. But I would have saved myself years and years of worry if I knew what those signs were 20 years ago and how to fix them, how to nip them in the bud.

If you don’t know what the signs are, you can’t get out ahead of the problem.

Yeah. Exactly. It’s a slow devious thing and it can be hard to see. It’s a slow strange cultural shift that I wish I could have sensed or been able to sense 20 years ago.

I wish you could have, too.

[Laughing] Thanks.

Thank you. This was great. We really appreciate you taking the time to chat with us.

Absolutely. I enjoyed it. This was a great addition to my Friday morning.

This interview was edited for length and clarity.

The ghosts of management future.

We asked you to reflect on the ghosts of management past, and now I’m curious about the ghosts of management future. How do you think new technologies and automation will affect the way we manage or lead teams in the future? How might things be different five or 10 years from now?

I think distributed teams and workforces will be the future. This is Michael Lopp’s opinion, not Slack’s opinion. I think it’s inevitable. There are too many lovely cities full of all of these employable people while it’s getting really, really expensive in other places. I think the economics will push us towards a more distributed way of working. Hopefully Slack has a role to play in this transformation. I think it will be easier to do than it was five or 10 years ago. And I think this is what I hope will happen as much as I think the economics will just take us in that direction. That seems to be headed in our direction.

There’s actually a piece about that topic in last month’s Wired—tracking some of the other places where startups are emerging, how the workforce in those places is different, and how the work from funding to staffing and everything in between will have to adapt—or is already adapting.

Yeah. I think we’re going to see more and more of that.

Alright, last question. You’ve given great advice to hundreds of managers of the future. But what’s one piece of career advice you wish you would have got 10 or 20 years ago?

20 years ago? Twenty years ago?! Hmmm.

Is that too far back? Will it help if I sing the Cher song If I Could Turn Back Time?

[Laughing] No. It’s a good question. I’m just sifting through a list of tweets and articles and conversations. Um… I’m going to wish I could have crafted this better but I’ll say this: be aware of what political behaviour looks like in a team and nip it in the bid as quickly as possible. I’ve learned this through the school of hard knocks. I’ve been in a lot of companies where there has been rapid growth and with rapid growth you get silo-ization. You start with a small, cohesive core of people and then you get really large and, over time it gets political. It’s very normal to think or act like: “These are my things and this is my team.” And through no fault of their own, people try to recreate that sense of small, coherent team, except now there are many teams across the company all doing the same thing. And then hierarchies start to emerge and people start thinking about ‘us’ versus ‘them’ and weird, political behaviour happens because of these silos and the separation between them.

I now know the warning signs when this starts happening. And I jump on them and address this immediately. But I would have saved myself years and years of worry if I knew what those signs were 20 years ago and how to fix them, how to nip them in the bud.

If you don’t know what the signs are, you can’t get out ahead of the problem.

Yeah. Exactly. It’s a slow devious thing and it can be hard to see. It’s a slow strange cultural shift that I wish I could have sensed or been able to sense 20 years ago.

I wish you could have, too.

[Laughing] Thanks.

Thank you. This was great. We really appreciate you taking the time to chat with us.

Absolutely. I enjoyed it. This was a great addition to my Friday morning.

This interview was edited for length and clarity.



This post first appeared on Louder Than Ten, please read the originial post: here

Share the post

An interview with Michael Lopp: Managing humans when the sky is falling

×

Subscribe to Louder Than Ten

Get updates delivered right to your inbox!

Thank you for your subscription

×