Ben Callahan 
===

~Yeah, test, test. Check one.~

~Testing, 1, 2, 3.~[00:00:00] 

Hello and welcome to Pod Rocket. The podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking and product analytics. You can try it free@logrocket.com. ~Uh,~ I'm Noel, and joining us today is Ben Callahan, founder of sparkbox. ~Um,~ Ben, can you give us an overview on, ~uh, kind of ~who you are and what Spark Box is?

Yeah, absolutely. My name again is Ben. I am, ~uh,~ an old computer science guy. I studied computer science growing up and then, ~um, kind of~ started a couple little businesses doing, ~you know,~ websites for the local companies ~and,~ and that kind of thing. Moved into doing some audio and video work. I made some short movies for a while ~and,~ and did, had a little recording studio doing music stuff and.

Eventually kind of found my love of, ~uh,~ user experience, ~you know,~ building, building front-end experiences, using most of the time kind of web technologies. And that's ~sort of~ what my business partner and I built Sparkbox to be, which is a, an organization that helps other [00:01:00] companies. ~We're~ we're client services or studio.

We help them with their, ~you know,~ digital experiences, digital products, and ~um,~ Yeah, so we've been in business, we're coming up on 15 years now, and, ~um,~ it's just been really, ~uh, um,~ an, a really fun opportunity. ~You know,~ I feel really lucky to have met so many, incredible, ~you know,~ both clients that we've worked with, employees that we've had, ~you know,~ on our team for a season.

It's just, I've learned a ton and continue to each day, ~so,~

~Nice. Can I being, being in that space for, um, 15 years, how do you like, keep, I dunno. Keep it interesting. Stay interested in the work you're doing so.~

~Yeah, I mean, I, I guess the, my role has changed a lot over the course of those 15 years, you know, so I mentioned computer science. When I started, I was a software engineer. But, and I, and I think I, I chose that career path because I, I like to build stuff and, um, part of what, part of what I think I, I'm looking for in life is, is that idea of build things.~

~And I want, I wanna build things that actually can make an impact in, in the world around me. So, to begin with, that was, You know, products. And then over time it's just been this kind of gradual shift toward what I'm building actually is, is is an organization that. Helps other people build products. So I think it's, it's kind of because my, my role has shifted and that was never just a direct, one day you're doing this, one day you're doing that.~

~It's been a gradual thing. It sort of has come with a lot of change each year, you know? And so for me now, instead of writing code, I do a lot of writing words. You know, I, I, I think, and I write and I do tons of research, and I, I get a chance to talk to people. In specifically in design system, uh, space, you know, who are like, trying to solve really interesting problems.~

~And that's, to me, kind of keeps it fresh, you know, hearing the, the ways that they're approaching things and trying to look for the patterns in, in the bigger picture.~

~Gotcha. Gotcha. Yeah, that. That makes sense. It's, uh, it's cool to hear, I guess, that people can kind of find that engineering, uh, engineering satisfaction people get out of building things like in other facets of their life. Um, but yeah.~ Let's talk about design systems a little bit. ~So you said you've kind of been focusing on writing and talking about them, thinking about them.~

I feel like design systems are ~kind of~ in the. In the zeitgeist right now, or at least they have been for maybe the past few years. ~Did you, were you kind of like at, did,~ were you involved or thinking about this before that wave, or did you ~kind of like, you know,~ hop on ~as it was,~ as it was ramping up? Or where, how did that timeline look?

Yeah, that's such an interesting question because I think most folks who are drawn to design systems, as we call them today, are people who just. Think systematically. And so almost everybody that I know who's doing this [00:02:00] work at scale now are folks who, when you ask them about their history, will tell you they were doing this kind of work for a decade before we ever put design and system together~ in, in, in a,~ in a title of some kind.

So I, I definitely feel that, ~you know, when, when,~ when I look back at the work we were doing 15 years ago, We were trying to think very systematically because we knew our customers had more problems to solve than just the ones they had paid us to help with. And so what we wanted was to build something for them they could use in lots of contexts to solve lots of problems.

~And that's, that's it. You know, that's the root of, of, of systems work. And I, I'm actually, I've done a ton of writing about what a system is. I have a whole series called the Anatomy of a Design System that breaks it down, gives a nice visuals and all of that. But I'm actually not dogmatic about the definition of a system.~

~But to me, the reason that we do design system work is because we want. To have more consistent experiences for our users. We want to have, um, a, a faster process of iterating on ideas and getting those into, into the hands of our customers. And systems are just a way to enable that. So to me, the important thing is the benefits that systems offer.~

~I don't actually give a, I don't actually care too much about how you define it. I think there are some, some. Some patterns that we could use in terms of the definition that can, you know, are kind of tried and true and have been tested and be, are becoming standards, you know, in the industry. But honestly, I just want, I just wanna see the, the impact.~

~Yeah. Yeah. So I'm, I kind of in, in that, in that vein of trying to get definitions ironed out, it feels to me like, I guess my perception may, I'm biased, but a lot of people, a lot of our, ~a lot of listeners are probably, ~you know,~ they're more developers. They've, they understand the need to organize things.

