The Missing Stair in IT

2023-01-10 4 min read Devops
Photo by John Tuesday on Unsplash

There are missing stairs all over software development, and I’m willing to bet your organization, if it’s larger than the smallest of startups, has one. Do you know who it is? And if so, why do they still work for you?

What do I mean by “missing stair”? The Missing Stair is a concept that started in BDSM communities but quickly spread like wildfire across all sorts of nerdy or alternative communities. It was coined by blogger Cliff Pervocracy in their blog Pervocracy, and was coined to describe a rapist in the community. Everyone knew he was a rapist, or something like. But nobody wanted to kick him out of the community. He was like a stair missing from a flight of stairs: everyone knew to just step over the hole, but nobody wanted to fix it. Every so often, a new person would fall into the hole. “Aah yes,” everyone would say, nodding wisely. “That stair’s missing. You should just avoid it.”

I came across the concept in a blog by Captain Awkward which, if you don’t subscribe already, please do browse the archives and consider subscribing. She talks at length about geek social fallacies and how to rectify them so that we build safer, more healthy organizations. And what is a tech company but a geek organization with money involved?

Let me tell you about a past workplace, since I don’t want to out anyone at my current job. In one of my past companies (and I won’t say which), everyone knew the infra team was the Missing Stair. If you had to get an infra need satisfied, you would be instructed to make a ticket… and that ticket would sit in the queue… and sit… and sit. Months later, having moved on to a whole different project, you might get a curt message from the infra team demanding more information… and then it would sit again. They were too understaffed and overwhelmed to be able to do their jobs in anything like a timely fashion. The only hope for getting something you truly needed done in a timely fashion was to turn up at one of their cubicles with baked goods and a sob story. And then your ticket would be done… at the expense of whoever was next in line having to wait a little longer. Multiply this by a hundred and you had the problem we were facing.

In the book The Goal, the protagonist, Alex, goes on a boy scout hike with his son’s troop. (I promise this is relevant, if you haven’t already heard this story). He lets the kids order themselves in line, which results in the slowest hiker, Herbie, being at the very back. Alex kept having to double back and check on Herbie, while the faster kids waited impatiently up ahead at the designated rest areas. Finally, he had a bolt of inspiration: put Herbie in the front. The whole line could only move as fast as Herbie could go, after all; nobody could go home until Herbie finished the hike. Herbie’s slow pace effectively capped the rate at which the other kids could enjoy their hike. He likens this to his manufacturing plant, where under Lean Engineering, the whole line could only go as fast as the slowest machine. By buying a second of the slowest machine, he was able to produce real speed benefits, instead of the phantom benefits created by buying another fast machine and having it sit idle most of the time.

Usually in software development this is likened to ticket processing time. Your slowest tickets are a bottleneck for the faster ones getting done because they take up developer time. But it is also the case that engineering as a whole is like a big manufacturing line. The slowest department or person slows the work of everyone around them — and is also terrible for morale. Who likes not being able to get tickets closed because some asshole on the other side of the company won’t give you what you need? Nevermind that that “asshole” is drowning in more work than he should rightly be expected to complete.

Are you hiring software developers right now? Seriously, look at your open recs. My company is hiring at least three. But we all know where the missing stair is in our organization. I’m sure even the managers know at this point. How could they not? So why are we spending our money on more fast developers when a single addition to the missing stair team would enable so many to move faster?