Lo Etheridge
The arrival of decoupled content architectures and headless CMSs creates a new set of challenges for content modelers, authors, administrators, and others who work with content systems.
Lo Etheridge does developer relations for Hygraph, a headless CMS company. Dev rel folks don't typically drive organizational change and stakeholder alignment, but Lo's unique background in social work uniquely prepares them to help customers with the human side of content management.
We talked about:
Lo's work in senior developer relations at Hygraph, a headless-CMS company
their background as a team manager in the social work field and transition into tech
how creating content in siloed organizations can limit an organization's visibility of its content assets
their description of the role of developer relations
how their focus on people and human behavior naturally led to Lo's expansive view of a dev rel role
how their work on a team supporting a large university's many WordPress websites led to Lo's approach to empowering content editors and authors
the differences in content modeling practices as you move from monolithic CMSs and headless CMSs, in particular the human and organizational challenges that come with this transition
how conflict-resolution practices from the social-work world can help align stakeholders in the CMS and content modeling world
how conflict can be both a positive and negative dynamic and can even improve collaboration and facilitate change management
the role of federation in decoupled architectures
how eye-opening and humbling it is for Lo to watch someone use something that they built
how decoupled architectures enable smaller, iterative changes and adjustments on the fly
opportunities for bottom-up organization change that come with folks collaborating in decoupled systems
Lo's encouragement for all involved in content management - developers, managers, editors, and administrators - to work together
Lo's bio
Lo Etheridge is a Senior Developer Relations Specialist at Hygraph. They focus on developer education around Headless CMS, JS-based frontend and API technologies as well as the dynamic cross-functional relationship between developers and content professionals. Previously, they were lead web developer/programmer analyst and developer relations specialist in private and public higher education sectors. Before transitioning into frontend engineering and digital communications, Lo was a community social worker and public health educator in the field of harm reduction. They are a huge fan of David Lynch, Wu-Tang Clan and plays the theremin! Lo is passionate about digital ethics, community building, transformative justice, collaborative learning, tinkering with the Raspberry Pi motherboard, and making experimental music.
Connect with Lo online:
Twitter
lo dot etheridge at hygraph dot com
Video
Here’s the video version of our conversation:
https://youtu.be/L4wSDVrkGbc
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 165. The arrival of decoupled technical architectures in general, and in particular the fast-growing adoption headless CMSs, creates a whole new batch of people-management and organizational-change issues. You don't typically look to a software developer for help in such matters, but Lo Etheridge is not your typical developer. Their background in social work and conflict resolution lets Lo bring a unique and constructive perspective to these new challenges.
Interview transcript
Larry:
Hey everyone. Welcome to episode number 165 of the Content Strategy Insights podcast. I am really excited to welcome to the show Lo Etheridge. Lo is a lead or senior developer relations person at Hygraph, which is a content federation CMS. Welcome Lo. Tell the folks a little bit more about what you do there at Hygraph.
Lo:
Great. Hi Larry, thanks for having me. Like Larry said, my name is Lo. I'm a senior dev rel at Hygraph, and I work on a variety of things. I make a lot of technical content, tutorials and guides. I talk a lot about the content editor experience and the collaboration between developers and editors. Things like that. But I think what is more interesting perhaps, or unusual, is that I have sort of a very unique segue into tech. I started out as a social worker in the field of harm reduction and community based research and program development. So I transitioned into tech from working a lot with people of various roles, and situations, on a team together, leading those teams and getting them to all accomplish a single task, right? Even though these folks are all in different places in their lives, for instance sometimes on my team I would have two post docs. I would have a nurse. I would have folks who were in active addiction recovery, people who were active using, interns of all different kinds. And we would all need to work as a team to accomplish our goals, and it taught me a lot about how people work on teams, and how folks work together, and how you have to communicate information in a multitude of ways, depending on who you're talking to.
Larry:
Well that's why I was so excited when I first met you. I can't remember how we first met, but we most recently hung out at the Decoupled Days conference. And I was just like, wow. Not just people focused, but somebody with a deep background in people stuff coming to the content world. And one of the things we talked about, well I just want to talk quickly about the context for that, because that conference Decoupled Days is all about decoupled web architectures, and the new world of the headless CMSs that you all sell at Hygraph.
Larry:
But also the people stuff that comes along with that. You said this brilliant thing at the conference, like yeah the architectures can be decoupled, but we've got to keep the people coupled and recoupled as necessary. Can you talk a little bit about... there's so many things, we talked before we went on the air about content modeling and other activities. But what are the main people challenges you see as you're out there in the world helping people understand Hygraph and headless CMSs in general?
Lo:
Let's see. There are a few, and I think some of the big ones are these content silos, and the disconnect between teams within an organization. Sometimes you'll have the marketing team, and they're working on something, and you have another team, and they might be working on the same overall organizational project, but neither one of those teams knows what type of content they're writing, where they're getting their raw data or original source information from, and a lot of times that creates a lot of duplication of effort. So you see that a lot. You see this disconnect where teams should be coupled together in an organization, working to accomplish the same business level goals being siloed off and not really having visibility.
Lo:
So I think visibility is a key idea, and visibility is a multilayered thing. You have for instance developers. They sometimes don't have visibility in a literal way, meaning they don't know how the things that they are building are actually working in a practical context. So this tool that they built or the CMS that they built, how are the folks who are actually going to use it within the organization, how does that fit in with their process and workflow? You see those disconnects I think, and I don't know that without some sort of education and really pushing that sort of collaborative effort, that federation by itself fixes that. You really have to, along with the technical federation, you have to actually literally... The true definition of federation, which is these autonomous states and groups linking together to accomplish one overall or many overall goals. So that also needs to be in place for really I would say any technical implementation, but particularly when we're talking about effective CMS and great editorial experiences.
Larry:
Yeah, and as you say that I'm realizing that the concept, like you just distinguished between the technical federation and the human federation that needs to happen. And the first is a relatively easy technical accomplishment that many folks are working on. But the human part of it is so much more interesting. And one thing I want to back up a little bit and talk about, I don't know that all of my audience knows exactly what a developer relations person does. So maybe if you can talk just a little bit, because typically as the name implies, you're focused on developers. But you are unique, if not unique, but special, in that world, in that you focus as much on the editorial and authoring experience as you do on the developers. So can you talk a little bit about the context of your work with the humans in these various organizations?
Lo:
Sure. So there are lots of different developer relations, dev rels for short. Developer advocates you'll hear, sometimes you hear developer evangelist. And really we as a group are tasked with maintaining a good and continuous relationship with developers who may use a specific product, or a specific program language, and really straddle a multitude of teams and organizations that have dev rel or dev advocate teams. So for instance, the team that I'm on, we are part of the marketing department, but we also need to liaison with the support engineers who are in the community helping developers use our platform. We are also integrated with the product team. We're integrated with the technical writing team, with the sales team. So it's really this interesting straddle between technical ability, developer skills of some kind, because there's dev rels of all different kinds of technical platforms and languages and so forth.
Lo:
But it's a cross between that, but also very diplomat-like. In many ways,
