So many people have these really bizarre and outdated (by not just years but centuries) notions about how knowledge work gets done. They want to squish it into the model of factory work, but it just doesn't work that way. Knowledge work is typically creative, the right model is an art studio, a movie set, or a band. This makes hiring very difficult, which is exacerbated by the fact that engineers are innately bad at hiring other engineers without a lot of training or carefully focused self-improvement.
Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. But if you change the parts, you get a different team that does different stuff, or maybe doesn't even work at all. One of the big factors here is that if you think you can replace one person with just another person you're often wrong. Best case scenario you end up with something else (maybe better), worst case scenario is you can't replace the unique factors that made the previous person successful in that role (and realistically you need a team with a different breakdown of skills, different mechanisms of interconnectedness, etc. in order to have something functional).
The band analogy really helps here a lot. Realistically when you change members of a team you don't end up with something like Steve Perry stepping into the lead singer role of Journey. What you end up with is something more like Fleetwood Mac being transformed by merging with Buckingham Nicks or Genesis changing after Peter Gabriel left. You end up with a very different thing doing very different stuff. And the higher caliber the people the bigger the difference is.
What knowledge workers actually do day to day and what it says on their job description they do are often very different things, and you ignore that at your peril. Hiring based on the idea that knowledge workers are automatons with certain functionality modules installed is one of the easiest and most common ways to completely sabotage productivity and execution.
Knowledge work is typically creative, the right model is an art studio, a
movie set, or a band.
Knowledge workers aren't cogs, they're part of a team.
And if you look at how bands, movie studios, art studios or professional teams hire, it bears little to no resemblance to the hiring process described in the OP's article. All of the professions you describe hire through some kind of auditioning process. No sports manager would hire a star player on the basis of, "Do I think this person is a cool person?" No movie director would hire an actor on that basis. No art studio would hire a painter based upon a description of their personality. All of those places would judge a person on their portfolio, or an audition.
And that's exactly what those "silly" whiteboard puzzle problems are. They're an audition. Just like actors who have to say silly phrases with emotional inflection, just like bands that require new members to play some random short pieces, and just like football players who have to post their times on 40-yard sprints. Now you can argue that the auditioning process should be improved; that right now the skills exercised with the audition aren't the same ones used by a working programmer and I'd agree with you. I do feel like the process of auditioning for a software development role can be improved. But the way to do that is not to abandon the process entirely and just go with some kind of ill-considered gut feeling about "how much do I like this person?" The way to do it is to make it such that the interview more closely resembles the job the person will be asked to perform.
"Do I think this person is a cool person?" No movie director would hire an actor on that basis.
Well, considering the amount of work Mel Gibson gets these days (more or less zero), this does factor in a bit. I also gather that studios hire actors for reasons beyond their acting skill quite often. Consider also how many actresses fall off the face of the earth when they hit a certain age. Where's Mira Sorvino? Halle Berry? Jennifer Garner? Jessica Alba? Did they suddenly forget how to audition?
Considering all the TV shows where the actors are cast by the 8x10 glossies, it might even be the default to undervalue auditions.
Oh give me a break. Those actresses are just taking time off to have children. Nothing wrong with that. There are plenty of successful middle-age actresses.
There are plenty of successful middle-age actresses.
Mel Gibson took time off? Or he can't find good projects anymore?
Middle age actresses that aren't getting the parts they used to, fairly or not: Elizabeth Shue, Elizabeth Hurley, Catherine Zeta Jones, Nicole Kidman. It's plausible that many just left the business, but they all still act, just in much smaller projects.
There's some of that on the actor side as well. Michael Keaton has had a hard time of it for the most part. I just picked actresses because it's more apparent to me non-acting qualities carry more weight when it comes to actresses.
the right model is an art studio, a movie set, or a band
Knowledge workers aren't cogs, they're part of a team.
That's a bit ironic because movie sets and bands (almost always) are structured teams with industry standard roles (drummer, audio technician, key grip, gaffer) that make it easy to hire people for the duration of a gig.
Developers, analogously, might operate instruments; manufacture their own instruments; compose and/or improvise music; manage their own careers; negotiate their own contracts; edit their own recordings; package their own work for distribution; distribute their own work; and even perform their own focus group studies. Sometimes there's no time to figure out all those things out so you have to pick up one of the instruments of your predecessors and play something useful immediately.
I can perform the same exercise for film production, sports teams, and surgical centers. One of the big problems with software development is that we don't have distinct roles. Everyone is a developer/coder/engineer. It would be as if the entire music industry were executives and music developers. Or the entire film industry were producers, directors, and film engineers.
Anyway, I actually agree with you underlying point that the health of a team trumps the skills of a team every time. And since the structure of a software team is so fluid, cohesiveness and cooperation is actually more important than it is in a band.
1. We don't introduce ourselves at parties as DSP developers.
2. There isn't a category on glassdoor.com for network protocol developers. You don't see BLS data breaking salaries out based on the specializations you list.
3. If someone puts out a job listing for 'backend developer', you still don't know what your day-to-day will look like at you new job. Contrast this to 'pediatric nurse practitioner'.
4. We don't say to our bosses, "My specialization is X, but you want me to do Y work. We need to hire a Y person or you need to promote me to 'X engineer' and give me a raise."
5. Managers don't think much of sticking a rookie frontend developer on some backend tasks with no training or mentoring. "You'll review the code before it goes in, right? What's the problem?"
Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff.
Great comment, I totally agree that taking a wholly mechanistic view of how individuals and teams work is an error. You can't account for all the 'magic' that make some teams function in ways that are more than the individual parts.
Of course, you're striking at an underlying fear for managers. Our jobs are to make things work immaterial of the individuals: positively a managers job is to make the system of people/process/systems work, and negatively to make sure that no individual should be so indispensable for the project/department/organisation. This mechanistic view generally works because most roles are 90% perspiration and 10% inspiration, as the saying goes.
Perhaps a good mix is that when a hole is created in the team, to look at the situation holistically. As the short-list of candidates is drawn-up consider how they could fit into the mix, and how they would be additive - not the same as previously, but a new opportunity - like a new ingredient, rather than a replacement cog. It reinforces the idea of having more peers from the group involved in the hiring as this could open up a range of opinions on how the mix could change.
Comments
So many people have these really bizarre and outdated (by not just years but centuries) notions about how knowledge work gets done. They want to squish it into the model of factory work, but it just doesn't work that way. Knowledge work is typically creative, the right model is an art studio, a movie set, or a band. This makes hiring very difficult, which is exacerbated by the fact that engineers are innately bad at hiring other engineers without a lot of training or carefully focused self-improvement.
Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. But if you change the parts, you get a different team that does different stuff, or maybe doesn't even work at all. One of the big factors here is that if you think you can replace one person with just another person you're often wrong. Best case scenario you end up with something else (maybe better), worst case scenario is you can't replace the unique factors that made the previous person successful in that role (and realistically you need a team with a different breakdown of skills, different mechanisms of interconnectedness, etc. in order to have something functional).
The band analogy really helps here a lot. Realistically when you change members of a team you don't end up with something like Steve Perry stepping into the lead singer role of Journey. What you end up with is something more like Fleetwood Mac being transformed by merging with Buckingham Nicks or Genesis changing after Peter Gabriel left. You end up with a very different thing doing very different stuff. And the higher caliber the people the bigger the difference is.
What knowledge workers actually do day to day and what it says on their job description they do are often very different things, and you ignore that at your peril. Hiring based on the idea that knowledge workers are automatons with certain functionality modules installed is one of the easiest and most common ways to completely sabotage productivity and execution.
And that's exactly what those "silly" whiteboard puzzle problems are. They're an audition. Just like actors who have to say silly phrases with emotional inflection, just like bands that require new members to play some random short pieces, and just like football players who have to post their times on 40-yard sprints. Now you can argue that the auditioning process should be improved; that right now the skills exercised with the audition aren't the same ones used by a working programmer and I'd agree with you. I do feel like the process of auditioning for a software development role can be improved. But the way to do that is not to abandon the process entirely and just go with some kind of ill-considered gut feeling about "how much do I like this person?" The way to do it is to make it such that the interview more closely resembles the job the person will be asked to perform.
Well, considering the amount of work Mel Gibson gets these days (more or less zero), this does factor in a bit. I also gather that studios hire actors for reasons beyond their acting skill quite often. Consider also how many actresses fall off the face of the earth when they hit a certain age. Where's Mira Sorvino? Halle Berry? Jennifer Garner? Jessica Alba? Did they suddenly forget how to audition?
Considering all the TV shows where the actors are cast by the 8x10 glossies, it might even be the default to undervalue auditions.
Oh give me a break. Those actresses are just taking time off to have children. Nothing wrong with that. There are plenty of successful middle-age actresses.
Mel Gibson took time off? Or he can't find good projects anymore?
Middle age actresses that aren't getting the parts they used to, fairly or not: Elizabeth Shue, Elizabeth Hurley, Catherine Zeta Jones, Nicole Kidman. It's plausible that many just left the business, but they all still act, just in much smaller projects.
There's some of that on the actor side as well. Michael Keaton has had a hard time of it for the most part. I just picked actresses because it's more apparent to me non-acting qualities carry more weight when it comes to actresses.
That's a bit ironic because movie sets and bands (almost always) are structured teams with industry standard roles (drummer, audio technician, key grip, gaffer) that make it easy to hire people for the duration of a gig.
Developers, analogously, might operate instruments; manufacture their own instruments; compose and/or improvise music; manage their own careers; negotiate their own contracts; edit their own recordings; package their own work for distribution; distribute their own work; and even perform their own focus group studies. Sometimes there's no time to figure out all those things out so you have to pick up one of the instruments of your predecessors and play something useful immediately.
I can perform the same exercise for film production, sports teams, and surgical centers. One of the big problems with software development is that we don't have distinct roles. Everyone is a developer/coder/engineer. It would be as if the entire music industry were executives and music developers. Or the entire film industry were producers, directors, and film engineers.
Anyway, I actually agree with you underlying point that the health of a team trumps the skills of a team every time. And since the structure of a software team is so fluid, cohesiveness and cooperation is actually more important than it is in a band.
We do have specializations. Backend, frontend, platform x, video software, games, dsp, network protocols, etc
1. We don't introduce ourselves at parties as DSP developers.
2. There isn't a category on glassdoor.com for network protocol developers. You don't see BLS data breaking salaries out based on the specializations you list.
3. If someone puts out a job listing for 'backend developer', you still don't know what your day-to-day will look like at you new job. Contrast this to 'pediatric nurse practitioner'.
4. We don't say to our bosses, "My specialization is X, but you want me to do Y work. We need to hire a Y person or you need to promote me to 'X engineer' and give me a raise."
5. Managers don't think much of sticking a rookie frontend developer on some backend tasks with no training or mentoring. "You'll review the code before it goes in, right? What's the problem?"
Great comment, I totally agree that taking a wholly mechanistic view of how individuals and teams work is an error. You can't account for all the 'magic' that make some teams function in ways that are more than the individual parts.
Of course, you're striking at an underlying fear for managers. Our jobs are to make things work immaterial of the individuals: positively a managers job is to make the system of people/process/systems work, and negatively to make sure that no individual should be so indispensable for the project/department/organisation. This mechanistic view generally works because most roles are 90% perspiration and 10% inspiration, as the saying goes.
Perhaps a good mix is that when a hole is created in the team, to look at the situation holistically. As the short-list of candidates is drawn-up consider how they could fit into the mix, and how they would be additive - not the same as previously, but a new opportunity - like a new ingredient, rather than a replacement cog. It reinforces the idea of having more peers from the group involved in the hiring as this could open up a range of opinions on how the mix could change.