Lo Etheridge: Human-Centered Federation for Headless CMSs – Episode 165

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | Android | TuneIn | RSS

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:

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, dev rels are ambassadors between the product and the developers who use that product. And I think where I have come to since I fell in love with the niche area of tech that is content management systems is realizing that it’s the developers, but also that you can empower developers to really think about their whole organization, and specifically the people who are actually going to manage their content and create their content in the system that developers build. So I focus specifically on that relationship, because I think it is critical to the success of an overall technical implementation like a CMS.

Larry:
Yeah, Dean Barker famously talks about the reason people abandon and just hate their CMSs in general is that that kind of attention has not been given. The editors usually are typically ignored. Did you have to fight for that? It comes naturally to you with your background and your approach, but organizationally, and just in the profession of dev rel, was that a challenge for you, to become more people focused like that?

Lo:
I think that I am inherently as a person very people focused. My special interest is communication and human behavior, so I think a lot about how humans communicate with each other and how they relate to one another, and what it looks like when it goes well and what it looks like when it goes bad, and the effects of either one of those outcomes. So I just think about that naturally a lot, but I think that has led me through the path that I’ve taken in life. So one of the most impactful roles that I have had that has led me to my dev rel career now, in addition to my social work experience, was my first full-time, non-freelance developer role was at a large public university, and within that public university I was a part of a very small team that was basically in charge of pretty much all of the campus’s WordPress presence.

Lo:
And what ended up happening was we realized, oh, we’re doing custom development for the different colleges, for instance within the university and departments within that university, oh, but we also need to be doing lots of education. Because there is a disconnect between what we’re talking about and what folks are trying to do, and us understanding each other. So at first, we need to establish this shared knowledge base. So we started doing a lot of education, both at the administrator role of a CMS, and editor role, and also the developer. So providing education based on role within the context of how you use or build a CMS, depending on who you are. And that really opened up a world for me where I’m like, oh this is where the work is. This is where the work is, and figuring out how you can get editors and administrators and developers to communicate in a way that makes everyone in the group’s life easier.

Lo:
Because a lot of times it’s just about rethinking the problem, and coming up with a strategy that works for everyone. For instance, before we started doing these sort of classes and education around how to use the CMS and how to work with it, what we found was there was a lot of frustration from the in-college developers who were internal to a college or internal to a department, whereas we were part of central IT. And what we found was there was a lot of frustration there, because they were being asked to do things that they considered small content changes that took away from them actually building out requests that editors and administrators wanted. And on the same side, administrators and editors were frustrated because it took so long to get these changes, and also weren’t getting the sort of requests for new features and tools they needed to make their life better and help their work go faster.

Lo:
So working on that relationship and understanding, and having that pre-conversation. Developer at, let’s say it’s a college of, department of English. If you’re building out the CMS or you’re building out a process, don’t just think about how the tools that you are going to build and connect. Actually talk to the person who asked you to do this and figure out how they actually do their work currently. Because getting that visibility will help you build a better tool, and it will also help you both have a shared knowledge base and understand what the real task and goal is. And from that you can create some sort of encouragement and empowerment. And if you combine that with some education, you allow the editor or the administrator to make those content changes on their own, and you can build the ability for them to do that. And that frees up the developer space, and not having to put out those sort of fires, those quick content changes. They can actually focus on building the feature requests that you are asking for.

Larry:
Yeah, you’re describing the classic thing of, everybody’s unhappy in that situation, because it goes slowly because of the way it’s set up. And then the developer’s like, come on. I’m a developer. I’m not a content updater. But one thing as you’re talking about that, I had this insight the other day. I can’t remember, I was listening to a podcast or something, about one of these shifts from the old monolithic structures like WordPress and Drupal and Sitecore and all those kinds of monolithic CMSs to the more decoupled architectures is that… It occurred to me that it’s like in that world, at WordPress and Drupal, there’s this sort of technical thing that’s going on where you’re developing plugins or features and things like that, where the code, and the data in the code, it’s all conflated into one thing. Whereas in these decoupled architectures, it’s easier to tease out some of that stuff. Has that been a benefit? Am I thinking about that right? Is that one of the benefits of decoupled architectures, that moving from the plugin mindset to an API-sourcing mindset, is that kind of a fundamental thing that makes this human re-coupling easier?

Lo:
I think so, because it gives you the decoupled architecture, and combined with the ability to create a real content strategy and content models. Those things combined I think are major superpowers, because it gives you the ability to customize, and it gives you the ability as both a developer and an editor to fully create a process that is tailored to what you need to do.