~Like~ if they're using a front-end framework, they're like, yeah, I want things as componentized as possible, and ~like,~ make that all clean. What, ~like, ~what more than that? ~Is,~ is a design system beyond just like I want to use components everywhere I can and ~you know,~ react, view, whatever, what has felt, ~what,~ what is a design system ~kind of~ beyond just trying to, ~you know,~ componentize your front end.[00:03:00] 

~Yeah,~

~I.~

~this,~ this is ~like~ a very astute observation and what a lot of times when I talk to designers about this, they have. Only recently been given the tooling to be able to actually think systematically about the interfaces they're designing. ~Right?~ Developers, on the other hand, ~uh, That's,~ that's how our tools are constructed.

~You know, I mean,~ if, even if you just look at something as simple as ~like,~ css, the idea of a class name and me being able to assign a set of styles that, that move around with the class name, and now I can apply that set of styles to different elements in my dom. That is, that's such a systematic way of thinking, ~you know?~

So the same thing is true with, ~you know,~ any other form of development. ~You know, we, we, we, we,~ we break things down, just like you said. So~ that is,~ that is the, that is an important part of design systems because ~it's,~ it's ~sort of ~the, you, the implementation of them ~in,~ in reality has to be ~a, a,~ a set of components that I can implement.[00:04:00] 

But I think ~what, one thing,~ one sort of concept I've been trying in, in, in my coaching and consulting work with design system leads, one of the things I've been trying to help folks understand is that, Design systems have to exist at ~sort of a,~ a level above that, ~you know, it's,~ it's a conceptual thing and ~what we,~ what we really want is if we take just the classic example of a component, so let's just use a button, because that's what everybody uses.

I have a button component, right? That button component in whatever tool, in React ~or,~ or whatever, ~you know, you're,~ you're using~ is,~ is one. Instance of a concept, right? So ~it's,~ it's a level. That it's at the level that ~a,~ a dev needs to ~kind of ~put it on a page somewhere or in an experience somewhere, but that button needs to exist in lots of different a as an asset in lots of different tooling.

~You know,~ I have designers who might need that same thing in Figma. I have UX folks who might need that same thing in something like Axure or a prototyping tool of some kind. I have QA folks who might need to [00:05:00] see that in a context where they can do a comparison of some kind to validate. ~You know,~ so there, there every discipline has ~sort of ~a different set of needs for ~this,~ this concept of a button.

Now as a dev, I just, ~I,~ I'm so focused on writing code ~or,~ or building something that, that's ~kind of~ in my mind that I have this discipline bias about what a system is and it. It focuses me down on just the thing that I use each day. Of course, that's important, but my, I've been pushing design system leads to think more abstractly about systems because the tools will change, as you know, right?

We're using React right now, but we might be using something else tomorrow. And so ~what I,~ what we have to know is ~what are,~ what are the core concepts of that button? And this, ~it gets,~ it gets a little extreme when we're talking about something so simple, but ~this is,~ This is where, ~you know, you can,~ you can nest components to create a lot more complexity ~and,~ and that only works if there are foundational concepts that exist that go all the way back, I believe, to the brand of the organization.

And in this [00:06:00] way we're able to create alignment. That's ~much,~ much. ~Um,~ more impactful than just all of the buttons look the same in the product right ~now. If, if,~ if I've, if I, if that button has, again, it's cheesy talking about a button, but~ if,~ if the foundational elements of that button are rooted in the brand of the organization now the interaction that one of our end customers has with that interface that's built with that same foundational brand concept can align with.

The way that we answer a customer support email and ~the~ the way that, ~you know,~ our ad in whatever podcast that we put out there, sounds, and you know it, all of that sort of touchpoint of brand interaction. We can create consistency and that gives us, as designers and developers and product folks the ability to participate.

In ~sort of a,~ a, like a very holistic approach to connecting with our customers, and that's how we create really impactful brands,~ you know?~ So that's why I love this kind of work.[00:07:00] 

~Yeah, so I guess kind of,~ if I can play the devil's advocate for a minute here, right? Like ~the,~ the dev comes in ~with the. You know, they're, I guess,~ and anyone that's doing like the final implementation of the button in the mobile app or the page or whatever, I think it's easy for them to have the world view that like,~ well,~ I'm the one that's actually doing it, or, ~you know,~ our react code base is the thing that's actually rendering it.

Everything else is just gonna always be a poor abstraction.~ Like whatever,~ like whatever ends up, the designers need to work on ~the,~ the team that's doing this design like, We've gotta make the code that the machine ends up displaying on the page. So ~like,~ there's always gonna be like, ~this is,~ this is the truth.

And everything else is~ like,~ we're gonna lose fidelity as we ~kind of~ go up the stack. How do you build empathy there? So like ~the, you know,~ you can ~kind of~ shift how an engineer is looking at this problem to make it more of a ~like, um, you know,~ holistic approach to kind of design and the voice ~of a, of a,~ of a system.

