
Moneyball teams - bdg
http://bg-blog.com/2017/04/21/moneyball-teams/
======
georgeecollins
I wish I could triple like this! Hire the best is lazy thinking.

* I have been on teams that were not considered the best until they had success, then everyone on the team was a "star".

* I have worked places where they only hire "superstars"\-- and were pretty serious about paying for good talent and being picky-- and still failed for all kinds of organizational reasons. Teams with more role players, or more cohesion of goals would have performed better.

*I have seen people recommended because they worked at "X" or worked on the "X" project, and then turn out to be completely underwhelming. Great teams don't always only have great people, and sometimes the great team has people on it who are one promotion away being at their level of incompetence.

~~~
AceJohnny2
At a former (large, organizationally deficient) company, there was this small
team of 5 people with very different specialties (and personalities). They
were a "strike team" of sorts, tasked with helping out at a technical level
different projects that were in trouble. They were excellent. They saved my
team's integration of a camera co-processor in an SoC.

But finally a re-org came around and some high-level manager didn't have a box
under which to put them (or didn't have the right budget item to fit them in),
and the team was dissolved.

The guys were good in the teams they each landed in, but the synergy[1] was
dead.

Nowadays, my primary criteria for joining a team is the quality of the people
and of the manager. I wish I could say I've seen other teams of the quality of
that first one.

[1] yeah I said it

~~~
sanswork
One of my most enjoyable periods while working for someone else was at
CapGemini when I was between teams and lent out to do short term fixes for
teams where they didn't have enough developer resources/the right resources.
Typically just a week or two to go in figure out what was going wrong and
patch their systems then get swapped. I don't know if it was the change of
pace or the fact that you kind of got to feel like an office superhero that I
liked more but I was really young so probably equal parts both.

~~~
Tenhundfeld
I had a similar stint helping teams with system performance issues. I think I
found it so enjoyable for two reasons:

1) Solving the problems involved the focused exercising of all of my software
dev knowledge – often around database access, sometimes around garbage
collection and memory allocation of the specific platform.

2) The impact was highly visible and appreciated (by the team, management, and
system users), and the result was usually objectively measurable, e.g., the
global search now completes in 1/50th of the previous time.

That said, when I reflect on the 10 or so projects I helped in this time, they
were all problems the senior dev(s) on the team could have figured out. So, it
wasn't really that I was some rockstar who had special knowledge. It was more
that I was given time to focus on the issues, while the regular devs on the
team had bugs to fix, features to work on, etc.

Like you, I now work for myself, but if I were offered a job doing small-
medium performance optimization projects (without travel), that would be
tempting.

~~~
ethbro
If there were one key benefit of consulting / being an internal developer at
large it would be the ability to _leave_ after finishing a project.

Sometimes that's sad. (When the client / team is awesome)

But usually it means not having to deal with any of the worst parts of office
politics. (E.g. de facto stack ranking, non-merit-based favoritism jockying,
office management politics, dysfunctional management priorities, waiting for
someone to die / retire for a promotion, etc)

------
ryandrake
Another way to look at it is: What causes projects to succeed or fail?

