Hierarchy and the workplace

By SysAdmin1138 on

Charity Majors had a long post about this, and my experience with workplace hierarchy mirrors hers. It is a bedrock fact that US-style businesses have hierarchy. At the top of the org-chart is the Chief Executive officer. Below them are one or more managers. At the bottom are the Individual Contributors. Even in supposedly "flat" org charts there is at least some hierarchy, with the CEO at the top of the chart, maybe one person with "manager" in the title to do the day-to-day managing the CEO doesn't have time for, and everyone else.

For others, well. I work for Dropbox these days, and they've actually published their career ladders. Some highlights:

  • Software Engineer has seven levels, with five through seven being Staff and Principal Engineer roles.
  • Engineering Manager only has five levels, but the levels start at the number three and go up to seven.
  • Not listed on that framework are the "executive" levels (think C-suite) that aren't engineering but are business, and sits on top of these posted levels.

This is not a flat structure. There are some unwritten rules in the above structure that fall out if you read close enough:

  • Generally speaking, a manager can have direct-reports of Software Engineers of equal or lesser level. A Manager 4 can have reports up to Software Engineer 4.
  • Manager 5 is the start of the "Most of my direct-reports are managers" levels.
  • Software Engineer 5 through 7 are the "Staff +" roles.
  • Staff+ folk (like me) work with team-of-teams managers to do things.

With that in mind, here is Charity on how many companies describe how to interact with a structure like Dropbox's:

One of the most exhausting things about working at Facebook was the way engineering levels felt like a hamster wheel, where every single quarter you were expected to go go go go go, do more do more, scrape up ever more of your mortal soul to pour in more than you could last quarter — and the quarter before that, and before that, in ever-escalating intensity.

This has been my experience, too. Messaging around annual review season is heavy on growth messages, about working with your manager to build a growth plan, about how to document how you've grown, about how the promotion process works. Laden in this are strong implications that if you're not working towards promotion, you're bad at your job. This is never explicitly stated, this is merely strongly implied.

If you are a Software Engineer 1, your job is to become a Software Engineer 2 as soon as you can. If you are a Software Engineer 2, staying in that title for more than a few years is a sign you're not actually ambitious or are here to just punch the timeclock for a paycheck. And so on.

Thing is, for those of us who got into this career right out of college we can expect to be in this career-track for over forty years. A grow or die environment like the above isn't compatible with a forty year career, at least if you listen to the messaging. This is why people job-hop, because the hierarchy applies to companies as much as it does to the job levels inside them. A Senior Software Engineer at an airplane parts manufacturer in Kansas does not have the same cachet as a Senior Software Engineer at Twillio. Once you add company type to the levels, you get a lot more career levels to work with. To give an example of this, here is my career:

  1. First tech job out of college was in the Civil Service, working as a Help Desk technician (7 years)
    1. I promoted/reclassified my job three different times while I was there.
    2. When I left I was as high as I could get and still be a non-manager.
    3. Important: this was in a city no one would have called a tech-hub in the late 1990s.
  2. Second job (when this blog started) was also Civil Service, but working for a large public university (7 years)
    1. That job had zero promotion potential. The day I left I was still the newest kid on the team.
    2. The one job title they had for people like me had "Senior" in the title.
    3. Important: this was 80 miles north of a major tech-hub, Seattle. While not a direct competitor for jobs, it still influenced compensation.
  3. Third job was a major job sector change, I moved to a startup that was about 20 people all told (3 years)
    1. Startup meant flat job tree.
    2. I suddenly became the oldest
    3. Important: this job was when I relocated to a major tech-hub (Washington DC metro area). Which meant I got a 15% pay hike vs what I had been getting.
  4. Fourth job was a large .com-era tech company (2 years)
    1. This company was big enough for a job ladder.
    2. This is where I re-added "Senior" to my title, as "Senior Systems Engineer"
    3. Being a .com era company meant they weren't playing the stock-based-compensation game the way the likes of Google, Amazon, and Facebook were.
  5. Fifth job was another startup, but this time a San Francisco based one (4 years)
    1. Another flat job hierarchy, but this changed two years in when they realized they needed one.
    2. When I got a broken out title, I got "Staff". First time I'd heard the term.
    3. Important: This company was fully enmeshed into the Bay Area tech scene.
  6. Sixth job grew out of fifth job because Dropbox bought the startup (3 years so far)
    1. Important: while not a FAANG, Dropbox tries to compete with them in the job market.
    2. I lost "Staff" as part of the merger, but got it back a year and a half later.
    3. Stock-based compensation applies to almost everyone.

You can see my progression from "podunk government job" to "staff engineer at a name you recognize tech company", it only took me 23 years to get there. Started in amateur leagues, got picked up by the minors, worked up to AAA, and then one of the majors got me in a package deal. That said, places like Dropbox do sometimes hire people fresh out of college. They're a small minority, but they do exist. What about people who skipped my first 23 years of working my way up?

Charity opened with this parable about someone who did that.

My friend Molly has had an impressive career. She got a job as a software engineer after graduating from college, and after kicking ass for a year or so she was offered a promotion to management, which she accepted with relish. Molly was smart, driven, and fiercely ambitious, so she swiftly clambered up the ranks to hold director, VP, and other shiny leadership roles. It took two decades, an IPO and a vicious case of burnout before she allowed herself to admit how much she hated her work, and how desperately she envied (guess who??) the software engineers she worked alongside. Turns out, all she ever really wanted to do was write code every day. And now, to her dismay, it felt too late.

