Book Report: Radical Candor

Radical Candor Book Cover It’s a challenge to think of useful things that I can tell you about this book that you don’t already know from listening to the Radical Candor podcast (and you are listening to it, aren’t you?) — much of the book will be very familiar. The podcast often references the book and the book often references the podcast, so there’s a bit of a ouroborus trying to talk about one or the other.
The premise of the book and podcast is simple: by providing honest feedback (and especially not shying away from negative feedback) you will lead your team to better results. That’s not quite enough to fill a book, but that’s really at the core of all the advice: whether it’s getting to know what motivates your team or how to run effective collaborative meetings, it all relates back to create a culture of useful feedback.
There’s plenty of good advice to be followed here, and I would strongly recommend the book for new leaders (or even leaders moving into new roles) looking for good advice on getting started: there’s even a “Getting Started” guide at the back of the book to walk you through implementing the books’ ideas. Here’s one of my favorite bits, which is a typical example of the obvious (once it has been clearly stated) advice that the book is full of:

One of the funniest things about becoming a boss is that it causes an awful lot of people to forget everything they know about how to relate to other people. If you have a beef with somebody in your personal life, it would never occur to you to wait for a formally scheduled meeting to tell them. Yet, management has been bureaucratized to the point that we throw away effective strategies of everyday communication. Don’t let the formal processes — the 1:1 meetings, annual or biannual performance reviews, or employee happiness surveys — take over. They are meant to reinforce, not substitute, what we do every day. You’d never let the fact that you go to the dentist for a cleaning a couple times a year prevent you from brushing your teeth every day. Don’t use performance reviews as an excuse not to give impromptu in-person feedback.

I’m a reader and I liked this book quite a bit, but if you’re not a reader, fear not! You can get plenty from tuning into the podcast each week.

Book Report: The Visual Display of Quantitative Information

I’ve been interested lately in the idea of using infographic pages to display critical stats about the services my teams build. In typical fashion, I decided to start by reading a book, and this one seems to be the book to read in the field of informative graphics.
It was definitely a bit of a mismatch — I didn’t get what I was hoping to out of the book. Perhaps partly because of my disappointment in that, I also didn’t find the book to be very helpful. For one thing, most of the rules Tufte lays out are negative rules. “Don’t use gridlines” (he calls it chartjunk) is typical. Even some of his “Do” rules are really about things that should be erased. Some of the ideas seemed obvious to me and others felt like an opinion stated as absolute fact.
And that’s definitely a thing in this book: Tufte rarely sounds like he’s voicing an opinion, instead the book is filled with statements like “Beautiful graphics do not traffic with the trivial.” As I was reading the book, my inner voice would often fall into a Hollywood “Voice of God” tone. Here’s another typical example (although in this one, at least Tufte starts out with the qualifier “should”):

Data graphics should often be based on large rather than small data matrices and have a high rather than low data density. More information is better than less information, especially when the marginal costs of handling and interpreting additional information are low, as they are for most graphics.

Perhaps this book, written in 1982, has just become a bit dated? I found some of Tufte’s “improvements” on data display more confusing than the originals; apparently those visual metaphors did not catch on. I did get some value out of the book; I suppose it served as an introduction to some of the vocabulary and concepts, but overall I’d say this book is more useful to someone who’s building graphics in a statistical context than someone looking to do so in a business context.

Book Report: Turn The Ship Around by David Marquet

Turn the Ship Around Book CoverThis short, entertaining and insightful book tells the story of how the author, David Marquet, effectively applied bottom-up leadership principles when taking over command of a submarine, and achieved some truly remarkable results.
As I began reading a lot about leadership research a few years ago, I initially found myself quite surprised to find references that the US Armed forces have been increasingly abandoning command and control leadership approaches for a much more modern and collaborative approach. If you haven’t seen evidence of that yet, it may surprise you that the passage below was written by a submarine Commander:

In our modern world, the most important work we do is cognitive; so, it’s not surprising that a structure developed for physical work isn’t optimal for intellectual work. People who are treated as followers have the expectations of followers and act like followers. As followers, they have limited decision-making authority and little incentive to give the utmost of their intellect, energy, and passion. Those who take orders usually run at half speed, underutilizing their imagination and initiative.

Because this book walks through his journey starting a short time before he took over command, it offers insights that would probably be especially useful to someone taking on a new leadership role: I suspect it will be on my re-read list when the next transition in my career comes.
The book is surprisingly short, but it packs a lot of thoughtful advice into its pages while remaining entertaining and engaging. Marquet does a fantastic job of using stories to illustrate his point, and having fun with them. He achieves a subtle elegance with language that I don’t expect out of leadership books. Here’s a typical example, where I had to pause to ponder for a bit which meaning of “blow stuff up” applied:

