Creation, Attribution, and Misogyny

One of the hidden, insidious, morally bankrupt things that repeatedly peeks its head above the slime in open source development is plagiarism - specifically, the lack of attribution.

We can have all the arguments you want about 'pirating' code and the like - this is not about patent trolls - and pirating code is stealing, but it's also not really the subject of this post. This post, instead, is about intentionally writing creators out of history - whether it's through intentionally omitting an author or reference link or by actively deleting it. Of course, it happens all the time and it's dishonest...and not in a cute "I'm a smuggler for the Rebel Alliance" kind of way, but in a .

Oooh, what's that? Open source is different - it shouldn't recognize any individual authors/creators/innovators? No, that is absolutely not the case, and writing them out of history is not only dishonest, it's misogynistic as well. That's right, I went there. If you are writing authors, creators, or innovators out of history, you're a sexist pig - and frankly, there's no other way to see it.

We must take sides. Neutrality helps the oppressor, never the victim. Silence encourages the tormentor, never the tormented.

Elie Wiesel

I hear people all over the world crying out in terror "I'm not a sexist pig, I delete (or omit) all creators, not just women". Here's the thing, though, in removing creators you are, at the least, maintaining the illusion and bias that many people have that women are not creators, and at the worst, actively promoting a hostile environment that dismisses and negates the contribution of women. Neither option is something which should invoke pride in our work.

