Some people just can’t catch a break. It’s never their fault, but things just seem to go wrong around them. Projects spin out of control, bug counts skyrocket, hardware breaks, people quit. Whenever you look at a specific problem, there’s always a good reason – the scope was increased, the agreed-upon technology turned out to have major problems, their commit had a subtle interaction with unrelated code that caused a catastrophic cascade of failures… Any individual issue can be explained away, but the trend lines all point in the same, disturbing direction.
It isn’t actually that unusual to have someone like this on your team – likeable, hardworking, capable… And accident prone. Sometimes there’s an identifiable core issue that ends up causing a wide variety of problems (e.g., bad attitude, lack of testing, poor match for organizational style, etc.), but frequently it isn’t so easy. This is terrible all around – they aren’t succeeding, and it’s hard to figure out how to help them. Performance goals tend to focus on the symptoms – more automated testing, improved communication when issues arise, etc. – but these are bandaids, the equivalent of putting together a three ring process binder and hoping that the underlying problem resolves itself.
On the other hand, there are some people who seem, well, lucky. I’m reminded of one my coworkers from a prior job. She was a good, solid engineer – nothing flashy, but smart and dependable. You wouldn’t normally point her out as a star developer, but things just seemed to work out when she was around. People liked working with her. She wasn’t a mediator, didn’t get involved in disputes, but they just seemed to happen less often around her. She wasn’t a manager, didn’t have a formal leadership role, but projects ran smoother when she was involved.
Magical Thinking
In Blink, Malcolm Gladwell recounted the story of Abbie Conant, a trombonist with the Munich Philharmonic. When initially trying out for the position of first trombonist, her audition was performed behind a screen, and her interviewers were effusive in their praise (the music director cried out, “That’s who we want!”). It was only when she stepped forward and was revealed to be a “she”, not a “he”, that they realized their mistake. Women, it appears, aren’t supposed to be able to play the trombone, and they spent the next fourteen years first fighting to keep her out of the first trombone seat, then trying to suppress her salary. Go ahead and read the story, it’s fascinating and infuriating – but what’s the connection with this post?
The point is that people aren’t accident prone. They aren’t lucky. Things don’t magically break or work out when they’re around. There’s either a very specific competency that needs improvement (or at which they excel), or it’s in your head. That’s right. You’re an amazing pattern matching machine, and you’ll find a pattern in random events whether or not one exists. The problem is when you create a narrative to fit a set of data points, and don’t realize how your biases are affecting your judgment.
It’s easy to get caught up in a narrative, good or bad. It’s also completely understandable – there are a thousand things going on around us all the time, and using a heuristic like confirmation bias (the tendency to believe things that fit our preconceptions) is a great time-saving device. When it comes to people, though, it can lead you to create, then destroy, a golden child. Or it can prevent you from seeing progress from someone who’s on the mend. Lastly, it can make you look like a fool. There’s nothing like sitting in a performance review, spouting some “constructive criticism”, then realizing you have no examples to back it up.
What to do? You can constantly question yourself, but you’ll always be jumping at shadows, unable to make substantive judgments or decisions. Or you can write once, read many – blindly moving forward, never questioning a judgment once made (“thus also, a will to stupidity” – Nietzsche). The best method to combat either of these is a relentless dependence on metrics. How much is being accomplished? How accurate are time estimates? What about bug counts? Were the business results achieved? And so on. Depending on your tools and company culture, it can be difficult to gather this information – but once you have a way to get at it, you don’t have to rely on gut instinct, gossip, and out-of-date narratives.
Dan Dreams of Coding 