For phase one, we rendezvoused with a helicopter and picked up the SEAL team. Eleven burly guys, their weapons, two rolled-up Zodiac inflatable boats, two motors for the Zodiacs, and a bunch of equipment to blow stuff up left the helicopter, came on board the submarine, and went down the hatch.

If you don’t have time for the book, you can get most of the essence of it from this excellent video:

Book Report: The Ten Day MBA

The last time I was applying for a job I wondered frequently whether it would be a worthwhile investment for me to get my MBA. Many people go and get their MBA to get the sort of job that I had at the time. But would it have made me a more attractive candidate? Since then, I’ve had conversations with several trusted mentors and have decided that it’s not going to help me do the sorts of things that I want to do.
However, The Ten Day MBA looked like a quick and potentially useful survey over some of what I was missing. I’m pretty sure I’m not going to retain much of what I read; it’s simply too fast. A 30 page summary of quantitative analysis? Nope. Silbiger only has the space to make super quick statements without follow-up, such as when describing the Keynesian relationship: “It was especially true in the period between 1950 and 1985, but it has not been consistently so over time, such as the period since 1985.” What exactly is that saying? ¯\_(ツ)_/¯ You’ll have to find your own answers to many such questions when reading this book.
The book also suffers from being an older book that has been updated over time. A section recommending the internet as a really good way to do research, which lists a few useful search sites including yahoo and google as really good resources? You might get a headache from the speed at which your eyes roll into their sockets. And that worries me about other advice in the book which I know less about.
I quickly realized this was going to be useful in the same way that books like “Teach yourself C++ in 21 Days” were useful in the age of dial-up networking and terrible internet searching — the book gives you a general overview of the topics, gets some key words and concepts in your head, and you can refer back to it whenever you need to. When you do that it will give you a quick overview, which you can use as a springboard to jump into more detailed study.
All-in-all, for me personally this book was probably a better investment than getting an MBA would be. I’ll leave it at that.

Conference Notes: Neuroleadership Summit 2016

I’ve been looking for a conference entirely focused on leadership of software development teams, but haven’t found anything since goto leaders seems to have folded (if you have suggestions, comment, please!). But in my search, I found the Neuroleadership Summit, which appealed to the geek in me because of the hard-science aura of neuroscience. I was fortunate enough to attend this year and thought I’d share some of my observations.

General Impression
If you’re used to attending tech conferences, the first thing that will probably strike you about the conference is the diversity of the attendees. While I couldn’t find any published demographic data, I would guess that it was majority female, and it had many more people of color than you would be likely to see at a programming conference. This was a welcome change of pace for me.
The Neuroleadership Institute bills the conference as “the most brain-friendly conference on earth” (you can read some semi-propaganda about this) and I have to say that they certainly put some effort into this. The food served attempted to be more healthy than the average conference fair (mostly succeeding), but most impressively the format of the conference is significantly different than any conference I’ve attended. There are fewer sessions, broken up by more networking times, and most significantly, each presentation included several breaks during which you were encouraged to discuss your impressions with someone sitting near you that you had not chatted with before. While this was cringingly awkward for an nerd like me, it did often lead to insights, and I would say that generally I remember the content better than I normally would. Brain science, who knew, right?

Random quick hit clippings from my notes

  • “Mandatory non-thinking time”: decision making is taxed throughout the day. Before important meetings, set aside some time to not think!
  • Can we improve inclusion by capturing and encouraging curiosity?
  • Comment from Claude, one of the many interesting people I met: “Employees want to please their leader. Possibly in the laziest way possible.”
  • Impressive (scary!) things can happen simply by inducing a slight current to certain parts of the brain. This can be done with magnetic fields. tin-foil hats!!!
  • We still rely on labor policies that were created in the 1940s
  • A suggested strategy for overcoming bias in hiring: think about who will be the best hire 3 months from now?
  • Currently leadership potential is generally determined by self- or manager-based identification, which is a terrible predictor of future leadership performance.
  • Branding for new-agey initiatives can be hilarious. The Army brands its mindfulness training as “tactical breathing”.
  • Want to create culture change? Define a list of habits that embody that culture, and try to instill those. Keep the list small!
  • Feedback offered is almost entirely useless. Instead create a culture of asking for feedback. Thought: isn’t this exactly what we do when we submit a PR request? We should capture that better!
  • If you’re not getting feedback from at least three sources, you’re only getting bias (this one hit me hard)
  • We don’t learn from experience, we learn from reflecting on experience.
  • Trying to control your unconscious bias is like trying to control your pancreas.
  • Awesome phrase, and I’ve entirely forgotten the full context: “Deeper thinking at a structural level”
  • People who perform the best feel that they are bringing something unique and important to the team.
  • Instead of calling it diversity and inclusion, we should call it inclusion and diversity.
  • heh… The last thing written in my notebook: “We’re supposed to be sitting here and reflecting on the past few days and they’ve invited the most distracting possible performer to sing while we’re doing this. Instead of being able to think, I’m uncomfortable and NOT enjoying this at all” (to be fair, other’s in the audience seemed pleased)

