Interviewing – Challenge Your Assumptions

We’ve all been there. This guy comes in to interview, and three minutes into it you get this feeling. He’s all words and no action. He’s an arrogant bastard. He’s an architecture astronaut.

The interview goes on and on, and with every new topic, you find more and more reasons around why your initial sense is true. Hey, he didn’t give any credit to his peers. He invented it all himself, ha. What an ass!

This is all nice and great, except that you’re really sucking as an interviewer at this point. You had a gut feeling – you made a decision in the first few moments since you met the person – and you’re essentially looking for proof for your already made-up mind.

Since hiring superstars is your #1 priority, this mistake, in my book, is in the category of “lethal” if you’re a founder of a company and you’re bringing in employees #3, 4, and 5.

I’ll go further and stipulate that we’re hard-wired to be making such mistakes. There’s a curious amount of research on first impressions – the amount of judgment people pass on from the first 5 seconds of their interaction. In one leadership training class I took, they brought together a diverse group of people – completely different ages, industries, seniority levels. They had us pair up with a random person in the class, without exchanging a single word with the partner. Then, each of us gave some thoughts about the role, seniority, and industry of the other.

It’s shocking how precise – and how correct! – most of the observations were. The other person didn’t even open their mouth!..

The reason we’re hard-wired to make such a fast, snap call, I believe, is because of the basic fight-or-flight response. You need to judge whether the oncoming object is a danger to us; if we’re bad at it, we’ll get eaten. Thus, natural selection helps advance those that are good at it.

The problem, of course, is that at the workplace, the interactions are much more complex. You WANT to hire people that are radically different from you. You want to hire nay-sayers. You want people with radically different backgrounds, those that approach problems from the other angle. You want the whole of your company to be more than the sum of the individuals. If you fail to challenge your snap judgement, you’ll have a bunch of copies of yourself – creating an environment that magnifies your weaknesses, instead of compensating for them. Like the kings of the medieval times, you’re risking to suffer organizational hemophilia – the disease of “too much blue blood.”

Instead, I invite you to state the assumption that’s popping up in your head, and ask: what could this person say to convince me that they’re NOT what I think they are? If I think they’re not technical enough, can I ask them to code something? If I think they’re too full of themselves, can I ask them about a time when they were wrong? Literally, drop the current conversation topic, and abruptly switch to this new question.

Note that your first impressions, in some cases, will turn out to be exactly true. For example, one gentleman I recently met, I was getting a sense that he’s quite stubborn. I asked him to recall a time when he was convinced by someone else. A time when they thought one way was good and true, but someone jumped in and convinced them of a different approach.

The gentleman thought for a while, and came up with quite a telling example – as a business leader, he saw the technology group gravitate towards a process that he thought was dumb. He didn’t force his opinion down their throats; he let them have it their way. Note a subtle difference: he was NOT convinced himself; he merely allowed his people to make what he considers a mistake. This was quite eye-opening – by focusing on the assumption I made and precisely targeting it, I gave him an honest chance to convince me that my assumption of his stubbornness was wrong; instead, he reinforced it.

I encourage you to do the same the next time you’re interviewing someone for your team. What could this person say to convince me that they’re NOT what I think they are?

Advertisements

What are Product Managers for, anyway?

I’ve written about the core pillars that drive technologists. In this article, I’d like to drill in on the discipline that’s perhaps least understood – product managers, or PM’s.

Technologists have one fundamental weakness. Like all engineers, they like creating worlds from scratch. They liked disassembling toys when they were kids, and putting them back together slightly differently. They love the control, the thrill that comes from playing God in the virtual world where everything is possible. This causes a tendency to tinker – just because tinkering is fun. This is particularly true in well-funded startups and labs organizations in larger companies.

When your craft is fun, it’s great. You enjoy every moment of messing with the code, laying out those architecture diagrams on a whiteboard with your buddies… The rub, of course, is that at some point, you need to make a profit. You know – step 1: inspire everyone with an idea, step 2: execute on it, step 3: profit. If you keep tinkering forever, your VC will shoot you in the head, the department in your large company will get dismantled, and the bonanza will end.

