Autogram: Content and Design Systems for Enterprises – Episode 84

Podcast: Play in new window | Download

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

Orchestrating the strategy, design, and software work that comes with enterprise-scale digital projects is a complex and painstaking mission. It’s hard to imagine a team better equipped to take on these challenges than the founders of Autogram.

Karen McGrane, Ethan Marcotte, and Jeff Eaton have each mastered huge swaths of digital business practice.

Karen built the venerable UX and content practices at Razorfish and has arguably done more enterprise content strategy work than anyone else on the planet. It’s hard to find a content strategist who doesn’t cite her as a mentor or source of inspiration.

Ethan introduced the now-ubiquitous practice of responsive web design ten years ago. He’s working now to develop a holistic approach to creating design systems.

Jeff is an accomplished web developer and content management systems expert who has guided the content strategy for many of the largest sites on the web.

Together they help digital teams collaborate more effectively.

We talked about:

• Karen’s background as a content strategist and information architect and her pioneering work building the user experience practice at Razorfish
• Ethan’s background as a front-end designer and developer and the creator of responsive web design
• Jeff’s background in content management systems and web development and his work in content strategy
• how their identification of common concerns across content management systems and design systems led to them getting together as a team
• the Venn diagram that describes their overlapping skills sets: Karen in strategy and design, Ethan in design and software, and Jeff in software and strategy
• the challenges of getting content management systems and design systems to work for the whole organization, not just the content and design teams
• how to move from thinking about artifacts like websites to higher level design systems that have a broader impact on the organization
• how hard it can be to keep content, design, and tech teams aligned over the course a digital initiative
• the “tangly” challenges of implementing a decoupled content architecture
• the interplay between decoupled-content systems and pattern-oriented design systems
• the importance of focusing on the back-end authoring experience and of aligning on language and labels across different parts of the organization
• how to align teams on a collective shared understanding about design pattern language
• the tools and approaches you can use to help different teams develop a shared understanding of the concepts in a big, complex digital project
• the hazards of having complicated systems being led by any one discipline or team
• the challenges of scaling content strategy and design practices
• the ongoing thinking among enterprises that technology will fix their problems, when in fact it’s 80% people and process work that needs to be done
• the ongoing work in the design world to develop a common language around building design systems
• the importance of shared language and grammar across the span of big complex digital initiatives

Karen’s Bio

Karen McGrane identifies and solves problems with content management and user experience design across print, web, and mobile. She has partnered with some of the world’s largest enterprise businesses to streamline their digital operations and governance.

Follow Karen on Twitter.

Ethan’s Bio

Ethan Marcotte works at the intersection of design and front-end development, to help organizations design and build sites and services that can be accessed by everyone, everywhere. Notably, he introduced the world to responsive web design.

Follow Ethan on Twitter.

Jeff’s Bio

Jeff Eaton helps large organizations understand, model, and manage their content. Whether he’s fixing problems with CMS architecture or editorial workflow, his solutions sit in the overlap between design, communications, and technology.

Follow Jeff on Twitter.

Follow Autogram on Twitter.

Video

Here’s the video version of our conversation:

Podcast Intro Transcript

If you’ve browsed the web anytime in the past 20 years, you’ve benefitted from the work of the founders of Autogram. This power trio of digital talent includes Karen McGrane, who built the legendary content strategy practice at Razorfish; Ethan Marcotte, who introduced the concept of responsive web design, and Jeff Eaton, who probably had a hand in the strategy behind the last big content system you accessed. Everyone thinks technology will fix their problems. This team knows how to tackle the human issues that derail digital progress.

Interview Transcript

Larry:
Hi, everyone. Welcome to episode number 84 of the Content Strategy Insights podcast. I stuttered a little bit there because I’m so excited about this suite of guests that I have today. I’m really happy to be joined today by Karen McGrane, I’m going in the order that they’re on the screen here. Karen McGrane, Ethan Marcotte, and Jeff Eaton. If you don’t know who these people are, you should probably get out more, but I’ll let each of them briefly introduce themselves. Karen is best known as the person who says that, “On a good day, I make the web more awesome. On a bad day I just make it suck less.” So welcome Karen, tell the folks a little bit more about your background and how you’re associated with these guys.