Useful things for 1:1s based on neuroscience!

  • Best feedback strategy: “You should do more of x”. All negative feedback offered flares defensiveness. (This is exactly the same advice I’ve read in every parenting book I’ve ever read).
  • “What was the most useful PR comment you’ve received lately?” (also: can we build a github plugin to capture this?)
  • “Who on the team energizes you? As in when you walk away from a conversation with them, you feel energized?”

First, a quick complaint: the Neuroleadership Institute spent a little too much time self-promoting during the conference — that became increasingly annoying over time. By the time they brought the entire team on stage (which took a good 10 minutes) for a public thanks at the end I was getting really annoyed with it.
I had a great time at the conference, but I’m not sure I would personally go back. I’m not really the target audience. Much of the audience were professional coaches or HR folks. I would recommend this as a fantastic conference for a new leader (1st year manager?) to attend. If you read Harvard Business review on a regular basis, there’s not much more for you here. If you subscribe but never get the chance to read, perhaps it would be a good opportunity to focus once per year on new research.

Book Report: Reinventing Organizations by Frederic Laloux

reinventing-organizationsReinventing Organizations by Frederic Laloux explores non-hierarchical organizations (they’re called “Teal” organizations throughout the book) in an effort to explain how organizations can operate without much in the way of structure — essentially a CEO and then a bunch of title-less employees that simply find work that needs to be done and go and do it. It sounds utopian, to be sure, but Laloux explains the history of several successful businesses that have been operating in this paradigm for some time.
Probably most impressive is the story of Buurtzorg, a Dutch neighborhood nursing organization that grew from 10 to 7.000 nurses in 7 years, and has achieved incredible results:

The results achieved by Buurtzorg on the medical front are outrageously positive. A 2009 Ernst & Young study found that Buurtzorg requires, on average, close to 40 percent fewer hours of care per client than other nursing organizations—which is ironic when you consider that nurses in Buurtzorg take time for coffee and talk with the patients, their families, and neighbors, while other nursing organizations have come to time “products” in minutes. Patients stay in care only half as long, heal faster, and become more autonomous. A third of emergency hospital admissions are avoided, and when a patient does need to be admitted to the hospital, the average stay is shorter. The savings for the Dutch social security system are considerable—Ernst & Young estimates that close to €2 billion would be saved in the Netherlands every year if all home care organizations achieved Buurtzorg’s results. Scaled to the US population, this savings would be equivalent to roughly $49 billion. Not bad for just home care. Imagine if the incomparably bigger hospital organizations were to be run in a similar manner.

The book is filled with similar stories of amazing results, but where it fails, for me, is Laloux’s absolutely positive view of the organizations and practices. At no point is there any serious exploration of negative impacts the organizational changes described. The only negative language used in this book is to describe those who doubt that the system, and the book often uses flowery new-age language to describe business environments: a “beautiful set of practices”, a “wonderful procedure”, “we need integrity and wholeness to transcend the primacy of profits and heal our relationship with the world.” It feels more like a book about religious or spiritual practices than a book about business. Because of the overly-positive descriptions, and lack of any raised concerns, I found the book to be untrustworthy, especially given what I’ve read about Zappo’s attempts to adopt Holacracy.
Some of my peers who enjoyed the book more than I have share my skepticism about some of these practices in the context of a software development organization: I was disappointed that there was no example there. Laloux also doesn’t answer questions of scaling to my satisfaction: I find it telling that the book mentions (frustratingly briefly) that the two largest organizations discussed have both abandoned their “Teal” practices.
Laloux also blows right by issues that raise my eyebrows — as here when he explains that a Morning Star employee is expected to write a letter to colleagues outlining a work schedule that raises life-work balance issues to me (not to mention my cringe at the idea of having to write a commitment to colleagues outlining said “balance”):

Morning Star has a similar practice: each colleague indicates in his CLOU [Colleague Letter of Understanding] his work schedule commitment. A person might indicate, for example, 40 to 45 hours off-season, and 50 to 55 hours in high season (when tomatoes are harvested and processed). Because colleagues discuss their CLOUs, they know about each other’s commitments.

My biggest concerns are with the descriptions of the feedback and conflict resolution processes described in the book. Here’s a bit about feedback:

The first is simply to approach feedback with the ancient insight shared by all wisdom traditions. We can approach the world from one of two sides: from a place of fear, judgment, and separation; or from one of love, acceptance, and connection. When we have difficult feedback to give, we enter the discussion uneasily, and this pushes us to the side of fear and judgment, where we believe we know what is wrong with the other person and how we can fix him. If we are mindful, we can come to such discussions from a place of care. When we do, we can enter into beautiful moments of inquiry, where we have no easy answers but can help the colleague assess himself more truthfully. Bringing this kind of mindfulness to discussions is something we can learn, something that can be taught. Simple practices can help too: we can start feedback sessions with a minute of silence or any other personal ritual that helps us tune in to love and care.

And here’s the conflict resolution process at Morning Star:

The conflict resolution process (called “Direct Communication and Gaining Agreement”), applies to any type of disagreement. It can be a difference of opinion about a technical decision in a given situation. It can be interpersonal conflict. It can be a breach of values. Or it can be related to performance issues, when one colleague finds that another is doing a lousy job or not pulling his weight. Whatever the topic, the process starts with one person asking another to gain agreement:

  • In a first phase, they sit together and try to sort it out privately. The initiator has to make a clear request (not a judgment, not a demand), and the other person has to respond clearly to the request (with a “yes,” a “no,” or a counterproposal).
  • If they can’t find a solution agreeable to both of them, they nominate a colleague they both trust to act as a mediator. The colleague supports the parties in finding agreement but cannot impose a resolution.
  • If mediation fails, a panel of topic-relevant colleagues is convened. The panel’s role, again, is to listen and help shape agreement. It cannot force a decision, but usually carries enough moral weight for matters to come to a conclusion.
  • In an ultimate step, Chris Rufer, the founder and president, might be called into the panel, to add to the panel’s moral weight.

Since the disagreement is private, all parties are expected to respect confidentiality during and after the processes. This confidentiality applies of course to the two persons at the heart of the conflict as well. They must resolve their disagreement between themselves and are discouraged from spreading the conflict by enlisting support and building rival factions.

Thinking about how these processes might look to someone who’s been discriminated against in life — who’s likely to approach any of these discussions feeling oppressed rather than empowered raises huge concerns for me. Can you imagine that conflict resolution process in the context of a sexual harassment incident? Step one is to sit together and sort it out privately? Then they need to find a mediator? I seriously can’t imagine that this is truly the process in that case, and yet Laloux (as always, ignoring any potential problem areas in the practices he describes) does not mention any other process. In that context — even if that would be legal (I can’t imagine it is) — it is horribly, deeply immoral.
Laloux would respond to my concerns that they are coming from my own fear and ego (the word “fear” appears 83 times in 326 pages of text). Maybe that’s true, but I don’t think I’ve approached much of my career out of a sense of fear, and I am genuinely interested in the approaches these organizations are taking.
In fact, in spite of all of my criticisms about the book, I found it a very worthy read. First of all, it was deeply challenging to many of the views that I hold. More importantly, in spite of the fact that Leloux suggests that attempting parts of these practices within a hierarchical structure is a waste of time, I found many ideas in the book (and in my thinking about the book) that I will be experimenting with over the next few months.

Forget “allowing” remote work — it’s time to focus on enabling remote productivity

In the technology space, the allowing remote work has become default — you’re going to stand out if you don’t allow it. Remote work simply needs to be on the table for you to hire the best people. And allowing the flexibility provides huge payback: the benefits are well documented.
What I’ve learned in my current role is that remarkably simple tweaks can completely change the remote experience. It really comes from a simple rule that I can claim no credit for whatsoever:

whenever someone is remote, we treat all meetings as if everyone is remote.

This results in an office that sometimes looks a bit silly, as two engineers sitting next to each other might have a conversation back and forth while staring at their screens and wearing headphones, but the impact is enormous. We’re not allowing remote work, we’re finding ways to make remote work no barrier to working and communicating effectively.
The practice for the team has been to notify everyone on our team slack channel at some point in the morning when you’re working from home (if that’s not your default). No need to check in advance, just let us know. In fact, there are many people on the team who let everyone know in the same channel when they’re in the office. The early morning conversation is largely “WFH” or “WFO” posts.
Although there are some reasons that working remotely is difficult for me personally (mostly that I have pre-school-aged twins) I’ve found now when I work from home I’m able to communicate and collaborate just as effectively as I can from the office. Sure there are some exceptions — meetings with other teams is a big one — but overall, I’ve found that working from home is suddenly easy as a leader — I don’t have to cancel or move meetings or 1:1s around. Even if I was in the office, there’s a good chance that anyone else in a given meeting will be remote. And I’ve started to discover that there are certain types of work (catching up on email, bureaucratic tasks, writing or preparing presentations) that work much better for me when I’m at home, even with the twins periodically stopping in to see what I’m up to.
I’m reasonably sure that there are other simple tweaks that can help just as much, and I’ll keep looking for them. What works for your team?

