Skip to main content

Ban Bullies From Your Teams

If any of you have dealt with a bully, you will be quick to tell me that the bullies we encounter day-to-day are not ON the team.  They are ABOVE the team, or parallel to the team, or in some position of authority, and that's how we notice them.  This is true.  A bully, or as Robert Sutton defines her, "an a**hole,"  is defined by the difference between how she "manages up" compared to how she "manages parallel and down."
From the excellent blog post at
 A bully uses her position of strength to behave badly towards people who can't stop her.  Some bullies simply lack empathy, and some actively enjoy inflicting pain.  This is a serious problem, not just a "personality detail" about an otherwise valued coworker or employee.  Sutton has a wonderful New York Times article about how, in contrast to the Donny Osmond position on the matter, "Bad Apples Infect the Tree."  Well, for Osmond, it was "the whole bunch, girl," not the "tree," but the thrust is the same.

Bullies are unfortunately very common in the working world, particularly at the top end of the executive chain.  Some of you may remember the 2011 Jon Ronson book which found that corporate CEOs are four times more likely to score as "psychopaths" on standard mental health exams than people in the general population.

Fair enough.  Part of the bullying picture is indeed that you need to take appropriate measures to avoid being victimized by a workplace bully.  As is so often the case, Europe is way ahead of the United States in enacting national laws to provide redress for employees against workplace bullies.  Even in the US, some workplaces have actual "No A**hole Rules," which spell out a corporate policy about bullying, and which help to make those corporations the type of places by which most of us would like to be employed.

But I'm not talking about that.  I'm talking about you, and about the teams you actually influence or directly control.  If you have jerks on your team, it's your responsibility to reform them or get rid of them.  And you need to take a hard look on who is setting the standard that creates the nastiness on your team.  Sticking with the fruit metaphor, the apple doesn't fall far from the tree.  (And by the way, as Adam Lashinsky's new book, Inside Apple, reveals, Apple isn't exactly nirvana as a work place either.  But I almost digress.)  Two important questions:

Are you hiring and encouraging bullies on your teams?  Quick self-test:
  1. Is everyone who reports to you routinely nice to you, and do they agree with all of your edicts decisions?  Seriously, you're always right?  You need to worry right now, and a lot.  Start by finding out:  are they equally agreeable to each other and to people below them in the pecking order?  Do you even know?  My fourth-grade teacher, Andrew F. Horan, always said, "flattery will get you somewhere," and it will.  Make sure when you are hiring that you include peer interviews in the hiring process--don't just make "an executive decision."  Include 360 reviews or "skip levels," where people talk with their boss's boss at least once per year, in your mix of self-improvement HR activities.  And for yourself as well.
  2. Beware of making "an executive decision," in general.  If you are a "servant leader," and even more if you are an ambitious go-getter executive seeking promotion in most normal US corporations, your role is primarily to understand what your teams are doing, to socialize it across your level in the organization, and up the executive chain, and to support it.  You must certainly be mindful about your delegation strategy, but in steady state, you should not need to insert "your touch" on every single thing produced by your team.  Don't criticize, don't nit-pick.  Offer improvements if something comes to mind, but otherwise just celebrate your team's achievements.  You should give ALL public credit for team accomplishments to your team.  You should never take credit.  Understand me--people will give you the credit anyway!  Unlike the "trust fall," which I can never learn to like, this leap of faith by you will always pay off immediately for you, and pay networking dividends in perpetuity.
  3. Include a "character screen" as a crucial part of your hiring decisions.  I can't reveal my patented character screen technique for fear one of you might one day apply to work for me, but the information is out there on the InterWeb.  Find it!
  4. Institute your own "no bullying" rule for the part of your world that you control.  Investigate and follow up on bullying reports involving your team.  Do not tolerate them.  Is it really okay to cut into the productivity of everyone Janet interacts with, just because she's the only one who understands the PowerPoint template?  Think this through.
Even more importantly, are you a bully?  What if, unbeknownst to you, YOU are actually a bully?  Sutton has a handy self-assessment you can take to check this out.  I can't believe most people I know would fail this test, but just to make sure, I recommend you take it just to make sure.  As Sutton says, all of us are jerks some of the time, so at minimum, take the test to see whether you might be inadvertently making someone else's life miserable just because you have more power than they do, and they're scared to tell you.  It will be impossible for you to stamp out bullying in your work place if you're the guy at the front of the group, and you're the one holding the pitchfork and the biggest burning torch.

Let's make the world a safer place for nice people.  Start today!  Ban bullies where you can, and start the process by taking a hard look at yourself.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …