This year, Major League Baseball tried out a new — and in my view flawed — way to select which eight players would appear in the annual Home Run Derby (part of the All Star festivities). Instead of the players being chosen somewhere offstage, out of the public glare, this year the MLB folks decided that the competition for “Who can hit the most home runs” should have four players from each league. David Ortiz and Prince Fielder, both of whom have won previously, were asked to choose three additional players. And that’s when the situation began to go south.
If you weren’t paying attention: The Milwaukee Brewers’ Prince Fielder chose the LA Dodgers’ Matt Kemp, St Louis’ Matt Holliday, and his own teammate — and best friend — Rickie Weeks. No one disputed Kemp, whose home runs have probably been among the few bright spots for fans in Los Angeles, and few were openly critical of Holliday (though one can always argue about such choices). Fielder earned criticism, and very loud boos, because he chose Rickie Weeks primarily because of their close friendship. In particular, he snubbed the Arizona Diamondbacks’ Justin Upton, when the All-Star Game was being played in the Diamondback’s ballpark.
Think this has nothing to do with your career development as a software professional? Think again. At some point you are likely to be promoted to team lead, the first step towards a career in management. You’ll then have some choice in the team you work with, or you will be included when it comes to making a new hire. In Prince Fielder’s first “management” decision, he — and MLB — made several errors you (and your managers) can learn from.
Just because someone is good at one thing doesn’t mean he’s good at everything. The first mistake was on the part of the MLB decision makers, who imagined that a man who is good at seeing a baseball at 95 mph is also good at seeing what it takes to put together the right team. It’s an easy error to make because we do like to think that people who excel in one area (say, user interface design) will be good at other technical skills (say, implementing a cloud architecture) or at people skills (such as mentoring new team members).
This seems so obvious to me that I can’t even bring myself to come up with examples to back it up. Perhaps this plan sounded like good theater. It wasn’t.
Asking Fielder to make a solo decision about who should be in the Derby was dangerous no matter which players he chose. It was easy to make a political choice rather than to use other criteria, such as “Who hits the most home run balls at Chase Field?” or “Who puts on the best show during batting practice?” Fielder thought like a player, not like a manager. When asked to choose other players, he understandably considered his relationships with current and future teammates. He has to work with other baseball players, so his choices could come across as personal… and in fact they were, as was evident from an interview on July 5th:
He especially wanted someone from the Arizona Diamondbacks, whose home ballpark, Chase Field, will host All-Star week, and considered outfielder Justin Upton. But Fielder couldn’t pass on Kemp, who is having an MVP-caliber season, or Holliday, a two-time Derby veteran, or Weeks, his best friend in baseball.
“He’s a teammate of mine, this is his first All-Star Game, and I’m really excited for him,” Fielder said. “I want him to show people how far he can hit it.” [Emphasis added.--ES]
Be wary of hiring your friends. It rarely ends well. Most of us learned this in 8th grade.
Managers should make team decisions, with team or individuals’ input. I can imagine that this was a test of Fielder’s skill at putting together a “winning team,” in which case he flunked, given the number of home runs the American League players hit compared with Fielder’s National League hitters. (The booing notwithstanding.) I don’t think that’s what it was about, but the decision process (or lack thereof) does raise a few comparisons in how successful “techies” move into positions of business responsibility. (And, of course, how often they do not succeed.)
For example, asking an excellent coder to contribute outside her known strengths is a good way to test her for her suitability for other responsibilities. That’s how we grow: We get good at one thing, and then we add more knowledge. But when managers mentor people and let them try new things, prospective managers receive oversight and coaching. You let people make their inevitable mistakes where they don’t matter quite so much, or a good manager helps the brilliant coder have “learning experiences” outside the public eye.
Among the many admirable qualities of baseball as a business is its minor league system, which helps players develop their skills, return temporarily to fix a weakness, or fail in a smaller and less expensive domain. When a talented player spends time in a minor league team, he isn’t expected to figure out new-to-him skills (such as how to hit a curve ball) on his own. More experienced people offer suggestions, assign training exercises (which in a management context might be, “Who would you put in today’s lineup?”), and offer guidance.
Justin Upton saw this clearly enough, as he explained during an interview shortly after the Home Run Derby:
Upton:…I don’t think they should necessarily change the format; I think it’s pretty cool. They should definitely have some help from a panel. They should bring their list of guys to a panel and tell them the guys they really want on their team, and then other side can say, “No, these are the guys.”
Interviewer: Basically, “Did you consider this other guy?”
Upton: Exactly. They just need to be aided, not because he couldn’t do it on his own, but because it is a lot of pressure. It’s a lot of pressure, and it’s a lot of politics, so that’s the side he’s not going to see. You sit there and make out your list, but there may be somebody off it that could help you. I think with the help of somebody you can make better decisions. Like I said, there is a lot of pressure. I like that you don’t have to be an All-Star to be in it. That’s cool because sometimes power hitters don’t have a good first half, and so they’re unable to be an All-Star. You see guys like Mike Stanton that can just hammer the ball.
The notion of “minor leagues” ought to apply to a lot more professions than baseball, and I think it’s particularly relevant for software developers and testers, where the talent is the product. Jeff Angus, the eloquent author of Management by Baseball: The Official Rules for Winning Management, wrote:
In baseball, the ultimate talent-is-the-product industry, few people get to play in the majors before they’re proven at a lower level. In nonbaseball organizations, employers tend to try to short-circuit that, hiding their heads in the sand, pretending that fresh-faced MBAs or other organization’s failures and mediocrities or intelligent but unenculturated people in third world sweatshops getting $9 a day are capable of the high achievement the organization needs to succeed.
Does your organization have a baseball-style organization that trains less experienced talent on less important or low-pressure projects and work, promoting them to tougher and more important projects as they learn and prove their potential? If not, why not? Can you imagine what a major-league baseball team’s talent would look like if it followed the way your organization chooses talent for key projects?
Don’t lose sight of the goal: Whom do you serve? The goal of the Home Run Derby is to put on a show: Who can hit the most home run balls? The criteria for choosing participants should include things like the number of balls the player hit this year, how well does he hit in this stadium, and other “technical” data. Certainly those are primary data points.
The decision should also reference what the users — or viewers — want. Just as the Agile development community has drummed it into the heads of managers that making users happy is more important than an arbitrary product spec, anyone choosing a Home Run Derby lineup should consider both the local audience and the TV audience. In any All-Star game, at least half the people attending are going to be local fans; this year it was Phoenix, next year Kansas City. Those Home Run Derby seats aren’t cheap; mine cost $260 per person. Who do you think is paying the bills? I’ve come to the conclusion that the Home Run Derby should always include a home town player, simply because the fans want to cheer for a local guy, and every team has a local star.
Most software developers understand that it’s more important to make the users happy than it is to create a breathtakingly elegant application that doesn’t do what the paying customers want. You don’t make decisions based on what is convenient or fun for you, or at least I hope you don’t. If your solution doesn’t serve the users — or the fans — it isn’t going to succeed. People will boo. They will boo even louder if you chose a software design because it was created by your best friend, rather than the design from someone they know — someone who has already delivered.
Unfortunately, Fielder never got the message. After the Derby, he said in response to the very loud boos, “Pick who you want . . . If they have a problem, tell the other person they should be captain. They can pick who they want to pick.”
Were there other lessons I missed? Or do you think I totally struck out? Tell me about it in the comments.
