Social Hierarchies in Engineering Organizations

I recently read Anthropology of Mid-Sized Startups, which argues that as technology companies grow they begin behaving as tribes or religions. The article’s premise captured me more than the execution, and left me thinking about social hierarchies.

In the good times, people usually don’t explicitly notice social hierarchies–they’re too busy doing something they enjoy to analyze why they’re pissed off–but once things hit a rough patch, hierarchies tend to become a vocal sore point.

They’re irksome because they represent an institutionalized incongruence in the valuation of employees: you’re not as important as Jim, he’s an architect, you’re just an engineer.

Classical Engineering Hierarchies

It seems natural that engineers would complain about the management track–managers are always recipients of great hatred, probably because we do a lot of harm–but I’ve found engineers much more forgiving of line management than of another leadership track: architects.

I believe that’s because managers represent a different skill set, one which most engineers don’t particularly aspire towards. Architects on the other hand, generally don’t seem to represent a different skill set; Tim knows he architected half a dozen things over the last year. Why call Jack an architect if you’re not going to call me an architect?

Another classical source of tension is the divide between frontend and backend engineers (I wrote about this while I was working at Yahoo!). A third is some organizations make a distinction between product engineers who are building the customer facing products, versus infrastructure engineers who are building tools to support the product engineers.

Decouple Role and Title

In each of these cases, the organizations have started to conflate an individual’s role with their value instead of judging on their merit. Is a junior infrastructure engineer more valuable than a senior frontend engineer? Is an architect more productive than principle engineer?

Context free, I’d guess no.

I believe the solution here is to decouple an individual’s role from their title and compensation. Sometimes a junior engineer might serve as a team lead. They’re still a junior engineer. Sometimes a principal engineer might be an individual contributor, on other days they might be leading a critical architecture project. Changing the context they’re contributing in shouldn’t change their position in the team’s social hierarchy.

OK. Now, let’s go rewrite our organizations career paths.