Tanya Reilly

This post has some big gaps. Who is this for? When is it relevant?

The opposite advice is essentially addressed in Being Glue by Tanya Reilly^. If you do a job that your management chain is not measuring, you won't be rewarded for it.

Excerpting:

> But sometimes a team ends up someone who isn't senior, but who happens to be good at this stuff. Someone who acts senior before they're senior. This kind of work makes the team better -- there's plenty of it to go around. But people aren't always rewarded for doing it.

If you take the op advice literally, you might find that you're not promoted AND management thinks you're bad at your job

So the rules of promotions:

1. First, do the things that are expected of you. If you don't do these things (or you do them in a way that management doesn't expect or can't measure) you will have to do additional work to make sure they get measured. Staff engineers are good at doing auxillary work and explaining why it's valuable. If you aren't, then focus on the things that are obviously valuable

2. If you're doing everything your team needs from you, now is a great time to do the additional work. Figure out where test coverage is anemic, profile that really slow query, write up your list of pain points and throw together a list of some initial ideas for solutions (codex & Claude can be great helps here, but don't be like OP. If you use AI to write something, let everyone know: "codex and I think these solutions might work, but I haven't…

Most of the comments here are the generic "all business is evil" cynicism that's rampant on HN these days. The reality is not so simple. Here's my perspective, as someone who's actually done annual reviews and tried to build/retain a great team.

> drew a straight line between here's what you need to do to get this much of a raise or this much of a bonus

This is really really hard to do. It's not a good idea (or even a practical idea) to plot out all the work that you want an employee to do in a year, or even in a quarter.

You can prove this to yourself. Try and write down all the things you would like to get done over the next year and how much of a bonus you think you should earn for each thing. If you're in sales this is easy - it's a sliding scale ratio between revenue won and bonus. If you're in product or engineering I suspect you will not find it so simple.

If you've read posts like "Being Glue" (https://noidea.dog/glue), they talk the importance of work that's impactful within the team but very difficult to measure. If companies tried to draw a straight line between visible work and raise/bonus, nobody would ever choose to be glue.

This isn't to say that everyone is happy with how annual reviews work. As engineers we want everything to be black and white. If I pass this unit test, I get a pay rise. As managers who used to be engineers, we'd love to be able to give engineers that clarity, because you're right, they would get hyperfocused on it and we'd get a lot…

Maybe. Let's say there are broadly two hypotheses:

A: Women are systematically discriminated against in the workplace (sexism).

B: Women are systematically more inclined than men to perceive that they themselves are experiencing sexism.

(In the real world, we're going to have some mixture of the two, plus other factors, but simplified models are often useful.)

Systematic discrimination by gender in the workplace is well-documented. https://noidea.dog/glue is one example present in tech that's also applicable to research. At the level of this simplified model, A is true: that suggests that the 2023 WebSummit survey's results are a proxy for the level of actual discrimination.

Taking a step back… is this simplified model sufficiently-valid? From the page linked earlier:

> And they say "Look, you're great at communication. Your soft skills are outstanding. We just don't think you're an engineer. Consider becoming a project manager instead?"

> Kripa Krishnan, the legendary director of cloud product operations at Google once said that while she'd experienced some industry prejudice for being female and some for having an accent, it was nothing compared to the prejudice she experienced for being a TPM.

> The even more interesting part was that, when managers were asked to choose someone to do thankless work, they asked women 44% more than they asked men.

---

Back to the original paper, I'd suggest that the relevant question is: what proportion of the qualified female…

After someone gives a talk in person, some of the things they can do online:

1. Mention that they gave a talk

2. Post a video recording online

3. Post the slides online, as-is (PDF or whatever) with no explanation

4. Lay out the slides on a HTML page, with accompanying text (what would have been said by the speaker), so that it's easier to read — while still being clear you're “reading” a talk.

5. Redo/rewrite the whole thing into text form, paragraphs and all.

The author here has done 1 to 4, and you're complaining they've not also done 5, but that's a lot of work and I don't begrudge someone not doing that. I'll be grateful someone presented their talk in a readable form in the first place.

[I do agree this page was hard to read, at least on mobile and at least in its initial version—it's much better now—but I've seen many others post these "annotated talks" online and the format itself is not necessarily bad: for instance see https://idlewords.com/talks/ (example: https://idlewords.com/talks/superintelligence.htm) or https://noidea.dog/talks (example: https://noidea.dog/impostor) or https://simonwillison.net/tags/annotatedtalks/ (example: https://simonwillison.net/2022/Nov/26/productivity/) — maybe just some minor tweaks to CSS like putting the text to the right of the images would make it easier to read.]

That’s good feedback I think.

There’s an article that was going around again about ‘glue work’ ([1]) that has a story where an engineer gets caught up doing all this kind of mentoring, coordination and other work like that and then is passed over for promotions because they don’t have technical achievements (though they claim to have become instrumental in enabling everyone else’s technical achievements).

The article never gets to quite the right conclusion - it’s actually massive management failure - what I was thinking the whole way through was “why hasn’t somebody sat them down and told them to do their actual job??”

Mentoring and code review are both super important, but if the organisation wants you to focus on getting tickets done then you basically just have to, unless you can convince them to actually add the additional work to your actual role description or get enough seniority to add it yourself.

But it’s good to have feedback on what kind of work you’re actually going to be measured on in performance reviews, promotions etc.

1. https://noidea.dog/glue

Reminded me of another article I saw on HN recently, where sometimes a lot of the work done by a senior software engineer is "being glue", which is not as recognizable. When it comes time to slice the pie for stamps, a "glue" baker would probably get a pretty small slice: https://noidea.dog/glue

Also reminded me of a place I used to work which grew from being a flat organization to a more hierarchical one. Once the hierarchies were introduced, there was fierce competition to get to those few coveted spots, and it sadly changed a lot of the dynamics around the place. People who used to not care about position and recognition were suddenly faced with it making a much more recognizable impact in their lives, and it was a lot harder to dismiss as "not the point of it all".