Karen:
Larry, thanks for having us on today. So I’m Karen McGrane and I am an old school content strategist and information architect. I’ve been working in this field for about 25 years, and I ran the user experience practice at Razorfish for about 10 years and since 2006 I’ve been doing my own consulting firm called Bond Art + Science. But I’m thrilled to be here today as I have just started a new business with my friends and colleagues here, Jeff and Ethan. And we’re really excited to have a chance to talk to you all about Autogram.

Larry:
Great. And Ethan, anybody who’s been on the web in the last 10 years has benefited from your work in Responsive Web Design, and I loved . . . But you probably do other things besides set out standards for fluid grids and flexible image sizes and stuff like that. Tell the folks a little bit about how you got to your point in your career.

Ethan:
I mean, I’m still trying to figure it out, Larry, but it is very nice to be here, I will say that much. My name’s Ethan Marcotte, I’m @beep on Twitter or @RDW if folks don’t like GIFs. And I’ve also been working online for about 20 years now or so, and I’ve been spending most of that time as sort of a hybrid front-end designer and developer, and I might be best known to some folks in your audience as the person who coined that term Responsive Web Design, and that kind of overtook my practice in the last few years, and has been working with more teams on bigger and bigger digital products and working with them on some design systems consulting as well, started seeing some issues and started talking with Karen and Jeff about some of the similar issues they were seeing and that’s kind of how Autogram got started. So, glad to be here.

Larry:
Welcome. And Jeff, you first came to my attention as a podcast role model with your Insert Content Here, but you’ve done a lot of other stuff too. Tell the folks a little bit about your background.

Jeff:
Yeah. So probably about the same timeframe as Ethan and Karen mentioned, I’ve been doing web and web-adjacent stuff for probably 20 to 25 years. But I came at it originally from a journalism and what we would now say is content creation background and got into content management systems and web development just via the early days, when if you wanted to make, “a home page” that meant you had to learn how like a server worked and stuff like that. And just over time, I ended up getting deeper involved in the content management world, and probably about maybe 10 years ago or so, started coming back full circle as the content strategy world was really starting to take off, and it felt like coming home in a lot of ways because I’d spent all this time building structures and systems and tooling to support these things. And I was seeing all of these problems that I saw on projects, that came down to these strategy and content-centric questions, not having been answered effectively off the line before a specification for a website got handed down.

Jeff:
And that’s how I started digging deeper into these issues. I think Karen, Ethan and I have crossed paths on a number of smaller projects and just as colleagues talking about some of these things. And probably over the last year or so, as Ethan said, there are some of these emergent interesting challenges that we’ve all been seeing coming to a head on similar projects. And we started talking about them and saying, “I think there might be some patterns here, and I think we could maybe do something about this.” And that’s how Autogram got started.

Larry:
Nice. And I love that you said that you’ve identified some patterns and some challenges, and you decided to put together this team to handle that. Are there sort of top level concerns that you all have that you are hoping to address with Autogram?

Jeff:
Like areas of specialty?

Larry:
Well I guess, I’m thinking one of the things that, Karen, you talked about this in a recent, I think your LinkedIn . . . I read so much preparing for this I can’t remember where I saw it, but you were talking about the need for systems and for a different approach to things, and figuring out how to scale it. I think that’s what I’m excited about when I look at the three of you together, when you look at the overlap in your backgrounds and the actual opportunity to achieve what we see conceptually, is the way we should be doing and could be doing content strategy and content management. I think this is the team that actually do it. Is that where you came from?

