Buy My Book, "The Manager's Path," Available March 2017!

Wednesday, February 24, 2016

Ask the CTO: The Angry Employee

A few days ago, we had a fairly impromptu team meeting to discuss a new initiative. My goal was to brainstorm some creative visual ideas with the designers, but I also invited the engineering team so that they could participate. One of my senior UX engineers, Dan, was out of the office, and so he dialed in to the meeting because we couldn't realistically wait for a few days and it didn't seem urgent that he attend in person.
We had the meeting, and one of the ideas seemed to touch on some of the things Dan really cared about. The designers were proposing something that in my mind was orthogonal to what he had been advocating, but he felt angry that others were encroaching on his turf. This culminated in a rant on team chat about the situation which upset several of the other teammates, and when I tried to message him about it privately (he was still out of the office) he got angrier and accused me of not supporting him and always siding with the design team over tech. What do I do?


Well, there's a lot to unpack here. Seems like a few things that should have been minor issues (team meeting without everyone in the room, one person feeling that others were encroaching on their job) escalated quickly into some serious unhappiness.

Let's discuss what went well. Trying to address the issue of inappropriate venting on chat right after it happened was the right thing to do. Even though chat is not a great way to have difficult conversations, it is always good to provide immediate feedback when you see things happen that are not respectful of others in the workplace. Sometimes the person will apologize immediately, to you and the team. If this happens, you don't need to bring it up again but you do need to watch for it in the future. Unfortunately, this time it just escalated the situation, and instead of an apology you got blamed for creating the frustration in the first place.

The thing to do now is to get face time with Dan. You can take him to breakfast, lunch or coffee if being in a public place seems more neutral than doing it in a conference room or office, but it needs to happen quickly. Letting him cool down for a day before you address the issue again is OK and possibly even healthy, but it is not OK to let this hang out there for days.

Once you get him face-to-face, your job is to listen. Completely. Don't say anything except perhaps murmurs to indicate that you are listening and following along as he speaks. At the end, give him a period of silence to ensure that he is really, truly done saying what he needs to say. For many people, just listening will be the hardest part. But you gotta get comfortable holding silence even when you're bursting to comment.

Now that he's done, you are going to repeat back to him what his concerns are as best you can, and ask clarifying (vs leading) questions. Your goal here is to make sure you understand exactly where he is coming from, and he believes that you understand this. This is to stop yourself from telling stories about him. If you find yourself filling in gaps, "you are mad because you were not in the room because you're always taking days off whenever it suits you," for example, stop. No filling in gaps. No telling stories. No imagining motivations beyond what he has told you. Give him the chance to feel totally heard.

Only once he feels totally heard are you allowed to then offer your interpretation of the situation, and how it differs from his. Try to come at this with a new perspective given what you now understand of his experience. You may find, after hearing him out, that you did screw up and ignore his ideas. If this happened, admit it and apologize.

OK, cool, so you've heard him out, and stated your case. Now what?  First, if he has not yet apologized for the chat outburst, that needs to happen. It is not optional. Remind him that, as a senior person on the team, people look to him for leadership, and his behavior was not one of a leader. Beyond that, you need to start talking about why he trusts you and/or the team so little that he felt compelled to dial into a meeting that was really a courtesy invite, and why he thinks that others are stealing his ideas and getting credit that he is not getting. Because people rarely get angry and stay angry after a single minor incident. They get angry and stay angry because they've built up resentment about something over time. This is a strong warning signal to you that something is broken in your team. Even if this person is lost to you, identifying the trust gap on the team and working to repair it is essential for future stability.

A few final thoughts. We sometimes go overboard in trying to get everyone in the room for "brainstorms" and "idea sessions." Inevitably, as your team grows, people are out of the office or worse, you just simply cannot have every single person involved in these decisions. This often feels like a loss of control for early employees or senior folks who are, for whatever reason, excluded. Coming up with strategies that let people have effective idea meetings without having everyone in the room is essential. Remind everyone that ideas are just the barest first step. The path from "idea" to "implementation" usually twists the idea in ways you can't foresee, and there should be plenty of chances for people to help shape them into a better reality even if they miss the inception point.