Book Report: Idea Flow: How to Measure the PAIN in Software Development by Janelle Klein

ideaflowThis is a self-published book that covers a lot of ground, and it has some flaws. Reading this feels a bit like experiencing a non-stop high velocity flow of ideas (sorry, couldn’t resist) that can be roughly organized and overwhelming at times (I was reminded of the character Jordan from the movie Real Genius).
But the ideas themselves? They are crazy thought provoking. This book has me thinking a lot, and I think you could choose almost any section of it and dig into the ideas for weeks before coming up for air. This book will definitely require a re-read to fully explore what I’ve discovered from reading it, and I expect to find it just as fascinating the second time through.
As the subtitle might have you guess, this is primarily focused on solving painful projects. As I read the book, I thought back to various projects I’ve worked on where Idea Flow could have made a tremendous difference in our ability to identify the correct problems, and sell the executives on why we needed to invest in fixing the issues identified. I’ve recommended the book to several folks who are currently working on projects that have a lot of “pain” and I expect it will help them quite a bit. One strong reaction I have after reading the book is that Idea Flow Mapping strikes me as an idea that would be very difficult to implement as a top-down initiative. This is a developer-led movement for sure — the amount of data that needs to be collected could easily be perceived as very “big brother”-ish (in fact, more than one developer I’ve described it to used exactly those words) as a management initiative. Klein’s own suggested presentation supports this:

I want to make the business case to management for fixing things around here. No more chaos and working on weekends, this needs to stop. I need data to make the case to management, though, so I need everyone’s help.

I also haven’t fully figured out my own reaction here, but although I think this framework could offer a lot of value to many teams (including teams that I’ve worked on in the past), I’m quite convinced that the approach described here would add little if any value to my current team. Why is that? I’m not sure — perhaps my team is small enough that the communication of ideas between the developers and code are easier to keep in sync. Perhaps it’s simply that the codebase itself is small enough. Maybe it’s just that the group of developers are similar enough to make ideas flow naturally. I’m also willing to concede that I may be flat out wrong. I know I’m going to be thinking through this for a while though, and trying to figure out why I think that this is true.
Even though the practices described here don’t feel right for my project right now, the ideas will influence the way I approach problems moving forward.
Klein’s ability to describe the escalation of pain in our processes can occasionally feel like re-living the very worst of our professional experiences:

The pain doesn’t happen all in one step. One decision usually sets up the preconditions for an unavoidable high-risk situation later.
The classic example of this in software is writing confusing code. When the code is written, the author can manage it fine, get it working and deployed to production. There is no immediate impact from this decision. The problem comes in when we have to understand or modify that code and there is suddenly a high risk of making mistakes.
The best way I’ve found to explain these problems, I picked up several years ago from an article by Scott Bellware. The pain comes from an increase in the number and severity of safety hazards.
When we use analogies like land-mines, fires, and various types of hell, we’re referring to the hazards in our everyday work. We may not be working with sharp objects or explosives, but the anxiety, stress and exhaustion from working in a hazardous environment is very real.
Likening these conditions to working around land-mines makes a lot of sense. We aren’t necessarily aware that we’re in a high-risk situation until we happen to step on the land-mine and something explodes. The lack of awareness makes these conditions all the more dangerous. It’s the knife that’s in the wrong drawer, the toys left out on the stairs, the loose screws in our bicycle. Hazards increase the risk of injury.
Let’s say we deploy some changes, then later realize we made a mistake. Our code is doing something horrible like over-charging our customers. Now we have an urgent situation on our hands. We care about the company and don’t want to fail, so we do whatever it takes.
Suddenly we’re working late nights and weekends, choking down Red Bull to stay awake, and hacking out last minute changes. We might end up breaking something else in the process.
It doesn’t matter if we’re sick, if we were supposed to go watch our kids’ recital, or meet our spouse for an anniversary dinner. When things go wrong and our project is online, we sacrifice a lot. At the moment of urgency, we can no longer choose safety.
By compromising safety, we increase the likelihood of making mistakes and the pain from the impact. Things don’t always go wrong, we’re gambling. If we’re lucky, we save time. If we’re not, we can lose big. The more we lose, the more time pressure builds and the more compelled we feel to gamble.
Compromising safety pulls us into a vicious cycle that’s fueled by constant urgency. We keep rolling the dice and making riskier and riskier bets, in an attempt to save time, but in the long-run our optimizations backfire.