Basically, you need adult supervision. You need someone who loves and understands technology, but doesn’t get the ultimate pleasure from creating the most robust and beautiful architecture in the world. You need someone who’ll kick you in the butt because your customers have a REAL PROBLEM and the elegant technical solution you’ve been pondering for a few days doesn’t really matter for the client. The client wouldn’t care less if you shipped a SPAGHETTI CODE UNMAINTAINABLE PIECE OF CRAP if it solved their problem.

You need a customer advocate. Someone who has EMPATHY as the core pillar that drives them. Someone who feels the pain of the client and wants to do whatever it takes to have that pain go away. Yet, they are technically savvy to be able to maintain an intelligent conversation with an engineer – they’re not an MBA with zero technical background and Excel financial models in hand. Joel Adams – he was the first to fund Michael Dell of Dell Computers – once said, “When I’m valuing a company, I usually subtract $100,000 for every MBA on the team and add $100,000 for every engineer.”

That customer advocate is your product manager (PM). If you’re a startup, you need ONE product manager. They’re going to be the CEO of your product. Yes, you heard me right – if you’re a CEO of a technology company, you have much more to worry about than just your product. Hiring superstars is your #1 concern; #2 is being the Chief Earnings Officer. You need somebody in the weeds, somebody that’s not distracted by the fundraising and making payroll and getting Jenn the signing bonus despite the fact that the board is against it.

I like to think of a product development as a triangle with these vertices: test, dev, and PM. Here’s what happens if either of the vertices is weak:

  • Test: product is buggy as hell and clients see crashes and data loss.
  • Dev: product cannot be improved over time and an incremental v2 costs an order of magnitude more than it should.
  • PM: the product is technically robust and doesn’t fail, but nobody wants it. It solves no real-world problem.

The mission of the product manager is to instill the customer pain into every single engineer on the team. Let me give you a contrast:

  • Product 1: the PM understands the client well, and defines the product through technical specifications in EXCRUCIATING detail. Field names in the database tables, error messages to the comma.
  • Product 2: the PM understands the client well, but instead of going deep into the details, they explain the reasoning behind the product to everyone involved. They help engineers understand who the client is, what they do every day. How the product will help the customers. They drag the engineers to user research studies, forcing them to watch how customers struggle to find the damn OK button.

Beside sheer capacity issues, the PM on the product 2 will be more successful simply because it’s not humanly possible to oversee every decision. Engineers will be making calls all the time, and some of them will be wrong if they don’t understand the WHY. This is exactly the reason for getting them to feel the pain of the customer – instead of spoon-feeding them the details like they’re dumb.

A couple more notes on what PM’s mission is not –

  • The PM should not be a people manager. Google, Facebook, Redfin, Zillow, and many other companies subscribe to this vision that was initially created at Microsoft 20 years ago. An amazing book on PM called How would you move Mt Fuji describes the formation of this vision beautifully; the crux is that if the ideas about what the product should do come from my boss, I’m highly unlikely to say that they suck. If the PM is my peer, I’ll freely tell them what sucks and outright refuse to code up their dumb solution. The key to PM success is the ability to influence design decisions without authority to force them down the throats of the engineers.
  • The PM should not be a project manager. A project manager is someone who’s responsible for the SCHEDULE. Someone who’s responsible for the resourcing. PM’s have no managerial power over the engineers – so they can’t tell an engineer to hustle or really promise a delivery date. Those responsibilities should land on Dev Lead’s shoulders.

If I got you interested in the subject of the role of PM, you might want to check out this article from my brilliant friend Angela.

Avoid The Sea of Mediocrity

I recently wrote about motivational issues associated with large teams. In this post, I’d like to explore organizational aspects of this issue.

Larry Ellison, the CEO of Oracle, is known for a curious approach to solving problems in the product teams. If he sees a team that’s struggling,  he pulls a person from this team – reassign them – until they “stopped useless meetings and started shipping.”

Steve Jobs of Apple, said that “a small team of A players can run circles around a large team of B players.”

