I've read a good book about technical leadership and seniority in engineering recently - "Staff Engineer" by Will Larson. I've already reviewed it here (feel free to check it), so today I'd like to focus solely on one of the concepts covered in the book: so-called "Glue Work" (GW). It's not a new term, and plenty of people refer to it frequently (sometimes by different names: e.g., grout work or mortar work), mainly thanks to a viral article (and presentation) by Tanya Reilly that you can find here (kudos!).
What's GW?
... and why should you care?
The nature of GW is simple: it's about filling the gaps between what everyone else does and making sure these things do not fall apart. It's all about those tiny details that are frequently omitted/forgotten, hardly ever planned explicitly (one can't get deep to every little detail, right-o?), but surprisingly often can make a subtle difference and determine whether a project succeeds or goes down.
Let's bring some examples of GW to shed more light on what makes this kind of work so specific:
- updating the information radiators (like a roadmap) or evergreen models/design documents (like an API contract schema)
- on-boarding of the team's new members, providing them enough face-time during the ramp-up period (so they get truly productive, instead of being the burden)
- synchronizing work outcomes across parallel teams/streams (e.g., sharing lessons learned, insights gained, tooling produced)
- updating test data seeds, tutorials/how-tos/templates, maintaining performance test rig, adding Developer Experience metrics' monitoring
- peeking into production metrics, error/access logs, or product feedback (collected directly from users)
- improving the tools or processes that don't work satisfyingly well, "managing a change" (being its agent) until the effect is achieved
- making sure that external assumptions have been met (outside of the team's boundaries/control)
Volatile, unappealing, non-technical, ...
What do those kinds of activities have in common?
- they are not very visible (in terms of public recognition), spectacular, or appealing - they look more like something that has to be done, but preferably ... by someone else
- in fact, they aren't strictly technical, and they require different skills (communicational, organizational, etc.) than programming language proficiency - some would even say: they are not engineering work at all
- when isolated (pinned down) individually, they look like something one could sacrifice (postpone, delay infinitely) to speed up or focus on something else, which is more directly related to customer value
- it's hard to answer intuitively - who should be responsible for them (they are on the "edges" of ownership of more typical engineering work items)
- they don't teach about them in the university or programming languages courses/books - one needs a certain degree of experience (seniority) to identify them (and understand their importance)
- they are absolutely essential in aligning efforts of multiple teams and keeping "the whole engine" running (mid- and long-term)
These characteristics emphasize the main problem with GW, mentioned by both Tanya (in her presentation) and Will (in his book):
On the one hand (identifying) the GW requires significant practical experience and high awareness (of why it's important), while on the other hand it's the kind of work one can easily get stuck in, and frequently it will NOT be perceived as something valuable/demanding enough to earn you the career promotion (or any other tangible form of recognition).
Fixing the approach to GW
IMHO the issue usually occurs when the person doing GW doesn't "sell" it well enough (to both: the manager and the whole team) - e.g., by proactively (beforehand) raising its need & importance. In such circumstances (doing it quietly, without much fuss), it can truly appear like a lack of transparency and a symptom of a lost focus.
Let's be honest: there are many people who simply excel in "getting themselves busy" by doing low-priority work based on their own agenda (driven by their personal preferences or career priorities). You don't want to get mistakenly classified as one of them, correct?
Being transparent and making sure all the identified work (including GW) is prioritized and allocated using the very same rules is indeed essential, but it's equally important to realize that the GW is an integral part of engineering craft - it shouldn't be performed only by the ones who either are the least assertive or the most emotionally attached to the project/company (aka they care most).
It's OK if a technical leader identifies a chunk of GW to be taken care of - but it doesn't mean (s)he should perform it her/himself. The true leadership in such case would manifest in:
- involving other developers (fairly and equally)
- tutoring them (why this activity is important, what are its goals and how to perform it)
- and (at last but not least) providing feedback after the work is ticked off
We, engineers, get spoiled so easily. I've heard it so many times: "I want to do interesting stuff ONLY." The problem is that it's not the modus operandi of the solid, reliable crafts(wo)man.
The real-deal, no-b*llshit engineering is about doing 100% of what's necessary. Some of that work is highly creative, unique, and extremely satisfying when tackled. But apart from this highly compelling "engineering poetry," there's also equally important "prose of everyday's life" - the other side of the same equation, that may not appeal similarly attractive, but is there for a freaking reason.
P.S. Btw. ...
I didn't mention it in the text (as it's an entirely different kind of discussion), but many organizations tackle the GW by creating dedicated positions/roles that do pretty much ONLY that (the GW: but they rarely call it that way).
Technically, positions like Technical Program Managers, Project Managers, or (even) Scrum Masters are great examples here - their primary purpose is being the glue.
Whether I do or don't have a problem with that depends on an answer to a straightforward question: "does this person have sufficient empirical experience to be able to identify, assess and conduct the glue work correctly?". That's why I frequently question content-free, non-technical PMs or the idea of a SM as a fully separate career path for non-tech people w/o SDLC experience.