Larry:
And you just said two of my favorite phrases, content modeling and content strategy. That my life right there. I’m glad to see that we intersect with that. One of the things about, content modeling, a couple of my favorite content modelers talk about the distinction between the activity of modeling your content, of talking to all the stakeholders, figuring out what’s technically feasible, what the users need, all the stuff that needs to happen, and then the building of the content model itself, which is a more technical activity. Does that differ now? Like you said, your first big tech role was that WordPress role, and now you’re in this fully decoupled world. How does content modeling compare across those experiences for you?

Lo:
I would say in comparison, in decoupled architecture and for instance in Hygraph, there is again, just the ability to customize much more, and actually create models that fit right into your business goals or needs. And I think that that is the power of decoupled architecture. However, I think that it’s important to note that those capabilities are there, but it’s up to education and pushing that behavioral narrative of how you go about content modeling, and how you come up with a content strategy. That is just as important as the actual technical tool itself, and I think that even though we have lots of decoupled architecture options out there, we still have maybe I would say a lot of developers building content models that are not necessarily informed by the rest of the folks who are within the organization. And that’s not the developer’s fault. It’s sort of again, the nature of how your organization works. And a lot of organizations, when they get really big they become very siloed out and there’s lack of communication.

Lo:
There is also this… I’m going to go off on a conflict tangent just for a second. So I’m studying peace and conflict, and really specifically conflict resolution. And there’s this concept of intractable conflicts, which is this, it’s a longstanding conflict that’s sort of… it’s not unsolvable, but it kind of has a stalemate, and it also goes in ups and downs. And I think that the developer and editor relationship can be very much that way, when communication isn’t good and when those relationships aren’t solid. You can have a disconnect between what is being built and what is being used, and those two groups don’t ever communicate or talk to each other. And it’s super important that we get to a place where, okay, we have just decoupled architecture. That’s fantastic, this is a great tool that allows us to make customer content models. We can customize our process.

Lo:
But if everyone is not communicating, it doesn’t benefit you as well as it could be. There are a lot of content models being built, like I said before, that are not informed. In which case, that’s not going to be ultimately beneficial for the developer in the long run, it’s not beneficial for the editor, and it’s not beneficial for the organization in the long run. Because you’re just going to create and replicate perhaps some silos that you already have. And I think that-

Larry:
I was just going to say, that’s been a frustration of mine when I watch the headless, decoupled world unfold. It’s not a huge frustration, because I think a lot of people are kind of… their models and and their workflows and stuff are replicating the old monolith, but at least they’ve decoupled it. There’s a separation of concerns. You have back-end developers working on the CMS and front-end developers working on the website, so bingo, you at least have that. But there’s still that, a little additional thing. But that dynamic you were just talking about, what do you call it, the intractable conflicts? It seems like there’s both an opportunity to address them in these new decoupled architectures, but also maybe some potential for new kinds of conflict or misunderstandings. I hope you have some success stories.

Lo:
I do for sure. And one of the things as far as the conflict, conflict can be positive and negative, and I think that very much that relationship, the relationship between developer and editor in its current status is very much an opportunity to be creative and to use technology, which I believe technology fully is just another tool for humans. It is another sort of tool or application that you can use to infuse collaboration into your organizational culture. Because at the end of the day, that is also what’s super important when you’re implementing. If you’re moving to decoupled architecture or implementing any new technical situation, what matters most in how you can make the most successful implementation possible is change management. And so when you get into change management, that is where it’s important to have a foundation of collaborative organizational culture. We have open communication. I know what team B and C are doing, even though I’m on team A.

Larry:
Yeah, when you talk about change management, so much of that, it’s like you need levers and ways to dive into that. I wonder if federation as a concept, as a thing, does that help in that sort of… Nobody’s going to bust silos anytime soon, but federation seems like a good way to span silos, to connect them. And that’s kind of what I’m thinking about. Does that make sense, that link between federation and change management?

Lo:
Yeah, because if we think about the actual sort of human aspect of federation, or what federation actually means, the literal definition of federation is a group of states with a central government, but independence in internal affairs. So if we apply that to an organization, all of the different teams would be the different states, and the organization itself is the central government. And I think that federation is two-fold. Content federation, or any other type of technical type of federation is best implemented when you have human federation. And I think that that is something that needs to be talked about more, is sort of how we bring these organizations and groups within organizations together and create those relationships. The human sort of model of all of this.

Larry:
I’ve seen that, and the change model there, or the change challenge, there is at least popping your head up out of the silo a little bit, if not fully leaping out of the silo and embracing your colleagues.

