1. PeopleHacks
OSCON 2007
Adam Keys
http://therealadam.com

2. What are People
Hacks?
PeopleHacks sounds evil. Manipulative and mean-spirited. Like what the CIA does in movies.
Or even more cruel, what teenagers do to each other in movies (Mean Girls anyone?) But
that’s not what People Hacks are about. People Hacks are tools of advocacy, mind-moving
and learning to get along.

3. Why do people need
hacking?
Its a fact of the world that you’ll have to interact with humans. Not all of them will prove
friendly to your cause. Sometimes, you will want to grab them by the shoulders and gently
shake some sense into them. Sometimes, you’ll find yourself just talking past the person on
the other side of the conversation. Often, the other person wants to agree with you, but they
need some simple reassurance.

4. Why must I hack
people?
Didn’t we get into computer programming so we can spend all our time with perfectly
rational machines rather than irrational people? Well, the days of cowboy coders building
their hardware, operating system, toolchain and applications have passed. These days, the
name of the game is collaboration. And that means interacting with people.
To me, software development is fundamentally an endeavor of communication. We get sorta
caught up in the fact that the “most important artifact” is executed by a machine. But really,
projects run for the purpose of the machine usually don’t go o too well.
Take a second to reflect on your work in Open Source. How many of the triumphs are really
focused on your programming feats and how many are really about recognition of your peers
about your programming feats or recognition of your awesome ideas?
All these point me to the fact that adeptness at interacting with machines is at least as
important as your interaction with programming languages, operating systems and the
like.

5. Problems without
technical solutions
Unfortunately, some problems don’t have technical solutions. Open Source licenses are a
great example. There just aren’t that many reasonable ways you can encode the logic of
publishing your code once you distribute and app linked to it. So you write a license, and
encourage people to adhere to it. And then you encourage over and over again.
Its hacking people, moving their minds. Advocacy you might say. We’ll dive into that a little
bit later.

6. $ man humans(1)
We’re folks who have trained ourselves to maneuver through layer upon layer of abstractions,
pure thought stu. We hack our kernels, our hardware, our text editors and our web pages.
We’ve got specs, API docs, READMEs, etc.
But there’s no README for humans. It was, to me at least, all trial and error. And usually its
colossal failings that get you to step up and try to figure out how you can better interact with
people.

7. Episode 4
Getting Along
Let’s start our journey with some ideas about how to simply get along with those around you.
This is sometimes the hardest part. The act of socializing is often not as appealing as writing
code or tinkering with a new kernel. However, I’ve found my eorts are usually repaid
tenfold.
The other side is that, despite our best intentions, sometimes we behave in ways that aren’t
constructive to furthering whatever project we’re involved with. This is in many ways trickier
to correct, but its really critical to do. So, let’s dive into a few ways we can level up our ability
to get along with people so we can kick ass at raising the bar on our projects.

8. Emotional Hacks

9. Emo kids
Emo kids. They’re like the new dick and fart jokes; always funny!
Emo kids are the opposite of what we want. If you put people in an emo-kid state of mind, it
will be hard to work with them. That means it will be hard to advocate new ideas and it will
be unpleasant to be around them.
Do not want.

10. Emo kids
[x] Do not want
Emo kids. They’re like the new dick and fart jokes; always funny!
Emo kids are the opposite of what we want. If you put people in an emo-kid state of mind, it
will be hard to work with them. That means it will be hard to advocate new ideas and it will
be unpleasant to be around them.
Do not want.

11. Get a smile
It could be the case that I am exceptional. I love getting a rise out of people. Its the
foundation on which I base my advocacy. Its a lot easier to change someone’s mind or get
them to do something if they like you first.
Also, human emotions are infectious. Sit-coms have a laugh track for a reason. If you hear
one person laughing, odds are you’ll laugh too. So if you can get one person to smile, maybe
you can get two. Or four, eight, etc. Pretty soon the whole room is on your side and you can
move them in really interesting directions. Like trying a crazy new distributed source control
system or some fancy web framework.

12. Anti-pattern:
negativity
Like I said before, human emotions spread amongst folks within eyeshot. And ill-feelings
spread like wildfire. How many times have you seen one person get a little on-edge
responding to a mailing list and then the thread is just worthless after that?
Negativity is best avoided. Negativity is often just lazy. Rarely is it the case that you can’t get
your message across without flaming, insulting or criticizing.

13. The ABBA method*
*May not work for ABBA fans
That said, a little negativity goes a really long way. Like ABBA. So I suggest that whenever
you’re thinking of going negative, listen to some ABBA. It might put you in a better mood.
And if not, well at least if you’re negative all the time, you’ll have to listen to ABBA a lot.
This advice may not work for fans of ABBA.

