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
OK. Now, let’s go rewrite our organizations career paths.