Category: Management

Posted on

Passive dismissals and the “impossible”

This is an internal memo I wrote in the earlier days of Reliable Robotics. I’m sharing it here publicly in case others find it useful.

Werner von Braun has this quote, “I have learned to use the word ‘impossible’ with the greatest of caution.” I’ve gone searching for the context in which he made this comment but haven’t uncovered yet where he said this or what it was in reference to. But having been part of several projects now that many (including myself) thought were impossible I get where he is coming from. When you prove others wrong once or twice in your career you start to become immune to passive dismissals of impossibility.

Possibility vs. impossibility is not just a glass-half-full vs. glass-half-empty, optimistic vs. pessimist issue. The differentiator here is energy, not mental outlook. It takes less energy to passively dismiss something as impossible than it does to dig in and understand how something might be possible. Understanding the possibility of something requires focus, thought and action.

When we started Reliable Robotics, we heard our fair share of passive dismissals:

  • It’s going to be impossible to get an aircraft flying itself with a small team…
  • It’s going to be impossible to get permission from the regulator…
  • It’s going to be impossible to get permission from an insurance underwriter…
  • It’s going to be impossible to get a customer…
  • It’s going to be impossible to get an investor…
  • etc., etc…

These claims often came from a place of intuition, with no rationale or thought placed in them. These are all easy claims to make, and proving them wrong takes time and energy. To be fair, we are yet to prove all of the passive dismissers wrong. But we have, in relatively short order, proven many of these claims to be terribly short-sighted.

Looking back, I credit our perseverance through this morass of negativity to all of the wonderfully successful “impossible” projects we’ve worked on in the past. With success, you build up a certain resistance to passive dismissals. You never become entirely immune, but you do learn to separate the credible objections from the non-credible, and how to objectively address the doubts and concerns without falling prey to the emotional response.

Success only gets you so far however (as those with imposter syndrome can attest)! And when you are starting at the beginning, or following a failure, you still need to be able to bootstrap your own partial immunity to passive dismissals. For me personally, I’ve discovered that I’m actually energized by naysayers. A former colleague once observed, “the best way to get a great engineer enthusiastic about a challenge is to bet them they can’t do it,” and this is definitely true for my personality. The “we’ll prove them wrong” outlook, if properly harnessed, can provide a solid foundation on which to make something possible.

Eventually, you learn to take pity on the doubters, the non-believers, the dismissers. They just haven’t had the good fortune of being part of an impossible project yet, or they are just too busy to dig in and challenge their own assumptions. Either way, in a world where we are literally not constrained to this world anymore–a world Werner von Braun helped create–it does surprise me that anyone would throw the word ‘impossible’ around so lightly.

Posted on

Cherish the rigorous job interviews

Three times in my career I’ve rejected job offers because I didn’t feel the interview process was rigorous enough.

Straight out of school, the company did not ask me any challenging interview questions. I walked away thinking: “They’re not going to challenge me. I’m not going to grow working here.”

Another company did not ask me any questions about what I wanted or why I was interviewing with them in the first place. I walked away thinking: “This place has no soul. They’re not going to care about building my career.”

Later in my career, every interview focused on my resume and not much else. I walked away thinking: “Everyone here must just get hired based on their resume.”

This meme (above) has been making the rounds lately on reddit, and while I appreciate the sentiment behind it, I personally could not imagine accepting a job offer somewhere after a single interview, especially if I didn’t know anyone at the company. The market for talent is growing more competitive every day, but as a candidate you should consider if the company is looking to just put a warm butt in their seat, or actually help build your career.

To employers, a rigorous interview process should convey to a candidate a commitment to excellence in both who you let into the organization and how people will be treated once they join.

To candidates, understand that rigor means the employer cares about mutual alignment and shared success, and not just jumping through arbitrary hoops as the meme suggests.

Originally posted on LinkedIn Pulse.

Posted on

Be Excellent To Each Other

In California, employers with 5 or more employees are required by law to provide at least one a hour of sexual harassment and abusive conduct prevention training for employees every two years.

We recently went through another round of this training at the office. A recurring theme from our team during and after the session was, “if you just be a good person you’re going to avoid many of these problems.” I was also impressed by feedback from our team that there are a lot of other types of unwanted behaviors you might encounter in the workplace well before you cross the “legal threshold,” and that we should try and articulate these to make clear to newcomers what is or is not tolerated at our company.

