Overlap and Glue

— 3 minute read

I've been having some conversations with clients recently around, for want of better terms, glue and overlap approaches to integrating different communities/disciplines/groups within an organisation.

Advanced warning: This is fuzzy and not well fleshed out — but this blog is all about the fuzzy and not well fleshed out!

Overlap is where there's lots of active collaboration & cross-functional work. Folk actively reaching out between the disciplines for common ground. Finding new ways of working together. Shifting stuff around.

Glue on the other hand is when folk are really good at defining the point where the two disciplines interact. They work separately and the point where the two meet is well defined, rock solid & immovable.

Overlap doesn't mean agile. Sometimes folk are working together on very linear waterfall-ish work flows. Sometimes they're not iterating. But they are collaborating. They are changing who-does-what a lot.

Glue doesn't mean waterfall. Two-way communication happens. Feedback loops happen. It's not throwing stuff over the wall. But that communication occurs in a well defined way. Sometimes around an artefact (a design system, some OKRs, etc.). Sometimes around an activity (the monthly c-suite update, the weekly coffee the CPO & CTO have, etc.) Sometimes both.

Glue vs Overlap isn't global — people can be playing in both spaces at the same time. For example a development team can be all glue with product, and all in the overlap with QA.

I'm biased towards working in the overlap. I love cross-functional spaces and the value that comes from people with diverse skills and experiences working together directly.

That doesn't mean that glue approaches don't work. Quite the opposite. The act of defining the areas and mechanisms where groups interact can be a super useful driver to discover more effective ways of communicating and working.

Overlap-Glue feels a little bit like the specialist|generalist continuum when it comes to individual preferences — but bigger than that since it's more about how groups of people work together.

Overlap-Glue feels a little like some of the things that talked about in the Team Topologies book — but more context driven with people taking up different stances in the same groups depending on who they're working with and why.

Overlap-Glue feels a little like this crosswise org chart dimension that John Cutler talks about in this tweet - but at different levels of granularity.

Overlap tends to be more high-cadence work, Glue low-cadence work (but not always).

(You see what I mean about "fuzzy" :-)

But people who love glue sometimes seem to hate working around the overlap. And folk who love the overlap sometimes seem to hate working around the glue. Folk especially hate moving from one type to another when contexts change.

And boy, have the last few months caused a lot of context change!

So I've been seeing teams that spend most of their time in the overlap having to suddenly deal with other bits of the organisation who spend all their time in the glue.

I'm seeing folk with really, really effective processes around the glue that suddenly having to move to playing in the overlap because the context has changed so much their old ways don't work any more.

And so… Overlap and Glue. Having labels to talk about those differences — fuzzy as they are — has been helping: "Do we need to start working more in the overlap", "Do we need to build some new glue?", etc.

Hope you find them useful as well. If you do, let me know.