14. Criticism
Let’s talk about criticism. Its a powerful tool amongst human relations. Its very, very
deterministic. It gets people up, gets them moving. Everyone loves a critic.
So my advice to you: don’t use it.
Well, that’s the simple way to put it. Criticism is best served to those you know very, very
well. You need to know they can take it. Otherwise, you’re just going to put the other
person on the defensive. They’ll withdraw from the conversation, and then you’re going
nowhere. A turtle with his head in his shell goes nowhere.
Or worse, the person may start to simply oppose you on principal. Not useful.

15. Criticism
Let’s talk about criticism. Its a powerful tool amongst human relations. Its very, very
deterministic. It gets people up, gets them moving. Everyone loves a critic.
So my advice to you: don’t use it.
Well, that’s the simple way to put it. Criticism is best served to those you know very, very
well. You need to know they can take it. Otherwise, you’re just going to put the other
person on the defensive. They’ll withdraw from the conversation, and then you’re going
nowhere. A turtle with his head in his shell goes nowhere.
Or worse, the person may start to simply oppose you on principal. Not useful.

16. Complement before
criticism; no schism
If you must criticize someone who isn’t right in front of you and with whom you don’t already
have an excellent relationship, there is one card you can play. Give them some love before
you drop the tough love. Kiss their ass before you hand it to them.

17. Jerks
In Open Source, we seem to have a love-hate relationship with jerks. For the most part, we
have little tolerance for them in the form of trolls, comment spammers and those who game
sites like Digg.
On the other hand, we tolerate jerks if they are highly capable. You can probably choose any
Open Source project you’ve worked on or utilized and find some incredible coder who is also
a glorious asshole.

18. The No Asshole Rule
I just finished reading this book. Its about the tremendous negative eects assholes –
abusive and demeaning people – can have on an organization. Its very unapologetic; its take
is that you should get them out of the organization as quickly as possible, showing no
remorse.
Some folks from the Subversion project have a great talk on this – they call them poisonous
people, but its all the same. Jerks aren’t cool, so just don’t tolerate them.
So yeah, if you’ve got folks who are making your life dificult project-wise, `kill -9` them.
The Subversion folks have all sorts of tips on how to do this.
Next, make sure your project or community has a zero-tolerance policy towards abusive and
demeaning behavior. Of course, you have to approach enforcement somewhat gently to avoid
violating the rule in enforcing it, but always working from a perspective of respect can do
worlds for your productivity.
Finally, if all else fails, route around your local jerk. If you lack the clout to oust them or they
represent all the knowledge in your project, find ways to make progress without going
through them. Give them an isolated subsystem and don’t pay much mind when they unload
on you. Form a support group for those around you when the jerk strikes, you can turn those
frowns upside down.
I apologize for using the phrase “turn that frown upside down”.

19. Sanity check
Let me tell you why this presentation came to be. As it turns out, I’m a recovering jerk. Just
ask around, I’m sure you’ll find someone. I do, after all, have ex-girlfriends.
So, yeah, I’m recovering. Hard part number one: figuring out you’re a jerk and deciding you
would like to cease this pattern. Hard part number two: realizing you’re being a jerk, at the
moment you’re being a jerk.
Easy part: do an OSCON presentation on how to not be a jerk!
So far, all this not being a jerk and “People Hacking” is going well and I highly recommend
reforming yourself if you’re thinking about it. Its good for you in addition to those around
you and your long term career and health.

20. Episode 5
Moving Minds
OK, so now we’re on the road to recovery. The next level is to start using our new found
social adeptness to convince others that our ideas are really great.
This part of the talk is about advocacy. In the Open Source community, we seem to end up
doing a lot of it. In some ways it reminds me of the taunting that always proceeds fights
between Jedi and Sith. “Come to the dark side”, “no follow me on the light side and redeem
yourself”, etc. The dierence is that software and Open Source advocacy usually doesn’t end
in severed limbs. Thankfully it does involve a lot less lightning.
The key to successful advocacy, whether about philosophy or software design, is to work
from where the other person is and gradually get them over to where you stand.
I actually borrowed the general outline for this section from an article on Web Worker Daily.
That’s an interesting tip unto itself: base your advocacy on the eorts of others who have the
gone through it before you.

21. Understand the box
I like to start by understanding where the other person stands. This part is a lot like
gathering requirements from a customer. You need to understand the constraints of the
world they live in, the forces that are exerted upon them and where their pain currently is.
This will save you tons of wasted eort. As much as you may want to help people, folks
building their system in C are going to have a hard time using metaprogramming facilities
and those working on .NET systems are going to have a really hard time adopting Solaris.
So, grokking the context of the person you talk to is critical. You can’t really ask someone to
think outside of their box before you understand their box and why its shaped as it is.