Karen:
I think one of the conversations that I have with Jeff Eaton a lot is around philosophically what happens with the content management system and where are some of the pitfalls that you see as it gets more widely adopted, and people start working against the grain of what we think they’re, “Supposed to be doing,” to actually achieve their goals. And I think in our conversations with Ethan, there’s been a lot of very similar conversations around what’s happening in the design systems world. So as design systems have become the hot new thing, I have a sense that there are some conversations that are happening conceptually or philosophically about how they work, but a lot of the actual tactical things that are being done are very much focused on tooling and processes for designers or developers.

Karen:
I think that if we look at what’s common between content management systems and design systems, I think is a lack of focus on some of the higher order concerns around, how do you get traction? How do you get adoption? How does this evolve over time? How do you plan the rollout? How do you plan for long-term success? And I think that’s the type of challenges that we’re looking to focus on. I don’t know, Ethan or Jeff, do you have anything you want to add to that?

Larry:
I would love to hear Ethan’s perspective on that because it sounds like we’re trying to do this top to bottom connection from the front end all the way down to the deep bones at the base of it, the strategy and the structure and everything. Ethan, can you speak to them?

Ethan:
Yeah, I mean, I can try to. I mean, one of the reasons that Karen and Jeff and I started talking last year was after a few years of working on a number of design systems, it was striking to me that from a design in front of the implementation side, for the most part a lot of product teams, and this is a broad generalization, but the idea of content is really about, okay, well, there’s the text we need to fit into these design patterns, these little modular interface bits that we’ve documented. And all that planning and strategy that has gone into actually defining some of the structures that the design team was ultimately working with was obscured a little bit by the fact that we had to create these modular pieces of design. And so it was just interesting to me that these two conversations were happening, but not actually really ever connecting. And so that made a nice segue into actually syncing up with Jeff and Karen a little bit.

Larry:
Right. And Jeff, I don’t know how you divvied up your roles there at Autogram, but you seem like the guy in the middle on that, what we were just talking about there, the CMS, I apologize if I’m mischaracterizing you, but like the CMS guy in the middle of stitching together to design and the strategy stuff is that-

Jeff:
That feels like a terrifying hat to wear. But it’s funny, we’ve actually talked about this, where the different perspectives and backgrounds and expertise we bring to it fit together. And I think we envisioned it as a Venn diagram more than a stack, I think. It’s like there’s content strategy, there’s essentially a software development component to this, and then there’s a design component to it. Any large scale, web or digital project has those pieces to it.

Jeff:
And all three of us, it felt like we had lived most of our careers as an overlap point in two of those. Like with Karen, the intersection of content management systems and contents, I’m sorry, of design and content strategy, my role in the content management system space was more at the overlap of the strategy and software side, and Ethan’s background was more bridging that software and design side. And we’ve individually, we’ve seen so many situations where different teams and different areas of practice and areas of specialty failed to connect and failed to bridge communication planning, and just vision gaps in projects, and the work that was going on in those different silos just got stitched together at the last minute.

Jeff:
It was like the image of building the train tracks across the country, and you get to the middle and you’ve got to make sure that the tracks actually line up. Felt like so many projects had that moment where it became painfully clear that different silos of experience and knowledge, not even talking about pure business and political divides inside of an organization, but just the areas of practice weren’t coming together as effectively. And I think that has really shaped how we see it. It’s not so much a stack of backend to frontend as different overlapping spheres of complementary interest.

Larry:
That to me, makes perfect sense, and you set me straight because I was picturing Jesse James Garret’s layers, and the Venn diagram makes a lot more sense, at least in terms of pigeonholing you all. But what you were just saying, takes me back to Karen, what you were saying earlier about the need for a higher order look at systems, or tell me more about that, what you meant by the kind of higher order thinking and work that needs to be done to pull all this together.

Karen:
Well, one example would be how content management systems always get sold with a feature checklist, and vendors are constantly competing to make sure that they can tick all the boxes on a big grid of what features they have, when frankly, that feature checklist is, if not just irrelevant, but sometimes actively harmful in figuring out how the system is going to work for your team, and what the processes are going to be. I think that design systems suffer a little bit from some similar thinking where it’s very much focused on, “Are we going to use React?” and not on, “How is this going to work across our entire organization? How do we ensure that teams from marketing and product and across the entire business understand what we’re trying to do here?” And so it means that a tool like a content management system or a design system winds up being really siloed as a tool that is intended to help only the people who use it.