Yeah. Oh, this, these, this is a really, this is a really good conversation. ~I, I, the,~ the concept, even just the way that you phrase that, how do you build empathy there? I think that is the core of it and the way, ~and,~ and at least in my experience, the way that we try to help. Courage, that sort [00:08:00] of growth of empathy is by putting these folks in situations where they're engaged in, ~you know,~ constructing the very specific thing they know they'll need to use from what is the conceptual, ~sort of ~foundational, brand based, ~you know,~ whatever elements, ~you know, kind of are, are,~ are foundational to it. And letting them observe and participate in the decision making there. ~You know,~ so this in my mind is, I was just talking with somebody about this, how ~they had,~ they had, this is a design system lead for an organization. ~Um, they,~ they're about a year in on their system and they had made some promises to their leadership about how. They needed a team to build a first iteration of a design system, but over time, their hope was that team size could reduce and they could start to use more of a community driven model. The system could be maintained by its subscribers. And, ~um, you know,~ that's a ~very,~ very idealistic, ~um, ~view [00:09:00] of the process and I tried to kinda share that with them, but, ~You know,~ the, ~and, and,~ and in that conversation, one of the things that we talked about was. This concept of contribution, ~which,~ which design systems folks talk about a lot, which means just that the system's never gonna be perfect ~as,~ as folks who are using it, perhaps a dev discovers a thing that it could do better. They build that for their specific use case and then help abstract it into something that~ other,~ other product engineers or whatever could use.

So contributing back into the system in some way, ~that process is,~ it's.~ It's, uh, it's slower when we, the, the,~ the product of the design system evolves in a much more slow manner if we rely on that, right? Because we're, it's ~sort of~ a forced collaboration between different disciplines and the design system team and re,~ you know,~ refactoring and getting ~the,~ the fastest way to do that is for the dev in that situation to just build a thing.

They need to build. Let the design system team know the design system team has the expertise to understand ~the,~ the necessary refactoring to make it systematic. So they [00:10:00] take that work, they do it themselves, integrate it into the system. They let you know it, it's now available to others. That's the fastest way to do it.

But that's not an empathy building exercise. And so I think of contribution more as ~the, the,~ the way that we help develop empathy for each other. ~Um,~ so it's really like exposure, ~you know,~ it's like engagement. It's participating in that. ~And,~ and I'm not necessarily saying, I know this is going on. I'm not necessarily saying that. You have to, in order to be successful, in order to build a successful design system, you don't necessarily have to build that empathy. It's really hard for me to say that as somebody who culturally lives ~in,~ in this sort of very collaborative space, I want to, I want that, ~you know,~ that's my personal desire.

But I also worked with some organizations that culturally that's just not. In the cards for them at the moment. And so I'm interested in understanding how that the culture of the organization impacts the way that we [00:11:00] approach this stuff. Because there are ways to have successful systems that don't require that.

~And,~ and for you to be able to operate at great scale very efficiently without that, now that comes with other negatives, ~you know,~ so ~it's, it's,~ it's always about pros and cons and ~how do we,~ how do we weigh those out?

~Right. Yeah. So like, yeah. Let's, let's kind of,~ let's jump into that a little bit. ~So yeah, you're kind of talking about. How org different organization shapes, uh, I dunno, like cultural styles, sizes probably even play into this, like should contribute to these people or to people making the decisions about how, how the design system manifests and how that like kind of the decision making process and information flows when I guess. What, like what is, what is the, what is the good,~ what is a good starting point for people coming in these organizations that,~ like,~ they're trying to ~kind of~ build this, but ~they, ~they don't know exactly how to like, do that mapping or ~make,~ make this flow work. ~What are,~ what are like the high level ~kind of, you know, here's,~ here's a good framework to get started with given your organization's, ~um, kind of~ attributes.

~Yeah,~ I would say that the only starting point that I know of that works is to come to that problem with a recognition that your. Personal preference for how to get things done is not the only way to get things done. So that kind of openness is, you ~kind of~ have to have that as a foundational understanding before you tackle the cultural side of all of this.

And once you've ~kind of~ personally done the work to figure that out ~or, or,~ or [00:12:00] agreed ~that~ that's okay, ~that's,~ that's a world ~we we can,~ we can live in, then it's a matter of understanding where everybody else is coming from. And I did, ~um, I mean the,~ the story I've ~kind of~ been telling about this. Is that we did an engagement with an organization for about a year.

We were helping them build a design system while we were also helping them build a product. And ~they, ~they had lots of ideas for new products. They wanted a system so that they could iterate on those quickly and, ~you know, kind of~ be work more efficiently. And so we thought, ~you know,~ that's the kind of work we love to do.

So we came in, we were working ~in those,~ in those two kind of parallel paths. One, one is a new sort of MVP of a product idea and that was being built with a system. We were ~kind of~ also building in parallel. And at the end of that engagement, ~well, we,~ we, we made great progress over the course of a year, but culturally, we were really struggling in that engagement.

And I'm not proud of this, but we actually had to, we could not figure out how to work well with them. And so we walked away from that client and ~it was a large en~ it was a very large engagement. Financially. ~It was,~ it was a very difficult decision to make as an owner ~of,~ of a business, but it [00:13:00] just felt like ~I, we had.~

