Skip to main content

The Mistake of Hierarchy

I was having lunch with a friend the other day and they were selling me on applying for a position in their company, which I was totally up for and interested in and in fact had already done for a couple of other positions. And the point we kept coming back to was the idea that I was "overqualified" or that somehow putting in for this job would be "beneath" me. Now, this is a customer-facing position in a software company where the users are generally going to be relatively bright engineers or sysadmins, so it's not exactly a Comcast Helpdesk job, but there was still this stigma, this idea both in their head and in the culture in general that a customer-facing role, any customer-facing role, is somehow less than a job as, say, a developer, or a devops job, or something like that.

I worked in a technical support role for six years, the last three or so in a supervisory role (mostly because if I'd've taken the "manager" title, my salary would've gone down, given all the OT we were expected to do). It shaped the way I think about IT, about as-a-service solutions, and as an Operations professional, in some very fundamental ways, ways that often get overlooked in a technical interview or on my resume. Thinking about the customer as something other than a PEBKAC, thinking about the solutions being developed as a tool for others rather than just a clever new toy, is now a bedrock principle of my operational ideology. But that sort of work and that sort of thinking are often devalued in IT, for reasons that are not entirely clear, except for this false hierarchy that has been created by... someone? The culture, I guess.

The hierarchy I keep seeing goes something like this: there are all of the people who aren't IT people, and they exist basically as parasites: sales, customer engineering, HR, etc. We'll set aside for the moment that all of those roles are what make it possible for the rest of the people to have jobs, but just bear with me for a bit. Then, in the IT "approved" levels, there are at the bottom anyone who's customer-facing: account reps, technical support, etc. Often this level also includes anyone from Alphabet Row: the CTO, the CIO, the CEO, who used to be part of the elite and then decided they wanted to stop doing "real" work. Then, above them, are the "true" operations people: the sysadmins, the dbas, the SAN managers, network engineers, etc. Then, at the top, are the "real" coders, the engineers that write software and find clever ways to be clever.

If you're like me and came up in Ops, the last two layers are swapped, but that's tribalism for you. But this hierarchy is built on a model that looks almost nothing like today's IT industry. It hearkens back to the old Microsoft-in-the-90s shops where if you wanted a job in IT you got a phone-bank job in the back of the paper with no experience and were expected to either educate yourself or burn out and go back to flipping burgers. Nevermind that that model didn't even exist then, that was just the template for this image we have now.

The model for software has changed significantly in the last decade or so. There are no longer "ship dates", or "gold masters", or for that matter "boxes" in which physical media is shipped. If you're lucky, you're working in an Agile shop where you don't even have "patch days" or "releases" (though there's only a couple of places, like Twitter and Facebook, where that's actually true, and the lesson to be learned there is that a successful business model that relies not at all on the user base is the most valuable piece of Agile Methodology possible). If everyone in the organization doesn't understand at a fundamental level who the customer is and why they are important, the organization is likely to struggle in its growth plan and maybe even kill the company. 

So it turns out that having people talking to customers, people who know what they're doing and a have a strong understanding of the fundamentals as well as the product being sold, is vital to a healthy company and a good growth plan. It's seven times more expensive to get a new customer than it is to keep a current one. Good, responsive, intelligent technical support for a company is about as valuable as another round of startup funding. So disabusing not just the culture but the workers themselves of this false hierarchy is fantastically important. A good company needs to value TS and Helpdesk teams just as much as the rockstar developers working on the New Shiny Thing for the next release. And most importantly, there needs to be a clear career path for those folk, even if that means creating new roles in the TS framework. 

I liked my time in TS, and enjoyed both the customer-facing work and the emergency-response role. But it's wearing to be at the bottom of a pyramid with no clear way to move up, and very little reward either in kudos or cash for a lot of what is sometimes very hard work. I'd love to work at my friend's company, and not just because it would mean a job, but also because the environment and the people and the customers sound pretty awesome. So I hope they don't think of me as "overqualified" and I hope they don't think I see this as "a step down". That's the culture talking, not me.

Comments

Popular posts from this blog

Organizing And You: Lessons from Labor History

    I made a joke on Twitter a while ago: Do I need to post the Thomas M Comeau Organizing Principles again? https://t.co/QQIrJ9Sd3i — Jerome Comeau says Defund The Police (@Heronymus) July 15, 2021 and it recently came back up because a member of my family got their first union job and was like "every job should be offering these sorts of benefits" and so I went ahead and wrote down what I remember of what my dad told me. My father had many jobs, but his profession was basically a labor union organizer, and he talked a lot about the bedrock foundation items needed to be serious about organizing collective action. Here's what I remember.    The Thomas M. Comeau Principles of Organizing -- a fundamental list for finding and building worker solidarity from 50 years of Union Involvement. This list is not ranked; all of the principles stated herein are coequal in their importance. Numbering is a rhetorical choice, not a valuation. 1) Be good at your job. Even in an at-will

Money and Happiness as a fungible resource

Money really does buy happiness. Anyone who tells you differently has a vested interest in keeping you poor, unhappy, or both. I know this because I grew up on the ragged edge of poor, and then backed my way into a career in IT, which is where the modern world keeps all the money that isn't in Finance. So I am one of the extreme minority of Generation X that actually had an adulthood that was markedly more financially stable than my parents. And let me tell you: money really does buy happiness. To be clear: at 45 years old, I'm now in a relationship and a period of my life where our household is effectively double-income, no kids. I live in the city, but I own a house, and can only afford to do that because of our combined income. We also have two cars -- one new, one used (though neither of them is getting driven very much these days) -- and we have a small discretionary budget every month for things like videogames, books, and the like. What my brother used to call DAM -- Dic

Activision, Blizzard, Game development, IT, and my personal role in all of that.

 I'm pretty sure if you spend any sort of time at all on Twitter and/or spend any sort of time playing videogames, you are by now at least aware of the lawsuit brought forth by the State of California's Department of Fair Employment and Housing versus Activision Blizzard, Inc., et al. From this point on, I'll add a Content Warning for folks who are sensitive about sexual assault, suicide, and discrimination based on sex, gender, and skin color, as well as crude humor around and about sexual assault , and what the State of California refers to as "a pervasive 'frat boy' culture" around Act/Bliz, especially in the World of Warcraft-associated departments.   Just reading the complaint is hard rowing, even with the clinical legalese in place. The complaint itself is relatively short; 29 pages laying out ten Causes of Action (basically, "these are the legs on which our lawsuit stands"). I'm not sure I have the vocabulary to properly express how a