You may want to triangulate with another person's observations of what happened in the meeting. If you decide to ask someone else about their impression, be careful not to lead them into a story you want to hear. Take the time again to listen instead of speaking yourself. Even if they agree with your assessment that Dan was out of line or tell you that you did nothing wrong, don't use it as a cudgel to bash Dan with. Be especially careful of WHO you ask to share their observations. If you are guilty of favoring designers over engineers and you ask another designer for their opinion, they may back you up, not seeing the problem. Another data point can be useful but it still does not actually paint a perfectly objective picture.

Finally, there's the possibility that you can't handle this alone, that the person is too upset to talk to you 1-1 and you need to involve a peer, superior, or someone from HR as a mediator. If that is the case, steel yourself for what will likely be an unpleasant meeting. Even if you smooth things over, it's going to take some serious apologizing on both sides and a concrete plan to work through the issues that led to this place.

Dealing with an angry team member is always touchy, but as with most difficulty situations, it gives you the opportunity to look at a bigger picture that you might have been missing, and think of strategies to address it. So don't panic, listen, and learn from the situation at hand.

Monday, February 22, 2016

In Defense of the Repetitive Business Book

Over a recent vacation, I finally read Mindset, by Carol Dweck. For those of you unfamiliar with the book, I'll recap quickly. Have you heard that you shouldn't praise your children for being smart, but instead praise them for working hard? That is probably the most popular trend coming out of this book, which discusses at length and in almost excruciating detail why a "growth mindset," that is, one that believes that people can get better at whatever they choose, that effort and exploration are the keys to success, is preferable to a "fixed mindset" that believes that you are as smart, athletic, musical, etc, at birth as you will ever be, and effort is secondary to your measure of natural talent.

Mindset is a deeply repetitive book. You are treated to story upon story upon story of the successful (and happy, and well-adjusted, and sustaining) person who exhibited the growth mindset. You're treated to many contrasting stories of the successful but less-than-they-could-have-been (and unhappy, and maladjusted, and burned out) person with the fixed mindset. You also get a good dose of research to back up the observations of the behaviors of people who both put themselves in various mindsets and people in experimental conditions who are put into the two mindsets. It ends with some situations that you might face, a parent with a fixed mindset child being one, and suggestions for how to approach them with a growth mindset.

I would absolutely recommend that you read it.

You may be surprised, given the faint praise I have given so far. It's repetitive, deeply so. If you get the concept, then, why read the book? You could probably get the gist with a blog post or short article, or maybe a TED talk. What's the value of a book on the topic, beyond lining the author's pockets?

I think that sometimes I fall victim to this fallacy that if I am familiar with the general outline of a concept, and I agree with the concept, that I understand this concept. I see this play out especially in non-technical topics. If I can roughly explain it to someone, I understand it, right? 

Of course, there is a huge separation between understanding a concept and putting it into action. Many of the concepts introduced in pop psychology or business books are pretty easy to understand. The problem is putting them into practice. Remembering to do them. Most people understand that the first step to losing weight for most people is to get more exercise and eat better, and yet, putting that simple practice into place is hard. It's hard because breaking habits is hard, forming new habits is hard. Changing the way you react to things is hard. 

Mindset is in some ways just a rehash of concepts of Buddhism. Let go of your notion of "self." Be open, relaxed, curious, willing to believe that you can grow. The only inevitability in this life is change, nothing is fixed. That means that, yes, success is ephemeral, but it also means that you are capable of changing, learning, and growing, all the time. Many leadership, pop psychology and business books end up sounding like a rediscovery of parts of the dharma. No one is surprised when you say that, as a philosophical, spiritual, or religious person, you are still learning the meaning of your particular path, and learning every day how to walk that path. It is no surprise that it takes a lifetime of study. So, too, does learning the concepts of leadership, creativity, interacting with fellow humans, and growth. Whether or not it is a spiritual path, it is not something that most of us find natural, and not something that will sink in with an article, or even a book. But it helps to get a prolonged exposure to the idea, to work through some of its nuance, to spend 5 hours with it instead of just 15 minutes.