Karen:
So a front end developer’s job, or a designer’s job is slightly easier because they have the system, or the content entry people have a slightly easier job because they have the system, but it doesn’t ever actually touch the way that the rest of the business works. And so, like Jeff Eaton was saying there’s a lot of problems that start to emerge on the margins there, as the systems need to work with other groups, no one’s really planned how that’s going to happen, it often doesn’t work very well. And I think when we’re out talking to organizations, we really try to position ourselves as helping to understand how that system is going to exist and live over the long term and what the overall process is going to be, or the overall strategy for working with it is, not just, “Hey, we built this tool within a beat.”

Larry:
Right. And there’s so much just in that, what you just said, that’s a whole podcast episode right there, just unpacking those last few sentences of yours. But one thing, well, two things about it, Ethan, I saw your head nodding the whole time Karen was talking, so I want to get in to see what you were thinking there. But I think that one of the bigger things there is that this is so much about people and organization and organizational change management, not so much a technology thing, ultimately, but everybody thinks of it as a technology thing. But Ethan, back to you, why was your head like it was like a bobblehead going there?

Ethan:
Sure, Sure. Well, I mean, I do that most of the time when Karen talks, but it was making me think of the fact that I think for the last few years, the perspective on design systems specifically has really been on thinking about it as an artifact, that we’re going to produce this really beautiful website that’s going to show how the system breaks down in individual components and then they stitch back together without having that broader conversation about why the organization is rallying behind this as an initiative that’s worth investing in, and how our individual product teams are going to be working with us on a day-to-day basis.

Ethan:
There’s all these conversations around how different teams are going to be feeding contributions back into it, how we’re going to gather feedback from teams to see if there are any gaps in the system that tend to be a bit of an afterthought for a lot of these organizations. And so that higher level thinking that Karen’s talking about it is something that I think ultimately needs to be one of the first conversations that happens as part of the design systems process and that’s one of the conversations we’re having with clients right now.

Larry:
Well, that gets to another… just comes up all the time with every content strategist I talk to, is that, that issue of the seat at the table and getting access high enough in an organization, that you can have those broad impacts. Do any of you have insights into how to crack that nut?

Jeff:
Keep having the conversations. I think it’s especially challenging because the problems that make it apparent that those conversations need to happen early are often only seen maybe six months, nine months, a year into a project that actually results in these things being built out. So there’s a certain point at which, if an organization has been sold on the idea that a given project or a given product suite or something like that is going to solve the problems, the real tangly issues that occur down the line, things like, “Oh, hey, we’ve got a marketing team that’s been planning out our content and we’ve got a design team that’s been planning out our design system and we’ve got an IT team that’s been evaluating CMSes, and we’re six months in and they haven’t been talking to each other aside from occasional requirements check-ins. And there’s not really a shared understanding of this thing that we’re trying to make, and suddenly nothing matches.”

Jeff:
Those kinds of things aren’t necessarily apparent until they’re encountered. And I think those are the conversations that it’s very hard for people who are in the trenches, in any one of those individual silos to escalate up the ladder in a timely fashion, in a way that’s early enough to make it clear that, “Hey, a change of direction organizationally needs to be made here.” And I think to a certain extent, that’s why we’re working really hard to talk to organizations that are fairly early in the decision making process about something they’re going to be launching or a project they’re starting to initiate. It’s not so much that we have any desire to run a giant effort, it’s that so many of those decisions get baked in early, and you have to start that dialogue process really, really early to avoid oversights getting baked into a plan-

Larry:
One thing that occurs to me, oh, sorry, Jeff. But one thing that occurs to me as you’re talking is that it seems like some of the new tech… this is mostly about people and processes, but technology can help us out of this sometimes it seems like, and some of the recent advances, well not so recent, but growing advances in things like headless CMSes, or decoupled CMSes, and even responsive web design – disarticulating things from one another so that you can still have your silos, but there’re systems and methods by which you can stitch it all back together. Does that figure into your grand plan in Autogram?

