Recognising and rewarding glue work

Tanya Reilly has a great slide deck with speaking notes from a talk she has given called Being Glue.

She writes:

I’m a software engineer.

I wrote 211 lines of (work) code last quarter.

Instead of coding, she spends much of her time on ‘glue work’, which includes:

  • Make sure we work on things that take us where we need to be in a year or two
  • Go to a lot of meetings
  • Check in on projects
  • Review other people’s designs
  • Ask a lot of questions
  • Have a lot of one-to-ones
  • Do a ton of mentoring and coaching

My first though on reading this was “She’s doing a leadership role and should be promoted and get a pay rise.”

But the rest of the deck goes on to explain how this glue work is under-valued and subject to gender biases. Specifically, if female engineers focus on glue work (anything which enables others), they can be labelled as ‘not technical enough’ and skipped over for promotion, in favour of those who did the more visible hands-on technical work once the enablement had been unlocked.

This got me thinking. Enablement work may be under-valued, but in the past when I focused on it and spent less time with my head in code, I was usually rewarded. ‘Someone had to do that grunt work Jim, and you [stepped up to the plate] (insert other sports / war analogy here). Well done for taking the initiative.’

Thinking back, I’ve never had the benefit of an explicit progression framework or concrete job spec that called out the value of this kind of work. If there was, it fell under vague terms like ‘good written and verbal communication skills’ or ‘good stakeholder management’.

In some interpretations of agile software development there is an attempt to keep glue work to just a few people, so that more of the team can focus on the idealised view of programming as mechanistic, heads-down, headphones-on, individually meritocratic, genius-inflected, in-the-zone, all-out productivity. The scrum master role is there to deflect the annoying interruption of business from the precious programmer. The BA and/or PM are there to do all the messy stakeholder-y stuff which gets translated to hard acceptance criteria.

This is cobblers. Everyone needs to do some glue work, because it is needed at every level of detail. It doesn’t stop being necessary once a story card has been written. And it isn’t a manager capability, it’s a required part of being a knowledge worker.

So, make sure you are explicitly recognising the value of enablement and glue work at every level of experience and progression in your team. And reward people who demonstrate them. It shouldn’t be seen as ‘taking the initiative’ or going above and beyond the call of duty (war analogy alert) to do this stuff. It’s a fundamental part of the job.

Glue work is not just leadership work. It’s technical work.

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.