Defining Glue Work
The most critical yet unloved work of engineering teams
The oldest known use of glue predates modern human history. In fact, the first discovered use of glue involved the use of birch bark tar to glue stones together. When archaeologists examined the specimen, they dated it back to 200,000 years ago!
Glue has since evolved over the years into much more complex compounds and formulations. From simple plant and animal based resins to today’s industrial grade synthetic adhesives, glue has become an everyday tool for all sorts of applications, including repairing the handle on my favorite tea mug on multiple occasions.
This idea of joining or sticking things together has meaning beyond just the world of adhesive substances. We often use glue to talk about culture or community. For example, we might say that culture is the glue that aligns our company or that trust is the glue that binds a community together.
From that perspective, glue is an incredibly positive force in helping to join people, processes, and things that have commonality. Through that process of bonding, we work, communicate, and collaborate more effectively from a place of strength. As the fable from Aesop goes, sticks in a bundle can't be broken but sticks taken one by one can be easily broken.
More and more however, I hear the term glue referred to in a negative sense when speaking with engineering organizations. They use it to refer to the work no one wants to do. In other words, anything that is not actual coding. This is the work that is perceived as drudgery, tedious, and not additive to one’s experience or interests.
I saw a talk at a DevOps Days event a few years back by Tanya Reilly who gave a name to this work. This is the non-engineering work that supports everything that engineers do on a daily basis. That can be onboarding hires, writing documentation, note taking, improving processes, reviewing designs, mentoring, etc. All of this happens, but often is not very visible and certainly is rarely appreciated. For these activities, Tanya called it “glue work”.
While glue work has a negative connotation, it still needs to be done and often does get done by someone. In fact, there are people that actually enjoy this type of work and excel at it. Others simply feel it is the responsible thing to contribute to and take ownership of for the sake of the team. So these engineers raise their hand or simply roll up their sleeves to dive in.
Normally this would be a positive dynamic in a team to have such a go-getter. Unfortunately, the disproportionate number of these volunteers tend to be women. In taking on this work, they do less coding, which means less direct impact on team outcomes such as the speed, frequency, and quality of building and deploying products. The result is women more often get passed over for promotion than their males peers, even if their glue work was a significant contributor to the success of the team.
Since giving a name and definition to glue work, more engineering leaders and managers have been taking notice. They are starting to give shape to this work by defining and distributing it in a more systematic, measurable, and fairer way. It is written into job descriptions, allocated in work planning, and measured and evaluated as part of everyone’s responsibilities.
We are still a long way however from being more structured and intentional about how glue work is defined and managed. We know intuitively what some of this work looks like. We talk about it with our teams and management. No one though has yet to provide a clear map of all the work and tasks that go into the bucket that is glue work.
A couple of years back, I started to put a definition around some of the things I was commonly seeing in engineering teams that often gets ignored. The two big areas I immediately noticed were around documentation and knowledge management. It fit all the characteristics of glue work; it was tedious, ongoing, and required lots of long-form writing and quality reviewing.
Over time, I noticed other work that also was laborious. Some of it was repetitive and manual tasks required to test and deploy code. In other instances, it was the effort required to figure out a particular vendor tool. There is all sorts of work done by engineers that is non-code related in just getting quality code out the door or in learning the tools that might reduce the manual work.
Some of this work fell naturally in the realm of DevOps. That means anything that touches code from the IDE or CLI to production across the entire code pipeline and infrastructure. Much of this pipeline can be automated or customized to help developers do their work more efficiently and effectively. This has been the benefit of CI/CD, Infrastructure-as-Code and tooling from cloud providers to remove much of the grunt work from developers.
Other work seemed more vendor and tooling-centric. Over the past decade, there has been an exponential increase in the number of developer tools on the market, whether open source or proprietary. Many of these tools got little traction, but some would become breakout hits like Docker, Kafka (Confluent), Kubernetes, Terraform (Hashicorp), Supabase, Hasura, and others.
What defined these successes? They obviously hit upon a critical need for developers. But the other thing was that they had a vibrant community to support these tools with documentation and examples and forums. Then these projects turned into companies that brought more resources to improve usability, hire developer advocates, host and sponsor conferences and user groups. All of this I define under the umbrella of developer experience, which is also a critical contributor of developer productivity much like with DevOps and automation.
However, what do we call all the internal documentation, onboarding, collaboration, knowledge management, and all the other non-tool related activities of engineering teams? This is called developer enablement. In the chart below, I put some of this glue work into this category.
You might then, why do I draw this as intersecting circles? All the stuff I highlight in the middle that we dismissively call glue work is actually the adhesive that is keeping engineering teams from completely falling apart in chaos. This work gets done, but often in a piecemeal fashion by managers, volunteers, or other departments.
The era of piecemealing this work needs to come to an end. We are starting to see some startups focusing in this arena to help engineering teams control the chaos. Stack Overflow is helping teams to more democratically contribute to knowledge through their Teams product. Edify is tackling the process of smoothly onboarding new engineering hires. There are a bunch of tools around status reports and stand ups like Status Hero, Geekbot, and Jell.
Some of the activities under the banner of developer enablement do not even need tooling. In fact, much of this is cultural or process oriented, especially when it comes to continuous education, long-term planning, facilitating mentoring, and so on. While this is a nascent area that not many engineering leaders are actively discussing, I expect to see a function emerge called developer enablement over this decade that begins to own much of this work.
In looking at the diagram above, do you know who is doing the work of developer enablement on your team? Do you recognize and reward that work today?
Mark Birch, Editor & Founder of DEV.BIZ.OPS
Had a great time this week participating in two online sessions. The first was a tech talk I hosted on “Why Startups Use AWS for AI and Data Workloads” this past Tuesday, an intro session introducing startups to the various AI/ML capabilities provided by AWS. Then today I moderated a discussion on “Creative Strategies for Hiring an Engineering Team” with Ajey Gore of Sequoia India and Leonid Olevsky of Omise for the AWS CTO Forum. If you are curious about either of those sessions, let me know.
As for the travel schedule, where oh where will my travels take me? Well here are a bunch of places I am confimed I will be this summer. Let me know if you will be in any of these places, would love to catch up!
San Francisco - I am in San Francisco this week for talks at the AWS Startup Loft, a 500 Global event, and to help out customers, including supporting an event with Supabase.
Los Angeles – Along with SF, I am heading down to LA from June 17th - 20th to connect with some folks in the investor world and reconnect with founders I know down there.
New York City – On July 12, I will be at the AWS Summit comes to NYC, in my hometown! If you are coming, I will see you there.
Asia – I will be back in Singapore July 22nd - 25th, then heading to Bangkok for a month as my base to support any startup events while I am in Southeast Asia.
Sydney – I am excited to head out to Australia for the first time in over three years to participate in the Tech Leaders event on August 18th. I plan to stay a few days before and after and looking forward to meeting startups in the region!
Want to learn more about DEVBIZOPS and read more hot takes about IT, technology, and working smarter. Receive our weekly newsletter by signing up to our Substack!
Nice article and really loved the diagram, Mark.
I have also experienced dedicated teams focused on dev enablement as their role, made positive impact but failed to be rewarded properly in the end. This is especially so in delivery focused orgs where frontliners more recognised when stacked rank against the enablement team.
They are often starved of resourcing when it comes to hiring when we use metrics such as revenue per employee etc.
There are creative ways to quantify the impact though but the uphill battle is I guessed against a culture that rewards motion than impact.