Jeff:
I mean, I’ll just say hard yes. I think in that mix, I’m particularly familiar with the decoupling/headless discussions because that’s been a heated debate inside of a lot of, not just development communities, but inside of the CMS ecosystems for open source and even closed source products and stuff like that. To what extent should we emphasize we are a headless content store that people can just put stuff in and do whatever they want with? To what extent should we try to build differentiating features on top of that that require deep integration with the front end? I think one of the underlying challenges is that building and implementing a really successful decoupled architecture requires answering lots of tangly questions about why the content is what it is, what the intent of it is, what longevity expectations do we have? What are the different things that we ultimately want to do with it?

Jeff:
Those are all questions that need to be answered for even a highly-coupled, highly-integrated CMS that handles everything front to back, but decoupling initiatives tend to be treated as like a forcing function for those conversations. They get treated as, “Oh, well, if we go decoupled and we’ve got to build a content API, that’ll force everybody to have these conversations and we won’t have to make a philosophical political case for it.” It’ll just be, “Everyone likes decoupling now, it’s hot and we’ll have to do this.” And sometimes that’s true, but there’s nothing magical about the technical architecture of decoupling that says, “Good decisions will be made in response to those questions.” It’s very easy to say, “We’ll just do what we have to do to get this out the door.”

Jeff:
And then you’ve got a system that is technically decoupled, but you won’t really recognize the benefits that you were hoping for. So, yeah, I think that’s a big part of it and at least for me, the interplay between decoupled-content systems and pattern-oriented design systems is really fascinating because when I really started chewing on some of this stuff a couple of years ago was a project where an organization had a huge shared content library. They were building a content API on top of it, and they had, I think somewhere between eight to 10 different distinct brands with their own design approach, that they wanted to all be able to consume this content. And they wanted editors to be able to assemble stuff and work with it on a shared system. But then on the front end, they were going to be different brands, different app channels, stuff like that.

Jeff:
And it forced careful conversations about what kinds of choices are inherent to content creation. What kinds of choices do we want the aesthetic layer to be applying. When we talked about like how things get assembled, that has design implications, but it’s also part of the meaning of the content. Negotiating where those lines are and why the choices are being made is really the heart of a lot of those successful systems.

Larry:
Hey, I want to get to two follow ups on that first with Karen. Karen, you talk a lot about how important the backend is, and considering when you’re having editorial workflow be a really early consideration in any strategy. So can you speak a little bit to that part of what Jeff was just talking about that?

Karen:
Yeah, I think that what Ethan’s describing as a forcing function is something that, I’m just out there constantly trying to push people to think about, how is this content structured? What is the experience on the backend? How is the author or the editor of this content going to be interacting with it? And I would say that first I think there’s been much more focus on creating a better author experience in the half dozen years since I’ve been talking about this pretty a lot. One of the things that I’ve seen more clients do is get their content editors and the authors involved in usability testing a new CMS, and really focusing on making sure that they understand the labels, that the fields make sense to them. That they’re the right fields. That it’s not just a thing where some developer threw every possible field on the screen and the author supposed to pick through them and figure out which ones they need.

Karen:
I also do think that the trend toward the coupling can also mean that there’s more flexibility on the backend and that that author experience for a lot of the decoupled tools, like I’m on the advisory board for Contentful. I think it’s because it’s not so much of a monolithic system, the editor experience with the author experience can be a lot easier. But honestly the parallel that I see the most with is when you talk about things like naming or labeling, and what does that experience mean for the person who’s entering fields of the CMS, or what does that mean for the person who’s attempting to understand the purpose of a design pattern, unless that language is shared, and clearly explained, you’re going to wind up with a lot of misunderstanding and people are going to call things different things.

