Your “high bar” is wrecking your team

Near the beginning of my technical career, I worked at a fast-growing startup. One afternoon, my CEO walked into our dev area, which is something he never did. Some people in snazzy button-downs and sport coats followed him into the room, tipping us off that this was likely a show-and tell for some fancy VC-type folks in hopes of raising our Series E (or F or P or Z, who can remember) round of financing.

“And here are our developers. Everyone on this team has at least a Bachelor’s in Computer Science from great schools.”

I tried not to let my eyes bug entirely out of their sockets at this, and continued with my work. There were a lot of degrees in that room to be sure, but unless Salt Lake Community College secretly awarded me an honorary BA in Bad Sonic Fanart, none of them were mine.

But, sitting there in my sense of inferiority and exclusion, I knew for a fact I was a valuable contributor to that team! Even as a new developer, I learned fast, collaborated, and played a big part in getting our software shipped.

So when I tried to bring other people onto the team, I felt confident the right thing was in looking for someone with those traits. So after bringing in a couple of candidates I knew would make a great contribution, I was surprised to find out that my boss passed on the candidates, calling them “journeyman developers” and “not up to our technical bar”.

The cycle repeats

That’s the first time in my career I’d heard the phrase “keeping the bar high.”

A few recruiter calls later, we’d managed to hire some “star performers” with impeccable resumes who dazzled us with whiteboard acrobatics, while actual work tended to seize in the face of office politics and interpersonal turmoil.

I was puzzled by this, until I saw this happen again at another job. And again, and again. At one job, a CEO would screen candidates’ CS degrees among schools to make sure that we didn’t let in riffraff from lower-tier Computer Science programs (worth noting: to work on a team that I ran).

This rather bizarre logic planted a question in my mind: why are so many companies in our industry fixated on setting and protecting a “high technical bar” when this makes their teams worse by all measures of output, product quality, team diversity, and turnover?

Who decides what the bar measures?

Maybe before we can answer that question, we need to ask: what does a “high technical bar” even mean? That phrase carries with it a self-important sheen of “rightness” and “intellectual rigor” even as it hides a mountain of bias.

It’s lunacy to think that a software developer could contribute along only one axis, but “the bar” is almost always set along exactly one: amount of exposure to a formal computer science education.

Almost every software developer in our industry with a CS degree will tell you they “dust it off” periodically for some classes of problem, while most of their day-to-day is work they learned on the job. But the majority of technical interviews still focus heavily on the skill of solving algorithmic problems on a whiteboard or demonstrating the ability to classify algorithms in big-O notation.

That’s why all these “mastering the tech interview” blog posts and books are filled with back-of-the-book solutions to common computer science algorithmic puzzles.

So you have a “high technical bar” that you assess via puzzles whose solutions can be memorized from a “hacking the interview” book. Cool, let me know how that works out.

Maintaining the high

Congratulations! You’ve assembled your “Avengers of code” via puzzles, brainteasers, and discussions of esoteric language features.

We are a team of the best, because we only hire the best, because we have a high technical bar. QED.

And it just so happens that this reinforces the egos of team members, executives, investors, etc. At one company the CEO used to talk about how this was “the best engineering team ever assembled”, on repeat, despite zero evidence in the form of shipping software (and significant evidence to the contrary once that software actually did start shipping). Who wants to argue with someone telling you you’re the best?

But how do you keep this rolling? How do you avoid the other shoe dropping once the team is actually expected to ship working software?

Well, that’s where the shit starts hitting the proverbial fan.

Setting the bar on your team

bar-setting

Even after expectations move from “we hire only the best” to “where’s my software”, you’re still left with the residual effects of this culture of bar-setting. People in these cultures tend to “set the bar” for each other and expect their team members to jump over it.

This means people on bar-setting teams are sitting with their arms folded, waiting for candidates, and ultimately their teammates, to fail their expectations. And when they inevitably do, we “flip the bozo bit” and ask why we have “B players” on our team.

It’s hard for me to imagine a less healthy environment than one where a group of people sits waiting for their teammates to fail them in some as-yet-unimagined way, but this culture is very real and very common.

Helping each other over the walls

wall-boosting

The frustrating thing about this tendency toward setting each other up to fail via artificial bar-setting is that there are very real walls that we as members of a team need to climb over to get our products out the door and solve real-world problems.

We have deadlines to hit, bugs to fix, logs to read, 1 AM pages to answer. We have customers to serve, teammates who need our help, and yes, in some cases, investors to impress at the next board meeting.

The least productive teams I’ve seen are so focused on whether their teammates should be there in the trenches with them that they aren’t focused on the fact that they’re all on the same side of the battle. They’re so fixated on making sure every hire is a CompSci superstar that they can’t see the prismatic rainbow of skills it takes to design, ship, and support software that withstands the harsh realities of real-world use.

