You can bring a horse to water...

Trying to Convince People to Change

I was talking to a friend who was frustrated with one of her engineers. This engineer had a tendency to fall into some bad habits when stressed out, and my friend had given him a book to read on the topic, but he hadn't bothered to read it. Why not read the book, which would shortcut all of these conversations and corrections my friend needed to make over and over?

Are you familiar with this story? I am, having lived it several times. I have given my team various books to read over the years. Some of those books include:

Creative Mission Critical Synergy For Leadership

Turn the Ship Around
Leadership and Self Deception
Making Things Happen
The Five Dysfunctions of a Team

I have even held reading groups for some of these, I wanted so much for my team to read them.

I love to read, and I have grown to love books in the "self-help/business/leadership" genre. These books have taught me a ton, heck, I blogged my defense of the repetitive business book because I find so much value in them. They're great!

However, getting value out of books like these is predicated on two important factors:

1) You have to actually read them
2) You have to read them with an open mind to learn from them

Asking my team to read books has had mixed results. The most successful book I tried to get folks to read was Turn the Ship Around. I read it with my leadership team, and we would discuss it in our team meetings. It is a book that is so deeply applicable to the practice of managing engineering teams that I think it was easy for my team to appreciate its value.

For most of the rest of the books, the people who were already interested in the topics read them, and the people who did not want to change what they were doing did not. Even when the doubters read them, they read them with a mind towards disagreeing with their message, and I'm not sure they got anything out of the books.

This is not a fun lesson, but it is an important one for anyone who is managing a team. You can't force people to want to change. You can give them information, books, classes, coaching, but if they don't see a need to change, none of that will help. So the first thing you have to do, before giving them books, is to really convince them that they need to change.

Ah, but this is tricky! Do they actually need to change? If they change, it will make your life easier. Will it make their life easier? 

Sometimes, we want people to change when in fact what needs to change is the situation we've put them in. If someone on your team is acting really negative, do they need to change their attitude? Or perhaps, do you need to move them to a team where they are not being ignored by their manager?

Before you look to change the people, make sure that the change that needs to happen isn't in fact something in the environment that you can control. 

Most people are going to behave in unhealthy ways when they are in unhealthy environments. Asking someone to change the way they react to stress is a tall order. Sure, it would probably be good for them to chill out, be nicer, stop blaming others for their problems, but I've been working on my unhealthy reactions to stress for years and I know I still have a long way to go. Even when people want to change, personal change doesn't happen overnight. It is usually easier for a manager to change the environment than it is to change a person's reaction to that environment.

Looking back to my successful reading suggestions, they have almost all come when people had control over their environment, and the book was about helping them drive change in the team. It is pretty rare that I've given an unhappy person a book for reacting better to unhappy circumstances and seen them embrace it.

Poor reactions to difficult situations can negatively impact the team and it's your job as a manager to help people identify these behavioral issues. Books can be great for this, but they are rarely going to shortcut the process of change. No matter what, don't forget to look at the circumstances that are triggering the behavior. It is unlikely that you'll coach your team to Buddha nature but you might be able to reduce the stress that is causing the problems in the first place, and that's a win for everyone.

Ask the CTO: The Angry Employee

Question:

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?

Answer:

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.

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?

Framing

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.

What do I do with my time?

Question:

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.

Qualitative or Quantitative but always Analytical

I did a panel at Etsy's engineering leadership offsite today, which was amusing. One of the topics of the panel was:
Challenges of balancing data-light product bets vs purely data driven incremental improvements.

All three of the panelists agreed, although each of us phrased it a different way. The first panelist (Dan McKinley) spoke about the need, even for products that are not purely A/B test driven, to drill down on the goals and try to find something to measure about how a project will actually achieve a goal. If the project is part of a larger goal to increase revenue by 25% this year, what way is it contributing to that? How do we measure its success? Even when you are driving decisions by "vision" there is some quantitative goal you are trying to achieve, so state what it is.

The second panelist (Albert Wenger) spoke of the importance of balancing the quantitative with the qualitative. Some things cannot be purely quantitatively measured, and there are qualitative measures that are incredibly valuable to the process of discovering product market fit. User testing, user research, watching how people actually engage with a product are all essential to creating something great, beyond simply finding numbers to measure and trying to increase them.

My perspective on the issue is that qualitative methods are important, but qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.

So, instinct and guesses are necessary. But we needn't lose our analytical approach just because we don't have data. When you build something, you have a hypothesis about the person you are building it for. You have a guess as to what they will like, and most of the time you have a reason for that guess. When you're trying to build a business, you need a chain of events that you expect could happen that would indicate a product is successful. You have a sense of what to start measuring once the thing is released that will show whether it is working. Answering the questions of who is my customer, why would she use this, and what will signs of interest and engagement look like is essential to going from vague instinct to thoughtful first product.

Data can't make all our decisions for us because data isn't there to get us from 0->1. We have to use our powers of observation, of empathy with our customers, and of deduction, to create smart hypothesis in a qualitative way. Qualitative analysis will always have a role in product development, and customer empathy is likely to drive us more quickly to great products than simply relying on numbers alone.