So, read Mindset. Think about your own mindset. I can say that personally I have moved slowly from fixed mindset to growth mindset over the years. It has been hard. I still fall back in places to the fixed mindset. Why am I moving? Mostly because it's just more fun to grow. To learn new things. To believe that you can change. I kept meeting these people that seemed so light, so free, so creative, and they just seemed so willing to learn and fail and learn some more. Why not me? Why not all of us?

Monday, February 15, 2016


I had a realization, towards the end of my last job, about company values. What are company values (aka "Core Values")? Well, here are some examples: Zappos, Etsy, Facebook. My former company had 10:
1. Everyone deserves a Cinderella Experience
2. Dream big and go after it!
3. Make the most with what you have...scrappiness is a virtue
4. Debating, honest conversations and collaborating make the company stronger
5. Happiness and positivity is a choice
6. Embrace the RTR family and bring your authentic self into the office each day
7. Bring your best intentions to everything and trust that others do the same
8. Adapt and learn from everything you do
9. Roll up your sleeves and get involved. Everyone should be accessible and involved with the day to day elements of RTR
10.We are all founders of Rent The Runway
When I first started, I was skeptical about the purpose of Core Values. Zappos, the most famous advocate of this concept, seemed a bit weird. I am not a conformist, and I felt like expecting a diverse group of people to embrace the same set of values and beliefs was a bit Orwellian.

What changed my mind? As part of the company review process, we would ask people to mention ways in which their peers embraced the core values. One person might write, for example, "When Jane suggested we try this crazy experiment to increase the performance of our product page, she encouraged us to dream big and go after it." You weren't required to spell out how each person met every value, just give one or two instances where they had met them.

Is it a good idea to use values as part of the performance review process? Well, for better or worse, one of the things that indicates success within a company is how well a person is capable of working within the culture of that company. This can be a bad thing, when the culture of the company is confused with the color of the company, the gender of the company, the background of the people in the company. That is not a very specific culture, and it is likely to cause bias that does not actually serve to reduce the collaboration issues that you might worry about in heterogenous groups. When company values are more explicit, however, they give you something that is (hopefully) less correlated with how people look and more correlated with how people communicate, make decisions, and behave.

I wrote, read, and delivered many reviews, always involving a section on values. I also observed many "core value stories," where employees would stand up and tell about another person or group who went above and beyond and how that tied back to some of our core values. I got to see over and over again examples of people exhibiting these values and the ways they presented themselves.

At some point, I realized there was a pattern. The people in the company who were beloved by all, happiest in their jobs, and arguably most productive, were the people who showed up for all of these values. They may not have been the people who went to the best schools, or who wrote the most beautiful code, in fact they often weren't the "on-paper" superstars. But when it came to the job, they were great, highly in-demand, and usually promoted quickly. They didn't all look the same, they didn't all work in the same team or have the same skillset. Their only common thread was that they didn't have to stretch too much to live the company values, because the company values overlapped with their own personal values.

What's the takeaway here? Well, we often talk about "culture." By now, we know that beer and ping pong tables aren't culture. Many of us fear that "culture" can be a dog whistle for "people who look like me." And yet, people are more likely to be successful and happy if they are in a company with a culture that matches their values. My experience has led me to conclude that looking for the values of your company as part of your interviewing process is probably at least as important as the technical and skills screening, in finding the best employees.

Why is this post called Framing?

The way you ask people to look for values is going to make a big difference in what they look for, and what they see. You might have 10 values, as RTR did. Would you really want to ask every interviewer for a "yes/no" on all 10? Probably not. But if you boiled that question down to "culture fit", do you think the interviewers are going to think about the company values? Or are they going to think about whether this person looks like them, talks like them, is "a person they could get a beer with?" The way you frame the question of culture is important, and if you aren't explicit, people may skip over the details and go with their bias.