The book is self-published and, as with many self-published books, it occasionally flared the OCD grammarian in me. A bigger problem for me is that it was not possible to read this on my kobo for two reasons. First, the images flow off to the right of the page, so they’re not fully visible. But even allowing for that, color is required for understanding the images — you’re going to have to read this on a color screen (or print it out, I suppose).
Organizationally, the book could use the hand of a professional editor as well. One example — the book could do a better job of laying out the mechanics of how idea flow mapping works and how to read an idea flow map a little earlier and more clearly. It’s not a complicated topic, but the book jumps quickly into showing idea flow maps without a sufficiently basic primer on what they are and how they work. By the end of the book, I think I understand how they work, but during the first few chapters I often felt lost.
Regardless of these small complaints, the book and it’s ideas are well worth exploring. You should go read it! If you’re not the reading type, you should at least watch Klein lay out her case here: Let’s make the pain visible

Confession: I am terrible at interviewing (and I suspect the rest of the world is, too)

n.b.While I would imagine a good bit of this applies outside of the realm of interviewing software engineers, what follows is specifically written about software interviews. If you’re looking about other types of interviews, read on, but, proceed with caution.

I’ve had positions open under me for pretty much all of my career as a technical manager. And so I’ve spent a lot of time interviewing, and given a recent focus on hiring a more diverse team, a lot of time thinking about interviewing. And what I’ve become more and more convinced over time is that no one (really, no one) is good at interviewing. Sure, lots of us point to the teams that we work with and say, “Look at all these amazing people! We must be doing something right.” And that’s probably true, but I’m reasonably sure that the thing we’re doing well is not interviewing. Even more terrifyingly, as I’ve looked at it closely, I’ve become convinced that it is not possible to do well.
Does that sound crazy? I don’t think it is — under the very best conditions as an interviewer, you can only ever have one side of the story. If you should be so lucky over a long career of hiring to hire no one that you view as a mistake on any level, that’s fantastic (if somewhat improbable), but also only tells you 1/2 of the story. Have you ever been talking with someone who was doing really well in the interview process, only to suddenly choke and bomb a segment of it — eliminating themselves from consideration? Do you think that was a fair representation of their skills? Have you ever interviewed someone and wondered at their evident career success v. their inability to perform the simplest tasks in an interview? Sure, some of those folks may have completely misleading resumes; but I’ll bet more than one of them simply choked under the pressure, and your assessment told you that they were no good.
And why is that? How good is your assessment? Let’s take a look at a few common tech interview gotos.

  • Whiteboard coding has taken a well deserved beating over the past few years, but that’s only a sample of the awful things we do.
  • Stupid questions. What do you expect to learn by asking someone how they would keep from being eaten if they were a cucumber in a salad? Or how they would escape from a blender if miniaturized? Do these questions tell you anything about a candidate? Is this an ice-breaker? Do you expect these questions to put a candidate at ease? Puh-lease! Best case scenario, they give an interviewer an opportunity to feel smug. That’s not going to help anyone.
  • FizzBuzz and other well-known interview problems. Congratulations, you’ve just learned that your candidate can memorize some stupid code from a programming interview questions web site. Do you know if they can actually code? This category of simple question may have some value as a screening question, but I’m unconvinced it tells you anything you need to know on an on-site. And if you find yourself questioning whether someone who struggled a bit with FizzBuzz is worth hiring, because the last 3 candidates aced it in seconds, shame on you. You’ve got one candidate who just thought on their feet and got where they needed to be against 3 who read one of the 892 books that currently come up when you search for “programming interview” on Amazon.
  • Have you ever been in a good panel interview (on either side of the hiring equation)? I’m pretty sure it would be possible to prove the exponential relationship between the number of people interviewing and the terribleness of the interview. Add 3 interviewers to an interview, and at least one of them will get distracted by their laptop or mobile. Four? Then you’ll have at least two with a conflicting agenda. Five? Someone’s going to start monologuing (and everyone else will check out). Your focus quickly becomes about group dynamics, rather than the candidate. Meanwhile, you’ve wasted a significant chunk of multiple peoples’ time and increased the stress on your candidate. Are you testing for endurance?
  • Pair programming? I’ve talked with a lot of strong advocates for this, but this technique can be a great way to eliminate anyone who hasn’t spent a lot of time pair programming. (Remember how uncomfortable it felt the first time you paired? And I’ll bet that wasn’t with the added pressure of being on an interview.) Also, as much as I just beat up panel interviews, having a second interviewer in the room brings a valuable second perspective to the table, and there’s just not much room for a 3rd in pair programming. If you’re not looking for someone bringing a specific language skill to the table, this can get even more complicated — you might have to switch interviewers depending on the candidate, and now you’re going to lose any reasonable chance of fair evaluation across a set of candidates.
  • Looking for someone that “clicks” with the team? That’s a great idea, but it’s also almost impossible to make this an important factor without guaranteeing a monoculture. Are you looking to increase diversity on your team? (hint: you should be) Are you competing to hire in an increasingly candidate-friendly market? (hint: you are) Then you need to monitor this carefully. It’s also too prone to eliminating candidates who are too nervous to let their real personality through in an interview. (Relevant: how often have you let your real personality through in a job interview? )
  • Post-interview analysis meetings. sigh Here’s an area where I’m especially ashamed of my own once-valued previous practice. My last team would wait until everyone was available, gather around an open section of floor, kick a soccer ball (oh, hai, rest of the world, that’s a football to you) back and forth, and discuss a recent candidate. Chances are, minus the soccer ball, you’ve done something similar. There are a few problems with this approach. First, by the time we all got together for that conversation, no one’s perspective was fresh. But the biggest problem with the let’s-all-get-together-and-make-a-decision approach is that the first member of the team to voice a strong opinion will generally carry the conversation. If you’re feeling slightly positive about a candidate, but the first person to speak says, “Oh, that candidate was terrible!” are you going to argue? What if everyone was reasonably positive except that first speaker? What if someone at the table has a very high opinion of the candidate but doesn’t like conflict? How will you know?