We had tried so hard~ to,~ to come~ at that,~ at that sort of challenge from different directions and we couldn't figure it out. And ~that,~ that happened~ like right~ at the end of the year and we went into a holiday break for, ~you know,~ a couple weeks, ~you know,~ there just towards the end of the year and into the new year and, ~I was,~ I was so frustrated, ~you know,~ so I spent, it just ~kind of~ pushed me.

I, ~I like, kind of~ was like dwelling on this problem. So ~I, I, it,~ it pushed me for the next year into this research area around understanding organizational culture and I, I did a bunch of reading on ~like,~ Ways that people have considered cultures and things inside companies. There's a lot of this stuff that's been out there for decades and so I, I didn't feel the need to recreate something here.

So I found one concept that I've really ~kind of~ latched onto, ~um,~ which is called the Competing Values Framework. And so ~this is,~ this is decades old.~ Um,~ but basically it gives you kind of these four quadrants. ~So,~ It's called competing values cuz it maps two sets of competing values on an x and a y axis.

And that gives you, it's not, ~you know,~ it's not, no, no organization lives wholly in one of these quadrants. Everybody has [00:14:00] a little bit of each, ~um,~ but. It helps you to ~kind of~ see, oh, there are lots of different ways to operate. ~You know,~ and there are definitely trends. ~You know,~ startups tend to be in this more ad hoy ~kind of~ creative space,~ you know,~ banks and finance and hospitals and like anything where there's like risk, they tend to be more controlling with more hierarchy, ~you know,~ so ~you,~ you can start to see how this works.

~Um,~ but that's given me a nice, ~um,~ model to work with. ~So, uh,~ and I've written a bit about that. I'm happy to speak in more detail around that.~ If, ~if you'd like.

Yeah. I guess No, ~I'm, I'm,~ I'm, I am curious. ~I guess I, I'm,~ I'm thinking ~like,~ Like you said, like ~a lot of,~ a lot of tech companies, startups and stuff, they're in this, they're in this highly collaborative space where everything is organic and there's ~a lot of,~ a lot of those decisions that a big. Company has made, ~like,~ regardless of their industry, ~you know, like ~as the organization grows and just things become more regimented, is ~um, uh,~ like priorities are ~kind of~ shifted and compartmentalized.

~Um,~ I think ~that~ that does tend to happen, but I think that, ~you know,~ pe tech teams in general, regardless ~of,~ of where they are, at least in my anecdotal experience, have always felt more of that kind of, Want to collaborate [00:15:00] and ~make,~ make the, make their work process better, like throughout the organization ~than,~ than other, ~um,~ pieces I've seen.

~Um, is there, like, does this feel. Does does, is there,~ is it easier to sell this kind of ~like,~ Hey, we need to make this a more holistic approach to how we, ~you know, uh,~ design our experiences. Is it easier to sell that to ~like, kind of~ these newer age technical teams than it is, I don't know, like ~the,~ the rest of the business?

I guess, is it easier to sell ~kind of~ down to the implementers than up to the owners in these organizations? A lot of the time,

I think it totally depends on the perspective of the individuals involved, ~you know? Um,~ and~ for,~ for that reason, a lot of our work in this space is,~ it's,~ it's not technical at all. ~You know, it's,~ it's ~kind of,~ storytelling is really what it is. And the processes we go through here are, Let's understand, especially if we're trying to sell up to leadership.

Let's understand who these individuals are. I wanna know their history. What's their career journey trajectory? I need to understand what's important to them as an individual so that I can show them a view of the system's work that we're advocating for that aligns with the [00:16:00] things they want, ~you know?~

And that's storytelling. ~You know, that's,~ that's, ~uh,~ that's sales is what really what it is, ~you know? ~And so that's ~kind of, kind of~ the approach we take. ~I,~ I don't know that it's necessarily easier or harder because the truth is if you objectively look at the benefits that a design system. Offers ~a,~ a healthy system offers, it's almost impossible ~to,~ to not see how beneficial it could be.

So no matter what you want it, it ~kind of~ can, it can shapeshift a bit to serve those needs.

~Yeah. Yeah, it feels like,~ it feels like the benefits there. I just, I think ~the,~ the sell is in like getting people to accept that the operational overhead is worth it. ~Right? Like that's,~ that's the thing you're trying to make work.

~Yeah, that's fair. And,~ and not just that, like the sort of organizational shift that's needed, that's a, it's a culture thing. ~It really is because it kind of requires,~ it requires folks to really ~kind of~ come together to do a thing. It ~kind of ~puts teams. Different disciplines inside of an organization on the same team.

And there's definitely, ~you know, the, the,~ the more modern organizations that [00:17:00] you were ~kind of~ describing, maybe perhaps where you've had a chance to work, have that, they have that in their d n a, they want that. ~Um,~ but a lot of times ~they're,~ they're pushed to be fast. So hard that, ~you know,~ collaboration slows you down.

~So the,~ the, what happens when you're being pressed for efficiency is ~you, you,~ you put your, you close your doors and you all, ~you know,~ put your headphones on and you get your work done. And that's not a collaborative approach to the work necessarily. So it ~sort of ~pushes, unintentionally, pushes you out of collaboration ~when you're,~ when you're so focused on speed and you ~kind of~ have to be in, in a really competitive market.

