This post reminds me that software engineering doesn't have a plus minus.

mekka okereke :verified:

Emelia 👸🏻 (@[email protected])

There's an utterly ridiculous "study" out from Stanford about "ghost engineers" which are reportedly engineers who do nothing at companies. Pray tell, what flawed methodology did this "study" use? It assessed code changes made by these engineers, not by lines of code changed but by "simulating a panel of 10 experts to evaluate each commit" This fatally flawed study does not account for: - management & planning - research to unblock work - collaboration with other staff - helping other staff

Hachyderm.io (hachyderm.io)

Basketball players used to be measured by stats like Points, rebounds, blocks, assists, steals, etc. You could see that Jordan was good, because he scored a lot of points and didn't have a lot of turnovers. You could see that Dikembe Mutumbo was good, because he got a lot of blocks. Stockton was good, because he always seemed to be the last pass right before a teammate scored (assists).

1/N

mekka okereke :verified:

But Draymond Green was a key part of the Warriors' dynasty, but he never scored many points, never got a ton of blocks or steals, and never got a ton of assists. But... the Warriors seemed to be invincible when he played, but very beatable when he didn't play.

Draymond doesn't show up high on most regular stats, but he has the highest single season plus minus in NBA history.🤯

Plus minus is a calculation of how many points your team scores with you on the court vs with you off the court.

2/N

mekka okereke :verified:

In every tech organization, there are some people that seem to know every system, everybody, and every problem. They're super helpful, and save coworkers months of wasted efforts, by short-circuiting dead end paths, sharing efficient workflows, knowing which services already exist, and generally having great technical judgement.

*None of those skills are quantifiable on performance reviews, other than peers saying thanks (if they're lucky).

*Many underrepresented engineers fill these roles.

Paul_IPv6

@mekkaokereke

these are sometimes called "glue" or "soft" roles but still not given the credit they are due for how vital these roles are.

SlightlyCyberpunk

@mekkaokereke Well...we don't really want to reward that though. Having those people mean your org is in trouble. Get that shit documented so people don't have to waste a bunch of time asking around trying to find that guy.

togdon

@mekkaokereke @whereistanya’s glue work: https://www.noidea.dog/glue

David Megginson

@admin

Yes, document as much as you can.
No, they're not a sign of a dysfunctional org. Think about things like organisational memory ("we tried this back in 2014") and coordination ("team X has something you can use"). People won't even know to go looking for this stuff in documentation.

As @mekkaokereke points out, these are the most-valuable and least-appreciated people in any tech organisation, far more important than so-called "rock star" programmers.

SlightlyCyberpunk

@david_megginson @mekkaokereke Sure, but what happens when this person quits because they're working 14 hour shifts seven days a week because nobody can get anything done without running it by them first? I have seen these people get a coworker coming to their house and pounding on their door to get them to login to help with something on their day off. That shit gets bad very fast.

So perhaps your org can afford to say that this task is getting delayed a week because that essential person is out...but otherwise, if deadlines aren't gonna move for them alone, if whoever is there at the moment is going to be pushed to get that info however they can, then you need a different solution then just letting it all sit on one guy.

mekka okereke :verified:

@admin @david_megginson

Fair question, but it sounds like several related but slightly different topics.

1) How do we properly recognize and reward "plus minus" teammate accelerators in technical orgs?

2) How do we retain those accelerators, and make sure that they get to work at an enjoyable, sustainable, pace?

3) How do we build organizational resilience? How do we reduce dependence on these accelerators to increase non-accelerated velocity?

SlightlyCyberpunk

@mekkaokereke @david_megginson Yeah, I mean I'd probably summarize it more like "don't make the ability to accomplish work dependent on casual social interactions"...but in the end I think your version would achieve that lol

Riley S. Faelan

@mekkaokereke I have worked in a place where we had somebody whom, every time you got a fancy new tech toy, you'd give all the manuals and driver disks and the tiny accessories in the box that you didn't need right away, because he was particularly good at keeping them around for the not-too-common-but-recurring possibility that you might need any of these bits in the future. I don't think this ever showed up in his performance reviews, yet what he did contributed to things running smoothly, especially to things running smoothly in emergencies.

sollat

@mekkaokereke
In biotech this is sometimes referred to as being an SME (Subject Matter Expert). The person who knows the thing and the other thing and why the third thing is a bad idea. It’s usually a non-management track so it can be limiting within a company, but it helps getting the next job.

Kee Hinckley

@mekkaokereke My entire career has been centered around being the person people came to to figure out how something worked. If it's not in my wheelhouse, I'll find the person who knows it. That's how I met my first wife, she'd just started at our company and when she had questions, even about her own side of the org (she was in compilers, I was in UI), her coworkers would say, "Ask Kee, he's right across from your office. He'll know."

When I joined Meta's Integrity team (aka trust and safety elsewhere), I made it clear to the person who hired me that my leadership style was to understand the system and be a facilitator who found the people with good ideas and helped them be successful. Unfortunately, when I started, the org had changed. When I told me new boss that my leadership style was to facilitate success for others, he said "We'll have to do something about that".

It was a disaster. Some of that was other issues I was having, but it was very clear that in a company that prides (?) itself on rewarding people based only on measurable progress, someone who helps other people succeed was not going to be valued.

It even extended to entire groups. I pointed out that the team that built the tools for new groups to integrate content moderation was swamped supporting new teams rather than writing software. "Why," I asked, "Don't we create a team whose sole job is onboarding other groups?"

The answer was, "We tried that, but we can't keep the team staffed unless we just use contractors, because there's no way to get promoted in a team like that."

If Meta can't put a dollar value on something, they don't think it's important.

Rowland Mosbergen

@paul_ipv6 @mekkaokereke in my terminology, I call them translators or generalists.

They not only know how to talk to people to get things done, but also can push back because they have enough knowledge to know when others have already done it/ know that it is possible.

GunChleoc

@admin @mekkaokereke @david_megginson I definitely document the shit out of everything, because I'm a bus factor of 1.

Documenting things can be hard for software developers though, because not all of them speak neurotypical. So, generalist "translators" are indeed important.

David Megginson

@gunchleoc Yes to all that. Present Me appreciates every word of documentation Past Me wrote 5, 10, or 25 years ago, because otherwise I wouldn't know what that fool was thinking with that code.

But as you wrote, writing doesn't come easy to everyone. And furthermore, documentation works only if you guess correctly in advance what questions people will ask. Experienced human colleagues can adapt to changing contexts and answer new questions as they emerge.

@admin @mekkaokereke

David Megginson

@gunchleoc The other side of the coin is that BigTech companies think employees are interchangeable units that they can lay off at year-end and replace 3 months later with a different "full stack developer with 10 years experience."

Not so. Companies are the unique people who make them up, with their knowledge, experience, and social interactions. Connector types hold them together: casually laying one off is like amputating a finger and assuming you can replace it later

@admin @mekkaokereke

GunChleoc

@david_megginson @admin @mekkaokereke Yep. Some poor sod will need to understand that code 2 years down the road, and chances are that poor sod will be yourself.

If you aren't given time to do anything else, at the very least hack some quick comments into the code for the important decisions you made.

Riley S. Faelan

@mekkaokereke The fact that highly sklled yet marginalised people tend to get career-blocked and end up in these "informal advisory" rôles might possibly have contributed to the Hollywood trope of the Magical Black Person and/or Old Woman Who Gives Good Advice.

Riley S. Faelan

@admin You're being a bad manager.

Carry on. Wouldn't want to give you good advice that might increase your power of bad management over non-standard people who deserve better.

@mekkaokereke