Episode 5: Deep Dive - Should Designers Learn to Code?
In the second Surfacing deep dive, hosts Lisa Welchman and Andy Vitale explore a much debated topic, should designers learn how to code?
The conversation took an interesting turn as the two begin to consider the way that teams are structured around the web and discuss new possibilities about how design and technology teams can work together.
Transcript
Announcer:
Welcome to Surfacing. In this month's deep dive, hosts, Lisa Welchman and Andy Vitale explore a much debated topic, should designers learn how to code? The conversation took an interesting turn as the two begin to consider the way that teams are structured around the web and discuss new possibilities about how design and technology teams can work together.
Lisa Welchman:
I think today that we said we wanted to, or I said, I wanted to address that pervasive argument that everyone in the design community can't stand which is of interest to me because I'm always a bystander in this debate, which is, should designers learn how to code?
Andy Vitale:
Yeah. I think we can say no, and it becomes our shortest episode of all time.
Lisa Welchman:
Yeah, exactly. It's always fascinating though, because on whatever social media platform and it's usually Twitter, but I'm not on a lot of them, but I think Twitter is particularly... people get really impassioned about it and I just find it really fascinating, and whether or not it's... Why is everyone so upset about even the question happening?
Andy Vitale:
I have no idea. To me, people should do whatever they want to do, whatever makes them feel right. When we talk about designers, I get the argument that, hey, there's different types of brain people and creative people are not really great at understanding code, but that's not entirely the case. I think of myself and maths' definitely not my strong suit, but the creative side of me is. And I've tried to code, I understand code, I think, can I actually write code? Does anyone want me to write code?
Andy Vitale:
At this point in my career, I don't know if anyone even wants me to design a lot of things, but the ultimate goal of the person creating the thing is to be able to create something that communicates to an audience their intent. And whether that's a drawing on a napkin, or it's a wireframe, or a mock-up, or a prototype, or code. It's whatever that person needs to communicate that idea as easily as possible to someone else.
Lisa Welchman:
The first time I ever heard that question, which was many years ago, and I have an interesting background as it relates to web development, web design, which is I'm in that first generation of webmaster types. So when I was at Cisco Systems, that those were the years, mid to late '90s, where everybody just did everything. You got the web server up and running, you found the search software, you indexed the website in the search software, you designed web pages, you did the HTML code by hand.
Lisa Welchman:
You just did, that was the webmaster. And it's interesting because even what is it? 25 years later? It's still the case that I run into some groups where there are people who are still functioning in that way, but for the most part, people have started to specialize. But my hands on history was just doing everything. And so for me, when I think about that question, I'm like, "Well, yeah, those are completely different disciplines, whether or not to do well."
Lisa Welchman:
But I also have to say, as a management consultant who's around digital teams, which include designers, and content strategists, and technologists, and librarians, all sorts of skillsets, it's very helpful to understand what they do. And because I did all of those things a little bit, and I know Prolog, which is coding language nobody uses. But I understand code and I understand the logic of code.
Lisa Welchman:
And I think even more importantly, I understand the limitations of it and what it can and cannot do. And that doesn't mean you can't try to push or pull things, but I think being informed about those things and understanding how they work just makes me better, and it makes me a better team member, it makes me able to coach other folks better. And it helps me actually have a sense of empathy for everybody on the team because I get what the limits are and what can and cannot happen.
Lisa Welchman:
And so when I hear designers pushback back with this kind of like, stop, I don't even want to look at code or even know what code is. It just seems really harsh and not team-like. Do you know what I mean? To not be interested in it at all. I don't believe that anyone expects a designer to be as a developer, or maybe some people do, but that's not what I'm talking about. I'm not saying you need to be as good at code as you do at design, but to at least understand it.
Lisa Welchman:
Is that an unreasonable thing you think, or?
Andy Vitale:
No.
Lisa Welchman:
Guess a better question is, you said you know how to code a little bit. Do you think that makes you a better designer?
Andy Vitale:
I think it helps me understand the limitations of some of what I'm doing like you mentioned. I have not come across many or any that I can think of designers that are like, "I don't want to know anything about the code." I think it's, "I don't want to code," which is fine. But it's, I know I need to understand the limitations of this platform or the capabilities of this platform so that I can actually work in it and collaborate with the development team.
Andy Vitale:
I think there's a piece of it that is like, at some point, if you just knew like a little HTML and CSS, you can make some changes yourself. But I think as engineering language has evolved, the core of all of this I think is just speed to delivery like we talk about many other times. I think when you can get something from an idea to something tangible that's live, quicker, it always seems more beneficial.
Andy Vitale:
And I think as you mentioned in the early days, it was a webmaster or someone doing this work. Even as people that went to design school or learned how to design in a school like I went to, we learned how to use Dreamweaver. And Dreamweaver was a tool that we can actually create design layouts and it wrote the code for us. Now, the code it wrote wasn't clean, it clunky-
Lisa Welchman:
Yeah, it was really clunky.
Andy Vitale:
... but it was something. Yeah, but we could launch a site. It was only at the point where maybe I didn't work on my own or started to work on bigger projects or in larger organizations that I realized, hey, the code this creates is shit. We need experts that can take this idea that I have and turn it into like clean code that doesn't slow down the design or understands the design.
Andy Vitale:
So it's interesting to see and I wonder if as engineers are learning in school today, are they learning design programs at all too or trying to?
Lisa Welchman:
Yeah. I don't know the answer to that question. That's an instant question, but when you described Dreamweaver and all the WYSIWYG web editors that were out there, which was Hot Banana, Front Page, Dreamweaver. There were just this whole cycle of generations of this stuff, which seemed fun and I never liked, because I learned HTML and Notepad. And also I knew how to code, so I knew what clean code ought to look like even though HTML isn't code, it's a markup language, which is a difference.
Lisa Welchman:
That's the other thing that it's not code, it's a markup language. And so I think it's... But what I find really interesting and maybe a little not quite even keeled is the sort of distress call from the design community when there are tools that allow coders to "design." You said, "Wow, it was really great. We got this stuff out faster." And yeah, I learned eventually that it made nasty code, but we deployed it faster and it looked good, but probably, you were killing the technologist.
Lisa Welchman:
And so on the other side now, you've got a set of tools where technologist or regular business people can "design" stuff and deploy it faster. And so you've got the flip side and you have, I don't know. Maybe it's just the design community is louder than the code community, but the screams that you get when technologists do the same behavior on the other side are just really loud from the design community.
Lisa Welchman:
And I'm probably not going to win any fans on this, but there just seems to be a little bit of a preciousness in the design community about the work that gets done like we are kind of super special. And I don't know if it's because the work that they do is visual, and the visual aspect of it is very heralded. You can really, really see it. The number of people who are going to compliment the superficial aspects of our user experience, like the visual aspects of a user experience versus the people who are going to say, "Wow, that's really elegant code," it's just no different.
Lisa Welchman:
And so I think to a certain extent, the design community eats up that the same way that founders who get millions of dollars think they're geniuses because they've got millions of dollars, because everybody's telling them, "You're so great." I think people tell designers, "Look at this great experience you created." And they're eating that up and getting a little bit pumped up, over-pumped up on that.
Lisa Welchman:
Whereas I think we all know that underlying a really good experience is creatively and beautifully architected code and things like single sign on. You can make it the most best visual experience, but if I've got to enter that my name and address 72 times-
Andy Vitale:
Exactly.
Lisa Welchman:
... or whatever. So I don't know, maybe, like I said, I'm probably not winning any friends, but it feels like there's a little bit of lack of balance. I don't know what you think about that.
Andy Vitale:
I like that you pointed it out because maybe because I am part of the design community, I don't notice it in the same way. And I think that is interesting to me because as designers, we often talk about empathy and understanding. So it feels like what I need to do is take a different perspective or a different look at the way we communicate and talk to see if I can see what you're seeing. Because off the top of my head, I'm like, "I don't know that I agree because I don't see that all the time."
Andy Vitale:
But I do at least with the designers' voices being loud in the community, I guess I could-
Lisa Welchman:
Maybe.
Andy Vitale:
Again, it's hard to see. It's almost like looking at yourself in the mirror every day and then six months later, you gained 15 or 20 pounds, but you don't notice it until you see that before and after photo. In the moment, you don't actually see these things as they appear. The interesting though for me is, now that I definitely don't do a ton of hands-on design, but back when I was, having the opportunity to work with a really good front end developer or UI engineer that we're able to take designs or just understand the design component or the front end language to communicate ideas.
Andy Vitale:
Some of that collaboration and some of the ideas they brought to me were like, it was great, it was a partnership. It was very different than earlier when I would create a design and it was more of a handoff. It was more of, what happens to it? Oh, wait a minute, this goes live and the code or the final output doesn't match my designs at all. So I think as both front end development and design have evolved into creating products in mature organizations, I feel like the quality and collaboration has gotten better.
Andy Vitale:
But now we're at this other point where it's becoming territorial, and what I'm starting to see are these titles like UX engineer or UI engineer, creative technologist, design technologists are popping up and I'm curious why that's happening. My theory on it is we are losing front end developers in a lot of organizations because they're looking for that one person that can do it all, so they're going full stack. And I've seen this in the last few companies we've had full stack engineers and not people really focused on the front end.
Andy Vitale:
And when we go through the demos, we're like, "Hey, wait a minute. This doesn't match the comps." And we're using tools that are easy to communicate between designers and developers. It's easy for them to see the CSS and HTML attributes, it's easy for them to see spacing and grids, but they're just not matching and they don't see it because we're looking at things from a different perspective.
Andy Vitale:
And it's not until we overlay the mock-ups on the actual live code and the demo environment that they see that-
Lisa Welchman:
Is not working. Yeah.
Andy Vitale:
... wait a minute, this is actually off by like five pixels, but there's no desire to fix that. So the designers are like, "Well, I should be working with front end developers in partnership, but I'm not because there are none. So now we have to hire our own so that we can have this and then plug it into the backend system." That's the same reason why companies are like, "Let's hire a product designer so that they can do multiple disciplines at once so that we can get more out of a single person instead of having three specialists."
Andy Vitale:
So it's an interesting transition to see how it's gotten like full circle, but not... I don't know. I don't know the point I'm making here, it's just this designers coding is a lot bigger than I think I thought when we talked about having this conversation originally.
Lisa Welchman:
My perspective on this is fascinating to hear you talk about this because it's really bringing back an opinion that I've had for many years, probably the last 10 or 15 years about the way web/digital teams are formed inside of an organization, which is... I'm stepping back a little bit, one of my favorite topics is understanding how the internet and web impact how an enterprise must function. You've probably heard me say that a million times. It is, yes, it's interesting to see how they disrupted banking, and higher education, and elections.
Lisa Welchman:
All of that stuff's really wild too, but to me, the really, really subtle and interesting thing is how business and employees must interact differently within that business because of these digital spaces that have opened up. It's just really suddenly pushing on these models. And one of the things that existed prior to the advent of the commercial web was this IT and marketing component in the business.
Lisa Welchman:
So IT marketing in the business have been arguing with each other prior to the web and they'd staked out their territory. IT tends to claim that territory with control. They're heavy on policy, I'm going to yank server down. No, I will not deploy that. I'm going to shut you out. That's how they control that kind of stuff. The business' control mechanism is often money. We're making the money, we have the money. "You, IT and you, marketing, you don't make any money for us. We pay your bills, do what we say."
Lisa Welchman:
And marketing's over here and their power is, "We are the front face of the organization. We are the voice. We make all the colors, we do all this stuff." So you've got this interesting trifecta of things going on, and then here comes the web inside of it. And what's interesting to me is, digital is all three of those things together, but because those organizational units existed prior to the web, they're false, they're false piles.
Lisa Welchman:
The reality is, and I've always said this, if you want to form a digital team, one of the best digital teams, the best form digital teams I ever saw was very early on like 2001. One of the big financial services firm had a digital team that had everyone, the technology people, the "tech people," the design people, everyone all together in a pod stuck off of the CEO's office. So in some sense, it's maybe the SaaS version of like a chief digital officer. They didn't call it that.
Lisa Welchman:
I've had mixed feelings about that title as well, but just pushing that aside for a second. But everything that you needed was in that group, and so there was no arguing with anybody. It's like, if you need a front-end development, even though I don't think they called it, then, then you got it. Whatever you need, you got. And so this idea that there are disciplines that are different from one another and almost to a certain sense, disassociated, to me is odd.
Lisa Welchman:
Looking in as a management consultant from the outside, I'm like, "You guys are building the same thing."
Andy Vitale:
Only because-
Lisa Welchman:
The People, not guys, you people.
Andy Vitale:
I think that that's become the argument for designers having a seat at the table that separation, because the last few places that I've worked going back to, I don't even know. Actually, the bank I worked at last, when they went through the merger, in the beginning, when I started, their design reported into IT, into technology. So it was like, all right, well, technology felt like they were a service organization to the business or to product.
Andy Vitale:
And then because design reported into technology, they felt like they were in control of the velocity of the design team. And I always heard like, "Hey, we're waiting for this stuff. We have developers or engineers with hands-on keys and it cost X amount of dollars while they wait." And then we went through the merger and then design and product were in the same organization, and it really was a single organization. So it felt like here's two thirds of the triad of product design and technology.
Andy Vitale:
And then technology is on the outside and technology's the service to the organization and design and product we're more aligned. That's where I think that having that triad of product, design and engineering makes sense because A, there's a group of three. So whenever there's a decision to be made, it's either unanimous or it's two agreeing and one has to accept that decision.
Lisa Welchman:
Go along.
Andy Vitale:
I think that's good, but I think having them all in the same organization is interesting only because I don't remember a time that I can really point to that I remember that having been a thing. And I wonder if it would solve so much of the petty bullshit that goes on over like territory wars and decisions, and who's pointing fingers at who, and blaming who. Where I'm at now, we've got a pretty good relationship with our partners. It's up to us to figure out as we mature and evolve.
Andy Vitale:
And mature is such a weird word, but as we evolve as a product organization or product competency within an organization, we need to make sure that we're all involved lock-step through the process from what ideas are being generated or insights are being gathered, all the way through when we're launching things and learning from what data we gather, whether it's qualitative or quantitative through the process. And I think there's still room to involve each party along the way.
Andy Vitale:
But I'm going in a further direction because you mentioned the triad, but going back to like just our original should designers code? I just want to bring it back to that for a moment. We both kind of agreed that the answer was no, but I don't know that we really dove deep onto, yes, they're separate skillsets. They need to be aware of the capabilities of each other and limitations of how each other work. To me, that's the same thing.
Andy Vitale:
When we briefly talked about it, I said, "That's like hiring a plumber to do my electrical work." Maybe they could do it, I wouldn't want them to do a huge project. And you started to talk to me about when you had some work done and you had someone come in and tear up a wall and they were like, "That's not my job to put it back together." There are specialists and there are generalists, and I would call a handyman to paint something or fix something small, but I wouldn't want them to do the job that someone else is a lot better or more qualified to do.
Andy Vitale:
So I think that's why designers shouldn't code, not saying there aren't designers that can express and communicate better with developers in a language they understand, but I wouldn't expect that of every designer.
Lisa Welchman:
You just said a lot and it's interesting to hear you talk. I think one of the things that gets missed here from where I'm sitting, from a governance and collaboration perspective is folks just not understanding that you need to design a team that's fit for purpose.
Andy Vitale:
Yep.
Lisa Welchman:
And so just going back, what's happening is organizations are retrofitting a team that was designed to do something completely different. Definitely not make things and put on the web. Definitely not craft a user experience that spans the capacity of five business units and two major core infrastructure disciplines, marketing and IT inside of an organization. Plus a little records management and infrastructure stuff as it relates to metadata and taxonomy when you start throwing personalization in.
Lisa Welchman:
And so, one of my arguments for the work that I do is that no one's ever stopped to design the team and said, "Look, we're trying to create a comprehensive user experience that involves a team with many different disciplines and people with a certain amount of knowledge," that would be the business. Knowledge about the market and a certain expectation about what they're trying to achieve.
Lisa Welchman:
Given that this is the overall experience that we're trying to create, that's just strategic component, what we're trying to achieve here. What is the best team structure to support this? And I would imagine if most people actually stopped and did that exercise, because is what I do all day, it's not the team they have. And so instead, people dig their heels into where their ego is sitting, which is, I went to school for this, whether it's IT, marketing, business, whatever, this is what I know I'm an expert in.
Lisa Welchman:
And it's interesting because there's so many UX people in this that they're basically putting themselves in front of the experience that the customer is going to have. And then sometimes their own business interests on the whole, because the governing mechanisms inside of the organization are siloed and the power of each silo is sort of trumping this overall, creating this overall experience.
Lisa Welchman:
And so I just think there's just not enough attention being paid to just a very fundamental thing, which is, is our team organized in the right manner to get this work done? Right. So instead we're talking about, let's argue about some old roles that we've had forever, designers versus coders versus... It just doesn't even make any sense. On every click on every page, five or six disciplines are represented.
Andy Vitale:
Exactly.
Lisa Welchman:
There's content on every page, there's an interface on every page, there's code, there's a hosting infrastructure underneath that's going to make that page break. Think about all of the vaccine websites that can't take the load, because somehow there's some disconnect with IT that nobody said the governor, or the president, or whatever is, tell everybody to go hit this stuff. That used to be like... It doesn't happen any much anymore, but you remember every time there was a Superbowl ad with a URL in it, it was like clockwork.
Lisa Welchman:
It was like, nobody told IT, "We've got this ad." Probably millions of people are going to click this link at 3:30 on Sunday afternoon, or whenever. I don't watch football, so whenever that happens and... Or American football, I should say, so I don't get beat up by everybody else in the world. And I always used to look at that and I was like, "Okay, technologically speaking, I know that there is a server and host infrastructure that can handle that load. And two, it probably doesn't cost that much, why is that broken?"
Lisa Welchman:
And so it's these unnatural rifts that happen, and it's a poorly designed team. And so I think that question of, should designers code, should coders design is a non-question to a certain extent. Because honestly, if the team were properly designed, it's like saying, let's take a musical example, either an orchestra or a rock band. I'll say rock band because more people know or a four piece ensemble. Most people know that four piece ensemble better than an orchestra.
Lisa Welchman:
But I would expect that the guitar player at least gets what a drummer can and cannot do. And that after playing in that same band together, also understands where some of the stress points are or aren't, or might even be able to play a little drum at a certain point after just watching them for a while, because you're interacting and collaborating with each other. And so for me, that's the hope that if you can get the team designed properly, people will interact.
Lisa Welchman:
So the designers will intuitively know as they're designing, "Oh yeah, I worked with a front end developer the last time. I'd like to do it this way, but I know that's going to be like 18 more cycles," or whatever. Or, "Our taxonomy isn't a faceted taxonomy, so we really can't do it like that." Or maybe they say, "But we really should do it like that." And then they go to the taxonomy people and say, "Hey, I don't want this hierarchal mess. I want a faceted one, because this is how it's going to work." And they have that conversation, which is collaboration instead of fighting.
Andy Vitale:
And that's so reliant upon what you talked about of having the right team built. Because I see in a lot of places, I hear from a lot of designers like, "Hey, I work on this thing in this area, but I'm not 100% dedicated to that and neither are the engineers." So they just pick something up and move on to the next thing. And it's so important in a large enterprise. Our teams are dedicated to the problem spaces because they need to learn that knowledge, not only of the customer and the business, but the capabilities that we're building.
Andy Vitale:
So you're not working with a different engineer that's reinventing the wheel the next time around or doesn't know the struggles that we had for the last three months over the limitations of like single sign-on or dual factor authentication that impacts the experience. So it is, that's the solution is each team may be different, each problem may be different, but I think somebody needs to collectively or individually design that team, organize that team so that they can tackle those problems the right way.
Lisa Welchman:
I'm of course, going to violently agree with you on that one because it's interesting. I always say, "I'm not a designer, but I am a team designer. I'm a designer of groups," and it is frustrating for me to see how much people are just running into each other for no reason. Everybody usually has the same intent, they want it to work well. Even the ones that folks like to complain about the most, IT, it is actually because they are very policy-oriented, because historically that's just part of their culture is to be...
Lisa Welchman:
Theirs is oriented around security and privacy policy as the marketing team is oriented around brand. Each one has their own area that they like to protect, and that's good because we need somebody to protect those areas as well. But they're, for the most part, unless you work in a hyper controlled regulated industry like the financial sector or pharma, or if you're in other certain parts. Certainly in the U.S., it's looser than is, say in Europe with GDPR.
Lisa Welchman:
But most people are trying to get the most that they can within the bounds of the law, out of the experience for the organization. And for good and for bad. Sometimes that's led to some sticky experiences that maybe didn't need to be so sticky, but for the most part, people are trying to do that and they're trying to do their job well.
Lisa Welchman:
What do you see since we seem to be agreeing that the team's poorly formed? What do you think folks can be doing from where you're sitting as a team lead, knowing that I walk in, if somebody hired me, they're basically saying, "We know our team is poorly formed, reform us, Lisa."? But even then, getting them to make the changes that they need to make is really, really tough, because people don't want to undermine that.
Lisa Welchman:
But you're in the position where you're leading a team and sometimes people just don't have the time or the energy or the will to actually turn that team over. What do you think would be, based on our conversation, some easy steps or not easy, just steps that people could take to lean more into that direction of a richer collaboration in an environment where the people who are creating the digital experience are operating in silos?
Lisa Welchman:
We like to talk about silos all the time, but when digital people talk about silos, what they're usually saying is, "I hate those people over in business." Or, "I hate those people." They're not thinking, well, we are siloed correctly.
Andy Vitale:
Exactly.
Lisa Welchman:
We are siloed. And so I'm talking, keeping it in the family of people who are making digital and forgetting about all those other silos, which are problematic, it's another conversation. But what do you think can happen in that space?
Andy Vitale:
I know. For me, in my role, it really is about identifying the opportunities to improve, whether that be the quality of the output of the design team or the relationships that we have with our partners. Or the holistic, like what's not working as we try to collaborate to produce better outcomes in our products for our customers. So it really is a lot of like just understanding perspectives from all sides.
Andy Vitale:
Talk to them, what's working well, what's not working well, making sure that they understand they can see the picture. And if they don't, it's educating them on a proper process for a team to produce products and look to best practices and examples of what had worked well in the past. And you build those relationships so that you can get people to try it. Let's pull together a small team, let's try it this way, and if it works, you can scale that.
Andy Vitale:
We're doing that now. We're identifying a little bit better way to help the designers understand their specific roles and responsibilities, and then work on working agreements with our partners, and then figure out how we can carve out this small group of people to try something just a little differently to see if it works. And if it works, we scale.
Andy Vitale:
And then, in a position like I have now, like we have, having a voice that people can listen to and the ability to share these experiences publicly, we can even further create best practices or examples of what has worked and help other people that are struggling with the same problem in other organizations. So it really does just start at assessing the landscape and building those relationships to get the opportunity to trying it.
Andy Vitale:
Seeing what works well, what doesn't work well and taking what worked well and continuing to iterate until you hit it right. Because it might be slightly different in any organization, but the key foundational elements of like these parties in this working relationship, if they work this way, if we build things together, the outcomes are going to be the same most of the time, and share that. And that might work well for someone else or it might hit 50 or 60%, but it's foundational that they can build upon.
Lisa Welchman:
Yeah. Those are good things. I think for me in answering my own question, I'm going to go big or go home on this one, which is, I think that the root of the problem is that the compensation structure and how success is rewarded is skewed towards an old model. So if people got bonuses based on how well an experience was architected and operated cohesively rather than down their particular organizational silo.
Lisa Welchman:
There is marketing performance objectives, and IT performance objectives, and business performance objectives. And so I think people are pretty not complicated and they're going to do the things that cause them to look successful. Whether or not, I'm not saying that in a negative way at all, I include myself in that. You want to look good, you want to do a good job and you want to be thought of as successful and competent in your organization.
Lisa Welchman:
And that usually equals not just money, but some sort of, I don't know what the right word is, accolades or whatever inside of your organization and also bonuses. And so when I look inside of an organization, one of the first things I look at is, how's your money running? If they're not collaborating well together and it is just as I described. IT's got a bunch of money that they suck off the entire business, they just get money to run and they operate this machine that's often in a black box, nobody knows what they do, and it runs and people write them checks, and they've got a tremendous amount of power.
Lisa Welchman:
Marketing communications is a little interesting in that way as well. They tend to spend stuff a little bit faster. They get budget as well, not as much as IT. Unless it's advertising or commercial-related budget, that's a whole different thing, but the whole digital teams often grabbing for money, trying to get money out of the organization and the businesses make money. The business units make money for the organization as I described before.
Lisa Welchman:
And the compensation is lined up around that. It's almost like an internal enterprise version of, you know how we all say, "Don't organize your website based on the business units"?
Andy Vitale:
Right.
Lisa Welchman:
Of the organization, because that makes for a horrible user experience. We've been saying that forever and who knows why we haven't learned that lesson yet, but people are still doing that. We also do the same thing team-wise, which instead of saying, "We're going to compensate this team holistically based on whether or not you create a unified user experience, the whole experience," it's still cut up in these silos.
Lisa Welchman:
So I think organizations really need to look at the way that they... That's the word I was looking for, reward people for success. And if that started to line up around the values that you described of working together as a full team, that you actually will be able to make some sorts of changes. Because everywhere I look, it's the same thing. They control that and they control that, it just doesn't make any sense.
Lisa Welchman:
I'm hoping that 20, 30 years from now, what we'll see is that the impact of the internet and the web actually re-engineer the enterprise. Right? Because it should, it re-engineered everything else, why would it not do that? Right?
Andy Vitale:
Yeah. And I think the thing that I'm thinking about that we haven't touched upon because it's not relevant to designers coding versus not, or organizational... Well, I guess it is for organizational structures is, the centralized versus decentralized groups too. There are areas that the design team reports into design and also that could be separate. In a lot of places, there's the separation between designers who create products and the marketing designers.
Andy Vitale:
And marketing is its own thing, and this is the digital team. But if you've got a centralized engineering team, and a centralized product team, and a centralized design team, then really who's calling the shots. Yes, it's a collective, but isn't it better potentially, I guess every organization is different, if they were organized by... Maybe it is by line of business, maybe it is by problem that they're solving.
Andy Vitale:
And those teams have both product design and engineering in that same vertical. There's arguments for both cases and it depends again on maturity and lots of different factors. And I think, just ask, I was playing devil's advocate to myself because all of what I talked about was a centralized structure. But if it was decentralized, would that solve anything? And the answer is, it depends.
Andy Vitale:
It's not a yes or no, it's not black or white. It's a gray area, but it's worth thinking about if you're going through a similar situation of what could be solved if we ended up just changing the way our organization is laid out and really start to dive into the changes of redesigning the organization.
Lisa Welchman:
I agree too. I think the last thing I have to say on that and in reaction to what you said is, you're reminding me of one of my favorite things and I'll try and take it out and put it in the show notes. It pops up every now and then in a talk for me, which is I have this execution atom, which is literally an atom. And the nucleus of the atom are performance indicators, so metrics. Quantifiable, measurable things that you are trying to achieve.
Lisa Welchman:
I want to sell this much. I want this many clicks. I want whatever that may be is broad or is narrow as that needs to be a depending on what you're doing. That's half of the nucleus. The other half of the nucleus are standards. And so that's basically saying, "Here's how we work. Whatever you need to have standardized on for the brand, whatever you need to have..." All the full set of standards. I put them into design, editorial, publishing and infrastructure and hosting and network.
Lisa Welchman:
From the least technical to the most technical, I hate that description, but just the 360 degrees of standards that you need. And everything else that you just described, making things, interacting with stuff is floating around it like electrons. And so it requires, so instead of having a permanent structure, you have an impermanent structure.
Lisa Welchman:
And depending on what you happen to be making at the time you pull in what you need, but the sun are these performance metrics and these standards, so that you're all have the same basic instructions of what you're trying to do, but how you apply them is situational to either the product design process or whatever it is that you happen to be doing at that time.
Lisa Welchman:
It reminds me of like back in the 1980s, people tried to do matrix-managed organizations and they just couldn't get it done. I always say that I think they could not get it done because they didn't have the right technology tools that would allow people to stay connected in that process. But now we have things like Slack and we've got, I'm looking at you while we're recording this. We have all of these tools that allow people to form temporary teams around a shared goal and objective, get it done and let it go.
Lisa Welchman:
Now, of course, there's an operational component. Once you've developed something, it has to be maintained, so just take this a little bit with a grain of salt. But I think there's another way to work other than saying, "I'm going to engineer this team hard and solid to stay like this and everything that we make has to go through this one factory." It's like having a single factory that's supposed to make 19 different cars, or assembly line. And it just doesn't work that way.
Lisa Welchman:
One assembly mine is really optimized, I don't even know enough about automobile manufacturing, but let's just assume it makes one model car, various versions of it, whatever the case may be. But it's certainly not making everything that organization makes or that that car manufacturer makes. And so I think that's what we're trying to do, we're trying to create a single factory by hardening this org structure and then thinking that it can turn out anything.
Lisa Welchman:
I think that is irrational and doesn't make a lot of sense. But I also think that the history of the enterprise and the corporation is around this hierarchical, nested thing and not a faceted free atomic structure. One of them is three-dimensional, and interchangeable, and has a lot of motion in it, and the other one's hard. And so I think... I'm always saying, "I hope I live long enough to see."
Lisa Welchman:
I think a little bit of that starting to happen now with the result of the pandemic, because people are working from home. So you're getting a little bit more detached from that. But I think that that sort of shift is what's going to be required in order to get this done. Does that make sense to you? Because I'm always saying that all the time. I've been saying this for years and everyone's like, "Yeah, you're right, but you're kind of crazy," but I think that's what we need.
Andy Vitale:
It definitely makes sense and there are pieces of it that I'm starting to struggle with. Not struggle, just think about, which is the intent is to make me think about this. How in that structure do we support this matrix of understanding the problem space really well and also driving... Driving's an interesting word, but ensuring, not from a governance perspective entirely, but really making sure the quality of each individual discipline or subgroup their expertise is represented in this?
Andy Vitale:
Because what I didn't see, yes, we can definitely get a group of people that are multidisciplinary, cross-functional aligned on OKRs, or objectives, or metrics that we want to go after. But still at that point, who's making sure that the individuals building it are doing their best work. We talk a lot about autonomous teams, but there needs to be somebody to coach them through it, to oversee the work, to QA the work, to make sure that it's actually hitting those metrics.
Andy Vitale:
Depending again on who you talk to, it will be anyone in those roles will say, "Oh, it's my responsibility to do that. I'm the product person I'm going to make sure that all of these things are met and the design is met." So I'm just curious, who's going to oversee design quality? Who's going to oversee dev quality? Who's going to oversee anything else? Who's going to oversee the copy? Who's going to oversee the legal decisions that are made in that situation?
Lisa Welchman:
That's fair. That's a fair question and I think when I put my governance hat on, I would say, okay, always, there's going to exist this core team of folks who are establishing standards. Not from an operational maker perspective, but just from, there will be experts who say, "This is the way we do things," and that those things will be articulated and they'll also be deployed.
Lisa Welchman:
One of the things I never see inside of an organization that I'm always trying to install is governance ops, which is basically somebody whose job it is to make sure that we actually have standards and that everybody who uses the standards knows what they are. And that can even get as tactical as things like giving people recommendations for hiring people. If you're looking for this type of resource, here's what you need and they need to be able to do these sorts of things.
Lisa Welchman:
So at least there's some standardization that happens around governance and governance ops, which makes it a little bit more solid. So I would say, that half answers your question in terms of setup. The other part of what you're talking about that I don't know that I have an answer to is real time while we're building. But part of me is going, "Well, if the standard is there, isn't that just taken care of in a QA process?"
Andy Vitale:
You're right. And it's having the right demo process so people get their eyes on things and making sure that it's seen and those discussions are being had. The more I think about that after I asked the question, I've built a solution to this or we're rolling out a solution to this. We're calling it some sort of guild or brain trust, but we're having a core group of people that are looking at almost everything from a different lens of quality so that they're not tied to the KPIs or the OKRs.
Andy Vitale:
But they're actually tied to the quality of the work and making sure that it meets the standards, and the governance, and it's our own version of governance that we can take these core folks and get their eyes on many things to make sure.
Lisa Welchman:
The number one thing that I usually see that is challenging for folks like you, who are trying to build a team and get it moving basically in an agile, but safe way, just get it operational and moving well, operating well. I shouldn't even use the word, agile, because operating well is this pushing together of governance and ops. Because what you described earlier, which is, if it's not really clear who's supposed to, in general, be establishing the standard that is going to apply, anyone will think it's their job to do in execution.
Lisa Welchman:
And so what I'm always trying to get people to do is like, yes, there will always be some weird situational decisions that has to have to happen when you're designing and building product. But for the most part, you can know what types of standards are going to always apply. At least 80% of those things can be the same or similar, and then there's these little nuances. But if you don't actually define that set of stuff upfront, you're always trying to do it in a project, in process.
Lisa Welchman:
And it gets done slightly different over here, and slightly different over here, slightly different over here. And that's when you get this sort of cacophony of stuff that happens online. So it's a conscious decision to have to really pull all of that out and say, "Look, there's a part of the organizations whose job it is to enable everyone else." Make sure we have these standards, make sure that they're communicated, make sure that people are trained so that they can actually use things.
Lisa Welchman:
And even more strongly, make sure that they are implemented. People like to write down standards and the obvious thing is like embedding a template inside of a web content management system. That's implementing a standard, but there are all other sorts of things. Implementing a standard might be making sure that you hire people who can write for the web, because there's no other way to implement your editorial standard other than to hire people who know how to write for the web.
Lisa Welchman:
Sometimes it's not a technology solution, sometimes it's just training. Sometimes it's not a standard, it's a guideline because you can't really get a hard standard. So I think there's just a lot of effort that needs to be put into that. But this really turned into not a conversation about-
Andy Vitale:
Should designers code?
Lisa Welchman:
... should designers code? How did we get to this? I think we were like, "No," from the very beginning. They don't need to, but they should be... How about this, but they should be on a team that collaborates in such a way that they become familiar with the limitations and practices that people who do code have to live with.
Andy Vitale:
Exactly. And I think just to even bring it full circle, but tie it all together is, should designers code? They don't have to. Should anyone that's building products understand the capability of the code, no matter what their discipline is? Yes. Just like the designers and the engineers should understand the business requirements and the needs of the business, and they should understand the design perspective.
Andy Vitale:
So it really is, no, you don't have to do someone else's job or what feels like someone else's job. You can, if that's what you do, but you should be aware of what everyone else is doing and understand the capabilities of what they're doing so that you can build better products.
Lisa Welchman:
There you go. 100%.
Andy Vitale:
Cool.
Announcer:
Thanks for listening. If you enjoy Surfacing, please rate, review and follow us wherever you listen to your podcasts. Also consider supporting the podcast on Patreon at patreon.com/surfacingpodcast. On the Surfacing Patreon page, you can support the podcast or become a member and gain access to exclusive monthly Ask Me Anything podcasts with Lisa and Andy.
Announcer:
If you have suggestions for guests or a topic you'd like to hear about on Surfacing, please reach out via the contact form found at surfacingpodcast.com.