Os Keyshacks


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Os Keyshacks

  1. 1. PeopleHacks OSCON 2007 Adam Keys http://therealadam.com
  2. 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. 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. 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. 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. 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. 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. 8. Emotional Hacks
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. Episode 6 Herding Cats Not just for managers anymore!
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 40. Wrap-up
  41. 41. Homework
  42. 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. 43. Q: Can I ask a question? A:Yes
  44. 44. EOF