> They hand him his racket, and tell him that at his next French Open (played on slow clay instead of fast grass), he will serve and volley and play left handed.

This is essentially what happened with Rafael Nadal, who's uncle/coach made him play left-handed despite being naturally right-handed. He's won the French Open 9 of the 10 times he's played it.

That's where I disagree with the "No B Players" argument. I agree that people need to be put in situations where they can succeed. But there are certain people for which that set of situations where then can excel is significantly larger than normal. And there's a lot of people who are only able to be successful in a very narrow set of circumstances. As a business, it's very rare that you can design a role around a candidate. But you can choose to hire the most adaptable employees you can find. Those are the A players.

And, for me, those A players share one simple trait...the love to learn and pursue it outside of work. Whether it's an engineer experimenting with new technologies in side projects or someone learning a new language/skill outside of work, that need to continually grow as a person leads to employees who can almost always fit themselves into whatever role comes along. Those are the A players that I look for when hiring employees and when interviewing with a potential employer and that's the type of employee I try to be.

I think you've just agreed with the OP's premise. Your criteria for A-player is that they be adaptable. You hire people who are adaptable and you're happy with those people because they meet your criteria.

But other employers have different criteria. Some value productivity over adaptability: they like people who can product vast amounts of value in a specific set of circumstances, and they're happy to ensure those circumstances are met. The classic example of this is the "no social skills" code geek who can churn out vast amounts of production code but is totally unable to handle a meeting with a customer to agree requirements.

I agree with your sentiment about loving work. That point of Flow where work and play meet is where people get to shine and be great. But it's a different place for everyone, and some are not that adaptable.

My understanding is that Nadal didn't really switch to being left handed. When he was a child (was it age 8?), he had two handed strokes off both sides, which is common for kids. Young tennis players often drop the non-dominant hand on the forehand when they get stronger. His uncle, noticing that he was as strong off the left as the right, encouraged him to play as a lefty. He perfected this over countless hours for the next 11 years, winning the french open at age 19. This is vastly different from taking a seasoned pro and suddenly telling him to play with complete different tactics with his non-dominant hand! In fact, if Nadal were required to play with Federer's strokes tomorrow (ie., use his right hand, and hit a one handed backhand), my guess is that he'd get bageled in his next pro match, and I doubt he'd ever be in the top 100 again (that's an extremely conservative estimate, there's a good chance he'd permanently collapse in the rankings).

That said, I do think that Nadal is an excellent example of how to be adaptable. Take a look some time at how he approached hard courts after his initial success on clay. Rather than staying way back, he moved much closer in on the court, taking the ball on the rise, and taking his opponent's time away. It was a big adjustment for the former clay court specialist, but it worked, and it's why Nadal is now one of the few players with a career slam, and titles on every surface.

So yes, you need to adapt, but (and I know I'm stretching a sports analogy a big far here) it demonstrates how the truly top players go about change. They do adapt, but they're highly strategic about it, they leverage existing strengths, and they don't do it on a whim (and they especially don't do it on someone else's whim).

I actually think that technical leaders are also very organizationally savvy people. They adapt and learn new things, but they don't get jerked around from task to task - and they'll say no and fight strategically about it if need be. They understand how to align their projects with their strengths, and what they want to learn next. This way, they don't waste time or mental energy, and they play from a position of strength.

There is a limit to autonomy.

I mean, if you have a project that is big enough that 10 people are working on it, you have to have consensus about version control, build systems, what version of what languages and libraries you have running in so forth. If you don't, life is going to be hell for the ops people. If the organization can't enforce these kind of standards, it is a failing organization.

If some place has 150k lines of Cold Fusion and Microsoft SQL stored procedures and you are hired to maintain that system, you are going to have to deal with that environment, and you can either do what you can with that environment or go someplace else if you don't want to deal with it.

There are many dimensions to performance and one of it is that some people are good starters and other people are good finishers. The starters do the 20% of the work that gets you (seemingly) 80% of the way there, but the finishers have the determination, energy, pride and broad-spectrum knowledge and experience to do the 80% of the work that gets you (seemingly) 20% of the way there.

Superficially the starter seems to be 25x more productive than the finisher, but without the finisher, the starter might not deliver any business value at all.

The huge variation in the numbers, plus all of the emotional and political factors involved make a correct accounting of the situation almost impossible. Depending on how it plays out, the starter could be seen as a C player and the finisher an A player (the product wouldn't have shipped without the finisher or it could be around (people forget that the finisher actually shipped the product, all they remember was that he was always complaining about the build system)

> Superficially the starter seems to be 25x more productive than the finisher, but without the finisher, the starter might not deliver any business value at all.

I wrote a post about exactly that:

http://jacquesmattheij.com/A+tale+of+two+programmers

Finishers are actually quite rare and worth their weight in gold. And starters need finishers just as much as finishers need starters, but I've seen tons of people that are good at starting stuff and only very few that are good at finishing. It takes real perseverance and dedication to see a project through to its conclusion.