The famous book Mythical Man-Month that shaped generations of engineering managers explores one side of this issue – inefficiencies related to communication, where every new engineer needs to talk with all the other engineers in order to be successful. Communication costs grow exponentially with the addition of every new team member.

Joel Spolsky, another brilliant mind, speaks of “best engineers being ten times as effective as average engineers” in his famous essay. He backs it up with very curious research.

Guy Kawasaki says that “A players hire A players; B players hire C players.”

All of them are really saying the same thing: if you think you need a large team to solve the problem, think again. If you think you can hire a lot of OK developers to solve a large problem – by splitting the problem into small chunks – you’re going towards failure. If you think that compensating your engineers at the 66th percentile is going to bring you the best talent, try again.

There’s a simpler way. Instead of hiring team of 20 mediocre developers – and paying them 20 “industry average” units – hire 2 SUPERSTARS and pay them 2 units each, way at the 99th percentile of comp. Take the issue of salary completely off the table. Create the best possible working environments for them, with free on-site massage, best tools money can buy, and most importantly, colleagues they can be proud of.  There’s one important point to this rhetoric: the superstar you hire has to be AMAZING. Not just good, but head and shoulders better than you as an engineer. They have to be a true “free electron.”

One single moron in the office, and every superstar that ever interacts with them will ask “what does it say of me that I’m working in this office? This guy is a developer just like me; he’s probably bringing in the same cash home. Am I stupid? Are the managers here not understanding who’s good and who’s not? This guy wastes so much of my time..”

What, you’re telling me that you can’t afford to pay your developers twice the industry average? But you CAN afford to pay ten developers that are doing the same amount of  work?.. I’m literally talking about saving FIVE TIMES the cash. And gaining the efficiency – because that one guy will not have the useless meetings every day just to align the schedules.

I’ll say even more – if you bring in someone average, you’re making a NEGATIVE impact on your company’s bottom line. Over the long term, you’re assuring its place in the sea of mediocrity. A brilliant friend of mine – a true free electron – once shared a story about working at a large company. He and a friend were superstars on a SWAT team, kicking serious butt and attracting positive attention of the executive team. They wanted to bring in a third person to their tiny group to help scale their efforts. Both of them were amazing engineers; those that are 10 times as productive as the rest. They wanted someone at their level of output. Their request was blocked by HR, who suggested that “you should get an underachiever to transfer to your team; by working with you, they’ll get better!”

What do you think they did? Did they agree to bring in an underachiever? Did they stay motivated? Were they convinced of the HUNGRY PASSION of the company to succeed?..

I once personally was a part of an organization where someone truly incompetent was brought in. After a few weeks in the office, it was obviously clear to everyone that the hire was a mistake. There was just one little problem, though: it took a painstakingly long time to fire them. 18 months. This was the time it took to build a case and convince HR that there is enough documented failure and no possible lawsuit coming, so they could fire them.

What do you think was the impact on the morale and output of the team?..

Avoid the sea of mediocrity. Avoid hiring average people like the plague. Hire PASSIONATE, HUNGRY people that are SUPERSTARS in their field. Compensate them in a way that makes them forget about other jobs – and never interview externally because of pay.

The Core Pillar That Drives Technologists

This article is about putting labels on people. If you’re a technologist – a nerd at heart – I’m going to put you into one of three categories. I’ll call them D, T, and P. I’ll explain what they are in the end.

D’s like beautiful code. They love complex algorithms, elegant systems, clever hacks. They thrive on discussing design patterns, threading, synchronization. They care about HOW something is built. They don’t care what the thing is – a microcontroller in the pacemaker that saves lives or a mission control system in a nuclear weapon.

P’s don’t give a crap about how something is built. They care about the customer’s pain. They almost *feel* this pain themselves, and this empathy drives every action they take. They want that pain to go away. They want the double entry to disappear. Seeing the “OH MY GOD THIS IS AMAZING!” expression in customer’s eyes is the ultimate goal for them. P’s don’t care if the way this was achieved was through copy-pasting the same stupid code snippet thirty times, creating an unmaintainable, ugly piece of code.