So that's hard.

~Yeah. Yeah. I'm just, I'm,~ I'm. Again, like viewing this from a developer's lens, and ~this,~ this feels a lot like, ~you know, when a,~ when a code base is rapidly developing and you have like lots of contributors, ~uh, you know,~ making pull requests, sending code up at the same time it's like the scrutiny that is being given to each line of code and every technical decision that's being made, ~um, kind of~ throughout.

And like you said, it's easier to just kinda, everyone's operating as a little independent agent, like building a feature, just shipping it. And then there's the very little, ~um,~ Thought going into the impact on the [00:18:00] system as a whole. ~Um,~ but then, yeah, like I think ~that,~ that, that has always felt like a very cultural thing to me.

Like even ~that,~ that manifestation of maybe it's the same, like maybe this is the same kind of rut. It's like people that care about the long-term health of this kind of, ~you know, uh, ~code system, if you'll like, if you'll forgive that versus like the design system.

that's great. Yeah.

~Yeah. Is there so.~ I guess kinda, if I can continue that analogy, ~um, I,~ I think that I've done quite a bit of reading ~and, ~and thinking about there's in, in large code bases how, ~like, um, say say a,~ say a dependency is changing, ~right.~

~I think there's,~ there's still ~kind of ~the, a dec a decision hasn't been made on ~like~ who is in charge of updating downstream. Dependencies, people that like are subscribing to the code, like the API that someone has defined as an engineer. And that feels a lot like this kind of collaborative process that you were, are describing before of ~like, you know,~ the subscribers to a system versus the people like the organizational decision makers that are managing it.

Does that, have you found in the, while that those two typically correlate,~ like if a,~ if a technical organization [00:19:00] is one where the,~ um,~ the subscribers are ~kind of~ managing. The centralized APIs that a lot of people are depending on, they are in charge of those updates. Does that tend to manifest as a subscribers also owning more of that kind of design system, or are these separate concerns.

I don't have the data to, ~to,~ to answer that, ~you know,~ objectively. But I, my hunch is probably that you're right. ~Um,~ one of the things we do is we have a little culture survey we can run internally with an organization because the culture stuff applies not just to the org as a whole, but to every. Any place where a couple folks are getting together consistently, like there's gonna be a subculture that forms.

And so ~kind of~ what you're describing here is that ~the, ~the engineering side or the technical side of an organization often does have its own subculture and, ~um,~ I ta I, I have some work I've done to ~kind of ~show like the spectrum of culture and spec, specifically from ~like~ a more collaborative approach to a more controlling or hierarchical approach.[00:20:00] 

~And, um,~ and a lot of times ~the,~ the healthiest place to be is. Towards the center of that. And it's only the extreme ends where we start to get like a lot of unhealth. ~Um,~ and that's ~kind of, you know,~ so organizations that are~ really,~ really collaborative, they, if they're too far on that spectrum, they actually don't get much done.

~You know,~ cuz they have to get consensus and that takes a long time. And on the other end it's ~like,~ if we're fully independent, ~well~ then we're not. We're developing. We're not ~you, you know, we're,~ we're working on an island without the input of others, which is actually not a healthy process either, right?

So it's finding a way to balance those things. ~And the,~ the nuance is in how far off center can I go towards what a culture wants without reaching ~those,~ those stages ~of,~ of extreme sort of unhealth.

Got it. Yeah. Yeah. Is there, ~uh,~ again, ~if,~ if one's sitting in an organization and they're, maybe they don't have a lot of external ~resources, but they're~ resources, but they're ~trying to advocate,~ trying to advocate for, like getting more of a design system established.~ Is there some, are there,~ are there signals they can look out for [00:21:00] that may indicate that they are either like, ~too far,~ too far, they're trying to do something too collaboratively or they're trying to do it too centralized?

Like too controlling, ~um,~ that might help them si or might signal to them that like they may need to evaluate,~ you know,~ where they ~kind of ~try to steer the organization to get more buy-in, like from these~ uh,~ stakeholders.

man, that's such a tricky thing. ~I,~ I think it's really hard to see that. In the midst of it, ~when,~ when I talk about this stuff, like if I give a, ~um,~ a presentation on this sort of cultural, the cultural side of this stuff,~ I,~ I have people come up and they always have one of two things to say to me. One of them is, you showed me why I don't fit in into the company that I work at.

Personally, I align here. My organization is here, and those are opposites. And that's why I'm so unhappy in my job. And so it's a very personal thing. And then the other one is more about them understanding their past failures. ~You know, they'll,~ they'll say, oh, now I understand [00:22:00] why there was so much resistance to this approach that I tried to put into practice.

So I'm working now, like one of the things I really want out of this is to find ways to help. This understanding prevent future failures as much as it helps us understand past ones. And ~so,~ I don't, I wish I had better answer for you there, but I'm, ~you know, I'm,~ I'm looking for that kind of, what are those signals?