The most productive teams I’ve been on are the ones who are pulling each other over these walls in the battle against real-world problems. No, that doesn’t mean that you can pull 10 random software developers together and have an ideal team, but I’d rather have 10 random developers who are in it for each other than 10 superstars who will bar-set each other to a standstill.

A note on “lowering the bar”

One phrase in hiring I dislike more than a “high technical bar” is “lowering the bar”. This one is more insidious, more intellectually dishonest, and drips with even more gatekeeping bias.

It’s almost always used to avoid having a conversation about including a more diverse set of folks on a team. “We want to include more diverse folks but we don’t want to lower the bar,” means a team is considering a candidate that might bring something different to the table but that “something different” is not measurable on their yardstick of Computer-Science-derived technical merit.

I think that often, these people aren’t really worried about a “lower bar” as much as the ego-threatening possibility that their formally-trained “hard skills” could be comparable to, or *gasp*, less valuable than, informally-learned “soft skills” like mentorship, compassion, leadership, or collaboration.

I know a lot of people who have a formal CS background who deeply value the skills along these other axes, and I have never heard any of them express any concern about “lowering the bar”. Just saying.

Bar-setting is a failure of management

If you find yourself on a team of people who are setting a bar for each other rather than helping boost each other over walls, it doesn’t mean the people on the team are bad. It does, however, mean that your management is definitely failing you.

What you are likely dealing with is a team that is incentivized to tear each other down rather than deliver a result together. Your management is failing to help you find and focus on a shared purpose beyond “managing the optics” of your individual performance.

If you look around and you don’t see people who are different from you, from different backgrounds, it’s likely your interview process tends to select the same “high performer” over and over again. Your management is failing to value the variety of skills it takes for a team to create and support a product.

So what can you do?

Whether you’re a contributor or a manager, changing culture is hard. Your influence may be limited. So how can you help shift away from a culture of bar-setting?

And if these things are fundamentally out of alignment with your workplace’s values…

  • You can (hopefully) leave.
  • (And if you can’t leave, maybe you can start a support group)

Goodbye bar-setting, hello wall-boosting

On a healthy team, you won’t hear a lot about a “technical bar”, but you will see a group of people focused on a shared goal, helping each other over barriers, and getting software out the door. They’re not perfect, but they don’t need to be. They tend to focus on making their customers happy, learning from their mistakes, and helping each other get better.

I’ve worked on both kinds of teams, and I’ll bet my career on wall-boosting teams over the most talented bar setters. By starting small, you can create an example of success. With success, you just might get your team to buy in. With some results and buy-in from the team, you can teach your team’s leadership that larger-scale cultural change is possible.

Who knows, if enough of us can show off what collaborative, supportive, inclusive teams can do, maybe we can bend the arc of the industry in that direction. It’s worth a shot.

 

Why I love grumpy developers

photo by spdracerkmw via Flickr

Edit: I wrote this post 3 1/2 years ago, but never published it for reasons. But I like it so here goes:

I’ve already posted about the developer who took me aside and introduced me to programming.

But there’s a part of that story I have never publicly talked about, because it’s pretty embarrassing. But I think it’s important to share.

The lead developer at the startup I’d been doing marketing for was sort of a polarizing figure within the organization. He was brilliant beyond description and fiercely loved by his team, but some of us outside the  development team labeled him as “arrogant”, “aloof”, or worse.

Certainly, there was some tension between marketing and development, and I was the worst of them. I mistook the lead developer’s emotional distance for a lack of feelings and felt justified in criticizing him.

One day, I made a point of excluding him from a group lunch, making snide remarks about why I didn’t want him there. Inevitably, I found out later that he had overheard my cutting remarks.

Not long afterward, he confronted me and asked what my issues with him were. I started by trying to justify myself, and eventually realized, with no small amount of shame, that there was no good reason for my feelings and actions, and I apologized. We decided to try and “start over” with our professional relationship.

Well, if you know me or read this blog, you know how it worked out: He introduced me to programming and became a trusted mentor and one of the greatest influencers in my life.

Grumpy != unkind

Since then, I’ve discovered that many of the most fascinating (and sweet) developers I’ve met are often mislabeled as grumpy.

Before I go on, it’s important to make the distinction between “grumpy” and “unkind”. I am not talking about people who act like jerks, and tear down others or their work to make themselves feel superior.

I’ll use the term “grumpy” in this article to point out a common public perception, but in no way do I endorse using it to actually describe a category of people.

I’m talking about makers who are often perceived as “prickly”, “not communicative”, or “aloof”. Developers who growl a bit when an arbitrary timeline is imposed on a project, or when dragged into yet another multi-hour meeting.