Karen:
And I think that’s one area where organizations really need to pay a lot more attention. Some people refer to it as like micro content. And yes, you can describe those labels as micro content, but really it’s about having those conversations and the shared understanding across the different groups in the organization, different business units or different silos to make sure that you understand why people call things a certain thing and where somebody is going to get really angry if you rename it.

Larry:
Yep. Yeah. Ethan, can you speak to the other side of that? Actually one specific question I have is, to what Karen was just talking about, in your work as a designer and just your colleagues in general, I’m wondering what percentage of your work is geared towards front-end design, the end user experience and how much you focus on that internal enterprise, internal user experience?

Ethan:
That’s a great question. I mean, I think there’s been a shift in the last few years. While I was listening to Karen a little bit, I was reflecting on the fact that most of my design systems work has been working with product teams to help them develop that shared language around what this design system is actually going to be referred to as internally, so that I’m naming these patterns in a collaborative context, for example. So when you’re actually thinking about a specific piece of the interface, rather than letting, let’s say, the engineering team come up with a name for that object, having a conversation with more disciplines, across the board to actually say, “Okay, well, here’s the purpose of this pattern, and here’s what it’s meant to be used, so maybe this is the most logical name for this object.”

Ethan:
The benefit of that exercise is that it creates a collective shared understanding about why this design pattern is important, not just to the page or to the interface, but to the broader team, because ultimately you want somebody who’s going to be able to make a situational decision about why that’s important and to use the right pattern at that time. So anyway, I was just listening to Karen talk about that higher level vocabulary that needs to develop and thinking a little bit more about the fact that what I’ve seen on the front end, it’s really been like trying to make it as cross functional as possible and get more people involved in the definition process.

Larry:
I guess, for all of you, do you have tools that you use because this issue of alignment, to what you were just saying, everybody using the same language talking about the same thing in the same terms? I’m all of a sudden thinking about internal metadata, about, “No that’s what we call this” when we’re talking about that, but anyhow… or building things like domain models or content models, these higher level models that help everybody stay on the same page. Do you all have favorite tools or techniques for doing that work?

Jeff:
Boxes, lines.

Karen:
Spreadsheets, you can have spreadsheets.

Larry:
You have to say spreadsheets in a content strategy podcast. So thank you for getting that out.

Jeff:
Well, I mean, it’s funny because that question of, what is the best tool to capture a complicated thing that lots of different team members look at from different directions and see different angles of? I mean, I think, one of the early content strategy articles that got published on… at least a part talked about that, blind men describing an elephant metaphor. And I think one that I’ve used when talking about the challenge of content modeling a lot is maps of a city. Is a satellite photo from Google Maps the real view of Chicago? Or is a street map? Or is it a population density map? Or a blueprint from the 1800s of what the subway tunnel layout was? Which of those is the real map? And I think the answer is always going to be, yes, and none of them, because the thing is something bigger.

Jeff:
I think I’m trying to remember the article that I picked it up from, but I know Ethan was the one who ended up sharing the link initially, but it’s like a hyper object. It’s this many faceted thing, that the reality of the system we’re building and working with is the only perfect, accurate, description of itself. And what we’re trying to do is not make a perfect blueprint in exactly the right document or tool, it’s figuring out what the right questions to ask are and what the right ways to communicate the answers are, so that all of the people who are involved in this, that all of the different teams that are working on different parts and pieces of it can know that they have the same shared understanding of that thing.

Jeff:
And that when we talk with each other, we’re on the same page and we get it, and that if I have to make a judgment call, I have a fairly high degree of certainty that that judgment call is going to be compatible with the judgment calls they’re making over on that team. Those kinds of things are more the guiding factors than, what’s the best tool? And then it usually turns into spreadsheets and diagrams and maps.

Larry:
Ethan, were you going to say something?

Ethan:
Oh, no, I was just nodding along because Jeff recited one of my favorite articles about design systems in the last year. So, yeah, it was Robin Rendle who wrote about the hyper object of designs systems, because I think the feeling from a lot of independent contributors who work on design systems, is they were only able to perceive the smallest slice of this massive thing that dwarfs their work and giving folks, I think, visibility into the breadth of the system, but also confidence to make situational decisions when they need to is something I’m really interested in as somebody who’s been involved in that world for a while.