22. Go slowly
Patience. Its just not a fun skill. But its absolutely critical if you’re trying to change the way
people go about their endeavors. Humans are conservative creatures; most don’t want
constant upheaval in the way they go about their life.
So when you’re advocating change, you need to go slowly and lay out a gradual plan for them
to get from their current place of pain or non-enlightenment to promised land.
Its also worth noting that dierent people have dierent rates of change. Even for dierent
parts of their life. Let’s talk about me, for example. You put a programming language or
paradigm in my face, and I’ll definitely hear you out, probably even try it out. However, if you
insist I try some new food, I will promptly shut you down. I’m very progressive in trying out
new software, but very conservative in trying new foodstus. This never seems to make
sense to those around me.
Which points to another important thing to keep in mind. People are stubborn, like me and
food. I’ll come back to working around “personality anti-patterns” like that in a little bit.

23. Prepare for the tough
questions
Its inevitable people are going to ask you questions. This is a good thing; it means they’re
not completely apathetic to what you’re saying. Answer them with patience and a smile and
you’ll get a lot closer to where you’re leading them. But, there are two sorts of questions you
need to prepare for in particular.
The first sort of question is what my boss often calls “stump the vendor.” Whether you’re
really a vendor or not, they’re questions aimed at shooting you down or exposing flaws in
what you’re saying. Usually they come in the form of asking how some bizarre corner-case
works. You’ve got two ways to come about this part. First o, you can prepare for them and
make sure your demo or pitch is well-suited to dealing with the corner case.
The second way is to straight up acknowledge that they’ve pointed out a rough spot. From
there you can tell them how one might route around that rough spot in the product or idea.
You could always shout them down in a 37 Signals style, saying that you don’t think that’s
very important, but you gotta have real stones to pull that o; plus you run a serious risk of
completely failing at trying to move their minds.
So the other manner of tough question is when they touch on the elephant in the room. Most
every idea or technology has some rough spot that the community would kinda like to avoid,
but inevitably has to deal with at some point. For Ruby, there’s the VM and Unicode support.
For PHP, there’s the whole PHP4 vs. PHP5 thing. For the GPL, there’s the question of how you
really support yourself with GPL software and the TiVo loophole.
I find that when the elephant in the room is brought up, the best tact is to just step out of
your advocacy shows and be as earnest as you can about the problem. So when people ask
me about Ruby performance, I say yeah, its not great. I tell them about the really promising
projects and when I think they may come to fruition.
The bottom line is that honesty and modesty go a long way.

24. Don’t be a maximalist
Allow me to be somewhat controversial. People who tell me that all the software on the
planet should carry the GPL license kinda irk me. They’re wonderful people; I just don’t think
that’s a reasonable stance. It fails to realize the realities of the box that I mentioned earlier.
You can zoom out on this specific instance to come to the notion that you shouldn’t be a
maximalist. It would be lovely if you could get your whole company to adopt an Open Source
license or adopt something like Python or Ruby for all new projects. But its highly unlikely
that is going to succeed in all cases.
To a large extent, advocacy and moving minds is about small victories. Get people to change
one little thing at a time, help them find success. Word of those successes will spread and
with luck, their change will accelerate.
But asking them to switch from the old way to the new way, everywhere, all at once, is just
shooting yourself in the foot.

25. Insinuate ideas
The best ideas I ever heard of were my own. Right? We all feel that way. Narcissism makes
the world go around, right?
We’re all most enthusiastic about our own ideas. So the ninja move here is to plant the seeds
of ideas in the minds of others and then let them introduce those ideas as their own later on.
Then you just smile to yourself and proceed to world domination!

26. Always remain positive
I can’t stress this enough. So I will keep stressing it.
People get defensive if you play the negative card. Defensive people are no longer looking to
move the bar – they are only interested in maintaining the bar.
Even if the sky is falling, you have to choose a place to start raising it.

27. Episode 6
Herding Cats
Not just for managers anymore!

28. Anti-patterns of
individuals
First, I want to look at anti-patterns of individuals. The idea here is to recognize people who
are tricky to deal with and give you some glimmer of hope on interoperating with them.

29. Stubborn
Like I said before, I am a fairly stubborn guy in the ways of new cuisine. Other people are
stubborn about their ways of working, about their choice of language or perhaps their
operating system of choice.
So I’ve found the most eective way to get me to try some new, weird food is to make me feel
like a hero. Play to my inner diva; tell me how awesome I will be if I manage to sample some
cuisine. It also helps to bury said new cuisine is something familiar. I’m not a big fan of
seafood, but if I obscure crabmeat amongst fried rice, I can bring myself to try it.
So the two tactics there are to make the other person a hero for trying something new and
obscure the fact they are in fact trying something new.