I’ve now had a few years of experience in this arena, and the developers people sometimes label as “grumpy” often become some of my favorite people. Let me try to crack open a few misconceptions.

Misconceptions about “grumpy” developers

Grumpy developers are not mean.

In fact, they’re some of the kindest souls you’re likely to meet. I’ve had several developers labeled as “grumpy” (or worse) take me under their wings as I was learning, encourage me, and patiently answer my ridiculous questions, all with no expectation of reward. And I have heard this from many, many others.

Grumpy developers are not cynics.

They generally distrust people who have something to gain from taking advantage of them. Many manager-types will set deadlines, promise features, and use flattery, intimidation, or both, all in service of extracting every ounce of their worth. This leads to a guarded state that is often mistaken for cynicism.

Grumpy developers are not egotists.

The best developers have at least a glimpse of their own capabilities. They know that when faced with a problem, however unknown or difficult, it is merely a matter of time before they will have the problem solved. Far from ego, this is actually a valuable form of optimism!

Brad Pitt is in this commercial. Brad Pitt is not a developer.

Grumpy developers are not loners.

They often crave connection but may avoid crowds. They’ll choose deep, one-on-one communication over sitting in a group, laughing and enjoying life like some kind of Pringles commercial. And sitting in meetings is like the world’s lamest Pringles commercial.  So don’t be surprised when they turn down a meeting invite or “team building exercise” so they can get back to work.

Grumpy developers are not lazy. 

Experienced developers quickly learn to hate repetitive busywork. So if you have a backlog full of repetitive, menial tasks, prepare to have them stack up. But these same people will frequently work a second shift after “office hours” just to have uninterrupted work time. That doesn’t smack of laziness to me.

Grumpy developers are not pedants.

True, some developers can be pretty pedantic at times. But the “grumpy” developers are usually neither dogmatic nor pedantic when they glare over their glasses at you when you try to check in code that is poorly tested. They are wincing inside at the pain that both you and they will soon feel as a result of bad coding decisions, and they’re not shy about correcting the problem.

Grumpy developers do have feelings.

The most shocking thing to me is how much people (myself included) feel justified taking potshots at higher-profile developers, especially ones who maintain large open-source projects. No matter how accomplished, people still have feelings, and it can be difficult to remember that when we disagree with them.

Why do people label developers as “grumpy”?

I think it’s primarily for one reason: Grumpy developers do not suffer fools.

So then… what constitutes a fool?

Imagine learning that an application in widespread use had left in obvious, gaping security flaws that could compromise the data of all its users. You’d be obligated to say something, right? You might even be angry with someone who would ship software that endangers its users in this way. The person who let this happen is seen as a fool.

The person who does no cursory research before offering criticism or asking a question is seen as a fool.

The person who makes politically-motivated, short-sighted promises is seen as a fool.

The person who hamstrings developers by trying to get them to conform to the manager’s schedule is seen as a fool.

The person who cannot take criticism, who choose preservation of ego over self-improvement, is seen as a fool.

These people generally receive no quarter from “grumpy” developers. I’ve been the fool many times before, and will many times again in the future. The trick to this is not to take it personally, but to dig for the source of frustration. You’ll find it isn’t personal and is usually easily rectified.

Maybe grumpy developers are just tired. 

So here you have this group of highly-skilled, self-motivated people athat are fully aware of their own capability. And then they’re dropped behind enemy lines to sit in meetings, fill out forms, re-answer the same set of questions, and rapidly switch contexts, all while trying to carve out enough time to ship software.

And I think this generally applies to people in all creative fields. Would it be a better world if all these grumpy makers-of-things woke up with a newfound sense of “customer service”? Maybe, but I’m not convinced. In professions that require hours of solid concentration, there is a heavy penalty to be paid for being overly accommodating.

The secret to getting along with “grumpy” developers

As I mentioned earlier, I think a good start is to avoid affixing labels like “grumpy”. However you perceive their disposition, they’re people with feelings and a lot they want to offer the world.

There’s one developer in the Ruby community who’s somewhat legendary for being prickly, and I recently heard a story about him taking several brand-new developers under his wing to mentor and guide them. This has been my experience as well: many of the greatest kindnesses I’ve been shown as a developer have been from people that are often labeled “grumpy”.

Like so many things in life, the secret is not to flatter, coddle, or kowtow, but to be more interested in them as fellow humans than in what you can get from them.

(Incidentally, when you call devs “rockstars”, you really mean “racehorses”: they’re superstars now, but someday they’ll wind up at the glue factory.)

So the next time you label a developer as “grumpy”, perhaps take that as a signal that you might actually want to stop and really get to know this person, this fellow traveler in life’s journey, a little bit better.