I've seen my share of failed projects throughout my career (as a participant
and as a co-worker watching it happen). By a huge margin, most of the failed
project did not fail because the engineering team was weak, or because they
didn't hire "rockstar" programmers, or because the engineers didn't go to
Stanford. They failed because of things like requirements growth, unrealistic
schedules, emotion-based/gut-based (rather than measurement-based) product
decisions, and external factors (market changing and company couldn't react).
If companies spent more time worrying about these things and less time
worrying whether their engineering interview candidates can balance a binary
tree on a whiteboard, we might see hiring practices change.

~~~
snarf21
I agree with everything you've said so I won't add to it.

There is an interesting anecdote that I love. Some number of years ago there
used to be a show called EcoChallenge. It was made by Marc Burnett but before
Survivor. It was simply an adventure race but no politics and no contrived
voting. Each team of 4 must be co-ed. There is a starting point, there is a
stopping point and there are way stations along the way. Simply go from start
to end hitting the way stations. Everything else was left up to the teams. The
one big twist is that you can't win unless _ALL_ of the team hits each way
point. Teams are allowed to race 24x7.

One of the last years it was on tv, a team of navy seals bombed out and a team
of 3 playboy playmates went further then they did. The team that won (from NZ)
had a sick teammate and spent two days nursing their teammate into passable
health. They loaded up all that person's gear split 1.3x, 1.3x, 1.3x, 0x and
set off. They rocketed past all of the other teams and won by over a day.

This is what real success looks like. A determined team laser focused on the
_exact_ same goal and doing whatever it takes to get there.

~~~
devonkim
A bit more on topic, I was asked to read a book on leadership and teamwork
that's a bit of a cliche these days but Coach Wooden's Leadership Game Plan
for Success covers a lot of these ideas specifically in a sports context. A
lot of leadership texts revolve around sports out of sheer ubiquity in subject
matter among business leaders culturally but beyond some pop sociology type of
research I really don't pay much attention to them in a business setting. Why?
In much of the world of software, day-to-day work is not a race against a
competing team towards the exact same goal as much as it is a race against
oneself and against market inertia whether that may be the default mode of
failure or convergence to an equilibrium point that needs to be readjusted as
the team discovers the hidden rules of a game.

In fact, a lot of business is probably a lot closer to something more sadistic
and cruel in gross mechanics like from Takashi Miike's 2014 As the Gods Will
(and the manga of the same) - arbitrary filters where the rules are very clear
only until after people have died. Some stages test raw individual skills
while others test cooperation. And in some cases it didn't actually matter if
you had either of those because "luck" is the bigger factor (the fact few in
practice agree upon these slack variables to achieving business success shows
how random things are for survivorship moreso than controllable factors like
skill and effort)

------
Evolved
One of my favorite movies, _Miracle_ about the 1980 U.S. Olympic hockey team
that upset the Soviets, had this dialogue that actually happened between Head
Coach Herb Brooks and Assistant Head Coach Craig Patrick. I feel it applies
here.

 _Patrick: This is the final roster? You 're kidding me, right? You're missing
some of the best players.

Brooks: I'm not looking for the best players, Craig. I'm looking for the right
ones._

~~~
caseysoftware
Which implies something major that everyone is glossing over:

If the "right people" aren't the same as the "best people" are the criteria
we're using for "best" correct?

~~~
conjecTech
I think the real lesson - and the premise behind Moneyball - is that when you
have a complex objective, you can't evaluate people in a vacuum. You have to
optimize at the team level. You can try your damnedest to come up with
heuristics and metrics to evaluate individuals, but if you don't allow
yourself to consider the context that they'll be working in, you'll miss a lot
of potential.

~~~
asdfasdf32r3
I don't think this is the central thesis of Moneyball. I'm a huge baseball
nerd, including on-field and statistical side. The idea behind the WAR (Wins
Above Replacement) stat is that you should adjust for context, then evaluate
players in that vacuum.

Moneyball was about identifying and exploiting market inefficiencies. It
actually rejects the team level optimization ("he's a team player" is
explicitly rejected as a valuation of a player).

Instead, Billy Beane identified what components led to team success, then
found which of those the market doesn't pay for. Then he got those guys.

Used to be thought that a good baseball team had a speedy leadoff hitter.
Teams would play objectively worse players because they thought their style
better "fit" their role.

Moneyball was the start of the revolution that you just want to get the best
players. Then accept that playoffs don't really mean anything other than
randomness with small sample sizes.

~~~
rsync
"Instead, Billy Beane identified what components led to team success, then
found which of those the market doesn't pay for. Then he got those guys."

Let me ask you - as I am not a baseball nerd - if there is any counter-
argument to the BillyBeane/Moneyball/WAR movement ?

I don't mean knee-jerk, irrational objections - but real, reasoned counter-
hypotheses ?

~~~
kmonsen
Yeah, the counter argument is that you mess up the team chemistry. This is
extremely hard to define and measure so can sort of always be used.

Billy Beane is constantly attacked for destroying the looker room chemistry in
the local press.

~~~
kamaal
>>you mess up the team chemistry.

True, only if you have a great team already and you don't desire messing it
up. If that is the case, you wouldn't need that method at the first place.

On the other hand, teams are pretty dynamic these days given the interfaces
and responsibilities are well defined. Or at least are largely defined well.
So replacing team members is never really a problem.

------
AndrewKemendo
_Presumably you have teams of Web-stack ( "Fullstack") developers._

This caveat should have been put up front.

Since "Best" is a vague loaded term it's more accurate to understand the
problem that you're trying to solve.

If you are creating a new web-standard or industry shifting technology then
you absolutely need the best. If you are creating a new web based CRM for
firefighters, then you need someone who is good, but probably doesn't do
vector algebra in their head or [insert favorite discriminator for something
hard.]

~~~
acdha
> Since "Best" is a vague loaded term it's more accurate to understand the
> problem that you're trying to solve. > > If you are creating a new web-
> standard or industry shifting technology then you absolutely need the best.

There's a tension between these two sentences which is worth more
consideration about what “best” really means and how it intersects with
scalability.

If you're working on a web standard, “best” tends to mean things like
“experienced”, “works well with others”, and “broad and deep understanding of
what the users do”.

If you're working on a major new technology, it might be more likely that you
really need someone who is incredibly good at a particular hard skill but it's
still likely that if you have a problem in that class it will exceed any
individual's capacity and the limiting factors will continue to be
coordination between people, ability to maintain clean separation of
responsibilities, etc.

Think about something like LLVM – there's a ton of really hard work in
compilers and optimization, it's had a significant impact in multiple parts of
the industry, and while there are some people who rightly deserve a great deal
of respect for work on those hard problems, a key part of the success which
hasn't been virtuoso work at that level but rather keeping a design which is
clean and extensible enough for so many different organizations to use and
contribute to.

~~~
AndrewKemendo
Yes, fair point. Ended up stepping on myself there a bit.

Maybe "Top of their discipline" would be a better way to say it.

~~~
acdha
Yeah, it's hard to talk about this since we're using a single term to convey
multiple complex concepts.

~~~
bdg
This reminds me of a post on Less Wrong about the meanings of words and the
idea we're targeting.
[http://lesswrong.com/lw/np/disputing_definitions/](http://lesswrong.com/lw/np/disputing_definitions/)

------
ktRolster
Or, hire the best, and make a team out of them. Or hire people with high
potential and push them to reach it. Or, hire people who can get the job done.

One thing for sure: if you have mind-numbing processes, "the best" will leave,
and others will not reach their potential.

~~~
shallot_router
Yeah, these "don't do [hip thing], do [contrarian but normal/common sense]
thing" articles (or the reverse of them) are becoming a bit tired.

You should have good team-building and organizational skills _and_ good
technical hiring skills.

~~~
rhizome
Everybody thinks they're doing the common-sense thing and not being
contrarian, even if it's the hip thing.

~~~
shallot_router
Very true.

------
jph
Moneyball and Six Thinking Hats are excellent approaches to for people and
roles.

But they aren't enough. The key driver of top-tier teams is excellent ongoing
safe communication.

To build communications, use team goals (e.g. OKRs & KPIs), team ways of
working (e.g. TEAM FOCUS), and team positions (e.g. scorecards).

My notes about these are open source:
[https://joelparkerhenderson.github.io/](https://joelparkerhenderson.github.io/)

Edit to explain abbreviations:

* OKRs = Objectives & Key Results

* KPIs = Key Performance Indicators

* TEAM = Talk, Evaluate, Assist, Motivate

* FOCUS = Frame, Organize, Collect, Understand, Synthesize

~~~
pklausler
CARGO CULT BUZZWORD OVERLOAD

~~~
sebastos
For those wondering: Collect, Aggregate, Reduce and Generate Objectives to
Cultivate Understanding Learning and Teamwork

------
dkarapetyan
Hiring the best doesn't scale. Building teams does. The problem as with hiring
the best is that almost no one knows how to build good teams. You will
probably spend way more time resolving conflicts and dealing with politics
than you'd like and in the end the software product will still be a steaming
pile of technical debt.

~~~
cbtacy
upvote x 1M

------
jwineman
Cached:
[https://webcache.googleusercontent.com/search?q=cache:zDlwVT...](https://webcache.googleusercontent.com/search?q=cache:zDlwVTWJLLwJ:https://bg-
blog.com/2017/04/21/moneyball-teams/+&cd=1&hl=en&ct=clnk&gl=us)

------
sesteel
This is a pretty important lesson that gets lost at times. Teams with people
of diversified passions work well; if everybody is super into data structures,
UX, security, etc., then debates can rage and feelings can get hurt. When
people on a team specialize differently, everybody can be a mentor to
everybody else. To me, that is a great team to be on.

~~~
bdg
Yes, and I also suspect this has lead to "we don't hire jerks" policies, which
are great when you find someone who enters a conversation and talks down to
everyone. That person fails a culture fit.

However, there's another kind of person who just talks over you, doesn't put
in the effort to communicate their ideas, or refuses to accept other ideas.
These can remain hidden until tested in the depths of some technical
discussion. They might pass a culture fit.

------
curiouscats
I agree, same sentiment from W. Edwards Deming: "A company could put a top man
at every position and be swallowed by a competitor with people only half as
good, but who are working together."

[http://quotes.deming.org/authors/W._Edwards_Deming/quote/101...](http://quotes.deming.org/authors/W._Edwards_Deming/quote/10159)

------
lordnacho
It happens now and again that the best team has very few of the best players:

\- Denmark at Euro 92. The only world class player, Michael Laudrup, decided
he was boycotting the coach. His brother was a fairly decent striker, and
future Man Utd legend Peter Schmeichel was in goal, but everyone else was a
journeyman.

\- Greece at Euro 2004. Nobody from a top team in a top league, but Otto
Rehagel managed to coach them to victory. Not amateurs, of course, but
certainly not superstars.

\- Leicester City last year in the Premiership. Nobody on the team was a real
target for a top club, except maybe Schmeichel junior, also in goal. But they
played a great season and one of them got voted player of the year. And Vardy
beat the scoring streak record. What's interesting is how they fell apart this
season under the same coach, who then got sacked and replaced by someone who
has partially brought back the magic.

The rest of the time, the winners are built around a small number of world
class players, and competent squaddies. This is typical of US teams, where you
have a salary cap, meaning the superstars will be spread out, and you need to
be efficient in paying for the squaddies that are appropriate for that star's
game.

~~~
what_ever
So once in Premier League since it's inception (1991 IIRC) and twice in Euros
since I don't ever remember when should be that surprising?

------
avip
My model for ideal hiring are the Spurs. They consistently hire for talent and
potential, provide the proper mentoring and conditions for the potential to
fully materialise.

"As you sow, so shall you reap". But few have the patience to sow nowadays. We
rather buy ready-made in the grocery store.

~~~
Rylinks
Most companies cannot have their employees sign multi-year contracts. Outside
of sports, there is a much bigger risk of your competitors poaching people
after they've developed.

~~~
ryandrake
Presumably that's always a risk regardless of whether you hired someone junior
and trained them or whether you hired someone already skilled. As long as
you're doing the standard things that help you retain talent (like paying
market rate, providing good opportunities, etc.), there should be no reason to
worry, right?

The only companies that should be worried about "poaching"[1] are the ones,
for example, who are not paying market rate, have crappy projects, provide no
career advancement opportunities. I've never heard of a talented employee
leaving a company for literally no reason.

1: Which by the way, is a pretty offensive term--we're not deer or wild game
owned by some feudal lord.

~~~
humanrebar
> The only companies that should be worried about "poaching" are the ones, for
> example, who are not paying market rate....

Well, "only" is implying it's not almost universal. Companies routinely pay
market rate for new hires and then base raises and bonuses on KPIs for
individuals, teams, or the whole organization.

Are there companies that say, "Well, we had a mediocre year, but market rate
for devs went up 8%, so I guess that will be the baseline raise for
everyone."? If a company does anything less, eventually employees are paid
below market rate and they're forced to negotiate a bigger raise (convincing
management to ignore KPIs and pay attention to market rates) or find a new
job.

~~~
ryandrake
Or they leave for a company paying new hires market rate.

The job market doesn't care if your company had a mediocre year, any more than
your suppliers care. If the price of screws or cables goes up 8% you either
pay it, look around for something cheaper, or negotiate. Somehow, when it
comes to labor, companies think paying “what we paid last year plus N%” makes
sense.

I guess the take-away here is: Companies by and large do not worry about
poaching. Rather, they are willing to live with it because they see the
alternative as too expensive.

------
neogodless
I'm four paragraphs in, and I don't want to get too hung up on grammatical
errors, but it's making it hard to follow along on what point they are trying
to make.

> and was won against with teams spending over $100 million

What does that mean? They spent less on their teams, and they lost? So they
should spend more!

> Once upon a time the ambitions of your company were exceeding the throughput
> capacity of your development teams. This is the ultimate goal of hiring...

This sentence ends with the ultimate goal, but "this" seems to be referring to
the previous sentence, when it really isn't.

> If ambition growth constant

I'm guessing they mean "is" constant?

~~~
mediocrejoker
I am a native English speaker and I had a hard time following the point as
well. I surmised from the title that the thesis was going to be "x number of
decent developers who work together well can produce a product
better/faster/cheaper than x great developers who don't get along"

I think a bit of proof reading might make it easier to follow the argument in
this article.

~~~
bdg
I had hoped to convince people that since hiring is about improving team
throughput there may be better ways to do that besides simply saying "hire the
best".

------
ChuckMcM
I am a bit surprised if this is new information to anyone who has managed
teams and/or thought seriously about the challenges that job has to face. When
ever I hear an executive making the assumption that "software engineers" are a
fungible resource and they will just move 6 over from the project that is on
track and humming along to the group that is behind and in trouble I know they
are clueless about managing high performance teams. Every team needs a mix of
people and when done well the talents and skills of the individual members
complement each other and create an effective whole. Too many people trying to
drive, or too many people unwilling to drive as an example can both leave the
team floundering and unproductive.

When someone asks me what I think their priority should be as a manager, their
day to day job if you will, it is looking for ways to improve this spread of
talents to minimize overlap and cover gaps.

------
runeks
Only hiring the best is inherently unsustainable, because it implies a need
for "other companies" to train people into being the best, and only then are
you willing to hire them.

The greatest companies are those who offer an atmosphere in which good
developers can grow into the best developers. The worst companies are those
who believe they can hire people from great companies, and consequently
transform into great companies themselves. Great companies produce value; poor
companies consume it.

~~~
mighty_atomic_c
This is an interesting point. Companies that try to "hire to greatness" have a
steep fee to pay for their hiring approach, and it might not work for reasons
that cannot possibly be squashed into, and recognized from, the sloppy
"greatness" scalar used to score the possible team members.

As you said, cultivation of expertise is a better approach, and I'm happy that
where I currently work fosters this carefully and deliberately.

------
reubenswartz
One thing that struck me from Ed Catmull's book on Pixar, Creativity Inc[1]
was how much effort they put into trying to get people to work together
effectively and how important that was in the final results, versus the
talents of the "super stars".

After the Disney acquisition, they kept the companies separate, but basically
got rid of a bunch of red tape at Disney Animation and injected a bunch of
Pixar cultural practices. The DA team went from mediocre results (many people
thought Pixar would just shut them down) to producing hit movies.

[1]
[https://www.amazon.com/dp/B00FUZQYBO/](https://www.amazon.com/dp/B00FUZQYBO/)

------
jtraffic
I used to play basketball almost every week at the university gym. There were
these guys in their 60's who still played with 19-25 year olds and routinely
won. I asked one of them if he saw one particular thing young people tended to
ignore. He said, without hesitation, "the team game."

There is probably some bias, the young guys probably didn't play quite as hard
as they would have otherwise, but I'm really not convinced that accounts for
the entire story.

Maybe it's just as simple as: interaction effects on teams are often stronger
than main effects.

------
afpx
The 'best' is so subjective as to be meaningless. I have worked with probably
500 software engineers, and I have been the best of all of them. (Well, one
guy was probably as good as me.) But, maybe this is only because I value
things that a lot of other people don't? My criteria are just different.

I have led teams that developed software resulting in 4 successful (another
subjective word, but in this case, acquired) startups. I designed and
implemented 14 products. All together these products were used by hundreds of
millions of people. Some of them are still used 10+ years later.

But, I still can't always convince hiring managers to hire me. I don't have a
blog (don't care). I don't have a github (don't have time). After being turned
down some say that I'm 'too mellow' or that I'm too abstract or too specific
or that I didn't answer their questions (usually one specific) the way that
they wanted me to. Again, it's all subjective.

At the end of the day, it's just a fashion show. And, when it comes to work,
I'm not into fashion (I have a laser focus on the product, its market
suitability, its functionality, and and its market success).

Basically, people hire the ones that they like. And, I believe the evidence
shows that most managers prefer to hire people who are worse than them, or at
least only better in certain ways. Corporations are just glorified
hierarchies, remember.

So, if you get turned down a lot, take it as a compliment.

~~~
peteretep

        > I have been the best of all of them
    

What's your metric for that? How would you have known if you weren't?

~~~
hinkley
Well, that's the problem isn't it? All you have are confirmation and survivor
biases to work with. You're going to get a lousy outcome.

Someone with far more practical experience than you might sound paranoid about
some things you don't even think about, and blasé about others (because they
have ways to mitigate the problem if it actually happens). You won't know
enough to realize why they aren't on board with your priorities, and you will
make conclusions that have no basis in reality.

You've only known this person for 45 minutes. You've known yourself for
decades. Which one are you going to assume is the idiot in this situation? How
often are you going to be wrong? And how would you ever know if you were
wrong? You just kicked this person out of your life because you didn't like
their answer. If they become lead developer at your biggest competitor, are
you even going to remember their name?

------
cpsempek
This reminds me of Reed Hasting's culture deck (he even uses a baseball team
as a metaphor when describing Netflix's hiring practices). To further the
analogy, Netflix would best be described by the Yankees--pay top-of-market for
those who have proven they are the best at their role. This has been
effective, for both the Yankees and Netflix. But, the interesting caveat, as
alluded to by the OP and the moneyball A's (and other teams), is that this
might not be an optimal strategy.

~~~
OpenDrapery
I think the Yankees model is a (possibly reaching) metaphor for capitalism.
All the capital concentrates in a few hands. But where are all the "best"
people supposed to prove themselves?

That's why you see so many posts in this thread like "I worked on the perfect
team for a short period, but alas, it was short lived." Building the gestalt
is always going to flame out. Right at the moment when you realize you've
assembled something special is when your team members start getting traded to
the Yankees.

That's why the only sustainable model is culture, culture, culture. Always be
striving for the perfect combination of team members. Keep the talent pipeline
active, and if you have someone who doesn't fit, get them out of there.

~~~
cpsempek
Interesting, to belabor the sports team metaphor, culture does indeed seem to
be an alternative to max salaries. C.f., Spurs being one of the most
winningest teams in the past couple decades, Tom Brady taking pay cuts in
order to maintain and foster a dynasty, and Steph Curry doing similar. In all
these cases, a great coach (read, CEO) has fostered a strict but burgeoning
cultures which rewards its members through a shared success in what they love
and not an individual's compensation.

Of course this analogy can be dangerous. Athlete's get paid extraordinary
sums, even while sitting on a bench 99% of the season. Whereas many employees
__have __to worry about their own compensation simply to survive, and such
selling of culture as a supplement to compensation won 't always put food in
your mouth (and thus can be exploitative).

Nonetheless, I appreciate your comment, you brought up an interesting view on
workplace culture that I never thought about.

------
jowiar
One metaphor I've been kicking around lately is that a long-term sustainable
software team needs a mix of "gas" (folks whose instincts are to churn ahead
-- "move fast and break things", if you will) and "brakes" (folks whose
instincts are to keep things under control, slow down and do things "right"),
and an organization that knows how to balance the two.

------
yuhong
I remember when michaelochurch was on HN. I think even nostrademons admitted
that closed allocation sucked.

------
rsync
I think we need to be critical of the Moneyball narrative - and not just
because Oakland hasn't actually performed that well under the MB regime ...

The understood narrative is that dummies were choosing players based on broken
heuristics and that proper, sober heuristics would uncover hidden value.

Put another way: If you remove human decision-making and replace it with
algorithms you will achieve better results.

I am skeptical of that conclusion in every other realm and I don't think
baseball (or hiring, as is the case in this article) should be exempt from
that skepticism.

Having read MB the book (and seen the movie, for what that's worth) I wonder
if Billy Beane is missing the potential for deeper insights that only human
brains can put together. It is the thing that we are good at, after all ...

~~~
bsder
> Having read MB the book (and seen the movie, for what that's worth) I wonder
> if Billy Beane is missing the potential for deeper insights that only human
> brains can put together. It is the thing that we are good at, after all ...

The human brain is _also_ very good at misleading itself. Statistics is how
you avoid that.

Do remember that Moneyball happened in an era where statistics was _just_
becoming more ubiquitous. Bill James was collecting and collating statistics
from a bunch of volunteers who used to snail mail him the scoring sheets from
the games. He only quit doing that in 1988 because suddenly there was a flood
of statistics.

So, from weak data to Moneyball in less than 10 years is actually fairly
impressive.

~~~
stupidhn
> _So, from weak data to Moneyball in less than 10 years is actually fairly
> impressive._

And it's taken over every sport thereafter: soccer, hockey, football and
basketball.

------
techman9
This reminds me a lot of Dan Luu's article, in which he makes the same
"Moneyball" comparison:

[https://danluu.com/programmer-moneyball/](https://danluu.com/programmer-
moneyball/)

------
uranian
> Software Development is often about human factors as much as it is the code.

Totally true that. But the title almost suggests you can build a winning team
out of a random bunch of average developers.

Although the best developer is an illusion as it doesn't exist as such, just
'building teams' doesn't really say much to me too. I've seen very terrible
teams that should have been replaced with just 1 good developer..

Personally I prefer to hire the best fit for the job, whether he or she will
be part of a team or not.

------
m52go
Thinking aloud...I wonder if the ancient Greek methods of sortition and
ostracism have any place in building teams at companies.

Obviously election (selecting people from a group) is hit-or-miss anyway...so
maybe reverse-election (eliminating people from a group) could help.

~~~
AceJohnny2
As a kid, one of the comic books I loved was the sci-fi Scrameustache [1]. One
of the recurring characters was a society of aliens called "Galaxians", who's
society was based on extreme sortition. Every week (or day?), they traded
posts. One would be a squad leader one day and the janitor the next.

Even as a kid, I realized this was a flawed concept, because it assumed
experience and knowledge were fungible. Still, it was fun to think about...

[1]
[https://en.wikipedia.org/wiki/Scrameustache](https://en.wikipedia.org/wiki/Scrameustache)
[2] [http://www.bedetheque.com/serie-682-BD-
Scrameustache.html](http://www.bedetheque.com/serie-682-BD-Scrameustache.html)

------
HiroshiSan
Seth Godin actually talks about this in his book the dip where he mentions
that the best means the best in their world (he goes on to explain the concept
of their world). Highly recommend the read.

~~~
bdg
Thanks for the recommendation, I'll add it to my reading list!

------
hunglee2
Excellent start to a post but really needs a follow up. I'd love to hear OP's
ideas on practical steps to take in order to effectively execute his team
based hiring model.

------
matchagaucho
The Moneyball metaphor is useful. The "best" player in baseball (Ty Cobb)
batted .366 over 24 seasons.

For every 10 attempts ( _at bats_ ), he "failed" 6.5 times.

Moneyball teams are really about hiring professionals who consistently bat
.300.

If each player is batting .300, then the results will compound (more RBIs and
runs for the team).

------
dvt
Sooo I totally agree with this concept: that teamwork is more important than
individual contribution; that we should focus on teams rather than metrics;
and that teams are simply more resilient than other types of organizational
structures.

Buuut, then the author starts talking about some corporate-bs mumbo-jumbo
"skills matrix". Moneyball is about "black swans" as Nassim Taleb would put
it: unexpected outcomes that defy the current knowledge base. In other words,
a conclusion that we could not have reached via deduction (but only perhaps
abduction).

But that goes completely against the "skills matrix" concept. The whole
_point_ of Moneyball is that the Oakland players were flawed given standard
metrics -- in fact, most were (very calculated) gambles.

>The final touch is to match these against levels of mastery. A lower level of
skill may be someone who is largely uninformed of the subject, a middle level
may be someone who can constantly use that skill well, and a high level is
someone who is a mentor and thought-leader.

Oh god, he really did miss the point.

>With your new chart you are well prepared to decide where to make an
investment. Should you hire for a specific weakness? Which team members get
what training? Can we run peer mentorship? Do I have unchallenged experts who
have no room to grow? Your answers are straight-forward now.

Yep. Whoosh. The whole idea of a strategy like Moneyball is that answers are
not straightforward. Moneyball is all about intuition vs. evidence. In the
case of the A's, intuition seemed to trump evidence, but the author keeps
telling us to collect more evidence (in the form of matrices, skill trees, or
whatever else). Not only is that the categorically wrong approach, it's also
not how you build good teams.

~~~
GavinMcG
I wouldn't have said that Moneyball is all about intuition vs. evidence, with
intuition trumping evidence. Rather the other way around: the A's acquired
talent that the _evidence_ suggested was underpriced, disrupting the
traditional intuition-based scouting approach. It seems like you've got that
backwards.

~~~
dvt
I really disagree, and I Podesta would also:

[1] [https://www.psychologytoday.com/blog/plato-
pop/201109/moneyb...](https://www.psychologytoday.com/blog/plato-
pop/201109/moneyball-it-s-intuition-vs-evidence)

[2]
[http://www.datacenterknowledge.com/archives/2011/09/23/the-l...](http://www.datacenterknowledge.com/archives/2011/09/23/the-
lessons-of-moneyball-for-big-data-analysis/)

According to Podesta: "Subjectivity ruled the day in evaluating players ... We
had a completely new set of metrics that bore no resemblance to anything you’d
seen. We didn’t solve baseball. But we reduced the inefficiency of our
decision making."

~~~
GavinMcG
That supports exactly what I was saying: "In the competition between intuition
vs. evidence, evidence wins."

So it's not clear why you are saying "In the case of the A's, _intuition
seemed to trump evidence_ , but the author keeps telling us to collect more
evidence (in the form of matrices, skill trees, or whatever else). Not only is
that the categorically wrong approach, it's also not how you build good
teams." (Emphasis mine.)

~~~
dvt
Evidence may or may not win (that wasn't my point), my point was that
Moneyball favored intuition over evidence. Even Podesta concedes that. So
using it as the example in the original article makes no sense.

~~~
GavinMcG
> Moneyball favored intuition over evidence. Even Podesta concedes that.

Both the articles you've linked contradict you. _Traditional scouting_ favored
intuition over evidence. DePodesta and the _Moneyball_ approach turned that on
its head, favoring evidence.

> DePodesta: “We said ‘unless we can prove it, we’re not going to believe
> it.’"

------
StreamBright
These topics are orthogonal. You can hire the best and build teams at the same
time.

~~~
bdg
I agree with that. I attempted to describe a way for a company to improve
throughput that isn't simply "hire the best".

------
Macsenour
Boss: I only want to hire the guy who worked on XXXX Project. me: That project
was 2 years late and 1.2 million over budget. Boss: Still, he did something
right.

------
Bahamut
Going to paste this here: [https://www.nytimes.com/2016/02/28/magazine/what-
google-lear...](https://www.nytimes.com/2016/02/28/magazine/what-google-
learned-from-its-quest-to-build-the-perfect-team.html)

------
Kenji
If you say "the best" that also includes being good at teamwork. Great
programmers write great interfaces anyway and are highly flexible.