Lo:
Yeah. And as a developer, I will just say nothing has been more eye-opening and humbling as watching someone use something that I built. And I think that that is such an important experience that a lot of developers need to have, because one, you learn so much. And a lot of times, the ideal situation is that that happens during the process of you building it and before. You learn about the initial way in which someone you are building something for does their work. But it’s okay if that doesn’t happen. You can still iterate on that, and have that sort of insight later, and then iterate upon whatever it is you’ve built.

Lo:
And that’s what’s so great to me about decoupled architecture and federation is it does, because things are decoupled, it gives you that opportunity to iterate and make small adaptions and customizations as needed when you get new sources, or you get new insight or information. And that includes, oh, I thought this particular team or content person or editor was doing this this way. But it turns out when I watch them, and the goal or the task they actually need to accomplish is this, and what I built doesn’t quite match up with that. Decoupled architecture and federation allows you to make those adjustments more on the fly.

Larry:
Yeah, and that’s sort of like, it’s often rolled out as a generic benefit of decoupled architectures is that separation of concerns, that you can kind of do things in parallel and reduce some of the unproductive friction that can happen in these kinds of relationships. And then federation is, I guess to contextualize that, is more like that’s the new practice that stitches it back together.

Lo:
Together, yes. So re-coupling everything, and that includes re-coupling the organization, right? And also, sometimes the organization wasn’t coupled to begin with. That happens all the time. But this can be a way to sort of slowly on ramp and use this sort of technology and these tools to start the process of coupling your organization even if you didn’t have it prior too.

Larry:
A lot of that stuff has to happen top-down, but this seems like these relationships down below in these decoupled architectures, the necessity of operating in these new ways, it seems like there’s maybe a bottom-up potential for change. I think the real change is still going to have to have support from the top, but does that make sense to you? Do you feel opportunities in these new ways of operating that maybe can begin to span some silos in some of these organizations?

Lo:
I definitely think so, and I think that bottom-up approaches to something like federation can work in that if you have teams, and let’s say maybe upper management or other business leaders in the organization aren’t totally sold on it. But if you have, for instance, the developer team, and maybe one of the main content editing teams or the content editing team, if they all have buy-in as a group, they can be sort of a living proof of concept to show that this way of doing things works, and you can get buy-in from the bottom-up by sort of managing up and showing, well, we’ve tried this thing out. This works. Let’s try to implement it across the organization.

Lo:
But in general, I would say it’s best to have top-down buy-in too with your idea. But sometimes people need to actually see the benefits and see how it works together to get that buy-in. People might not always initially just give the buy-in just from hearing about it. These things can feel very abstract. But if you can show a proof of concept and you can show, and show how this increases productivity or it increases user engagement or these sort of things, then you have a very real concept, that this federation or decoupled architecture that we implemented really works, and it gets us these results. We also work more efficiently, which a lot of times can be quantifiable.

Larry:
Yeah, and that idea of show don’t tell, and start small, don’t boil the ocean, a proof of concept is perfect for that and a perfect way of doing bottom up stuff. Hey Lo, I can’t believe it, we’re already coming up close to time. These things always go-

Lo:
Oh wow, that happened so fast.

Larry:
Well yeah, think about it. At Decoupled Days we were talking for an hour. So anyhow, but before we wrap up, is there anything that’s come up in the conversation you want to elaborate on or just that you want to make sure that we get to before we wrap up?

Lo:
Let’s see. I think that I just want to reiterate that as a developer and now as a dev rel, I want to impress upon my fellow developers and the developer community to remember that you are building tools that humans are going to use, and to think about those humans. And also I think from the other side of the perspective, if you are an editor, an administrator, you can also engage in that process whether or not you’ve been asked to or not. And say, hey, I want to show you how I actually do work, because I want us to build the best product possible, particularly when it comes to something like a customizable CMS or our content models. And I think that that can quickly dispel and sort of deescalate any sort of friction that there may be, because it’s in pursuit of everybody in the group trying to work together and have the best workflow and process.

Larry:
I love that. I love the way you’re wrapping this up, by showing some of the benefits and new opportunities for collaboration that arise from this stuff so, well thanks. Hey, one v last thing Lo. What’s the best way for folks to stay in touch if they want to follow you on social media or connect?

Lo:
So you can find me on Twitter at @lowisren, L-O-W-I-S-R-E-N, or you can always email me at Hygraph. My email is lo.etheridge, which is E-T-H-E-R-I-D-G-E, @hygraph.com.

Larry:
Well thanks so much, Lo. Always fun to talk with you. I really enjoyed the conversation.

Lo:
Thank you, this was awesome. I could talk about this forever.