Larry:
You both just reminded me of a slide in a presentation at Seattle Interactive Conference a year or two ago. They had a… if you hover a cylinder in the air, if you project light onto it from one side, it projects a rectangle on a wall, you project it from the end, it projects a circle on the wall. They’re both true, but the truth is the cylinder in the middle. I think that’s what-

Jeff:
Yeah, 100%. And I think a lot of the danger in having complicated systems like this, entirely led by one particular discipline or one particular team, is that, what perspective is it being looked at from question? You may build the world’s best square, but the problem is this cylinder and making sure that those different teams and perspectives are part of the understanding process. Is it just a way to get political buy-in or make sure things are less bumpy in the rollout. It’s a way to make sure that you’re actually getting the big picture.

Larry:
Hey Karen, this morning I read your whole list of Tweets of all the projects you’ve worked on, and I was exhausted afterwards, just thinking about it, but, I mean, in terms of fingers in projects, you probably have as much experience as anybody. Do you have any top level insights as to solving this issue we’re talking about?

Karen:
So, I worked with a lot of very large enterprise clients with my day, and they’re all equally broken. Sometimes clients will ask me, “Are we the most messed up client you’ve ever seen?” And I’m like, “You don’t know what I’ve seen.” I think that one of the things that tends to bubble up from the industry is that small teams, maybe working at startups or in a much more focused environment adopt new ways of working or start writing and speaking about, “Oh, here’s what this technique that we have.” And then these big monolithic enterprise organizations try to adapt that to their highly fragmented, highly siloed, highly complex working arrangement. And as we say, it just doesn’t scale. I think that for a lot of these organizations, I think it’s always going to be a little bit of a struggle for them.

Karen:
The challenges that I’ve seen across, we have a whole mess of unmanaged content. We have 11 David Julian PDFs, that nobody knows if they’re even useful or not. We have 3 million different domains run by different organizations that all look and feel different. Those challenges, I don’t really think it’s not like they’re ever going to go away, but I do think that with some of these approaches with a more refined and a more reasonable approach to content management with some of the opportunity to systematize things with design systems, some of those pain points can be lessened. And I think it really is understanding and respecting the complexity of those large organizations and not trying to say, “Hey, something that worked for a startup is going to work great for you too.”

Larry:
And just a quick thing to that. My big intent in doing this podcast is to democratize content strategy to take all this knowledge that you have, but a friend very wisely, I think told me a few weeks ago, he said, “Larry, forget it.” He said that a lot of the people you’re talking to like at Facebook and Google and some of the big enterprises, he’s convinced that they’re not learning their lessons and that I might be disseminating bad information. I don’t think I’m getting that from you guys, but I think that can work the other way, that smaller players… a similar dynamic to what you were just talking about, Karen, that you can think you’re learning from somebody else, but because everything is bespoke in this world that maybe you’re not getting the exact right lesson you need. Does that make sense?

Karen:
Yeah, I think the most consistent thing that I see everywhere is that people think that technology is going to solve their problems. And they think that, “Oh, if we hate our current content management system, the solution is to tear it out and put in the new content management system.” And, your technology is not your problem, you are your problem. Your people are the problem. And unless you really recognize that 80% of the work is going to be in figuring out, how does this process work? Who is involved? Who gets to make decisions? How does things change and evolve? What’s the governance model for it? If you do all of that work, then the 20% of the work that you put into building the new technology will go a lot more smoothly, it will be pretty easy. But if you continue to believe that you can just write a 10 million-dollar check to Adobe and your problems are going to go away, well, now you have two problems.

Larry:
Yep. Hey, one thing to that, Ethan, from the design perspective, I listen to podcasts endlessly, and I hear these kinds of conversations much more among like Jeff and Karen in the content strategy crowd. Are there similar conversations happening in the design world about these communication and organizational issues?