You climb, you jump to management, you climb some more. And find yourself at 45, with another 15 to 25 years left in your career, asking "now what?" I'm at a similar age and am also facing a "now what?" question, though not doing it from a high management perch. This brings me to the point of Charity's piece, that climbing the ladder should not be your goal even though the system is set up to encourage just that. What's been driving my career for the last 10 or so years has been to get into the room where the decisions are made. As Charity put it:

Most people who go in to management don’t do it out of a burning desire to write performance reviews. They do it because they are fed the fuck up with being out of the loop, or not having a say in decisions over their own work. All they want is to be in the room where it happens, and management tends to be the only way you get an invite.

It wasn't until I found out about Staff Engineers that I realized I could be in the room and not have to write performance reviews (and also still do engineering). In fact, I'm in the loop for promotions, which is a fundamental good thing. I spent the first 20 years of my career convinced I needed to be in management to have any effect on strategy. I also knew I didn't want that role for a bunch of reasons relating to having been subject to pathological management structures and not wanting to put up with that shit first hand. This "staff +" concept gave me a new ladder to climb, one that was better suited to how I wanted to work.

Charity spent a while explaining the power dynamics inherent in a hierarchy of job titles and managers. This feeds into my own talking points about non-toxic workplaces. The biggest factor in non-toxic workplaces is a strong degree of feedback up, down, and across the org-chart, coupled with collaborative decision making. Feedback builds context, and when people have the context for a decision they're more likely to agree with the decision. People who agree with management decisions are more likely to be happy with their jobs. Charity had specific advice that mirrors my experience.

Wrap your senior ICs into planning and other leadership activities. Decisions about sociotechnical processes (code reviews, escalation points, SLI/SLOs, ownership etc) are usually better owned by staff+ engineers than anyone on the management track. Invite a couple of your seniormost engineers to join calibrations — they bring a valuable perspective to performance discussions that managers lack.

These sociotechnical processes, also known as glue work, fit quite well with senior and super-senior engineers and also helps regularize "soft skills" being a key to gaining engineering maturity. If Engineering Management is doing all of this decision work, you have a potentially toxic environment. The processes around who gets to give whom Jira tickets is full of politics, and organizations are healthier if more than managers are allowed to be in those decision loops. This puts the power of decision outside of the management framework, which distributes power, and decouples (a bit) power from job title.

The danger here is reserving power for the sub-titles that often come with climbing the Software Engineer ladder. Sub-titles like "team lead" or "area lead" that are in part appointed by the managers of the team or area. This is another hierarchy. Engineers are keenly aware of hierarchy, it's how object-oriented programming works (hello, classpath), so it's conceptually easy to see this second hierarchy as having equivalent weight as the reporting structure.

That said, hierarchy is not a fundamental evil. Hierarchy tells you how you relate to other people in your organization, which allows you to hang a personal relationship on this externally imposed one. This allows expanding your network of personal relationships beyond the limits of Dunbar's Number, which is quite important once your company's number of employees gets much beyond 80. The danger of hierarchy is assigning it absolute power. I've joked in the past that if your boss tells you to do something, you can usually push back on it to some extent. But if your boss's boss asks for something, your only answer is "Yessir, of course sir, right away sir." This is an example of a personal relationship that grew out of the org-chart (your boss) versus a relationship that is entirely derived from the org-chart (your boss's boss). This "can't backtalk" reflex goes away if you've interacted with your boss's boss enough to know them as people.

Here are some things you can do to deemphasize the power assigned to the org-chart and job titles, beyond what Charity mentioned:

  • If you don't have it already, rework your job levels so you have ICs at equivalent ranks as some managers, similar to what Dropbox did (see above). These are your "Staff +" roles, at least at the moment.
  • If you are a manager-of-managers, be sure to get in front of the membership of your subteams often enough you have more than a handshake relationship with your people. This makes you less of a preacher from on high, and more of a person.
  • Improve how context is shared down the org-chart. Most companies need work here. People who have similar context as the decision makers are more likely to agree with the decision. Also, getting the contexts feels like being in the loop.
  • Share context for decisions that haven't been finalized yet. Many strategy makers prefer to decide the strategy before working on how to share it out, largely to reduce bikeshedding and confusion over what the strategy/decision actually is. But if people understand some of the debates held before the decision was made, they're more likely to agree with the decision.
  • Encourage feedback up the org-chart regarding decisions being worked on. In a company of any size, decisions are made with filtered and summarized data, which can intentionally or not reinforce biases. Accepting feedback from outside is more likely to result in better calibrated decisions, as that outside feedback might challenge the bias. It's more work, but you get better decisions.

Power is the perception that your opinion will change minds or direct action. Consenting to a decision as valid is a form of providing an opinion. These bullet points are all ways to improve decision consent, and provide pathways for opinions to reach the altitude needed for maximum effectiveness. These are all kind of squishy, and the sort of changes you need a senior manager/director or a well tenured staff+ engineer to push for. Some systems you can only change from within. Is it your turn?