Subscribe
Share
Share
Embed
The Question is a collaborative learning podcast about Design Systems. Smart people like you sign up, answer a few niche questions about design systems for each episode, and then we all get together to unpack the data we've gathered. Each week, I'll invite a new co-host to help facilitate the conversation. After the deep dive, the co-host and I record a recap of what we learned. That means, for each episode, you can listen to the recap and the full deep dive!
If you're a design system practitioner, subscribe today (https://bencallahan.com/the-question) to receive an invitation to each episode. This only works if the community joins in!
Stay in learning mode ❤️
Ben Callahan (00:00)
Hello, system thinkers. Welcome to the recap for episode 072. I'm joined by my friend Doug Neiner Doug, thank you so much for being here.
Doug Neiner (00:09)
my pleasure. Glad to join you.
Ben Callahan (00:10)
Yeah,
we just finished the deep dive and so we had a little break, 15 minutes maybe, and we are jumping right back in to talk about some of the things that we learned from the community in the deep dive call. Let me give you a quick overview of what we covered. So the topic this week was extreme design system support. Doug and I had a great conversation about this concept prior to the deep dive We asked you all four different questions.
The first was, how would you describe the support that your design system program currently offers to consuming teams? And we gave you a long list of options to choose from. The second question, with no constraints, how would you change your design system support program? The third question, what are the constraints that keep you from implementing that level of support? And we gave you a handful of options to choose from as well. And the fourth and final question was, describe a time when going above and beyond in support
a consuming team had a meaningful impact on adoption, relationships, or the system itself. We sent this out to over a thousand folks, 1,081 design system practitioners. We got 49 responses. And as always, wherever you're listening or watching this episode, you can get the link to the raw data and do your own analysis. ⁓ Doug, I want to start with you. Like we had these two questions, question one and three, where we gave folks
a handful of options to choose and we said, check all that apply. Tell me sort of what you saw in the data for those. Was there anything that stood out to you?
Doug Neiner (01:46)
Yeah, the one thing was you had separated out written and video documentation and written is maybe in the 90 percentile and video documentation is maybe 25%. So that was a, it makes sense when I saw it, but that was a bigger, that was a big discrepancy. ⁓ We didn't kind of dive, we got a little bit off track talking about perfectionism and design systems and maybe that impacts our ability to produce videos ⁓ that are easy to produce. ⁓ The other one was, ⁓
Ben Callahan (02:05)
Yeah
Doug Neiner (02:13)
that there was almost 50 % of the respondents said they have access to dev development environments to help debug, which was much higher than I expected. So that was really interesting.
Ben Callahan (02:19)
Yeah. Yeah, that's a huge lift.
Yeah, I love that. I, again, that's, I was with you on this, Doug. did, I've not really heard system teams talking about that very often. So it's really cool to see it exposed here in the data. You're right. Big difference between written and video docs. I, I think I'm biased here because I'm, I'm so used. So we're on episode 72. I produce video a lot in my own life. And so the
Doug Neiner (02:32)
Yeah.
Ben Callahan (02:48)
the tooling that's available these days has really lowered the bar in terms of the effort it takes to do that. tools like what I hear, this is Riverside that we use to record our recaps, even just using Zoom. like you get, it'll do an edit for you that has primary speaker over top of a screen share. mean, so you can use those tools that folks really do have access to to sort of really lower the bar for entry on this. ⁓
Doug Neiner (02:55)
Nice.
Ben Callahan (03:15)
But you're, it's so funny because you, said, Ooh, I wonder what the difference is, you know, what the overlap is between system practitioner and perfectionist. we actually, we asked the community to draw us a little Venn diagram and we got, ⁓ a pretty good sense for like a lot of us living in that middle ground, you know? ⁓ I see you Doug are perfectly centered.
Doug Neiner (03:20)
Hahaha
I had to be. mean, how can you be perfectionist and not be perfectly centered in the middle?
Ben Callahan (03:44)
I know. That's so funny,
man. So funny, but ⁓ awesome. I love it when we come up with a quick poll like that and get that we can get folks into the Fig Jam to help us sketch it out. Anything that you saw in that second ⁓ more quantitative question?
Doug Neiner (04:00)
And just that one is what are the constraints that keep you from implementing this level of support? ⁓ One thing that was really positive is that unclear ownership barely made the chart, maybe about 5 % answered with that. The biggest contenders there were headcount or bandwidth, which makes total sense. ⁓ The smaller the team, the less you can accomplish. And then competing priorities, that one was interesting. Given the success that comes from high levels of support,
what priorities would be competing with that. That one's interesting. And I imagine it has something to do with, we didn't really get into this in the call, but ⁓ the deliverables, the components, the new things can compete with the level of support teams would want to provide. So that was interesting. That was very high, maybe about, what would you say, 75 %?
Ben Callahan (04:30)
Hmm.
Yeah.
Yeah, yeah, two thirds, maybe a little bit more. ⁓ I love that you called out the unclear ownership. That was something I saw in this. And I think, I feel like I'm somebody who has been advocating for customer support roles on design system teams for a long time, because I know how important this is, and nobody does that. It's always like, we're gonna pass the pager, basically. That's how it used to be when I was in engineering. was like, I had to take a pager home once a month or something.
Doug Neiner (05:06)
Mmm, sure.
Yes.
Sure.
Ben Callahan (05:17)
systems
go down and I get the call and I have no idea what to do because I'm not a support person you know I mean like it's a it is a unique skill set in in a sense and and I think we maybe ignore that partly so I love this idea that unclear ownership is low what that means to me is that design system teams recognize this is part of our role you know and so now it's just a matter of like within the constraints we have to operate in how do we do that well you know ⁓
Doug Neiner (05:25)
Hmm.
Yeah, yeah, that's great.
Ben Callahan (05:46)
Will you, Doug, just give us, so, you know, not everybody knows you and I, so I'd love for you to just give us a sense for what your, if you had to sort of describe in a minute or two what your, you know, support approach looks like for the system at PlanVue. Tell us sort of how you approach it.
Doug Neiner (06:04)
Yeah, sure. So we have different, I mean, obviously we maintain written documentation, both of our design documentation. That's the, I'm trying to remember what Kevin always calls it, but it's the normative truth.
It's the thing that's supposed to answer the question of is it correct or not? We maintain storybook documentation. So we do all those things. We have an open Slack support channel for both the designers and the developers. They're separate, so we don't mix those two. It's open, people can join both. But then beyond the basic things, ⁓ we're constantly...
We do onboardings with new teams that come on and we walk them through what's available. It's not super formal, it's not pre-recorded, it's something that we do ad hoc as new teams come onboard. But the thing I like the most is whenever there's a defect, ⁓ try to run, Plainview has a bunch of different products that they've acquired or built over the years, so there's a lot of different teams. I try to get those running locally, because the fastest way for me to provide support is to able to pull down someone's branch.
run the code, see the problem they're experiencing, identifies that a defect for us is a defect in their code, ⁓ and often can just push ⁓ commit to their unmerged branch that's gonna be reviewed. But I can push a commit that fixes the problem, or I can go with them and give them very confident help. Telling someone to try this and try that and try this is not super effective. But we try to provide that deep level of support, either replicating the issue in our own systems if we can't run theirs, or getting on the screen share with them and.
finding out the issue, quickly identifying, do we have a defect? Is this something we can help them with? So a lot of that comes direct. Like there'll be some posts in our public channel, but then a lot of it comes directly to either the other developer on our team or myself. And we just deal with those one-on-ones because some people aren't comfortable ⁓ asking the public channel.
Ben Callahan (07:53)
Yeah, and I want to come back to this idea of, you know, like direct messages or private messages versus sort of conversation in open channels. But ⁓ it's it's I know that a lot of folks answer that they have access to dev environments. But for you to talk about it in this way, I hear you saying it's more than that. It's not that I have access. It's that you do the work to get these products running locally so that you can really understand that you're talking about.
like increasing the proximity. You want to be closer to the metal for this. like you're in the weeds, you're understanding what it's like to be a consumer in a sense. Is that fair?
Doug Neiner (08:28)
Yeah.
Yeah, definitely and it's frustrating so that involves obviously going through different permissionings for access to different repositories I think the most extreme example is I ⁓ worked with my boss to get it We work on Mac primarily, but I got a pay-in-view issued PC So I don't know if I'm the only one in the company with two PCs a PC and a Mac But that was so I could run one of the products which was really it was it was too heavy to run in the cloud well
It's like a like a virtual private computer ⁓ and then so they got me a PC so I could test on that ⁓ and That was probably that's probably the most extreme case where so I could run their product and give them the best support ⁓ But it was worth it because it one of our largest products. So it was worth worth ever
Ben Callahan (09:18)
Yeah,
man, that's that's that is legitimate support from leadership to have them be willing to kind of go through. I know what a headache it is to deal with all of that stuff with your infra team or whatever, know, security team, whatever that is. ⁓ Gosh, that's really cool that they see the value in that sort of level of support. That's neat.
Doug Neiner (09:29)
Yeah.
Right.
Yeah, it's been really cool. again, being able to, it's just so much easier to say, I see your branch, I see the issue, you know, in the support versus like send me a screenshot of your code. You know, it's just so much more effective if we can self-serve when we're helping.
Ben Callahan (09:42)
Yeah.
Yeah, my gosh dude, yeah.
Yeah, that's so good. Okay, so let's come back to the idea of, you know, DMs or private messages versus open channels. I'm, I think you're slowly converting me here. I've been an advocate for having these channels to be very open. And I know that you're not saying you shouldn't have open channels, but, you, you are very much okay with somebody just DMing you. And, you know, I've always liked the idea of an open channel because I want
other people to see the questions and other people to be able to chime in and answer. But tell me what's been valuable for you on the direct message or private message front.
Doug Neiner (10:34)
And I think this is so interesting. There's two things going on here. One is, I don't know, it's an idea of personal, I'm trying to think how to answer your question, because there was one piece we didn't get into in the larger call that I wanted to talk about. ⁓
Not everyone is comfortable asking their question in a public channel. They may be unsure about their own competence and worry that it's a dumb question. They may ⁓ just don't want to bother random people. I, for one, almost never will post in a very public forum asking a question. I just not who I am. I will find the person that can help me and I'll ask them directly. Occasionally as a last resort, I'll ask in a public channel. It's just the way I'm wired. And so I think maybe I'm more disposed to allow other people the same.
Ben Callahan (11:11)
Yeah.
Doug Neiner (11:20)
courtesy. I think the more we try to streamline the less touch points we get and then we don't know which conversations we've missed. Think about a ticketing system. Most IT departments have ticketing systems. Sure, it's super effective for them, but it's really awkward to use and you're trying to raise requests and it's asking you to pre-categorize your request and it's asking, you I don't know these, I don't know which department and how you have this set up. I just know I have a problem and I need your help. So I like that we've kept it very fluid.
Ben Callahan (11:21)
Yeah.
Yeah.
Doug Neiner (11:49)
The more we build trust, people start to ask in the public channel. We see that once we've answered some questions in private, then they'll feel comfortable asking in the public channel. Sometimes I have to tell them, hey, I'd love to help you, but you're in a different time zone. Ask my coworker, he's over in Europe. He'll be able to help you. So sometimes I do have to ask them to ask in a different forum. But most of the time we can just answer the questions directly and it builds connection. So I think we should be very careful about streamlining for our own.
efficiency when it's not as effective. Some people just aren't comfortable doing that.
Ben Callahan (12:20)
Yeah.
Gosh, you said that well in the deep dive and I wrote it down right here. You said it's not always about efficiency. It's about building trust and effectiveness. And I love that as a quote. I mean, I think it's so true. It's really, especially because system teams can, can be small and isolated. And we're asked, you know, we talked about this in the call, the boundaries of system work are blurry, you know, like what is our responsibility and what is not it's never black and white, you know? And so I think.
Doug Neiner (12:45)
Mm-hmm.
Ben Callahan (12:51)
⁓ with a small team, gosh, it's easy to try to think, let's just make this easier on us. ⁓ But you're right, maybe doing that reduces the effectiveness in some ways.
Doug Neiner (13:00)
Yeah, right.
So I'll take it one step further. Have you ever been working with a team and they're like, create a ticket, create an issue. It's like, like ends the conversation and you have to go somewhere else. So I do it sometimes on occasion with people that we work with for a while. So, hey, yeah, that's a great idea. Can you create a card on our board? And they're comfortable with that. use our product, Agileplace, to manage our work.
Ben Callahan (13:06)
Okay.
gosh. Yeah.
Doug Neiner (13:25)
But most of the time, I will create the card, I will capture the details, and then I will provide the link back to the person that asked the support request and say, hey, here's the defect that you reported that we're tracking here. That way, if they wanna do it, but it's just that extra step of, I'm not looking to offload the work as quickly as possible, I'm looking to make the person feel heard, their thing's gonna be taken seriously. So even in that level, it's much more efficient if they create the issue, but they don't know which categorization to give it, which other thing to do. So I wanna do that for them. So that's just some pet peeves I have with efficiency.
Ben Callahan (13:43)
Yeah.
Yeah.
Yeah.
Doug Neiner (13:55)
in large organizations.
Ben Callahan (13:57)
Man, that's
so insightful. You're prioritizing the relationship over the efficiency is what it sounds like. Yeah.
Doug Neiner (14:06)
Yeah,
I don't know that I was thinking of it that way, but yes, I think that's probably right.
Ben Callahan (14:10)
Yeah.
We I just was playing around a little bit because when I started looking through the answers, you know how I love a ⁓ quadrant ⁓ diagram. It's like how much. we could have your. I love it. I love it. OK, we'll redo that one. But I just was thinking about how a lot of these are a lot of the challenges here were the idea of scale versus effort.
Doug Neiner (14:20)
Mm-hmm. Yeah, I thought we could have used that for the perfectionism one too. Like from perfectionist to pragmatic, where are you? then...
Ben Callahan (14:40)
You know, like it's almost like, how do we reach the most people? And, ⁓ with, with the team that we have essentially, right? So it's like an acknowledgement of a small team in a large org. We have to, we have to think in terms of scale. ⁓ Guy pointed out, well, how do we overlay impact? Right. And I think this gets at the nuance of some of this stuff. Cause on the surface, you know, one of the answers we gave folks was, to, the first question, how would you describe the support your system offers?
was this idea of ⁓ we embed in consuming teams, meaning a design system team member goes and works inside of a consuming team to help support them, to help them learn about the system, to help them see how the system works, all of those kinds of things. And when I initially sketched this out, just kind of quickly before the call, I put embed in consuming teams in the top left, meaning it's low scale.
but it's and it's high effort. ⁓ But the more we talked about this, the more we saw. And if you look through the raw data and you get a chance to read the answers to question four, which was us asking people to tell stories about impact, ⁓ you can see that a lot of folks felt that when they do this kind of work, when they take the time to actually embed, get to know the product, get to know the team building the product, what they're doing is more than just supporting them. They're actually
Doug Neiner (15:42)
Mm-hmm.
Ben Callahan (16:09)
turning them into advocates for the system. And there's a exponential impact that has because those advocates will then answer questions for you, right? So they become your support in a sense. They also are just straight up average. They're telling everybody about the work, you know, like, so it is, there's a lot of benefit to that. Has that been your experience or?
Doug Neiner (16:21)
Yeah.
Yeah, more time I spend with the team is that it pays off in a number of ways, right? It pays off in less questions going forward, more self-service. Like those things, sure, you can tell someone you have docs and tell them a million times, but when you're pairing with them and you're referencing your own docs, our design system's to a point, I can't remember everything, whatever prop is named. So during our screen sharing sessions, I'm pulling up our docs. I'm finding, okay, that's what that prop is called. So ⁓ I think you're modeling some of those things. I think there's a huge level of...
Ben Callahan (16:51)
Yeah.
Doug Neiner (17:02)
effectiveness gained where not only are they seeing and then they're looking at the During the reviews the things that you're calling out the things that are important the things you're paying attention to so there's a I think there's a huge impact from that even though it doesn't You know, you can't scale it to a million teams if you have only four people But it but it does it pays off more. I think than you put into it
Ben Callahan (17:10)
Mm-hmm.
Yeah. And there, you know, we had a brief conversation about maybe the other side of this coin. ⁓ One of the responses I thought was really just like interesting to read. And this was a one of our respondents who has a fairly large system team for a smaller sized organization. And, you know, she said that they do quite a bit of very hands on.
Doug Neiner (17:32)
Mm.
Ben Callahan (17:50)
work with consuming teams. And that has definitely led to strong adoption. But she also had this statement in the fourth question where she said, our work is very high touch. And I sometimes think that it burns out our design system team. And so, you know, I think this to me was like, what's the balance? You know, it's kind of the way I was trying to think about this. Maya asked this in the deep dive. said,
When are we hand holding too much versus empowering teams with skills, skills and knowledge to self-serve? And I get it. Like, this is not an easy thing to figure out. I, I, I kind of put you on the spot in the call Doug. And I was like, how do you tell like what, know, what's, what's your, like, I think you probably have been doing this long enough that you have a good intuition around this, but like, tell us sort of like objectively, how do you make a decision on whether a specific.
support request is worth the hand holding, worth the investment, you know.
Doug Neiner (18:47)
Yeah.
So you're always trying to give the answer that gets them unblocked at a minimum. The question is, do you then take further steps? Do you get on a call to explain all the nuance about your answer and those things? And for me, if code is shared, ⁓ or even in the case of the question, you can sometimes sense there's such a significant gap between the question that's being asked or the code that's being written and where it needs to be, that you realize that they're not at a point to be able to benefit from that deeper mentorship. They need a more basic... ⁓
skill ⁓ education maybe or experience or anything. I'm not criticizing the people at all, but you recognize that maybe this is a backend developer that's been thrown on a front end task. They're going to be back on database migrations next week. This is probably not the time to explain the philosophy behind how our accessibility approach is going to be impacting here, ⁓ pointing out that these things are wrong. So I think some of it is just when the gap between where they need to be and where they are is so significant, you're more tactical in your response.
Ben Callahan (19:35)
Yeah.
Doug Neiner (19:48)
don't do this, do this. Down to giving them a code snippet. Just replace what you have with this. Sometimes that will be it and they, ⁓ thanks, they're unblocked, they're happy and I don't think any education happened. It's more like the live stack overflow answer. But at the same point, you've still built trust because it was another positive touch point with that team. So it's still beneficial, but yeah.
Ben Callahan (19:53)
Yeah.
Yeah.
Yeah, yeah, I
like that. I think I've experienced this in my own life as I'm somebody who just loves to learn. And I think there are these seasons where I'm like, I'm tackling some new thing that I've never done before. And I like to go deep. So I'll start research. And I may find somebody who's way more advanced in a specific topic than me.
and I look at their stuff and it makes no sense to me because I am so far behind that I can't learn from them. You know what I'm saying? And it's I have to find sort of the stuff that's just ahead of where I am. And then at some point a year later, maybe I find that same thing and it makes so much more sense to me, you know? So maybe there's a timing thing, you know?
Doug Neiner (20:38)
Yes. Yep.
100%.
Yeah, or you're so, you don't even know the term to search for, to find the answer. That's how, yeah, I know the feeling. Yes, exactly. So yeah, and that's fine. And people are different parts of their journey and just the time you spend, want it to be, you know, helpful to them and not just all go over their head and they go, okay, thanks.
Ben Callahan (20:55)
Yes.
Yeah, interesting. Right.
Yeah, and we're
this is a little bit off topic, but I want to take an opportunity to say this because I think it's really important for people to hear it. This is like a reason this is in my mind why it's everybody's responsibility to share what they're learning in their moment in this season, because.
There's somebody who's a little bit further behind you who needs what you know, and you don't have to be the one at the very end who's got everything figured out to publish a thing, to write a thing, to share it, to speak at a conference. ⁓ that's a huge deal. And I know that's not what we're talking about here, but I think it's I just I'm trying to get more people to share, you know, to share what they're learning. Yeah.
Doug Neiner (21:33)
Sure.
Yeah, no, I
agree. it, yeah, I completely agree. Share where you're at. Don't worry about the other stuff. will always be someone able to benefit from that.
Ben Callahan (21:56)
Yes, 100%.
All right. So we spent quite a bit of time, like we were the respondents and everybody attending the deep dive were very drawn to this idea of embedding. And so we had a lot of conversation around embedding. ⁓ Shaun had some really good advice. Shaun used to ⁓ run the system at Spotify and he had, he said we had a reverse embedding process that he walked everybody through. I,
asked him to drop it into that FigJam. So wherever you're listening, there's also a link to the the FigJam file. You can get into that and you can see Shaun's process. was like, you know, there was a scope document. There's a run book, which is basically like, how do you onboard somebody quickly? Everybody got an embed buddy. So somebody that they could like, you know, go to with questions. And then they had ⁓ that playbook, you know, which was just like put together a presentation of what they learned, essentially. So really nice, concise.
way to approach embedding. ⁓ And this was the reverse embedding, right? So this was ⁓ having a consuming team come work on the system team. And the reason Shaun was sharing here was because one of the things that we've also observed is having folks join your team all the time, only for a short season can be very disruptive to a team. So I think it's really interesting to see he addressed that by creating a really strong process, you know, a series of steps to follow. ⁓ You guys haven't
done the reverse. Is that right, Doug?
Doug Neiner (23:26)
We once, I think.
Ben Callahan (23:28)
Once, okay.
Doug Neiner (23:30)
that might have been twice. I'm trying to remember. I think it was just once that we took in. We had a basic internship. We didn't call it that was more of an internship with a product designer on the design system team. And fast forward a year or two later, and that designer is full time on the design system team now. So, but it had a huge impact at the time. So just to have them think through and see it from a different perspective. It's not about what's best in this instance. It's about what's best across the system. What can be consistent? Like, so even that the mind shift between
Ben Callahan (23:45)
⁓ okay.
Doug Neiner (24:00)
tactical product development and the systems development was, I think, quite beneficial to the designer.
Ben Callahan (24:06)
Yeah, I love that. Alexander also had a really good story. know, he's in the system that he used to work on. He talked about this idea of like, when we've sent, when we've had opportunities to send design system team members out to consuming teams, we had misaligned incentives. And so he talked about this idea where a product team or a consuming team just needed more bodies. They needed more people, you know, on a project. And so they took a system designer or developer onto the team.
but they weren't really there to do systems work or help spread that sort of systems knowledge. Instead, they were just somebody to move cards. so of course, there's a little bit of benefit. They're going to gain some empathy for what it's like to be a consumer and that sort of thing. But if the incentives aren't aligned, you know, like if it's not clear why we're doing this, I could see how that would create a lot of friction, you know. ⁓ So interesting story, you know.
Doug Neiner (24:44)
Yeah.
Yeah.
Yeah, it was. It was also interesting. If you're going to go to the effort of embedding, needs to provide value to the embedding team, not just provide value back to the design system team. you have to be able to take up some of those other things. if what he described was they were just kicking everything design related over to, it's nice to see related over to that embedded resource or embedded person. And then, what do you call it? They weren't learning. No one was learning anything and that person was doing that work. you know, it didn't sound particularly helpful.
Ben Callahan (25:08)
It's true. Yeah.
Yeah.
Yeah. Yeah.
Not getting the real benefit there. ⁓ I also really loved Rebecca's point. She called out this idea that like in her work on systems, she said, you can identify just as an in any organization. You can always tell who's like a helper and who's a blocker, you know? And I think her point here was really well stated, which is as systems teams, we have to be perceived as helpers. You know, if we're blockers, people will just
go around us or stop coming to us. you know, she also made this really strong point, which is like, if you lose the reputation as a helper, it's actually really hard to get it back. And so I really, I, yeah, I loved this perspective and it gets to just like the posture of a, of a system team, you know, and what does, what should it be? So cool. ⁓ What else, man? What else stood out to you about the conversation?
Doug Neiner (26:06)
Yeah, yeah, 100%.
What?
Well, other things we didn't get into, which is kind of in hindsight, interesting. We didn't actually talk about the insight you get when you're embedded in a team to the issues with your own design system, with the way the components don't work the way you expected, or they don't have the flexibility that you need and stuff. there's that entire facet we didn't really discuss, but there's, it's not just about the trust you built with the team, the advocates you formed. It's also about the real time feedback that goes, ⁓ that thing I thought through was going to be this way is actually a pain in the neck to deal with. You know, what can we do to fix that? ⁓ So to me,
Ben Callahan (26:31)
Mmm. Yeah.
Doug Neiner (26:52)
also super valuable just to stay connected to the work and feel the pain that your consumers are feeling when they're using your components. Again from a development perspective for me but I imagine the same applies to designers as well.
Ben Callahan (26:59)
Yeah.
totally. Yeah. I think it's, really easy to, to sort of stay isolated when you're on a system team and to not sort of get into the weeds of building product. But that is our user. And in the same way that we have to understand the users of our, you know, customer facing products, we have to understand the users of our systems. And that's just good process, you know, good process to follow. So I love that.
Doug Neiner (27:19)
Yeah.
Yeah, yeah, totally.
Ben Callahan (27:31)
The other only last thing I remember us discussing was this this idea of sort of like who who to work with, you know, and sort of in your in your explanation, I think we were leaning more towards like instinct. I have sort of an approach that I follow, which is I encourage teams to this is not something that they share publicly, but we do a little exercises where we sort of look across the org and say, OK, of all of our consumers.
who's already an advocate and who's not, know, like who's kind of actively speaking out against the system or just doesn't want to engage. And of those folks who has a lot of influence inside the organization and who doesn't. And if you can identify the folks with high influence who are, I call them saboteurs, but that's probably overstated, you who are not active advocates for the system. That intersection is really interesting. It can be a scary group to work with.
But if you can convert those folks into advocates, then you're getting influential people in the org who are actively fighting against the work to actively fight for it. And that's a like that turns the tide, you know, in a lot of cases. Taylor had a great story about some of that opportunity that he had as well when he was at Fidelity. So, yeah.
Doug Neiner (28:35)
Sure.
What?
One
nuance too to this is the person themselves doesn't have to be high influence if the thing they're working on is high impact to the company. So we have a bunch of products that Plainview has in its portfolio, but there's a couple of them that are the heavy hitters. And so if you can have an impact on those products, that has a lot more visibility when it comes to the senior leadership team and the different people. even if that might be a little less scary to work into, you're not necessarily dealing with a C level person, you're trying to convert to an advocate.
Ben Callahan (28:51)
Hmm.
Yeah.
Hmm.
Doug Neiner (29:14)
But if you're working with engineers or designers on ⁓ influential product or an impactful feature in a product that's going to get a lot of visibility, can piggyback on that, help them be successful, and it in turn helps the design system be successful.
Ben Callahan (29:27)
Yeah, and you're
getting at like, what's the definition of influence? ⁓ You know, in a lot of cases, it's follow the money, you know, it's like, where's the money coming in? Like who's making the most profit for the org? You know, like that question will point you oftentimes at somebody you really got to work with or a team or a bunch, a group of teams you got to support. Well, ⁓ gosh, we're almost done here, but we didn't really talk AI at all, Doug. How was, how did we get through a whole session without talking about AI?
Doug Neiner (29:36)
Yeah.
Right, yep.
I know.
I don't know, it was mentioned
Ben Callahan (29:57)
Yeah.
Doug Neiner (29:58)
occasionally. ⁓ You and I mentioned even in the pre-meeting before the call, but yeah, that was interesting. ⁓
Ben Callahan (30:03)
Yeah. Yeah, I
think folks talked about it in their in their ⁓ answered it question too, which was ⁓ let's see, which was more about without constraints. How would you change your system support? I think a lot of folks were interested in looking for ways to kind of automate things, you know, and they saw AI as a tool for potential automation of support. ⁓
Doug Neiner (30:23)
Yeah.
Ben Callahan (30:29)
I think you and I are maybe wired the same, which is like for me, when I get on a customer support call, if they give me some robot to talk to, I am instantly just trying to find the keyword to get me to a human. Like talk to a person, talk to a human, you know, and I'll say that until somebody comes on to talk to me. So I don't know, but yeah.
Doug Neiner (30:34)
Hahaha!
Yes.
I
know, I'm a little concerned. I have yet to meet a bot other than like a full LLM that they can process and do more things that is helpful to me I'm with you. I'm a little skeptical. And again, from all things we've said before,
I'd be very careful not reduce touch points with our consumers. Yes, I want them to be able to self-serve if they're working in the middle of the night for some reason and they want to be able to answer questions, sure, help them out as much as we can, but I still want them to feel like they can reach out. I still want to hear about their pain points. I want to hear about the documentation that led them the wrong direction so I can fix it we can make it better. yeah, use of caution, I guess.
Ben Callahan (31:01)
Yes.
Yeah. Yeah, totally. Doug.
Yeah, Doug, I really appreciate you, man. Thank you for coming on. I know it takes a lot of work to do this show and so ⁓ for bringing an awesome question, for helping facilitate the deep dive and also continuing to to chat with me here in the recap. Thank you for your time and your expertise.
Doug Neiner (31:31)
Yeah, my pleasure.
Absolutely, thank you, Ben.
Ben Callahan (31:39)
Thank you so much for joining us on episode 072 of The Question.
This format doesn't work unless folks like you are willing to share some of your experience and then show up here in learning mode. Remember, you can get access to the raw data, the collaborative FigJam, and all of the recordings for this episode and many more on my website, bencallahan.com If you or your team could use an outside perspective on your design system program, I'd be honored to support you in that way. There's much more information about my individual
and team coaching program over on the website. Thanks for being here and remember, stay in learning mode.