Consistency Discussion

[00:00:00]
>> I know we covered a lot here, so, jump in with questions or ideas or if you disagree or-
>> One thing that I did write down, I'm curious how long, in your opinion, if there is any kind of correct answer to this, should you be in stage one before you maybe change tactics?

[00:00:19]
If you have been lagging in stage one for, let's say a year, is that a sign of something internally just not clicking and you should rethink your approach?
>> So sticking in stage one would mean you've never actually released anything is that-
>> That's unfortunately kind of where we're sitting.

[00:00:39]
>> That's okay, yeah. I would say, so usually I'm trying to think, I remember one specific conversation where it was a top-down scenario and the executives kept changing their mind on what they wanted the system to do. That's what you're dealing with? Yeah, so I think that can happen, I think with that individual, what I recommended they do was actually go the opposite route.

[00:01:04]
Which was to go talk to the subscriber groups, and get a feel for what the organization at the subscriber level felt that they needed. And I recommended he take that stuff to the executives and say, look, I know you have ideas about this, but this is from folks in the trenches doing the work.

[00:01:22]
I've asked them what they need and this is what they're telling me. And that was a way to kind of help them sort of hone in on something. The other thing you can do is say, let's scale back, let's do less to start, let's make this a very, very simple first version.

[00:01:39]
And then trust that as people use it, you're gonna learn and just start the conversation by saying, look, we got to iterate on this thing, we're never gonna get it right if we try to do everything at once right away, that's just not how software works [LAUGH] so we have to iterate.

[00:01:53]
So, let's get something very simple live first, and maybe that's a way, I don't know if you had those conversations already, but-
>> I think we're finally getting to that point where, for us, I think there was a lot of, we've talked about this kind of off camera, but sense of ownership that was needed from a lot of various teams.

[00:02:16]
>> Yeah.
>> And up until this point, very recently, we've tried to abide and allow for that to happen, but it's just kind of taken us in circles. So now we're at the point where we just say we're going to do what we feel is best and iterate as necessary, because exactly to your point, they had the assumption.

[00:02:39]
Myself, coming into this position, that in a year's time, we could just completely overhaul the entire application from the ground up and it would be just that simple. And they have since realized that that is, of course, not the case.
>> Yeah, definitely not the case, [LAUGH] yeah, okay.

[00:02:58]
You got one online there?
>> Yeah, maybe a little related. How would you unite multiple component libraries and multiple teams for one design system?
>> Yeah, this is so good, and it's funny, in larger organizations especially, I've had so many interviews where somebody is tasked with building a system.

[00:03:16]
And they start doing the work, they start engaging with product teams and subscribers and they find out there's, I talked to one guy who was like, I found 22 different design systems inside this organization. And that's a lot, I'm hoping you don't have that many [LAUGH]. But having more than one, having two, three, four, five of these things, at least the beginnings of something is very normal.

[00:03:39]
I mean, my default approach to this, I'm a really collaborative person, I like to work with other people, I don't see people as competitive. I just, let's all sit, so my approach is get everybody in the same room or on the same call or whatever and just lay out what are the strengths and weaknesses of each one.

[00:03:55]
And see if there's a way to at least bring the sort of conceptual approaches of these various systems under one sort of common unified approach. Now, it's also possible that having multiple systems is the right choice, that could be the best thing for that organization. This is where sitting here, having only that information, there's no way for me to accurately answer that.

[00:04:18]
So I think you would need to understand what are the goals of each of these systems first and try to understand are they meeting those goals? I think it's very reasonable to have more than one system, so that could be okay, also.