Game Design and Middle Management

Okay so this is not actually about game design. This is about my day job, rather than the retirement plan of just writing TTRPG code all day. So, I’ll give you a moment to switch gears, but while you’re switching gears I want you to consider Agricola (the game, not the database or Roman governor of Britain who I recently learned is at least partially responsible for the lack of bears in the British Isles - the Romans loved making charismatic megafauna fight humans). Anyway.

I’m not just a Staff Engineer anymore (whatever that means), but I’m a Manager. This is probably temporary while we deal with some folks on leave, but I can’t really do things halfway so I’m throwing myself in, and I’ve noticed an important change in my outlook on things.

My team maintains this big stack ranked spreadsheet of stuff we want to do. The Product Managers write up requirements docs, we estimate impact and engineering cost, try to put things in order, and then pop stuff off the stack as time allows. For the longest time, I had only a passing interest in the stack. I’d sometimes get something put on it, either a decent business idea or (more often) some pressing bit of technical debt or refactor work that would likely pay off in improved productivity later if we made some changes now. Once in a while I’d be assigned to shepherd a project from requirements to completion, but less frequently these days. As a tech lead, I mostly review designs that other people write, sit in on architecture meetings, and make suggestions. I am trying to learn to make more than suggestions, especially when I am pretty sure a bad decision is being made in my presence, but we’ll put a pin in that for now (it’s one of the things I really need to get better at, though).

So, I’m a manager now. I have a team of 10 reports, working on different projects, the majority of whom are L4. On the Google scale, this is “not a junior, but not a senior either”. Level 4 engineers can be expected to work independently on stuff, and occasionally write a simple design doc (maybe part of a bigger project). Once the engineer starts writing bigger, more complicated designs that multiple engineers all work on, they’re a senior engineer and we promote them to Level 5. Most of my team wants to get promoted. More money, more recognition, and, you know: most Googlers are a very particular kind of motivated achiever, so if you show them a level ladder, they’ll put on their climbing shoes. 

So now, the problem is this: I am managing (and therefore responsible for the career growth of) eight people who are at Level 4. I have a limited number of interestingly complicated projects that our promotion committees would say “that is clearly Level 5 work”, and all of those projects are important - they are likely to bring in lots of money if we execute them well, so we want to get them done.

Now, the stack rank is a worker placement game. I need to think about:

1. Who could get this project done most efficiently and quickly?

2. Who would learn the most while working on this project? Probably not the same as the person in 1, since they’re learning.

3. Who is next in line to get a “complex” project?

4. How urgent is the project in general?

I’ve moved from viewing this as a backlog of things to get done to viewing it as a resource to be carefully husbanded and meted out to the “deserving” (I’m using that word ironically, but cannot point this out in a footnote, as pika doesn’t support foototes). It’s wild how quickly that shift happened.

A disclaimer: it is possible (I have recently seen it happen) to get promoted to L5 on a collection of small projects, each of which demonstrates part of the story of what a good L5 engineer does. My team has more of this type of promotion than most, because of the nature of our work. However, it’s still a lot  easier to make the case that person X is working at L5 by pointing to a clear “here’s the design doc, here’s the 30k lines of code, here’s the $10 million in incremental revenue we attribute to the successful landing” story. Moreover, while managers (like me, plus my management chain) repeat this claim, none of the line engineers really believe it. So they also are kind of viewing the stack rank as an opportunity pile (it’s not a task, it’s a taskportunity!) Even if you weren’t interested in getting promoted, who wouldn’t want to get a chance to work on the big complicated project with a fun design and a lot of code output? 

So anyway, managing people is hard.