~You know? Um,~ the best that I have so far is there is this little cultural survey. In fact, you can buy this book by the original authors. It's called. Diagnosing and changing organizational culture based on the competing values framework. And it's very in depth, ~you know,~ it's, is, it is a lot of in the weeds stuff, but there are some, ~um,~ some ways in there to help you ~kind of~ identify culturally where your org fits and that can give you some really good in insight on how to approach things.

~Yeah. Yeah. Oh yeah. We'll,~ we'll get a, we'll get a link to that in the show notes, ~so,~ so people can find it. ~Um, yeah, so I think I, I,~ I ~think ~like having ~these,~ these kinds of kinds of mental mappings, ~like, uh, kind of a framework,~ a framework like this, ~you know,~ or a spectrum ~to,~ to think [00:23:00] about things on is pretty, I think devs would acknowledge that it's pretty useful to help ~kind of~ give.

Just a vocabulary and ~kind of ~assign a good, healthy mental model to like how one can think about these problems. But it also, I think that there is a tendency, ~um, you know,~ for like detail oriented technical people to feel like these are all just, like I said before, like kind of abstractions. They don't really help us get things done.

Like we can talk about where our organization fits in the spectrum and all this, but ~like,~ at the end of the day, like again, they're the one that has to implement how the button looks when clicked on and all this stuff~ is there. I guess,~ how do you, ~um, kind of ~reconcile that, like there is, ~like,~ this is, ~you know,~ like ~a,~ a mental abstraction that we're making to help us discuss this, but ~at some,~ at some point,~ like,~ we've gotta make decisions about who owns, ~you know,~ x, X, Y, Z piece of the system versus who owns this component.

~Like where do you,~ where do you ~kind of~ draw that line and~ how do you,~ how do you think, ~like~ ensure that. People aren't feeling, ~um, you know,~ like this is just ~kind of~ hand wave view or making decisions based on arbitrary

Yeah, I get that. I've definitely [00:24:00] experienced that. I think there's ~sort of a,~ a few things that come to mind. One, like I. When you are sitting in your, at your computer, ~you know,~ writing your code for the button, ~you know,~ we'll discontinue the analogy here.~ Um, you know, it,~ you actually do have a lot of personal freedom in how you choose to do that kind of thing.

Right there, there is still autonomy that exists, and I'm not suggesting that we wanna remove that from designers, developers, from any individuals. I think ~I'm,~ I'm just ~sort of ~saying, ~There's a,~ there's a maturity that comes, ~you know,~ with understanding that we're all operating ~kind of~ inside of ~the,~ the constraints of the cultural, ~you know,~ what the culture permits.

And so when you are headphones on head down writing code, You do operate ~kind of~ in your own space, but what I'm advocating for is a recognition that when you're in conversation with other people is where a lot of these things really apply. So how do we interact with each other? ~You know, what,~ what are the expectations around that?

And that's where, honestly, if I were to look across an org and try to[00:25:00] ~like~ map out where there is efficiency and inefficiency. I actually think the biggest amount of inefficiency comes just from the fact that we don't understand each other. It's like this ~very, very,~ very root thing where you say one thing.

I interpret it through my own experience and lens, and I actually interpret it differently than what you mean. But we both nod our heads cuz we think we know we disappear, we do our work and we come back and we've actually missed each other. And ~that~ that. Creates so much inefficiency inside of an organization, not just inefficiency.

It creates a lot of frustration, ~you know,~ so ~what,~ what I'm hoping for is to ~like~ ask that individuals who have that sort of very tangible, necessary practical view that you're describing, also step back every once in a while and recognize they're operating inside of a much larger. Thing, ~you know,~ and they gotta be a part of that too.

~So there are practical implications to this stuff. You know, like if we take the idea of, of contribution, well there's, you know, contribution, meaning I want to offer something back to the system, that there's a very practical, tangible process that I need to follow. In order to do that, it usually involves, you know, solving my specific problem and refactoring that work so that it can be applied to a broader audience.~

~That that can be done in, in a very collaborative way, or it can be done in a very sort of hierarchical way. It can be a set of steps that I follow, and those two processes for CO, for contribution are vastly different and. I think what I'm saying is that this is the kind of work that's necessary to understand where should we actually focus our energy in, in terms of, in this case, one example contribution, but that could be looked at across anything.~

~How do we prioritize our work? Well, there's, there's a process that people follow, but the, the process is dictated by the culture. You know, so if we don't understand the culture, we're just sort of going along with it, and, and I'm saying maybe we need to be, be willing to push those things in certain directions so that we can get more efficient work or, or better results.~

~Gotcha. I think so,~ I think I have a pretty good grasp ~on,~ on how that would look, ~uh,~ like from a collaborative perspective, like in a highly collaborative environment, how taking ownership of this, ~you know,~ whatever component [00:26:00] you've created and ~kind of~ bubbling that up would look. ~But how,~ how does that manifest in a more controlled, ~uh,~ hierarchical environment?

~Yeah, it's, it's, um,~ Most often, it's ~sort of~ more procedural, ~you know,~ it's~ like,~ it's less about us doing a thing together, finding consensus on how it should be done, and it's allowing the individuals who have the proper expertise to ~kind of~ do the thing they're good at. And so it's, it does end up feeling more.