Given these practices, which have all been at least considered in the various iterations of my interviewing process, it’s not really surprising at all that I’m terrible at interviewing. And if you’re a hiring manager and somehow the logic of all of the above hasn’t convinced you (and honestly, even if it has), then you really, really need to go read’s article on the arbitrary nature of tech interviews. Seriously, go read it. At the very least, scroll down to the interactive chart titled “Standard Dev vs. Mean of Interviewee Performance” and click around till you understand it.

Seriously, go do that.

Okay, back? “Only 25% of candidates are consistent in their performance.” I’d also like to take a brief digression to point out the realization that got me in this mess to start with:

The dark side of optimizing for high false negative rates, though, rears its head in the form of our current engineering hiring crisis. Do single interview instances, in their current incarnation, give enough signal? Or amidst so much demand for talent, are we turning away qualified people because we’re all looking at a large, volatile graph through a tiny keyhole?

With those horrifying, all too believable figures as context, go back and think about past interviews. I’ve definitely had the experience in the past of rejecting a candidate based on a teams opinion, while remaining somewhat sure that the team had eliminated someone with a tremendous amount of potential. I’ve also pushed back against a team decision to reject a candidate only to make one of the best hires of my career.
After thinking through all of the above, I came to what seemed like an obvious conclusion: I am terrible at interviewing. And given that the practices I’ve followed are widely accepted interview standards, I’m pretty sure the rest of the world could use some work on this too. In fact the only convincing evidence I’ve found that there’s a useful way to hire for actual skill in any field is a blind listening technique for orchestra members. I think there’s some interesting potential in applying more techniques like blind resume (or code) reviews, and I’d be in favor of experimenting with fully blind hiring. But unfortunately, I don’t think most organizations are ready for that yet.
So where does that leave us? Are we all just in an impossible situation with no hope? After all, I started thinking about this with hopes of identifying the best hiring process in the world and then implementing it and collecting all the benefits and privileges pertaining thereto. Instead, I’ve spent months staring at various revisions of this post with my head in my hands, wondering “what now?”
Here’s my conclusion, at least for now: hiring well is simply not possible yet. At least not for me.
Hiring better? That sounds like something I can work on. I’ve definitely got some ideas for that. Working with the candidates I hire through an imperfect process to help them realize their potential? Now for that, I’m definitely in.

Book Report: Presence: Bringing Your Boldest Self to Your Biggest Challenges

Amy Cuddy - PresenceIf you’re a reader of this site, you’re likely to have watched Amy Cuddy’s TED talk on power poses. This book expands on that, and is filled with fascinating insights into recent social science. I read the book after seeing Cuddy talk at Philadelphia Free Library’s Leading Voices. (You can listen to the podcast here.)
I was interested in the talk and the book largely because I’ve recently been spending a lot of time thinking about interviewing and hiring through the lens of building a more diverse team. One of the things I was hoping to get out of the book were some ideas for helping those from underrepresented communities in technology be more “present” during interviews. I certainly benefited from the ideas Cuddy presented in her TED talk when applying for my current job, and I shared the ideas with my daughter right before she kicked ass on the SATs. When I think about applying this from the other side of the interview, I have this vision of saying, “Okay, now stand in this room like Wonder Woman for 2 minutes, and I’ll be right back so we can begin.” Fun as the image may be, of course it would be far to socially jarring to actually work in an interview situation.
Why is it important to me to figure out how to put someone interviewing to work on my team at ease? Cuddy explains that better than I could:

Research shows that in pressure-filled situations, when we are distracted by thinking about possible outcomes of our performance, our skills are measurably diminished. When we explicitly monitor ourselves, second by second, any task that requires memory and focused attention will suffer. We don’t have enough intellectual bandwidth to perform at our best and simultaneously critique our performance. Instead we’re caught in a faulty circuit of trying to anticipate, read, interpret, and reinterpret how other people are judging us, all of which prevents us from noticing and interpreting what’s actually happening in the situation. This dynamic, which psychologists refer to as self-monitoring, is significantly higher for people who experience impostor fears. It takes us out of ourselves. It stands in the way of our presence.

So given that we know that interviewing is one of the most pressure-filled situations, what can we do when interviewing to break that faulty circuit? Here’s one useful thought from the book:

Pamela Smith, a professor of management at the Rady School of Management at the University of California, San Diego, and [Adam] Galinsky have demonstrated in their research that power often operates at a nonconscious level, meaning that it can be activated without our knowledge — turned on like a switch — and can affect our thoughts, feelings, and behaviors in ways we’re not even aware of. That’s good news. It means we don’t need to wear a crown to feel powerful, and we don’t have to plot and strategize ways to deploy our power in order to reap its benefits.
Recall a moment when you felt personally powerful. A time when you felt fully in control of your own psychological state — when you had the confidence to act based on your boldest, most sincere self, with the sense that your actions would be effective. Maybe it was at work, at school, at home, or in some other part of your life. Take a few minutes right now to remember and reflect on that experience of your personal power, on how it felt.
It felt good, right? Whether you know it or not, you’ve just been primed. Thanks to that little exercise, your psychological state was, and likely still is, infused with feelings of confidence and strength.

How simple would it be to start an interview with a question like “Tell me the professional accomplishment that has made you the most proud?” If that should prime someone to feel more confident, and have a better conversation? Well, chances are, you’re going to have a much better conversation.
During Cuddy’s talk, I asked her whether there was any research on how an interviewer could improve a candidate’s confidence through body language (you can here her response at about 1:08 in the podcast). She offered three concrete suggestions. “Come out from behind the desk… Be aware that your presence is really intimidating… so make sure that you’re not using that big expansive body language… Listen for whether they’re telling you everything they want to tell you… Ask, ‘Is there something else you’d like me to know about you?'”
The book offers another, related interviewing tip on the importance of warmth and openness in our body language:

In a famous 1974 paper, Princeton psychologists presented a pair of experiments on the self-fulfilling power of body language. The researchers wanted to know if white college admissions officers were unconsciously adopting cold, disengaged, and discouraging body postures (e.g., orienting their bodies away from the applicants, crossing their arms, not nodding) when interviewing black applicants, and, if so, how these postures might affect the applicants’ interview performance. In the first experiment, white interviewers were randomly assigned to interview either black or white applicants. Indeed, when interviewing the black applicants, white interviewers used cold, disengaged body language, and the black applicants were perceived to have performed more poorly in the interviews than the white applicants. In the second experiment, trained white job interviewers were split into two groups and instructed to use either cold, disengaged body language or warm, engaged body language. They were then randomly assigned to interview either black or white applicants. The black applicants performed as well as the white applicants when their interviewers exhibited warm, engaged body language. And applicants of both races performed equally poorly when their interviewers behaved in a cold, uninterested way.
Furthermore, in both cases, the applicants’ body language matched that of the interviewers; they were unconsciously mimicking what the interviewers did, which is what we usually do in social settings. In short, our body language, which is often based on prejudices, shapes the body language of the people we’re interacting with. If we expect others to perform poorly, we adopt body language that is off-putting and discouraging. Naturally, people take the hint and respond as expected — poorly. How could anyone ace an interview under those circumstances?
When our body language is confident and open, other people respond in kind, unconsciously reinforcing not only their perception of us but also our perception of ourselves.

Again, simple — remember to lean in towards the speaker and pay close attention. Nod or vocalize encouragement when appropriate. Orient your body towards the speaker. If you’ve been put in the position of interviewing candidates, hopefully you understand how to do these things in a way that feels natural. Essentially, treat the conversation as if you’re going to find it deeply fascinating, and chances are, you will.
The book offers far more than some useful insights into interviewing; it’s filled with research that will spark your imagination: after reading about research into risk-taking after assuming power poses (spoiler: it goes up) I became worried about what casinos might be able to do with that research. After reading about how her research has been applied to horse training(!) I’ve been debating conducting some research on our pets.
Cuddy has filled the book with the personal stories of many people who have been inspired to reach out to her and explain how her TED talk has changed their lives. While these stories provide a good bit of the heart and soul of the book, at times this feels a bit overwhelming (especially in the final chapter, which is essentially a collection of these stories). Very strongly, the same warmth, humor, and personal experiences that compelled us all to share Cuddy’s TED talk come across on almost every page of this book. It’s well worth the read.
Update:FiveThirtyEight has published an interesting article on problems in reproducibility which talks about Cuddy’s research quite a bit.