Ethan:
Yeah, absolutely. I mean, a big influence on me was two women in particular all
Alla Kholmatova and Charlotte Jackson who both wrote some pretty important pieces a few years ago about the fact that design systems perspectives were I think, siloed by and large, on very small subsets of the teams that were maintaining them. All the Alla Kholmatova wrote a fantastic book on design systems a few years ago, where she basically said that, The modular design patterns that you’re documenting, that’s not your design system. I mean, that’s one component of it, but it’s the broader, shared practice. It’s how your team actually interacts with and works with those patterns. And that’s, what’s actually defining a design system. That’s what elevates something from a collection of front end snippets into a broader system that your teams can power your products with.

Ethan:
And that was incredibly influential in me, because I was starting to see a lot of these linguistic disconnect between how teams talked about these systems, talking about atoms and molecules, and another team would refer to everything as organisms and there wasn’t that shared language across the board about that, that said, “Okay, this is why we’re making these decisions, and this is how we can actually implement on these systems.” So yeah, these conversations are just now starting to happen and I think it’s past due.

Larry:
Yeah. Hey, you guys I just noticed, I try to keep this around the half hour, we’re well past that, so I want to wrap up pretty quick. But what I want to do, I want to give each of you a chance before we wrap up. Is there anything last, anything that’s come up in the conversation you want to follow up on, or that’s just on your mind about what you hope to accomplish at Autogram or just in saving the digital world from itself? I guess, again, I’ll go in order on the screen, I’m sorry, go ahead Jeff.

Jeff:
No pressure.

Larry:
No pressure at all, but yeah, anything last from each of you or?

Jeff:
I mean, I think I would probably want to note, one of the things that came up in what both Karen and Ethan said was that idea of the shared language. It’s a phrase that comes up all the time, both in coordinating projects, and on the content strategy side, and on the design system side, and even in the software development side, like in domain-driven development where the big themes is this idea of building a language that the team can use to talk. And it’s been interesting as we’ve reached for better metaphors for talking about these systems that we’re putting together, that language and linguistics has been a really interesting one to turn to because it implies more than just pieces that have to be stuck together in some way. There’s not just the vocabulary, the nouns that we slap onto things, but there’s also an inherent grammar to a real functional language.

Jeff:
It’s not just, we call this, this, and we call that, that, it’s how do we use them together? How do we talk about them? What is a meaningful and correct way for these things to click together and work with each other? And again, from the linguistics perspective, how does this evolve over time? How much are we prescriptively saying what we think something ought to be? And how much are we describing the real world usage of a particular thing? How do people actually use this word, to use that metaphor? And I think that’s been very interesting and figuring out ways to take that evolving progress-oriented way of approaching that, how to take that seriously as a metaphor is something that I think has a lot of promise and-

Larry:
This always happens, Jeff. Jeff, you’re making me think of a whole episode on semantics, but I hope we can revisit that conversation sometimes. Ethan, did you have anything you wanted to say before we wrap up?

Ethan:
I could not possibly follow Eaton, I mean, that was fantastic.

Larry:
Okay. Well one last thing, I want to make sure folks know where to follow you online. Do you have social media places you like to… or what’s your best place to connect with folks? Karen.

Karen:
You can reach me on Twitter, I’m @KarenMcGrane and you could also follow the Autogram account, which is @autogram_is.

Larry:
Great and Ethan.

Ethan:
Yeah I’m @beep on Twitter, and yeah, yeah.

Larry:
Great, and Jeff.

Jeff:
I’m @eaton on Twitter and as Karen said, @autogram_is is the collective on Twitter. And I’m sure you can find us a rabble-rousing and vigorously discussing most of these same things online.

Larry:
It’s hard to miss you all online, I will observe that, which I appreciate. So thanks for being so active out there. Well, thanks so much to all of you for coming today. I really appreciate you taking the time out. I know you’re launching quite the empire there, so I appreciate you taking a little time to talk with me about it.

Jeff:
Well, Thank you. It was great being here.

Ethan:
Yeah, thanks for having us, Larry.