Segmented, ~you know, um, the,~ the specifically a design systems team would say, here's the set of steps. ~You know,~ here's the diagram that maps out the process. We're gonna do this part, you're gonna do this part. We'll review it, you'll review it. ~You know,~ and it's very linear in that way. And the only sort of collaboration that exists in there is the sort of series of checks and balances that are necessary to make sure the work is right.

~You know,~ so that's a much different approach than, Hey, let's sit down together a a and actually work on this problem to together. ~You know? Um,~ it's more of a kind of a structured handoff. ~And that's,~ that's an extreme. Those are two [00:27:00] extreme, ~you know,~ examples and there's plenty of space in the middle.

~Yeah, and I think,~ I think ~that ~that ~you, you,~ you articulating, this is ~kind of~ helping me understand why you're advocating for ~like ~the design system. Being most efficient when it's ~kind of~ in the middle somewhere. Because I think, yeah, ~I've seen,~ I've seen both of those extremes where it's like just the amount of control over every decision that's being made adds so much bureaucratic overhead as well.

It's just like, okay, who do I even ask? I've got ~some,~ some little, ~you know,~ implementation detail that wasn't ironed out and I've gotta go ~like,~ go talk to three different teams to figure out who actually owns this versus ~like,~ I have no idea what to do. Or I'm trying to build consensus with this giant team ~and see,~ and see kinda what feels the best.

~Um,~

~Yeah. That,~ that's ~sort of like, you know,~ the documentation side of design systems, ~like,~ like having a spot where we actually state who owns what. ~Like that's,~ that's not collaborative or controlling. That's just smart, ~you know? I mean,~ that's just ~like,~ let's just be real about ~like,~ people need to know that kind of thing.

They need to know. Who do I talk to about a thing? ~Um,~ so I don't necessarily think that one or the other means there is stronger understanding of ownership. ~You know,~ th that can [00:28:00] still exist ~in all of,~ in all of these quadrants, ~you know,~

~Yeah. Yeah. Um, okay, cool. You've, you've segued me nicely.~ The next thing I wanted to talk about, again, engineer engineering focused mine is like tools. Like~ what, what,~ what have you found works really well ~to help,~ to help with this? Like from an informational perspective to just ~kind of~ make these. ~The,~ the handoffs, the, ~um,~ like interfaces between these teams.

Like what works well? What have you seen in the wild?

~Um, you know,~ the tooling in the design system space is ~sort of a, it's a,~ it's a weird mishmash right now. ~Um, it's,~ it's early enough that there, ~you know,~ like there aren't. There isn't like a, in my mind, like one clear tool that all the design system teams should be using. There's plenty of organizations trying to do that, but the problem is every org that we've interacted with has.

A bizarre combination of needs. ~You know, and,~ and this is ~kind of~ like I, I've heard other folks say that design systems are~ sort of~ like~ a,~ a reflection of the org. ~You know,~ the way that they're built, the tooling that's needed to manage them [00:29:00] is all so dependent on the tooling that's used in the products themselves.

And so ~this,~ this actually comes even back beyond tooling, back to. The structure of a design system team, a lot of times the way that I help organizations make those tooling decisions and ~like~ who should be on the systems team, all of those kinds ~of,~ of decisions is to look across the org and see what are the things that are in play here.

~You know, so I, if,~ if your product team squads or I don't, however you're structured, have ~a,~ a half of a UX designer, a UI designer, and four devs, ~well~ then I. That might be a really good set of disciplines for us to think about for the design system team, ~you know,~ but not every organization is structured that way.

~So I don't have, um, this is, this is a,~ this is a challenge. There's lots of content out there about. Once you've made a decision about what tool to use, how to implement it, ~right,~ tons of YouTube videos, classes, online, all that stuff is out there. But making the, the decision about the right tool is a very ~sort of~ intimate, ~you know,~ like ~it's a, it's a,~ it's a decision that has to be made based on the [00:30:00] context.

So I don't have ~like~ a specific answer that I can say, this is the one you should use. We've had great success. ~You know,~ using, ~you know,~ react and storybook and things like this to ~kind of~ manage the day-to-day activity on the engineering side, we've had great success doing some smaller, more like web component type approaches.

~You know, I mean, there's. Um, it's,~ we've even done much less in terms of systems and focused more on like foundations and tokens. And then that really is an enabling tool for independent autonomous product teams to be able to use the frameworks they feel are necessary,~ you know,~ for their work. So it, I wi it depends.

I know you hate that answer, but

No, no, it's.

Yeah.

~That's a good answer. I think for, for nuanced, uh, nuanced problems like this, I guess.~ So a lot of those ~tools,~ tools you just mentioned, my theory would be that many of these orgs, even if they haven't really thought about their workflow kinda. ~In,~ in terms of design systems, they're already using ~some,~ some of those, maybe all of them are a large subset.

~Uh,~ are there, is it often the case that, ~uh,~ like when you're having this conversation with [00:31:00] organizations that they, ~that,~ that the tooling is, there are maybe ~no new,~ no new tools need to be introduced to kinda facilitate ~this,~ this change in process and flow? Or is it, have you found it almost as always the case that there is some additional piece that needs to be introduced?