We thought it would be best to capture the spirit of this through a slogan or simple expression. Some companies talk about a “no jerks policy,” but we didn’t feel this was specific enough. We also weren’t sure about expressing it as a negative. We thought a more positive slogan like a “Golden Rule Policy” would work better but this is tricky given the strong history of this expression in religion. (And the fact that some people treat others genuinely the way they expect to be treated but are still acting like jerks)!

While searching for a better way to capture the type of behavior we wanted to encourage at the company we settled on “be excellent to each other,” as popularized by the cultural cornerstone movie and pinnacle of American cinema, Bill and Ted’s Excellent Adventure. It may sound light-hearted, but beneath the surface there is a deep wisdom about life to be learned from these time traveling heroes.

After some iteration, we came up with a simple scenario-based training module to help capture this for the team. Others may find this useful, so I’m making available to the public here: Link

Posted on

Mailing lists considered harmful

I often catch myself telling people how much I hate mailing lists. It’s usually around the point in the conversation when I realize they’re giving me the “you’re a crazy person” look.

Before you give me the same look, hear me out! How often have you said or heard:
  • Who’s on this list?
  • What is this list for?
  • Who should be on this list?
  • Should I be on this list?
  • Can you add me to this list?
  • What should we name this list?
  • Who do I talk to create this list?
  • How do I add someone to this list?
  • Can I get permission to add someone to this list?
  • Who has permission to add someone to this list?

Or the worst: “Sorry you missed that super important email–I assumed you were on that mailing list!”

The social dynamic mailing lists create bothers me the most. The inclusion felt by those on the list, the exclusion felt by those not on the list… Creating mailing lists are quick way to silo an organization.
But it’s not all bad. Mailing lists are nice when you have a very large number of people that you want to broadcast a message too. They’re great for one-way communication like announcements.
Is there a middle ground? I believe if organizations followed some simple guidelines they could derive benefits from mailing lists and avoid most of the negative side effects. If I was so bold as to propose some guidelines for adopting mailing lists, they would be something like the following:
  1. Don’t create mailing lists for small groups. I think a good rule of thumb is about 10 people starts to warrant a mailing list. Anything less than that and you can remember their names. If you can’t remember their names then don’t bother them with an email!
  2. Let anyone join your mailing lists. Don’t do “ask to join” or keep the mailing list a secret. If you’re tempted to share secret stuff on a mailing list you probably should be mailing people directly anyways.
  3. Let anyone read your mailing lists. Maintain a public, searchable archive for all of your mailing lists. If your IT administrator complains tell them it’s the 90’s–web indexes for mailing lists have been in existence since the beginning of the web.
Posted on

Silent Privilege and Bias

Philip Guo has an excellent article on slate.com today about his experience as an Asian American software engineer.

    Even though I didn’t grow up in a tech-savvy household and couldn’t code my way out of a paper bag, I had one big thing going for me: I looked like I was good at programming.

I admit I’ve had predisposed biases about people before getting to know them. It’s human nature, it’s the way our brains work. The world is a complicated place and our brains need a way to quickly categorize what we experience or else we would be overwhelmed.

As a hiring manager, it’s a part of my brain that I try to shut off when I’m assessing someone’s technical skills–but it’s tough. I’ve even played games in the past where I covered up the person’s name before I reviewed the resume to see if that altered my impression of them. But over the years I’ve encountered enough individuals that violate any kind of stereotypes I had that it’s unwound most of them.

People always talk about race bias and gender bias, but something that surprised me when I first encountered it (in myself and others) was experience or education bias.

Tess Rinearson in this article talks about the “technically entitled,” the programmers that boast about how they’ve been programming since they were 6. You would think that someone who has been coding for that many years would be amazing, right? In my experience that’s not always the case. I’ve had candidates tell me on the phone they’ve been doing C++ since they were in middle school but when you dig into it they can’t answer simple questions about the language. Me personally, I started coding at a very young age but I know quite a few people that didn’t start until they were in college and they are way better software engineers than I am. If you assume there’s a correlation between experience and ability you could run into trouble.

What’s especially surprised me talking with and interviewing folks from different colleges and universities around the country is its dangerous to assume there is a correlation between education (school and/or GPA) and programming capability. You would think Stanford has an amazing computer science program, being in the heart of silicon valley. Anyone with a Stanford CS degree must be amazing, right? Well… I’ve interviewed Stanford grads that could not explain some of the most basic concepts about how an operating system works. But I’ve also interviewed Stanford grads that during the interview taught me new things about how operating systems work. So you can’t infer anything about ability from education either.

Race, gender, experience, education.. what inferences can you make about people then? None, really.

Posted on

Theresia Gouw on organization structure

