Stepping-Aside-As-A-Service

What a half-second of small talk taught me about my own factory settings

A few weeks ago I was at a business networking event, doing the thing you do after the formal part ends, which is stand near the coffee and make small talk with strangers while deciding whether your social battery has one more conversation in it. Mine did, as it turned out, and the conversation was a good one. I struck up a chat with a woman who had built a successful virtual assistant business. She knew her market, she knew her numbers, and she talked about her clients the way good operators talk about their systems (with affection and a complete absence of illusion).

I happened to know someone else in that exact space, a man in my network who was becoming a recognized leader in virtual assistant services. So I did the networking thing. I recommended they meet. Collaborate, maybe. Share ideas, at minimum. And then I heard myself say it: “There’s a lot he could show you.”

I caught it the moment it left my mouth, the way you catch a bad config change the instant after you hit enter. What I meant was “I want to see you succeed.” What I said was “here is a man who can teach you about the business you already built.” She had the successful company. She had the track record. I had positioned her, reflexively and without a moment of conscious thought, as the student.

I have spent more than twenty years in technology, most of it in leadership roles of one kind or another, and I want to be precise about what that sentence was. It was not malice. It was not even a belief I hold, in the sense of something I would defend if you asked me directly. It was a default. It was the factory setting talking, the firmware I was shipped with, doing what defaults do, which is execute silently whenever nothing overrides them. I have been working on overriding them for years. The sentence was a status report on that work: incomplete.

This is the part of the conversation about privilege that I think the technology industry, my industry, is actually equipped to understand, because we already have the vocabulary. We know the difference between a one-time install and a service. Boxed software was something you bought once, ran until it broke, and felt no further obligation toward. The whole industry moved away from that model (to SaaS, to subscriptions, to continuous deployment) because we learned that anything worth running is worth maintaining, and that maintenance is not an event. It is a posture. It has uptime requirements. It gets patched on a schedule, not when the mood strikes.

Most of what passes for allyship in leadership circles is boxed software. The one diversity panel. The single mentee. The statement issued the week everyone else issued one. You install it, you point to it, and you consider the matter handled, the way we used to consider a server handled because someone racked it in 2009. And like that server, it is quietly accumulating vulnerabilities the whole time you are not looking at it.

What I have started calling Stepping-Aside-As-A-Service is my attempt to take the other model seriously. The premise is simple. If you are someone like me (white, male, a couple of decades into a career where the doors opened so smoothly I rarely registered that they were doors), then the most useful thing you can do with your position is not to occupy it harder. It is to treat the redistribution of access as a standing service you run, with the same expectations you would put on any production system. Always on. Actively maintained. Monitored for regressions.

In practice it looks unglamorous, which is how you know it might be real. It is recommending the woman as the expert, not the recipient of expertise. It is hearing about a conference slot or a podcast invitation and asking, before you say yes, who would be better than you, and meaning the question. It is saying her idea was the load-bearing one in the meeting where the credit is being distributed, specifically in the meeting, where the record gets written, rather than privately afterward where it costs nothing. It is making the introduction and then getting out of its way, because an introduction you stay in the middle of is not a bridge. It is a tollbooth.

And it is the monitoring, which is the part my networking story is really about. Because the failure mode of any long-running service is not usually the dramatic outage. It is the silent regression. The thing that used to work, that you believed still worked, drifting out of spec while the dashboard stayed green. I believed my deprogramming was further along than it was. I had read the things, examined the assumptions, done the deliberate work. And then the default fired anyway, in a half-second of small talk, in a sentence I did not plan, which is exactly where defaults live. You do not find out what your system actually does under load by reading its documentation. You find out in production.

What I did next was the only part of the story I am at all proud of. I patched it live. I went back to the sentence and reframed the introduction the way I had actually meant it: two successful operators in the same space who might sharpen each other, with as much for him to learn from her as the reverse (and, given whose business was further along in the ways that counted, possibly more). A small correction. She may not have even registered the original sentence; the people on the receiving end of these defaults have usually heard them so many times that one more barely produces a signal. But I registered it. The patch was for the system that produced the bug, not just for the output.

That, ultimately, is why the “as-a-service” framing matters to me, and why I am suspicious of any version of this work that comes with a completion date. A service does not graduate. There is no release where you declare the maintenance finished and walk away; the moment you do, the drift begins. The defaults I was shipped with were installed over decades, by a culture that was very thorough about it, and they do not uninstall because I have decided I am one of the good ones. Deciding I am one of the good ones is, in fact, the most reliable way to stop checking the logs.

So I keep the service running. I step aside, on purpose, on a schedule, and I watch for the regressions, and when one fires in the middle of a perfectly pleasant conversation over networking event coffee, I treat it the way I would treat any incident: fix it now, figure out the root cause later, and do not waste time pretending the system is something other than what the logs say it is.

There was a lot she could have shown me. That was the sentence. Next time, I intend to say it on the first try.