Transmuting Low-Value Programmer Cred into High-Value Status Illegibility
Not long ago, I wrote a post about that one, “top” software engineer role that companies don’t hire directly into. I’m going to pick up where I left off there.
For a quick recap, recall the diagram I made (and my wife kindly GIF-ified for me). In red, you have the positions that a company will hire into, and in white, you have that one position that they won’t. It’s usually “Principal Engineer” or something like that.
A Recap of The Surface Narrative and the Real Motivation for This
In the last post, I talked about the surface explanation for this, accepted by idealists and pragmatists.
This role represents the most valuable software developers in the group to the company. These developers combine technical skill with a certain je ne sais quoi that combines experience, domain knowledge, inside company baseball, and embodying the company’s values and training.
But I also talked about how that doesn’t stand up to scrutiny. I talked about how if you picked the brains of leadership, you’d probably hear something like this. (Assuming you also gave them truth serum.)
It seems like a win for everyone. It rewards people for staying, makes us seem more prestigious, and it’s a non-monetary reward. They love it, and it doesn’t cost the company anything to do.
Significantly, that top role that requires hanging around the company for years, serves a very pragmatic purpose. It creates a position whose salary can creep up, unbounded, without dragging up the salary for the rest of the group.
In other words, create a bucket, put your lifers in that bucket, and give them 2% increases a year forever. Without that bucket, you’d either (1) have to stop giving them increases or (2) potentially have to pay new hires a lot more.
So you create this policy to keep labor costs down. And then you stand aside while the pragmatists and idealists manufacture and believe a merit-driven narrative. Easy-peasy.
Software Developers Are Smart, So Why Does This Happen?
Here’s the weird thing, though. Software developers are smart people in general, and pragmatists especially tend to tune out self-serving corporate narratives. Even journeyman idealists are mostly practical, aside from getting swept up in the industry’s collective meritocracy delusion.
So, what gives? Why do they agree to the unattainable pay band? And, even, in some cases, why do they insist on it? (Yes, this actually happens.)
Let’s dive into that today. And to do so, we have to start with a concept called status illegibility.
Introducing The Idea of Status Illegibility
I teased this concept in the last post, but I’ll explain it more here. However, if you want the deepest dive possible, read the brilliant explanation from the source from which I plucked the idea.
If you’re a programming meritocracy buff and recreational outrage enthusiast, then I’d sharpen my outrage stick if I were you. Programming skill isn’t nearly as commercially important as we tend to think, in spite of our preoccupation with it. Oh, it matters, particularly to software’s total cost of ownership. But the gulf between no automation and bad automation is far wider than the gulf between bad and mediocre automation, from an enterprise’s perspective.
So we programmers are left at the bottom of org charts to argue passionately about stuff that makes opportunists yawn and thus comes with no real organizational power stakes. For simplicity’s sake, let’s couch this in units of “programmer cred” and say they vary from 1 to 10 for any given programmer.
With that in mind, say you have a team of developers, all of whom have a cred score of 5, making the group’s collective score a 5. But, let’s say that, as an outsider (e.g. a candidate interviewing), you had no insight into the individual group members’ programmer cred scores, for the most part, only having a sense for the group. This is the core of status illegibility.
The less obvious your cred score to outsiders, the greater your status illegibility. And the greater your status illegibility, the more stable your role in that group. (Which tends to explain why developers emancipate themselves from mediocre groups via conference speaking and other cred generating activities).
Groucho Marx and the Journeyman Idealist Conundrum
Venkat posits that groups of [pragmatists] are stable in proportion to their status illegibility. And he relates this to Grouch Marx’s quip, “I don’t care to belong to any club that will have me as a member.”
To understand this in units of programmer cred, imagine our perfectly transparent group consisting entirely of people with a score of 5. This group will never hook up with interviewing journeyman idealists, bringing the flow of talent in and out to a screeching halt.
Why? Well, think about it.
If I’m a free-radical journeyman idealist in the industry body, my cred score is completely transparent. Let’s say I’m a 7. Why would I go hang out with a bunch of 5s? Alternatively, let’s say that I’m a 3. The interview process (bad at predicting performance, but excellent at assigning programmer cred scores) would cause the 5’s to pass on me. With a completely programmer cred-legible group, an applicant’s score must exactly match the group average in order for there to be a fit.
And, even then, why bother? Neither the group nor the candidate’s lot improves.
Fortunately for companies, journeyman idealists, and broader commerce alike, groups have status illegibility. You can look at Glassdoor and see that the company hires entry level developers. And you might see a programmer-famous developer from their organization on LinkedIn. These establish their alpha and omega at, say, 8 and 1, respectively. But all you can really infer from this is that their collective cred score is somewhere between 1 and 8.
So if they offer you the job, whatever else may influence your decision, a cred-mismatch won’t be an issue.
Programmer Cred Illegibility Case Studies: Examples in the Field
Let’s leave the theoretical and talk about some examples programmer cred’s and status illegibility in the industry.
First up for your consideration, Enterprise Silicon Valley shops (the Googles and Facebooks of the world). Enterprise Silcon Valley Firms are highly status legible. In the programming world, it’s axiomatic that working at a place like Amazon or Facebook makes you an instant 8 or so. The result is a large organization full of people hovering around a 9. Even though this creates reduced internal stability, the organization itself has staff stability by virtue of the fact that a bottomless well of 1-7s are forever trying to get in.
A more interesting example, perhaps, was a company called 8th Light some years back. They’re an app dev shop who, for a while, had the interesting distinction of employing legendary Uncle Bob Martin, who is clearly a firm 10 in programming cred. Now bear something in mind. Bob Martin doesn’t need a job at an app dev company. Once you’re in the 7+ territory, you can typically just float around contracting, freelancing, or consulting and do just fine.
So what gives (gave)? Well, an app dev shop landing an Uncle Bob is a play to manufacture upward-trending status illegibility. Without Bob, maybe 8th Light’s highest programmer cred holder was a 7 and the lowest a 5. With Bob? Well, now you’ve got a range of 5-10.
Companies like this don’t hire 10s because a single 10 will single-handedly raise their margin or even land them clients. They do it to grease the skids of recruitment. That hire is neither about clients nor about work product — it’s about recruiting.
A Quick Aside about Hiring Motivations
I think it’s important to point something out here. For most of the post, I’ve been talking as if the sole motivation for taking and offering jobs were to associate with greater programming cred. Obviously things aren’t quite that simple.
If they were, Bob or any 10 would have no reason ever to hire on anywhere. But the fact of the matter is that wheeling a dump truck of money up to Bob’s house might take us out of the purely theoretical realm of programmer cred and into the realm of practicality. I use this model to create a model that makes the subject more approachable.
I will also say that the different corporate roles have much different takes on programmer cred. Pragmatists don’t care about it, just looking for money. Journeyman idealists are obsessed with it. Normal idealists are unaware of it (with their preoccupation being company-focused), and opportunists… well, that’s a serious rabbit hole and thus a post for another day. (Throw me a comment/Tweet/whatever if that’s something you’d like to read about)
The Unattainable Staff Role and Status Illegibility
Now, after a meandering detour, back to staffing models, illegibility, and the original premise of the post: the unattainable staff role.
A lot of companies have reason to want to do what 8th Light did and land themselves a 10. But not a lot of companies can get Uncle Bob to come work for them. So they do other things to try to skew their status illegibility upward.
The most lazy or haphazard way to do this is to have staff developers generate some kind of mediocre public work product and present it as profound. Companies more on top of their game prod polished work out of them or have them present at conferences and publish papers. This puts a high shine on the 6s working for you until they look to applicants like 8s. And there are probably other tactics here that I’m not readily thinking of.
But there’s another option for manufacturing upward status illegibility that doesn’t involve individuals at all. There’s an instant way to turn your 6s into apparent 8s, even if outsiders are unaware of the names of those people. I bet you know what it is by now.
Recall Groucho Marx’s, “I don’t care to belong to any club that will have me as a member.” And then consider the inverse, “I do care to belong to a club that won’t have me as a member.”
Now you’ve got it, don’t you? That Principal Engineer II role that “we don’t hire into” is an attractive nuisance for journeyman idealists precisely because it artificially implies status to be had following a hire. So if they can swallow the salary implications, they’re sold. And once they’re sold and into the company, they’re more likely to stick around, first to chase the elusive title and then because of sunk cost once they earn it.
The Opportunists’ Take on All of This
Returning now to the opportunists who make such org chart decisions, let’s close out by examining this from their perspective. It’s an intuitive understanding of incentives and what butters people’s bread that causes them to view this sort of policy as such a win.
Most superficially, it tends to attract better talent, meaning a job slightly better done. Programmer cred correlates decently with programmer skill, which gives it some actual value, albeit consisting of pretty weak sauce. Recall that I said we tend to wildly overvalue programming skill financially, but that doesn’t mean it lacks value. That would be a silly claim. So programmer cred kinda correlates to skill, which kinda correlates to financial value for organizations.
But beyond that, this role makes recruitment, retention, and replacement easier and less expensive across the board. And let’s not forget the slightly depressive effect it has on departmental wages.
So, in the end, how do we account for the curious case of that one role that companies don’t hire into? Well, it brings a small improvement in efficiency of service delivery, combined with significantly lower staff costs, both in hiring and salary. Oh, and it makes you feel good to work there if you value programmer cred.
Therefore, I’d say to any of you aspiring opportunists out there, fight off your inner journeyman idealist and the tendency to accept programmer cred in lieu of money. When they tell you that they don’t hire into that role, flip the script on them by telling them that you don’t consider offers from companies that don’t hire into that role.