There would seem to be a pretty narrow range of companies that this would actually work for.
If you're a pet food manufacturer that needs a website, you're probably not going to find anybody who's really stoked about catfood and also knows Rails.
If you're Valve, you'll have no problem finding 10,000 kids who really want to write video games, none of which can code their way out of a sack.
So it would seem to follow that if you're looking to hire developers, you should start off by looking for people who are actually good at writing code. Or put another way, by looking at credentials.
It'd be cool if it worked the way the author describes, but for most situations I just don't see it happening.
I think what it comes down to, is if you're Valve, you get to have your cake and eat it too. You get to hire the best, and they're all increbibly motivated to make the things you're making.
"I think it’s obvious, everybody here could get a job in ten minutes. People like [someone walks into the door, it’s Jay Stelly, holding two coffees], people like Jay! Who brings me coffee.
Jay is the most senior engineer at the company [laughs]. And he saw that I didn’t have coffee! There are probably at least five publishers he could call and get a $30 million project in an hour if he wanted to.
The reason he’s here isn’t because he has no other option, he’s here because he can work with the best people we have. It’s here at Valve where his talent can make the biggest impact and he doesn’t have to waste time rolling his eyes at stupid things the marketing and management teams are doing."
It’s here at Valve where his talent can make the biggest impact and he doesn’t have to waste time rolling his eyes at stupid things the marketing and management teams are doing.
So, one secret to success is marketing and management that doesn't cause developer eye-rolling? This amounts to marketing and management that can actually communicate with devs. (And devs who aren't so one-dimensional that marketing/management can talk to them.)
The most important part of marketing-dev collaboration is getting the two to have any respect at all for the other one's work and have a willingness to learn about it. After that point, communication seems to become a lot easier. As a side note, all major failures I've been familiar with have toxic marketing-dev relationships, so it's worth everyone's time to make this work.
I heartily disagree. Who says a company that makes a boring/uninteresting product isn't solving challenging, interesting development problems? I mean, I hope it's not the case that the only companies solving interesting problems are the ones with an awesome product that everyone wants to work at.
Very true. I just quit my job to start a fashion startup. I really don't care about fashion, apart from sleeping with the occasional model (hasn't happened yet, but I'm hoping).
On the other hand, building an AI system that is capable of learning about fashion is pretty interesting.
Bad example. You're not going to find someone stoked about catfood, but I think you could easily find someone who loves their cat and cares about nutrition. People who love animals aren't hard to find.
> If you're a pet food manufacturer that needs a website,
...then you better hire somebody who will analyze your business requirements, tell you what's better for you (how to place your company on the web, how to integrate site maintenance into your business workflow), then maybe help you hire Rails developer, and perhaps conduct project management.
Otherwise, agree with you. If you want a site for your company, hire somebody who is interested in helping businesses build their online presence, not just a catfood freak.
I think your assumption in the beginning is correct! People have no idea about hiring and just do what comes to their mind first: application, interview, get started.
That is not a good way to hire.
But then you start to make the same mistake these badly hiring people do: You think you need to do all the science by yourself. But actually there is a solution to most hiring problems as there is a solution to most programming problems. And there is a science who spents a lot of time and money of a lot of people to improve the methods available and to find models more applicable. You can even study that stuff in university and get a degree for that.
So please, take that stuff seriously and do what everybody in a hiring situation should do: Learn what humankind already has available on the topic or pay someone who already did the learning!
PS: Yes, when you start to find out enough about this topic, you will see it is quite boring. You solve problems like everywhere else, too. First you try to apply a model to the best of your knowledge and then you just use the methods connected to the model. Both, the models and the methods, can be found in a lot of text books and also online.
That's great when you're hiring CEOs or product people, but I think if you're hiring a manager it's ok if his interest is more in managing than the end product.
Otherwise what happened to Google will happen to you.
eg, losing people like Sheryl Sandberg because you can't accommodate the needs of competent careerists for self advancement.
Edit: Just want to clarify that I'm not disagreeing with the original post. When you're small everyone's a product person, but you can take that idea too far.
The only problem I can see with focusing on interest is that I'm acutely aware of how good some people are at faking interest. I'm probably aware of this as I'm actually pretty awful at faking interest in things I find boring... (notably pro sports).
The problem is more a scientific approach to creating a feedback loop to the employee life cycle.
Initially you'd want to hire randomly to seed your 'gene' pool and then fire those who are unfit. This will provide feedback as to which measures best predict the outcomes the business wants to optimize for. And would take into account the fact that different businesses require different hiring practices and need to optimize for different outcomes.
This is just another idea for hiring that provides no information as to whether it's a better approach and completely ignores the rest of the employee life cycle.
The article talks about confirmation bias but provides no indication as to how hiring by interest changes anything about confirmation bias in the hiring process.
Seriously the product 'you all want to make' is a piece of shit that is essentially design by committee. There will be vocal people who DON'T want to make that product because by the nature of the process it has become bland and unimaginative.
My personal and completely unscientific approach to hiring is towards interesting people rather than people interested in the particular problem we're currently solving. I have no idea whether this is better / worse that credentials or hiring based on interest.
That's not the problem, that's an alternative and possibly complementary solution. The problem, as we both broadly define it, is hiring people that will help the business achieve its goals. Yes, I did not apply this method over the entire employee life cycle in this one post.
The method of frequent firing as feedback is far from optimal and not even feasible in smaller organizations. That is the context in which I'm operating and thinking about this problem.
With respect to the particular element of confirmation bias referenced in the first sentence, and repeating the second, hiring based on interest is a method that will seek to truthfully answer the question, "is this person going to solve the problem we want to solve?" rather than effectively allowing an employer to avoid a costly mistake.
Your comments about product development are not addressing anything in the post and could be delivered to a wall with similar effect.
Hiring based on interest will answer the question, "does this person want to solve the problem we want to solve". A good recruit is both willing and able. So, hire based on interest, but don't disregard credentials either. Focusing too much on interest risks getting showmen and excitable stupid people.
Showmen (a/k/a Charlatans) are to be avoided. And excitable talented people are gold!
But an excitable person can learn. Or be directed into another role. How does one motivate a disinterested but competent person? I fear that motivation is a harder problem to solve than lack of talent.
by giving them freedom. in my experience, what makes a job suck isn't that the problem lacks "excitement", but that you aren't given the freedom to do a good job. you can take pride in work for even simple tasks, if you own them. on the other hand, you can be in the most exciting field in the world, but have a crappy boss and a shit life.
and almost any technical job can become complex enough to be intellectually interesting, if you have the freedom to use tools to automate the boring bits. what kills is being forced to do tedious rote work because you are restricted in your process. working on a production line is boring; building a production line is fascinating. the line between the two is clear in factory, but not in software development.
"exciting" is for non-technical marketing people with an attention span of 2 seconds before they see the next shiny object. absorbing, empowering work hasn't got much to do with excitement. it's about expressing and developing something of your own. it doesn't have to be different, or exciting, or ground-breaking. it just has to be yours, to develop in the way you see fit, to meet the requirements you are given.
i didn't know this when i started; i imagine selling "exciting" work will get you people with little experience. but i'm wiser now.
If you're a pet food manufacturer that needs a website, you're probably not going to find anybody who's really stoked about catfood and also knows Rails.
If you're Valve, you'll have no problem finding 10,000 kids who really want to write video games, none of which can code their way out of a sack.
So it would seem to follow that if you're looking to hire developers, you should start off by looking for people who are actually good at writing code. Or put another way, by looking at credentials.
It'd be cool if it worked the way the author describes, but for most situations I just don't see it happening.