T’s like breaking things. From their early age, they found satisfaction – true, internal pleasure – in pushing the boundaries of our everyday objects. Any creative person might give you dozens of ways to use a paper clip in a few minutes. T’s will tell you how to break a paper clip –  and it will be quite a natural mental exploration for them. T’s just feel so snug inside when they can look at a piece of someone else’s work, and find a way to make it do unexpected things. T’s have a drive to prove their mental superiority over the creator of the product.

Fine, fine, this wasn’t a difficult puzzle. D’s are developers. P’s are PM’s, product managers (Microsoft calls them “Program Managers”). T’s are testers.

Here’s why understanding these core pillars might be useful: when you know what should drive a successful person in this role, you can interview for it.

Test. Don’t ask them whether they’ve written automation before. Ask them to list 50 ways to break an elevator.

Dev. Don’t ask a Dev whether what the difference between ShowDialog() and DialogBox() is. That trivia can be looked up in 30 seconds or less. Ask them a basic algorithmic question; ask them to code it in any language of their choice.

PM. Interview for empathy, and the ability to convert that empathy into designs. Ask them to design an ATM for a 5-year-old kid. Ask them to design a remote-control system for window blinds.

P.S. If you didn’t guess from the rest of this blog yet, I’m very much a PM. Most of the code I write is quite crappy – it’s a means to an end.

Hungry Artist Paints Way Better

When you are running a startup, it’s easy to imagine how great life is for the head honcho of the Microsoft Bing group. They have all the resources in the world available to them. The company is pouring money at them – BILLIONS every year! There are thousands of people working on the product! With that might, anything should be possible, right?..

You compare your tiny 20-person startup to Bing, and you feel inadequate. You’re worried about making payroll. Investors are holding you by the balls. You sort-of have market traction, and there are a lot of ideas, but you don’t have the resources to try most of them. Any mistake can be your last. You compare yourself to the giant Bing, that keeps pouring HUGE sums of money into every imaginable experiment, and are feeling like your constraints make you ineffective.

And here’s where I’ll jump in: Au Contraire. The constraints are making you MORE effective.

YOU are in a much better position. You’re a hungry artist, and you know that you have your butt on the line. Calculate your financial projections wrong, and you’ll run out of cash and won’t make payroll. The friends that you brought into your business – your *personal* friends – will not be able to pay their mortgage. Your *personal* reputation is on the line.

Since you’re desperate – hungry, constrained, call it whatever you want – you’ll become a maniac of perfectionism. You’ll POUR YOUR SOUL into every decision you make. The people on your team will do the same – if this company succeeds, each of you will be rich. If it doesn’t – and you’re on the clock here, seed money is running out – you all won’t be able to provide for your families. And will have a sad story to tell when interviewing for your next gig.

Let’s look at an example of what the lack of hunger can lead to.

First, it’s lack of commitment – when less is on the line, people tend to be less committed. Passionate people tend to do well and get better at their craft – and the lack of the passion often zeroes out all the other great qualities.

Second, it’s randomization. I’ll give you an example of what over-investing in product management will do. The core value of PM is to be the advocate for the user; they are the gatekeepers of end-to-end experiences. If you have too many PM’s for a product, then instead of owning large chunks and scenarios, you have each junior PM own a couple checkboxes. With this level of ownership, you get (a) zero motivation and (b) people start inventing work for themselves. And PM’s inventing work often leads to “running around with your heads cut off” for the entire organization – highly tactical efforts that don’t add up to a significant improvement in the end.

Third, it’s the famous Mythical Man Month effect. The larger an organization gets, the higher the communication costs. At some point, adding resources to a project makes it go SLOWER, not faster.

So the key phrase for me is “Strategic Under-Investment.” If you’re in a large organization with lots of resources, give people a little less resources than what they need. Force them to make tough choices.

So, rejoice and embrace your constraints. They are making you work harder, thus increasing the chance of your success. They are forcing you to make careful choices, all while facing accountability in the face of your personal friends. Just like with a hungry artist, your painting will be better.