Who gets the credit for the glue
Some people hold a team together without writing much code, and career ladders mostly can't see them. I keep wondering whose job that is.
In every team I can imagine there is some one guy who is quietly glue. He’s the guy who answers the new guy’s questions before the new guy realizes he needs to ask questions. He’s the guy who realizes two teams are stealthily building the same cache. The guy who creates the design doc no one else wanted to create, and then tracks down the comments on that design doc. And then updates the roadmap because no one remembered it.
Now there’s a name for this. It’s called glue work (credit Tanya Reilly). And I like that name. Glue isn’t cool. No one ever says, “Wow that glue is great”. But if you take the glue away, the bookshelf will fall down.
But when it comes time to do reviews...the glue guy sits down to create his packet for promotion. And it’s kinda skimpy. Where are all the big features? Well the glue guy has been working to make sure everyone else’s big features ship. The response you get is something like “not technically enough”. Yeah how technical would you expect to be if you review half the team’s PR with great care.
I’ve illustrated this as an iceberg. (old, I know, but icebergs are old for a reason; the bulk of them is below water and the bit that sinks ships is the invisible part).
The thing that’s making me itch is the value of this person to a manager. If you have someone who keeps things moving on your project, your week is that much better. Pretty soon you don’t notice all that coordination. It’s just there, like the dishes just being there in a house where someone always does them. But then you’re in a calibration room and you’re trying to make the case for that person with artifacts that don’t exist... and you realize that you’ve been taking advantage of a free lunch that someone else has been paying for.
So, whose problem is this? I keep coming back to the, umm, not-so-nice conclusion that it’s my problem. Or the problem of whoever sits in the manager’s seat. We can’t realistically expect engineers to say no to work that the team needs. But we also can’t expect engineers to redesign the ladder at lunch time.
The ironic thing is that we often already have the words in our ladder. Senior engineers are supposed to “multiply the team” and “lead through influence”. Words are there. But no proof, because no one took note of that afternoon spent un-confusing a new hire who’s lost. And now six months later...poof. You can’t weigh vapor on a promotion committee.
My guess is that the solution is mostly-dull. Observe it. Make note of it when it happens. Rotate the tasks that tend to cluster around the same helpful person (meeting notes, interview scheduling, etc) - because if a person always seems to end up with these, it’s a choice (unspoken). Make sure the mid-level engineer who’s doing a lot of glue also has something technical with their name on it (for some insurance).
And ask. Some people love this work and want to grow into a role where it’s the whole point. Others are doing it because the sink was full and nobody else was going to wash anything. Those are very different people wearing the same apron, and you can’t tell which is which from across the room.
I wonder how many good engineers have been nudged out of engineering entirely because they were too useful in a shape the spreadsheet didn’t have a column for.