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.
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
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?
You can look past your individual contributions, story points, and closed tickets and ask your management team to help you understand the impact your work is going to have on the company.
You can improve your hiring process to help qualified folks audition for a spot on the team.
You can name, explain, and reward the traits and attributes that add to the team, rather than mirror an unquestioned set of technical capabilities.
You can push back and ask what someone means when they say “we only hire the best.”
You can help your teammates over the wall by helping find out what’s blocking them (a pull request review? A sticky bug? A failing test? Unclear product requirements?) and helping unblock them.
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.