30. Know it all
We’re all familiar with this one. Someone who thinks they know everything there is to know.
They’re dismissive of anything you might tell them that is contrary to what they think. They
may actually know a lot, or they may know a little; they may be mostly right or mostly wrong.
Regardless, you’ve gotta play to their perceived knowledge. Saying “Jane, you ignorant slut.
This is the way it is...” will get you nowhere. The trick is to say something like “well certainly
you’re familiar with the fact that the Universal Frobnicator pattern has fallen out of favor and
the Specific Operator pattern has taken its place.” Always keep them in their happy place of
being the knowledgeable one and you stand a chance at working with them and even
changing their minds.

31. Teenage males
OK, here’s a classic anti-pattern. Your average American teenage male: brash, impatient and
righteous. Even worse, they are most often horribly wrong. But you can’t tell them they’re
wrong. Its just something they figure out later in life, that they were horribly wrong when
they were younger. I speak from experience.
Open Source and programming are unique in that we’ve got tons of teenagers running
around, many who are pretty accomplished technically. So the trick is to interoperate without
invoking their teenage angst hormones.
I’ve got two ideas about how you can work with this. First, you can hope to wow them with
your awesomeness such that they revere you a little bit; this tends to minimize their teenage
maleness and give you a fighting chance you can have a useful little minion ;)
If you can’t get them to reverse you, well you gotta try and be his friend. When he gets all
teenage angsty, just re-direct the conversation.
The imperative is to keep him from getting righteous and quoting Napoleon Dynamite: “Gah!”

32. Anti-patterns of groups
Next I want to look at dysfunctional groups and touch on how to refactor them into useful,
productive teams.

33. Cover your ass
Cover your ass, or CYA, is all about people watching out for themselves instead of the greater
good of the team or project. This can occur because they isn’t a system in place that would
cause them to care about the larger good; the incentive just aren’t there. The other reason I
think this culture occurs is because you have a negative feedback loop higher up in the
organization and no one wants to take the blame when the other shoe falls.
So there’s your solution right there: make sure people have an incentive to care about the
greater good, refactor the negative feedback loop and make sure you get the folks who will
never care about the greater good o the bus.

34. Alpha-oriented
I’ve been in teams where “team-work” really meant, “everything is done for the alpha dog.”
Some people are so charismatic or important that everyone ends up working for that person,
rather than working for each other as a team. This isn’t necessarily harmful if the alpha is
well intentioned; if the alpha is not, it has the potential to become disastrous.
So you’ve got two things to do here: work with the alpha to move emphasis onto the team
and then get the team involved in working with each other.

35. Bureaucracy
Bureaucracy, process-driven, turf-oriented all have sort of the same meaning to me. You
have silos of work, deliverables are tossed over fences, communication only happens due to
process.
This is where you need a team-wide meeting where you get people to just get along. Usually
bureaucracies arise because people aren’t that crazy to work with each other. So you’ve
gotta get them integrated, create a team jargon, inside jokes, etc. Once the team is
operating like a team, then the bureaucracy will probably start to fade away.

36. Coaching
I’ve become pretty obsessed with using the metaphor of a coach as someone who’s one part
manager, one part project lead and one part developer. On the one hand, he makes sure the
stu that needs doing gets done. On the other hand he gives direction to the eort. Finally,
he’s gotta be a former “player”, a guy who’s been there, or even better, is there right now.

37. Enable people to get
stuff done
The first critical quality I’ve observed is that great coaches enable people to get stu done.
You remove friction points, help people get on the same page and so on. Its interesting to
note there is organizational friction, like paperwork and email, but there’s also personal
friction. Mentoring folks on challenging gaps in their own workflow falls under the umbrella
of enabling people.

38. Make sure they can
have fun
Groups that have fun are more productive in the long term. Its not the fun that makes them
productive. Its the shared jargon and humor, the feeling of belonging, the pride in the group
identity that makes them more productive.
So I think an important function of anyone who attempts to coach is to make sure that fun is
had. Group lunches, field trips, leisurely outings, video game sessions are all great things to
consider.

39. Monitor the psyche of
the team
The last thing I think a coach should do is just keep an ear to the grindstone. The team
knows best how things are going. They express it with the verbal language, body language
and often comments in the sources.
The corollary to monitoring is tweaking to suit. Is the team a little down? Maybe its time for
some of that fun? Are they worried about something? Get everyone to talk about how to fix
it so you can remove mental friction to them working eectively!

40. Wrap-up

41. Homework

42. People
So who are some good People Hackers? Here are a few who immediately came to my mind:
Matt Mullenweg is probably the best I can think of. He’s very charismatic, subtle in his
advocacy and has moved many minds on many topics.
Kathy Sierra managed to go from zero to massively educating a lot of people very quickly.
David Hansson is a trickier topic. He’s a master of advocacy and moving minds, though there
are some burnt bridges in his wake. Still, he’s had a tremendous impact; he’s doing some
things worth contemplation and emulation.

43. Q: Can I ask a
question?
A:Yes

44. EOF