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.

 

Dumb stuff we say to non-programmers

Nearly fifteen years ago, I left my home to serve a two-year Mormon mission in Minnesota and Wisconsin. But one does not simply walk into the “mission field”. They must first spend three weeks at the LDS Missionary Training Center in Provo, Utah, which is probably best known for its unlimited supply of Marshmallow Mateys.

In the sixteen-hour-a-day crash course of the “MTC”, one major recurring theme was on using language that is familiar to the listener, rather than Mormon terms and colloquialisms.

In fact, it’s quite easy to spot members of the LDS church that have had this training, as they tend to use terms such as “congregation” (in the LDS church, this is referred to as a “ward”), “lay minister” (“Bishop” in Mormon parlance), or “church responsibility” (known as a “calling”).

There are scores, if not hundreds, of such “insider” terms woven into Mormon culture.  Imagine my disappointment after joining the church at age 11, upon discovering that not only was there to be no steak at steak conference, but also that stake conference was a two-hour-long marathon of back-to-back sermons.

The LDS church knows what many of its members do not: that the language you use has the power to invite people to participate or to shut them out.

There’s no “PTC”

Programming has a much larger, much more deeply embedded intrinsic language, except there’s no Programmer Training Center where ambassadors from the world of programming are taught this essential principle. Perhaps there should be.

One of my regrets is that at a prior company I never got to hold a training session I’d planned for our development team, where our accountants would come talk to them in tax code, to convey a sense of what developers often sound like to their coworkers.

It’s not that insider language is bad. It’s quite necessary. The fact that police communicate urgent information via short, numeric codes actually saves lives. For the rest of us, our jargon provides invaluable shortcuts when discussing complex concepts within a group that has a shared background and a similar level of understanding. Developers, in their efficiency, cram oodles of meaning into words and phrases that sound like total nonsense to non-technical folks.

But even knowing this, I often catch myself spouting jargon and terminology that draws blank stares from less-technical people around me.

Terms that shut out non-programmers

It’s hard to keep in mind that you’ve accumulated your vocabulary over years, or even decades, and that people around you may not share that same type or level of experience.

But even more difficult is the mindset change that requires modifying, defining, or even skipping terminology to accommodate people that don’t share your technical background. Here are some terms that triggered a sense of being “locked out” of programming conversations or intimidated me as a new programmer:

  • Algorithm: That word’s pretty big for its britches, considering it just means “a solution” or “a way to get to a solution”.
  • Abstraction: It’s a great term for programmers, but “stepping up/back a level” may suffice for non-technical folks.
  • Interface: Another fancy way to say “the way two things talk”
  • Parse/parsing: Another great term that is tough to unpack. The closest I can define is “to digest”.
  • Boolean: It’s just true/false, except when it means something completely different.
  • Design patterns: I don’t know how the Gang of Four did it, but they somehow created a naming strategy that is 100% guaranteed to make a non-programmer’s eyes glaze over.*
  • Parts of your technology stack: Unless for some reason you need to explain a technology, its purpose, and its benefits and drawbacks, it’s not helpful to let non-programmers know you’re going to create a Git topic branch to migrate your denormalized serialized data to a REST-based document database while preserving your Solr indexes.

Those are just a few of many, many terms that can sound odd or intimidating to people. Even terms like “array”, “hash”, or “object”, which to programmers is like “flour”, “sugar”, or “eggs”, are an alien language to 99.9% of people.

Now, if you’re a developer, you may look at that list of terms that intimidated me and wonder why I didn’t just “get over myself”. I can assure you that most people, when confronted with unfamiliar language, are silently wishing for you to speak at their level (or worse, misinterpreting you or tuning you out entirely).

The danger zone: misunderstood terms

I could devote a whole, hilarious post to programmer jargon that non-programmers think they undersand (and before I was a programmer, I was sooo that guy). The danger here is that instead of tuning out, people may get a completely incorrect picture (think “steak conference”).

  • API: For a thing that basically means “how you talk to my software”, this is frequently misunderstood.
  • AJAX: I used to think this meant any interactivity on web pages. In all likelihood, so does your CEO.
  • Object-oriented: I literally once told someone I was pretty sure it meant programming directly with graphical objects, you know, like buttons and stuff.
  • Technical debt: This is too often used as “parts of the code I don’t like” rather than “remnants of the best way we knew how to solve problems at the time”. So nontechnical decision-makers often discount the entire concept.
  • Refactoring: To you, it may mean “We’re paying down some of this high-interest debt.” To a stakeholder it means “I won’t get anything that I want while the developers play in a sandbox.”
  • Scalable: To me, this means “able to handle occasional traffic spikes” while a stakeholder thinks it means “racks and racks of stock-photo-style servers, ready and waiting for our inevitable million users.”

In my opinion, these terms are fine, with the only trick being to make sure you toss in your definition to check that you have a shared understanding.

My favorite programming metaphors

There are some programmer colloquialisms that I will never apologize for. And in fact, each time I explain them to non-programmers, they’re grateful for having them in their lexical toolbelt. They’re also great because each tells a specific story:

  • Yak shaving
  • Cargo culting
  • Bike shedding

If you’re not familiar with all of them (or even if you are), Matt Nielsen has written a terrific, laugh-out-loud funny post defining all three.

A path forward

Developers can’t even agree on the definition of terms among themselves, so what hope have we for a shared understanding with our non-technical cohorts? Well, like all language, it matters less what the terms mean and more what the shared understanding is of the people who are communicating.

Half of the solution can be handled by good process, and half is deeply personal.

Solution part 1: Shared definitions

Extreme Programming (guitar solo squeeedleedeedleedeee!) predates my career by a wide margin. But I love the concept of the “Metaphor” principle, which is similar to the “ubiquitous language” principle in domain-driven design, which advocates for a shared set of metaphors and language between the stakeholders (the problem definers) and the developers (the problem solvers).

I also think that non-developers and new developers are more than willing to meet somewhere in the middle. Stakeholders are quite happy to pick up technical terms when they’re core parts of the business or when they save time.

In my experience, the best results come from starting to reach out and show an interest in a business domain’s language, then slowly walking folks toward the technical implementations, bit by bit.

Solution part 2: Conversational empathy

The other half is in developing a specific kind of empathy: learning to have a running thought that wonders, “How are the things that I’m saying coming across to this person?” In doing so, you are forced to think from the perspective of the other person, to imagine what they hope to get from the conversation, and to think about what you’re saying that might trip them up.

This is a personal struggle for me, as I delight in finding just the right word  to describe something, a habit that often irritates people with my ostentatious loquacity five-dollar-word jibber-jabberin’.

But I really do believe that by adding one extra layer of thought during conversations, and periodically sitting down with stakeholders to nail down business-domain terminology, a developer can become as effective a force for good as anyone in the organization.

*I want to come up with design patterns with awesome names. The Sandwich pattern. The Exploder pattern. The Hug pattern. Who’s with me?