Women are profoundly underrepresented in STEM. That's a simple fact. We can debate whether it's a pipeline problem (it both is and isn't) or whether STEM fields are hostile environments for women (they are), but ultimately none of those causes affects the outcome that women are underrepresented in STEM, and it isn't getting much better, folks.

Read this Twitter thread

Let's take a case in point, Nicole Sullivan started something nine years ago that is used almost universally today in user-interface engineering today, and not only is she not "Twitter Verified", many people don't even know her name, and Wikipedia even deletes entries about OOCSS.

I appreciate Nicole's contributions to the industry I have made my career. When I use her work - whether it's CSSLint or OOCSS - I point out that it doesn't come from me, and given my experience working directly with her while she was consulting for PayPal, I know she would act in a similarly ethical manner.

Attribution is important, and as my career has progressed, I've seen it growing in importance. As anyone who suffers from Imposter Syndrome can tell you, love/hate relationships with ownership and attribution of accomplishments is a very real thing, but it's something the entire tech industry needs to get a grip on...and it's something that very definitely eludes us.

One final thought - as someone who has led teams of engineers, including those working on projects that resemble Frodo and Sam's journey through the Dead Marshes, morale is something rather fragile. One of the easiest ways to boost morale is to give everyone on the team the sense that their contribution matters - to, as we used to say at PayPal (and eBay), keep it human. One of the easiest ways to keep it human is to afford each other the dignity of recognizing the creator in them. Of course, the opposite is also true - take that dignity away and morale will soon follow.

Related posts: Visibility and Obscurity, My Pen Is My Tongue

The Danger of Going Above and Beyond

In a recent interview I was asked to describe the last time I went "above and beyond" for the customer. It seems a fair question, after all, we want people working with us who are willing to "go the extra mile" to serve the customer, right? I want to say both "yes" and "no".

I'll begin this journey by saying that for me, this question triggered a bit of a flashback to my first job not long after university. I was engaged to develop and implement the user training program for a new payment system. I spent hours testing the beta version of the software on all the platforms it was offered and wrote both the user and instructor documentation (including creating the graphics). As the second employee (the first was the person who wrote the software) I also did a few other things - all user-focused - like creating the inventory and supplies management system and some support software our customer service people used. One day as I was having lunch with the COO (Chief Operations Officer) he shared with me two management (related) ideals he had followed since his days with the US armed forces:

1. Even if someone gives 100 percent - and few people give 100 percent to their employer - the most you will get is 80 and the other 20 percent of the time they will not be productive
2. Don't keep an employee after you hear them say "it's not my job"

We all need down time. Sometimes the down time we need is a break during the day after we've spent hours working a particularly complex problem (been there, lots). Sometimes the down time is a couple of days off after working 80 hours in a week (been there too...more than once). As managers and team members we need to recognize that none of us give 100 percent. Are there some team members who are "more productive" than others? Yes, and no. It's much more common that we're all equally productive, just producing different things. We all need to recognize more than our own contributions (or our own kind of contributions - contributions of team members with roles like ours) and we all need to adjust our perception a little so that we're not only recognizing the 20 percent others are "not productive" but our own 20-percent time as well.

That second bit of advice still seems harsh to me, all these years later, but I can see how that construct shaped my perspective after having been introduced at such an early stage in my career. That does not mean that I mistakenly think that anyone can do anything and that all members of a team are interchangeable.

Team members each have their own strengths and they're not interchangeable. To put this in role-playing game terms, all good teams need a rogue (to help the team overcome obstacles and protect the team from danger), a fighter (to take care of the danger when it comes), and a healer (to restore the team after a dangerous encounter). This same general format works whether you're crawling a dungeon or launching a product (more about that another time).

If, in the midst of danger, the rogue said "hey, it's just my job to tell you about the dragon, not fight it" the rogue may find that he is crunchy and good with ketchup. If, in the midst of danger, a healer who says "my job is to heal the bite and claw marks after the battle" may find that she does not survive that long. In the same way, an engineer who tells the dev ops team that a failure was caused by "something in the way the build was deployed, and that's not my job" when there's an issue is not likely to survive long - and rightfully so.

As I said earlier, I stepped out of my role developing and implementing the user training program to work on other, related customer-facing issues at that first job. Was that going "above and beyond"? Some might say yes, but the correct answer is "no, not really". Was it going "above and beyond" when the COO instructed me to act as courier to redistribute the workload for another department in the same company? No. My job is to serve the customer, and in this case, as in many cases, "the customer" was my employer.

One of the things we have forgotten, misplaced, or perhaps discarded is not the mistaken ideal that "the customer is always right" but the very correct ideal that the customer deserves satisfaction. There was a time when companies employed slogans that were some version of "whatever it takes" but now it seems we have descended into a "give us a good review on Yelp/Google/Facebook/<insert your marketing here>" approach and we have lost a portion of what we were.

And here I am, back at my original premise - saying both "yes" and "no" to "going the extra mile" - and so I'll sum up as clearly as I am able. As soon as you define something as "above and beyond" you've categorized yourself and everyone else according to your perception of both productivity and job description. That, my padawan, is a dangerous road. A road visited by those who are eager to steal your reputation, your customers, and your livelihood. Don't travel that road.

Happy coding.

Fear is the birth of cruelty and the death of reason, wisdom, and finally, action. (Robert's Rule #26)

Fear, as our 'leaders' have discovered, is a powerful motivator. For most people, one of the most powerful fears is of losing their job, in fact, for some people, the fear of the loss of their livelihood is even stronger than their fear of death, because it means something very significant to those who depend on them. Because of the power of this fear, employers the world over become some of the most powerful entities known. However, this fear comes at a price, for fear is the birth of cruelty.

When you, as a manager, threaten someone's job and engage this powerful motivator, your 'direct report' will likely tow-the-line. They will likely become quite complacent. They will also likely quit innovating, start protecting their assets to the detriment of the team, and start looking for a place of employment where they believe they will be respected, which means their productivity will generally plummet and they will become a drain on morale. In short, what you will have created is a negative reinforcement cycle that will likely spiral out of control.

On the other side of fear, however, the lack of fear is an equally strong motivator. The lack of fear can be the result of either having nothing more to lose or a true feeling of safety.

The lack of fear that is the result of having nothing to lose - that finds its origination in desperation - is dangerous in the extreme, as The Art of War notes. It is the recognition of this fact that has led companies to treat terminated employees as criminals as they are escorted from the building, often without even being given access to their personal effects. The creation of this type of 'enemy' is a mistake of the highest order and you should always try to maintain the appearance that even those discharged have something more to lose. Helping them move on to another position (if that is at all possible) is a good start. After all, just because they don't fit in with your organization that does not mean they would not fit in quite well somewhere else. If you can honestly, objectively review their contribution you will (nearly always) find some benefit they provided to the organization that you can leverage as they look for another position.

On the other end of the lack of fear spectrum - when a person feels safe in their job - people are more likely to take risks, stretching and growing. They are also likely to innovate, be more relaxed and positively affect team morale, in essence become a powerfully positive asset. It is the creation of these positive reinforcement cycles that we need to create. One of the most powerful effects of these positive reinforcement cycles is the energy they contribute to the team, as study after study has shown that 'winning' begets 'winning' and nothing so strongly counters winning than fear and trembling, because fear is also the death of reason, wisdom, and eventually, action.

Silence and neutrality enable oppression (Robert's Rule #11)

[Tweeted 2011-05-09]

Today's post isn't directly related to work experience...at least not for most people.

I grew up in the middle of blue-collar union country at a time when unions were strong. Members of my family would have never considered crossing a picket line. Why? In part because it feels good to know that someone has your back. Of course there's always the collective bargaining thing too...after all, it's usually difficult, not impossible but difficult, to oppress a large group of committed, active people.

History is full of examples of people who have stood up to those who oppress them. One of the most famous in American popular culture is the Molly Maguires (if you haven't watched the Sean Connery/Richard Harris movie you really should). I understand that the real history of the Mollies is a bit clouded, and also that history is written by those who win. However, instances of the oppressed standing against those who oppress them provides a valuable lesson that applies to all of life, both working and non-working life.

Because this lesson applies to both work life and non-work life, it's become one of the rules I strive to remember every day. Every day, silence and neutrality enable oppression (Robert's Rule #11), and every day we must combat it, because oppression brings everyone down to the lowest common denominator.

If you pay peanuts, you'll get monkeys as employees (Robert's Rule #2)

[Tweeted 2011-04-26]

One day, as I talked to a CEO-type friend of mine, we discussed salaries. This guy, for whatever faults or adornments his personality may have, is a shrewd businessman. His experience in labor relations and negotiating with unions back in the day has served him well over his career, and while a lot of employers complain about salary and benefit packages making up 60% or more of their operating expenses, my friend made his opinion clear -- if you pay peanuts, you'll get monkeys as employees.

Now, I've happily worn the label code-monkey more than a few times in my life, but I want to project absolutely clarity on this -- we are not talking about a code-monkey here, this is more of the "trained chimp" variety -- you know, as in "a trained chimp could [do x] better than [your insult target]".

Before you go off on some "monkeys don't eat peanuts" tangent, skip it. The metaphor may break down when compared to actual monkeys and actual peanuts...but ignore that for a second. While money breaks down as a motivator (watch Dan Pink's animated lecture), it actually works pretty well as a motivator up to a point where, as Mr. Pink says, you "take it off the table". When you think about it, that pretty clearly coincides with a few other theories, such as the Law of Diminishing Returns or Maslow's Hierarchy of Needs.

One of the things I find interesting around this rule is the idea of outsourcing. If the primary motivation for 'outsourcing' is to find a less expensive workforce rather than utilize some aspect of collective unconscious or first-hand cultural experience/knowledge to improve local market penetration (e.g. in language localization) or implement a 24-hour workday (e.g. to reduce time-to-market for defect resolution or improve customer service), you will get what you seek, because, and let me be clear about this, there is amazing talent outside of [insert your country here]. However, even as ingenuity, hard work, and skill do not recognize borders, neither do apathy and inattention. The bottom line in this regard is this...if you want something built cheaply you can find people to build it cheaply, but in the end what you have is worth less than what you paid.

There are exceptions that prove this rule -- people who are very highly skilled and highly valued by their employer who are receiving peanuts when their monetary compensation is compared to what they would receive from other organizations. In the estimation of these exceptional people, their compensation package is not 'peanuts' -- likely because they receive significant non-monetary compensation (at this point, if you haven't watched Dan Pink's lecture, you really need to watch it).

One of the other things I find interesting around this rule is it's corollary -- if you're getting paid peanuts it's time to determine whether or not you're a monkey. It's likely that I find this interesting because it reflects a pivotal point in my career when an employer, many years ago, tried their best to convince me that I was little more than a trained chimp while I was certain that was untrue (and doubled my salary by changing jobs to prove it). Of course it could have just as easily gone the other way...I could have been little more than a trained chimp fresh from university, and likely was. Diligent practice made me better than I was and, hopefully, that will continue.

Oh, and for what it's worth, no monkeys were harmed in the writing of this post...in fact, no actual monkeys were used in any way.