Thanks to Etsy for hosting and my apologies to my fellow panelists if I misrepresented your views!

Hiring Engineering Managers: Screening for Potential

I have been in many discussions on the best way to interview and hire engineering managers. Here are my thoughts, having done this both successfully and less successfully, including some things that I have looked for in the past when being interviewed. 

First: Be thoughtful about what you are looking for. There are people out there who are looking for the opportunity to go into management. Lots of them, in my experience. These are good people to hire, because many of them will turn out to be good, thoughtful managers. Most of the time I hired this sort of person into a senior engineering role that quickly became a tech lead role. I was explicit at hiring that we didn't have a team to give them immediately but that I would be expecting that as the overall team grew they would move into such a role when it became available.

Now, I should be clear, this exchange requires a lot of trust on both parties, as well as the possibly unspoken assumption that they still have to prove themselves capable of doing the job once on the team. I have turned down jobs that asked me to make this bet, and I would not hold it against anyone who felt that it was too risky. But on the flip side, if you really want to grow your management from within, hiring people who both want to be eventually moving to leadership roles but are comfortable coming in as individual contributors first is pretty essential to making that work. If you want to grow management from within but don't bother to look for people who want to grow into management roles when you're hiring, you may end up with mostly people who just want to code, and that is not good for anyone.

OK, so you're hiring a specific management position. What do you look for?

There are two camps here. The first camp is that you look for incredibly smart tech lead-level developers who may have had limited management experience and put them in the role. They will easily pass whatever technical screens you put in front of them, but hiring is a risk because they may not really be good managers. If this is the way you want to go about hiring managers, you need to spend a good deal of time focused on screening for management potential. Screening for potential is different than screening for experience. Right now, I'm going to talk about screening for potential; in part 2, I'll talk about experience.

Questions to tease out potential: 

Tell me about a project where you have acted as the tech lead. What was your role like, as tech lead? What were things you did that were different from the rest of the team? How did you ensure that the project was successful?

What you are looking for: Someone who answers with more than just "I designed the architecture, chose the libraries, and wrote the most technically challenging pieces of the code." They should have taken an active role in the project management, even if there was another person explicitly or implicitly in that role. They should have contributed to predicting problems with the delivery and working with the people on the team or cross-team to ensure success.

When you bring a new team member onto your team, what kinds of things do you personally do as part of their onboarding? Have you ever been a mentor to a new hire or intern? What was that like, what did you learn from it?

What you are looking for: Someone who is actively engaged in the work of bringing on new people, and thoughtful about making that process better. Someone who respected the work of mentoring, who isn't just trying to shed human interactions quickly to get back to code.

Tell me about some things you have done to make the process of writing or delivering code in your organization better.

What you are looking for: Some strong examples of seeing process/people/systems problems and raising their hand to suggest improvements.

One suggestion I have heard, but not tried, is to do a role-playing exercise with the candidate. Set up a circumstance that might happen, such as, an employee is unhappy that they did not get promoted. Provide an overview to the candidate and give the interviewer some details that may include information that the manager doesn't necessarily know. Have a third party observe the interaction, and then at the end of the role play all three talk about what went well and didn't. This could be an interesting tool for hiring either the experienced manager or the potential-driven manager, but I also suspect it is easy on the flip side for it to go poorly if the interviewer isn't good at guiding the roleplay and knowing what to look for. (Credit to Marc Hedlund for this idea!)

Finally, when hiring this type of candidate, you are probably going to get (and maybe even should be intentionally seeking out) someone who is going to not only manage people but drive technical decision-making. Make sure that the people who currently drive technical direction (if they exist) are aligned on that front with the candidate. If the candidate is gung-ho about functional programming and microservices and you are happy in a more conservative technical space, you may end up with someone who wants to make big technical changes that you might not agree with. The team should feel a general alignment to their technical perspective, and ideally people are excited about working for this person because they feel that they will learn something, but don't just hire them as a manager because people are excited about their technical chops.

Overall, when screening for potential, look for signs of stepping up, caring about the people on the team, and thoughtfulness about the processes. In general you should also be looking for excellent communication skills, and everyone who interviews the person should feel pretty comfortable with the idea of working for them. Be wise to potential bias here. The best managers are often overlooked because they don't pattern match to certain characteristics, whether they are "tall and male" or "forceful personality" or whatever. Talk to the team before the interview and give them examples of great managers who sit outside of those stereotypes to reset their stereotype bias a little bit.

When you mishire on potential, it tends to come from overvaluing technical skills + pattern matching on "what a leader looks like", and the failure mode is managers who just don't deliver coherent teams and/or can't deliver projects effectively. Never ever hire a person you feel is overly ego-driven.

One final word on this candidate: If you hire someone for potential, be prepared to train them. They are going to need help. Whether it is formal training or a lot of mentorship from you or a mix of both, no one is born knowing how to manage. I think it is worth sometimes taking a risk on people like this (I'm glad someone did that for me once!) but they will struggle if they have to do it all alone.