In “Taking Our Company to the Next Level,” a lecture in the Entrepreneurship Through the Lens of Venture Capital series, Theresia Gouw is talking about organization structure in software engineering companies. Her thesis is: have an org structure, but keep decision making flat. There’s a rule of 5 with direct reports, and a rule of 5 with teams.
I cracked up when, in the middle of this, she offers this caveat:
“…well, this is in software engineering. Obviously if you’re building the next spacecraft and you’ve got significant complex systems it would be different.”
Overall, her points do align with my personal experience:
“You get the most out of people when there are around 5 or 6 people on a team, in terms of productivity. And happiness, when you do the surveys. For what its worth.”
Posted on

How to enchant your boss and your employees

Guy Kawasaki sums up how to be successful in the workplace in 4 minutes:

How to enchant your boss:

  • When your boss asks you to do something, drop everything and do it.
  • When your boss asks you to do something, turn around a prototype as quickly as possible.  This serves two purposes: a) It shows you dropped everything and b) it helps you check to make sure you’re on track.
  • Deliver bad news early.  And if you must deliver bad news, offer suggestions on how to fix the problem.*

How to enchant your employees:

  • Offer your employees an opportunity master new skills, work autonomously, and give them a higher a sense of purpose.
  • Empower employees to take action.
  • Suck it up.  Don’t ask anyone to do something you wouldn’t do yourself.

* In my experience, when bad news is discovered, it’s best to start an
internal countdown clock and deliver the bad news before the countdown
expires.  Depending upon the severity of the news the countdown may be
“by the end of the hour” or “by the end of the week”.  Within this time
you need to determine a) scope and b) possible solutions.  It may be the
scope is nothing and thus there is no bad news, or the solution is
quickly manageable and thus no bad news.  Or the scope could be much larger than you previously thought, or the solutions much more difficult. Either way, never deliver bad news without
doing your homework first.

And conversely, make sure if you’re
delivering good news it’s marked as good news!  This goes back to something very low-level in our brains.  In every interaction people want to categorize it as good or bad.  They want to know if what you’re saying to them is going to help them or hurt them.  So in email or in person, if you’re conveying good news or bad news, just say what it is right up front.  Especially if it’s email.. don’t wait for the last line of the email–categorize your message right on the first line of the email.  (I make this mistake all the time, it’s a tough one).

Posted on

On the Importance of Hiring

These two articles have helped shape my thinking with respect to hiring and interviewing. They are written by software engineers for software engineers, but they should apply to any discipline.

Yishan Wong: Hiring is number one (2009):

    Make hiring your number one priority, always… it is only once a culture of giving hiring top priority in peoples’ attentions will individuals and managers naturally begin directing their energy into doing things like deciding what constitutes effective interviewing techniques, what kinds of questions are best to ask, how to effectively diffrentiate between good and bad signals in an interview, etc, and subsequently how to train the entire cadre of interviewers to be able to effectively and repeatably practice this.

    …Hiring is a zero-sum game. Candidates that don’t join your company will join a competitor’s, and your loss will be their gain. If hiring isn’t your number one priority, it’s unlikely you’ll be number one at hiring, which means someone else will, and the true best candidates will go to them, while you’ll be left to hire the “best candidate you were able to interview.”

Joel Spolsky: The Guerrilla Guide to Interviewing (2000):

    The most important rule about interviewing: Make A Decision. At the conclusion of the interview, you have to be ready to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire.

    …An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. If you have any doubts whatsoever, No Hire.

Update: Valve’s internal employee handbook was recently released publicly: http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf It has some great comments on the importantance of hiring:

    …here are some questions we always ask ourselves when
    evaluating candidates: Would I want this person to be my boss? Would I learn a significant amount from him or her? What if this person went to work for our competition?

    …We’re looking for people stronger than ourselves.
    When unchecked, people have a tendency to hire others
    who are lower-powered than themselves.
    We should hire people more capable than
    ourselves, not less.

    …In some ways, hiring lower-powered people is a natural
    response to having so much work to get done. In these
    conditions, hiring someone who is at least capable seems
    (in the short term) to be smarter than not hiring anyone at
    all. But that’s actually a huge mistake.

    …[We value] people who are both generalists (highly skilled at
    a broad set of valuable things) and also
    experts (among the best in their field within a narrow disci-
    pline). This recipe is important for success at Valve. We often
    have to pass on people who are very strong generalists with-
    out expertise, or vice versa. An expert who is too narrow has
    difficulty collaborating. A generalist who doesn’t go deep
    enough in a single area ends up on the margins, not really
    contributing as an individual.