If you agree with me that values are valuable, I encourage you to put them in your interview process, and make them explicit. Don't ask for "culture fit", list the values and ask people to mention any they noticed the person definitely meeting or definitely not meeting. Prime the interviewers beforehand with the list of values, so they know what to look for. And then, let me know how it goes! Because this is still theoretical for me, and I would love to hear your experience, as well as any counterpoints to what I have suggested.

Friday, February 12, 2016

What do I do with my time?

I'm a new manager, new to both the company I work for and to management. When I joined this company there were several fires for me to help put out, and every day I was busy dealing with one urgent task or another. But now I'm drifting. My boss doesn't have time to tell me what to do, I don't have any features that I am responsible for, and no one is urgently requesting my time. What is my job, now that things are no longer on fire?
Ah, yes. One of the challenges of management that we don't often talk about is those times when you have no clear urgent tasks. Engineers deal with uncertainty in relatively bounded forms, such as, how should I break down this big project into smaller chunks, how should I architect this system, who should I talk to for information about this feature, what library should I choose? These are enough to stymie some, but usually by the time you've been working for a few years you know how to get started on these types of problems.

Management, however, is a different beast. Management is like being in operations. Operations engineers must balance a series of ad hoc needs (system configurations or permission granting, say), with fires (outages), and long-term strategic projects (moving to a new data center, upgrading a major piece of critical infrastructure). As a manager you also have regular ad hoc needs (1-1s, meetings, small decisions) and fires (hiring, firing, projects in trouble, outages). And you have long-term strategic projects (planning for the team growth, thinking about the next quarter's goals, anticipating future obstacles). Like operations engineers, many managers get really good at the ad hoc and the fires, and really bad at the long-term strategic projects. It's much easier to do things right in front of you than it is to think abstractly about unclear topics.

When faced with the blank slate of empty time and no obvious deliverables, what can a manager do to make the best use of that time?

As a new manager to a new company, downtime is a good chance to learn the existing systems. Learning things that you aren't actually working on can be really challenging, so if it's feasible you might find small bugs to fix or minor improvements to build, things that aren't urgent (in case another fire crops up) but that will give you the feel for working in these systems. You can also use the downtime to meet with other teams that your team works with, learn about their projects and challenges, look at what they're busy with. Lend a hand to their managers, or help your boss fill that gap if they don't have one.

At some point, though, you will have gotten comfortable with the teams, the code, the projects, and you'll still find yourself with downtime. This is the chance to flex your strategic thinking. Take a bigger-picture look. What are you not doing that is important, but not urgent? Maybe it's planning for reviews next month, setting up a team dinner, doing some proactive outreach to candidates you may want to hire in six months, or finishing that presentation that you have promised to give on testing but keep putting off. What are the recurring problems your team is having? What is not going smoothly? What could you be doing to resolve that? Remember, part of your job now is to define what work needs to be done. Your boss won't always be able to tell you what to do, and she probably expects you to tell her what needs to be done. Use this time to answer that question.

Sometimes we put downtime to use in bad ways, and I don't mean procrastination. There are times when the best thing you can do with downtime is take a breath, check in on the internet, watch a talk you have been meaning to see. All of that is better than using downtime as an excuse to make work for other people, which can happen if you're not thoughtful. If you use your downtime to half-bake a feature and throw it into prod for your team to support, that is harmful. If you use your downtime to wander around and interrupt your engineers who are busy working, that is harmful (and yes, I'm guilty of that sometimes!).

You are responsible for finding productive uses of downtime, and part of that is resisting the urge to meddle, micromanage, and distract your team just because you don't know what else to do. Is everything going ok? Are your teams productive, getting things done, working on the right stuff? Great! Use your time to think about the future, write a blog post, catch up on small unfinished errands. Don't worry, there will be another meeting, another fire soon enough. Enjoy it while it lasts.