Yeah, that's a great, ~uh,~ way to think about it. I think I. ~Um,~ oftentimes I would say a majority of the tooling's already in place. ~You know, um,~ now we might be using it a little differently or something, and so there's some work to do there. But, ~um,~ there is ~sort of~ a suite of tools that exist now that are very design system focused that most orgs who don't have a system, will not already have in place things like Supernova or Zero Height, ~you know,~ which are like the way that a lot of these.

Organizations are positioning themselves as that will be the hub, the center for your ~for, for you know, the center for the~ for the spokes to attach to. ~So, You know,~ I was just looking at, ~you know,~ zero height is one that ~we,~ we like, ~you know,~ and it has, ~uh,~ some really nice integrations with a lot of the kinds of things that an engineering team would use or ~a,~ a UX or design team would use.

So they're building integrations to bring these, ~you know,~ disparate sets ~of,~ of frameworks and things [00:32:00] into one place. And their primary focus is about creating really good documentation that kind of, you know,~ and, ~and offering that in a nice, very searchable, easily findable way. ~Um,~ so ~that's,~ that's a act, a really helpful thing.

But we've had great success building those sites, ~you know,~ from scratch too. ~Um, it,~ it ~sort of ~depends on the level of, ~um, You know, sort of~ technical expertise across the teams, ~you know,~ how easy does it need to be to modify the documentation? ~You know,~ if you've got a team of folks who understand markdown well, we can do that very easily.

~You know,~ when a GitHub repository, if you've got, ~you know,~ if you don't have that, we need, and we need to have a more sort of new, ~you know,~ a nicer interface for editing things well there, something like zero height could be a great choice. ~Um,~ And then it's like pricing comes into play. ~You know,~ cuz those tools are not cheap to, to use.

~Um,~ and ~it's,~ it's licensing for individuals and how many people are contributing. I~ mean,~ it gets ~kind of, you know,~ you know how all that goes. ~So, um,~ yeah. But oftentimes I would say the majority of the stuff you need is probably already in place or something that can solve those problems. Is there, so that's nice.

~That's cool. Cool. I mean, I always, I kind of, I like to leave off on give, I like to leave off giving listeners something concrete to go check out. So I guess, yeah.~ Before we wrap, is there [00:33:00] anything else you wanted to, ~um,~ to plug or promote?

~I,~ I just recorded a, ~um,~ it's about a five hour of. Like online workshop through front end masters. And it is, ~you know,~ it is very conceptual. ~You know,~ like everything that we've talked about today, because I think the problems are actually at this sort of human conceptual level. They're not at the implementation like it, people are so smart these days.

~It's,~ it's actually not hard to build things that can be reused. The problem is in. How we get there. So that's what this workshop ~is,~ is focused on. It's about end, ~you know,~ design systems in the enterprise and it's really a series of these kind of mental models to help shift the way you think about systems work.

So that's something that I think a lot of organizations have found really valuable. I've gotten some incredible feedback on that, and that I think is an area where I'm gonna continue to push. ~I'm, I'm, um,~ I'm. I would also say that if your listeners are in the midst of designing ~or,~ or implementing a system and they're struggling, I am continuing my research ~in this,~ in this space.

~So ~I would [00:34:00] love to hear the challenges specifically they're facing, or if they've solved some of these kinds of problems, how they've done that. That's incredibly valuable for me.~ So I have a, I, I try to make it very easy to, to get, to reach out to me and find some time. ~I'm always happy to have a conversation with folks and hear ~kind of~ things they're learning, ~so,~

Nice. What's the easiest way for people to get in touch with you?

~Uh,~ Twitter dms or LinkedIn, ~uh,~ messages, or, my email is just, I'll give it to you.

It's just ben@heysparkbox.com.

~Nice. Nice. Well, again, we'll, we'll, we'll have a, a chunk of links in the show notes as well. Cool.~ Is there any, anything else finally that you're, ~uh,~ excited about kinda in the space, on the horizon or in the future?

~I mean, I,~ I mentioned this I think at the beginning, like my whole. ~Sort of ~set of values are driven around making an impact. And the more that I do this work, the more I see the potential it has to create a lot more health inside of an organization. So the thing that is exciting to me is the systems.

That we're working on are doing that, but they're also on the opposite side, exposing ~the,~ the practices that are not healthy. So ~if,~ if that's something you're interested in doing, ~you know,~ it takes ~sort of~ a strong, ~you know,~ it takes ~a,~ a lot of perseverance, but ~I,~ I do feel very. Optimistic [00:35:00] about the impact ~these,~ these kinds of approaches are having inside organizations as a whole.

So that's the thing I'm probably most excited about. ~You know,~ I just love, I love to learn, I love to talk about this stuff. So this kind of conversation, ~I really,~ I really thrive on this and, ~um,~ I appreciate ~your,~ your time.

~No, of course. Yeah. Yeah. Uh,~ thank you so much for,~ uh,~ coming on and chatting with me, Ben. ~It's,~ it's truly been a pleasure.

Yeah, pleasure was mine.

Yeah.