Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been wondering whether adopting adopting AI coding assistance is effective generally, or if using them merely constitutes a different style of development and the efficacy is tied to how well the developer fits that style.

[00:00:40] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I've been thinking about the value of taking time to do fun things together as a team, whatever fun means for your team.

[00:00:50] Allan Stewart: Our topic for this episode is working on cross-functional teams. Cross-functional teams is pretty well known now, I think, in the industry and pretty well accepted. There are different varieties of team structures that we see at various companies. Some of them are more cross-functional than others, where members of different disciplines are literally working on the same team, right? That they're together as a team. And there's other ones where working with the cross-functional person, like they're only part-time working with your team, or like they there might be a shared resource across the teams or things like that. But in this episode, we wanted to talk about what are our expectations for these different disciplines?

[00:01:36] Dave Adsit: Yeah, I think it's really important to level set on that as a team. And I think that every team is going to have different expectations, but I think that there are some basic expectations that we can bring. Like, what do I expect from members of my team who are in a different role? What should should they expect from me? And what should we do together to move the work forward? So I think we'll go through and talk about various different roles, various different and the expectations that we should have for each other based on those roles. But let's start with product management. That seems like that's the most likely candidate for you have an engineering team with a a cross-functional flavor. The first group, the first thing that you're going to add that's not an engineer is probably a product manager.

[00:02:28] Allan Stewart: Right. And the product management is generally brought in to have a vision for the product, right? Like help orchestrate that work of what is this product? What is it about? What should, what do we want it to be? How can it be effective? And that kind of thing. And I think that the biggest expectation that I want with a product manager is collaboration with the engineering team. So coming from a perspective of I'm an engineer, I'm working on code, I want to collaborate with the product manager. There are definitely places that I have worked at and things that I have observed at other companies where that's not always the case. There's not always collaboration. Sometimes it's very much a ticket generating process where most of the work, all the thinking part is done ahead of time. And then everything else is just left over for engineering. It's just the coding it up. "Like we've already made all the decisions. We've already got the mockups. We've already got all the things that you could possibly need. And I just need you code monkeys to go and write the code."

[00:03:44] Dave Adsit: Yeah, I've definitely seen that. I've worked on teams like that. I think that that takes to the extreme that the product management owns the what of what we're going to build and engineering owns how. Um, but, uh, I would say that when I have been in environments like that, where product management, sometimes even in these cases, it's called product owner goes off and does all the thinking and designing and whatever ahead of time, and then delivers the tablets of what we want built to the engineers. I don't think of those as collaborative cross-functional teams. No. I think that what happens in those cases is that you have created a series of silos and handoffs, and that may be more effective than not having the role. But the reality is you have not created a team that has a charter to tackle a problem and deliver something of value for the company. So I think I agree with you. Collaboration is essential. And collaboration with product manager takes a lot of shapes, right? There's a lot of things that I expect to happen there. I expect the product manager to be doing research and discovery and understanding the customer and owning that customer relationship and then coming with an idea or a vision of what we're going to do. And then I expect them to interact with engineers to determine how are we going to cut this up into iterative slices? How are we going to find like the first part of it that we can deliver and then the next part that we're going to add on? And what do we need to build together so that you can learn more, you as the product manager can learn more about the customer and we as the engineers can learn more about the problem space for what we're solving. And I think I agree. Collaboration has to come first and foremost.

[00:05:39] Allan Stewart: Yeah. Having that high bandwidth communication helps in a lot of ways, right? Because otherwise, if taken to that other extreme where you just hand the tablets down to the code monkeys, at that point, you're basically running an internal offshore team. Right. And one of the things that we have learned, one of the big issues with product development and external contracted teams is that that lack of communication almost always leads to technical issues because they didn't understand the vision of what was being built or why certain decisions were being made. And so you often end up with mess of code, right? So there may be a mess of code for a couple of reasons, right? If the developers just aren't doing their job, they're not writing tests, they're not making clean code. Well, that's one problem. But if they don't understand what it is intended to do, then you get a different kind of mess of code, which the code might actually be fairly clean. But it's just not built structured in a way that is going to be able to meet the dreams of the product.

[00:06:53] Dave Adsit: Yeah, I've definitely seen that happen. So one of the things that I expect as a mitigation for problems like that is that we are working in small batches. I expect the product manager to bring small batches of work to the engineering team and say, "Hey, let's see what we can do with this. Let's see what we can do with this. I have an idea. What can we build for this idea? What do we need to do to either validate or execute on this idea?" And so I want small batches. And when I say small batches, I want things that are going to take, I want us to be able to release something of value to customers, ideally every day. But realistically, features that are going to make a difference to customers, I would like to release them a couple of times a month, a few times a week on that scale. So if you're thinking of feedback in terms of quarters and years, that's the wrong scale. I want feedback in terms of, or batches, I want to create batches on the order of days and possibly weeks on the larger end so that we can get feedback on what we're building. Are we actually building the right thing? Even when we do a lot of research upfront, when we do product discovery and product research upfront, we can still guess wrong. We've talked in the past about the product discovery double diamond of start with a problem, expand, ideate around the problem space, and then narrow down to one problem you're going to solve. Then ideate around the solution space and narrow down to one solution you're going to try. There's multiple opportunities in there for us to improve on what we're building. And we could have gotten the problem right and the solution wrong. And so if we're working in small batches, we can learn that quickly.

[00:08:37] Allan Stewart: Yeah. There's lots of opportunities for different kinds of experiments too. And by involving, by collaborating early on in that double diamond approach, right? If it gives us the opportunity to experiment with the problem space and experiment with the solution space before we get mock-ups, right? We can start searching for data or we can do some painted door tests. We can do some A-B testing along the way. Those kinds of things that allow us to explore those options and see, "Hey, is this even feasible? Is this going to work?" And it just reminds me, like, if everything that we've done is, like, is only customer interviews, then we're going to get the Henry Ford problem of all the customers are wanting faster horses. Right. And like, because they also are prone to this solution mindset, right? Like they're thinking of their own problems and they're like, "well, this is the solution that I want," but it may not be the solution that fits very well with our product, or it might, you know, in a lot of cases, not even tractable, right? It's not, it's not what they wish they had is that faster horse instead of something a lot better. And by, by actually building some of these things, testing them out, having that collaboration early on, we can shortcut a lot of painful wasted work.

[00:10:13] Dave Adsit: Yeah. One of the other things that I want from a product manager is prioritization of work. There's a million good ideas. There is always more good ideas for work than there is capacity to deliver that work. And so I want a product manager who is collaborating with the team to pick the most important, highest value things for us to do. And I want them to be able to say, "do this, then that," as opposed to, "why don't you try to do both at the same time." Because we know that doing both at the same time, they're both going to be delivered later. And there's a possibility that we can actually create value much sooner if we prioritize based on what actually makes a difference for our customers. And so I want a PM who's going to say, "do this, then this, then this." And I also want a PM who says, "here are five other good ideas that we're not even going to tackle." We're not even going to spend more time thinking about them because there are too many good ideas. These ones are not aligned with our current direction. They're not aligned with our current audience that we're targeting. They're not aligned with our current technology investments. And so we're going to throw these off for later. We're going to delay or just forget about them and not do them because there's always more good ideas than there is capacity.

[00:11:33] Allan Stewart: Another thing that I hope that a product manager will bring to the table is that they are really focused on that customer experience, right? Understanding the customer, looking at all the product requests and analyzing, like, what do people want and understanding that. And that's not to say that I don't want to be involved at all in any of that, right? I think that we've seen a lot of, you know, through the years, we've seen a lot of success with engineers having direct access to customers and getting in and understanding them better. So it's not that product owns that. It's just, that's their focus, right? Like that's their priority work. Whereas my priority work as a developer is to write the code, right? And so I don't, I don't want the product manager to feel like they have to come and write code. They, you know, in order to be part of the team, there are things, important things that they are are doing. And we each take a specialty. And, and we trust each other that, hey, and I think this goes just generally for all the various disciplines we can work with, you know, I want to trust that you're doing your job really well, because it's not something that I'm as skilled in, whether I can, or in some cases, I can't do that specialty at all. But I want to trust that, "hey, they've got their part down." And and that's what makes us better by working together is that they're doing something that I don't have a specialty in or I am not as focused on or lack that skill completely.

[00:13:04] Dave Adsit: Another thing that I want a product manager to do is bring knowledge, be very knowledgeable in the area of the product that we're building. In fact, I might say that I want them to be a subject matter expert in that area. In many cases, maybe not all cases, maybe if we're building extremely complicated sophisticated, uh, surgical software, like medical software. Maybe I don't need a doctor to be my product manager, but maybe I want somebody who at least has familiarity with the medical field and understands what the possibilities are and is good at communicating with people at that level of expertise. Um, but in many cases, I think that the, the product manager should be somewhat of an expert in the field that they are leading us in. It helps them have deeper empathy and a deeper ability to explain the concepts in a way that helps the engineers build the right thing the right way. It also helps them with one of the other critical skills of a product manager, which is understanding, analyzing, and making decisions about trade-offs. There are inevitably going to be trade-offs that we have to make in our systems as we implement them. We can't have everything we ever wanted. But if they understand the underlying space better, then they will be able to make better trade-offs about what are we giving up in the future? And will that thing become something important? Or if we made a different decision, would we be giving up something else that may not become important in the future?

[00:14:35] Allan Stewart: Another thing that I, the expectation I hold for product management is that the product manager should be a member of the team, not the manager or in charge of the team. The product manager manages the product, not the people that build the product. Right. So they own what it is we're going to build. They own that, that vision, right. And, and, you know, we share it together. We're building it together, but that that's their their core is to say, "Hey, what things should we build?" Right. To your point, there's always tons of good ideas and there's never enough time to build everything. And so they help us focus on what the most valuable things should be, but then engineering owns how we build it. And, and that's an equally important aspect of, of building a product, uh, is actually building the product. And so, so yeah, I, I expect that product management should not be bossing people around and telling them what, telling them what and how to do their work, but say, "this is what we want to accomplish. Let's work together on how we can make that happen."

[00:15:44] Dave Adsit: You know, I've seen a lot of people try this where they have kind of the product manager as general manager or GM of of this function type of a model. And they have the engineers and everybody else report to the product manager. And every time I've seen people try this, it's been a huge disaster. I think that one of the things that becomes very challenging very quickly is understanding and analyzing and developing people who have a different skillset than you do, while also managing a mission-critical product. Being a product manager alone is enough work for most people most of the time. Like that is a big ask. Understand the customers and their needs and what we can do to solve their needs and meet their needs. And what is possible and also divided into iterative releases that are small enough that we can get something done this month and next month so that we can have something for the marketing news. This is a big job. And when you add also manage eight engineers who have a specialty you don't and whose skills you are going to have a hard time evaluating and whose career development you're responsible for, but don't understand. I feel like you're setting someone up for failure if you make the PM, a GM, and have them run part of the product. And so I recommend against it in every case. I think we often hear that there is a healthy tension between product management and engineering leadership. And yes and no, like I suppose that it can be healthy. I don't want it to be conflict. If it's conflict, that's a problem. I expect there not to be conflict. I expect there to be

[00:17:24] Allan Stewart: collaboration instead. Yeah. I was just thinking that same thing. And I was thinking about healthy tension being something like a kite string. We need to pull apart a little bit. It's like we're pulling against each other, however you want to think of this metaphor. But that healthy tension is about there are product concerns and dreams and things, and there are technical concerns and dreams. And we need, if either side of that, I've seen plenty of cases where that gets out of balance. And if the engineers have too much say, then there's a lot of, you know, over-engineering kinds of things that happen and gold plating the product and building features that aren't necessary. If product has too much sway, way, then technical things that are very important go undelivered. And then we slow down, the system bogs down, and we can't release as quickly as we want to. So that's my thinking with that healthy tension is that you can't let either one of those concerns trump the other. And if you put the product manager in charge or an engineer on the team in charge of the whole team of managing managing everybody, they're going to have the same kind of problem, right? Like they don't have the skill of, of product management in order to help them be, you know, have their career development. And so there needs to be a different, a different way of thinking about that, where it's truly a peer relationship and that nobody gets in charge.

[00:18:58] Dave Adsit: Yeah, I agree with that. I think one of the things that I want a product manager to be aware of, but not necessarily involved in the decision-making on is the non-functional requirements for the system, the technical requirements like security and reliability and maintainability and all of those things that we talk about from an engineering perspective all the time. I want them to be aware of and understand that some engineering capacity must go to those things in order for the system to keep being delivered over time. If we take shortcuts there, we're going to have to pay it back later with interest. And so I want them to be aware of that, but not necessarily be making those decisions. Because we have technical people who can make those decisions instead.

[00:19:40] Allan Stewart: Yeah. Yeah. I think that one of the common things for, with all of the product people that I've worked with that I have really, really liked working with them. Uh, that what they had in common was this is that they had an appreciation for, there are some hard technical problems, and we're going to need to spend some of our capacity on that. And that's just part and parcel with how we work and we're going to do it continually, right? So we're not going to put it off to a hardening phase later down the road or "I promise that in three months when this big project is done, then you'll get you some time to do some technical things."

[00:20:20] Dave Adsit: Yeah, which never comes.

[00:20:21] Allan Stewart: That never pans out.

[00:20:24] Dave Adsit: There are a handful of things that I think a product manager is responsible for and an engineer on a team can expect that are, you know, they're the project product management skills. Like one of them is basic project management ability. Another one is customer interviews, customer surveys, data analysis. These are things that I expect a PM to be able to do and provide as a service or part of the work of the team. I also expect them to be preparing some light documentation around the features we want to build. I think we've talked before about Amazon one-pagers or PRDs or things like that, right? They're like, "what is the product that we want? What is the next thing we want to build?" And then I want them to run a kickoff meeting with the team about that. Here's the document. Let's go through it. Let's understand it together. Let's understand what's in scope and out of scope. Let's understand what things need to be done to accomplish this, how we're going to measure success. I want them to be responsible for all of that. And I also want them to be responsible for release management. One of the things that I was talking to one of my PMs about just today is the importance of developers delivering updates to the system multiple times a day. As we get things ready, we put them through our CI pipeline and we do continuous delivery. And now we have, I should say, we have deployed them ideally behind a feature flag. And now I want the PM to be responsible for bundling up those various deploys into a release that has a cohesive story. We've made a bunch of changes to the system. What is the story we're telling? How are we going to market it? How are we going to sell this to customers? What is the right unit of work to release together to create new customer value? You know, we, and I expect them to be responsible for that release management.

[00:22:23] Allan Stewart: Agreed.

[00:22:24] Dave Adsit: And then one more that comes is immediately follows on from that is manage feedback from customers. Will we do a release, go find out what they think. Again, do those surveys, do those interviews, have, find ways to measure engagement with the new things that we've done and whether they're creating value. You. Ideally, you will have some, not just qualitative feedback like surveys and interviews, but also quantitative feedback. Like we measured the behavior before we released the feature. We've measured the behavior after. The behavior after is more in line with what we want. And so I expect them to be doing those kinds of things and then using that as feedback into the the next iteration of development. So focus on how can we get version or, you know, the MVP, and then the first enhancement and the second enhancement and the third enhancement and, and learn, you know, when do we need to stop working towards this one particular goal? And when can we switch to another goal that is, you know, in alignment with our customer, our overall business mission or whatever.

[00:23:33] Allan Stewart: And then I think the final thing that I would would hope from a product manager is kind of a recognition that coding work takes time. There's a lot of little details that go into it. I mean, as compared to creating a wireframe or a mock-up, it takes a while to be able to do the coding aspect of it. And so I hope that that product manager can stay focused on what we are doing now and how they can help with what we're doing now, what we're doing now and what we're doing next, but not fly off the handle and be spending their, their days dreaming of what we're going to do in six months or, uh, you know, our, our five-year roadmap that is unlikely to come to fruition because it's just disconnected from reality. I'd rather them stick close and say, "hey, I'm here. I can answer questions that you need. And I'm reinforcing the work that is happening now," rather than coming up with new ideas and kind of, in some cases, undercutting the work of the team.

[00:24:45] Dave Adsit: Yeah, I agree with that. I want the PM to be readily available to answer questions about the work that's currently ongoing, going, even if that means that they may not have as much time available to work on what we're going to do next. I do want them to work on what we're going to do next. However, it's like, I don't want there to be gaps where the team is like, "oh, well, we worked through your entire queue and now you don't have anything." We've starved the queue. We've, you know, completely drained the queue and there's nothing left. But I do think that focusing on now is more important than focusing

[00:25:18] Allan Stewart: on next. Yeah. If that problem happens, I can assure you that there is some technical work that we can do that would be valuable in that space. I'd rather err on the side of, we ran out of something to do, then I've got your work cut out for you for the next 10 years.

[00:25:35] Dave Adsit: Yeah. So any team is going to have a collection of practices and meetings and rituals and things, and different members of the team are going to participate in different parts of that overall process. I think there are several meetings that I expect the product manager to participate in as a mandatory participant and possibly a couple as an optional participant. I think the PM should be at every team standup. I think a team should have a standup every day. And I think that the PM should be at every standup. I think that the team should have a retro every week and the PM should be at every retro. I think that planning should happen as needed ad hoc. For some teams that's scheduled every week, every other week, whatever. Some teams, they like to do planning a couple of days before they wrap up the feature that they're working on right now, plan for the next one. And so that includes some of those kickoff meetings and things, right? The bringing that info to the team. I think that a PM should be part of that. They're going to be cultural events. Like some of my teams get together and play games every Friday afternoon for an hour. Some of my teams have a lunch once a month that we pay for off of the company card. I expect a PM to be participating in those. And I think it's a strong sign that something is wrong if the PM does not participate in the team fun. One of the other meetings that happens, we do bit blameless incident reviews or postmortems. I expect a PM to be at many of those, maybe not all of them. I think that's one where I think, depending on the nature of the incident, it might be optional for the PM to show up. You have a very technical incident. It might not be a good use of their time to sit quietly and listen for 45 minutes while you all talk about how the problem with the database index is that it wasn't indexed properly in the database. And so the database was going to be slow because the index wasn't good.

[00:27:38] Allan Stewart: I see. I thought the problem was DNS. Well, the problem is always DNS.

[00:27:43] Dave Adsit: That's why the index is slow. Oh, okay.

[00:27:48] Allan Stewart: So we've talked a lot about our expectations and desires for how a product manager should show up. But I think it's only fair we talk about, well, what should a developer on the team be expected to do? How should they show up on the team for a product manager? And I think the first thing is that they should actually respect that role of product manager, that they're actually doing their job to define the important problems. We're working together to solve those, and we're going to focus on that, right? Right. That that the engineers are not retreating to do some other thing or circumventing the system by taking orders from somebody, you know, somebody else. You know that. "Oh, well, you know, so and so over in marketing said that we really need this. And so I'm just doing that, even though it wasn't something that we prioritized." Yes, there's going to be some technical things that we might work on. Ideally, those are in service to delivering the product, right? Making the product better and if at all possible, related to the thing that we're actually doing right now, right? The important thing that the product manager selected.

[00:29:02] Dave Adsit: on them. I think that the product manager should also be able to expect transparency from the developers. I think that as developers, we should feel an obligation to keep them in the loop on what's going on and what we're learning. Often, I think status needs to be a meeting. I think status should be visible at all times, though. We should keep our Kanban board up to date with with what we're working on. So the PM can always see what we're doing and how far along the process for like, if we've broken down a bigger project into a bunch of small pieces, they should be able to see how far along we are on those pieces. And I think that we should keep them in the loop on how long things are taking and how long we expect things to take. I am not a fan of estimates, but I am a fan of very loose timeframes. I tell my teams that they should be comfortable giving giving their PM an estimate in terms of hours, days, weeks, or months, and not a quantity of each of those, just one of those four words.

[00:30:11] Allan Stewart: I think that developers also need to be good at saying "no, but this is what we can do." It is very easy for developers to just get into that cantankerous mode where it's like, "no, no, no, we can't do this. No, we can't do that. It's It's impossible." None of these things can work because we often focus on all these constraints, right? Like a product manager doesn't have the same kinds of restraints or constraints that we do. And so they're free to dream. And that is a valuable thing that they bring to the team. But engineering can get so bogged down with these constraints. Like, "oh no, we can't possibly do this because the, you know, this won't work. This won't work." We need to, we need to get into that habit of saying, "no, but we could make it work if we did this first," or "we could do this instead," or "no, but what do you think about this alternative," so that we're not shutting them down and making them make it so that their job is impossible, right? Like their job is to challenge us to do things that are going to be hard that the other people haven't done before, you know, that nobody else has figured out ideally. Because otherwise, why are we doing it? There's some other product that's already out on the market. Like we want to be different. We want to differentiate ourselves. And so not shutting them down with "no, no, it can't be done, impossible" is a very important skill.

[00:31:35] Dave Adsit: That's one of the concepts that I took from Don Norman and Principles of Product Development Flow Lowe is he, he talks about finding the good idea inside the bad idea. And I think that "no, but" is a great way we can help our product managers discover the possible. And I think that we need to get good at it. I agree with you. We need to get good at that. Like when somebody comes to you with something and they're like, "can we do X, Y, and Z within the next three weeks? Because customer 12 needs it." Like, "no, but we could do this other thing. It's a subset of that. It will move the needle, you know, like whatever," right? There's a lot of things that we need to be saying, "but here's an alternative idea."

[00:32:18] Allan Stewart: Right. And it doesn't have to be as soon as they open their mouth. "Can we," and you're already saying no. Right.

[00:32:25] Dave Adsit: And it's a launching off point for a discussion and a mutual discovery of what could be built that would meet the needs. I think that a PM should expect a developer or team of developers to notify them of issues ASAP. If you go into standup and you say, "today, we're going to work on this card and it's, you know, we expect it to take the next day or two. And it's going to be solving this one particular problem, blah, blah, blah." And we go and start writing the code and an hour and a half after standup, we discover somebody took a terrible shortcut in this code it's extremely brittle. If we do anything to it, it's going to all break and it's going to cause this huge problem for some of our customers. We thought that it was written by sane people who didn't hate the future, and it turns out that we didn't do as good of a job at writing this code as we thought we were going to. I think a PM should be expected to be notified of that right away. If you say, "oh no, we told you it was days of work and it turns out it's going to be weeks, if not not months of work," don't wait till the next standup to talk to them about it. They may not want you to spend the whole rest of the day working on something that's going to be thrown away because it's not valuable anymore. If we can't get it done in a few days, it's not valuable enough to do weeks and weeks of work. We don't want to bet weeks of work that this is going to return value. So they should expect developers to give them bad news, updates of issues, ASAP.

[00:33:55] Allan Stewart: be? I think on the flip side of the coin, the PM should expect developers to share ideas and opportunities as they arise, right? Because there's not always problems. Sometimes it turns out that, hey, we could make this small change to code and it would have this impact. It might be a performance thing. It might be a feature, right? It's like, "oh, hey, did you know that because of this upgrade we did, or because of this technical improvement that happened elsewhere in the system, now we can do this? And it fits in, it's aligned with the kinds of work that we're doing." They don't know that they might have previously considered these ideas or not even thought about it at all. But once it's raised to them, they say, "oh, that is a great idea." And if it is a good opportunity, and especially if they're things that can easily be done, sometimes you can save a a lot of work. I know I've worked on teams where something, it turned out the engineers did not have an appreciation for how much work somebody else was doing. And then we made a small change. Like what for us was a very small change. It's like, "oh, when we create a new account, we're going to pre-populate it with half a dozen, you know, example pieces of data or something like that." And all of a sudden it made somebody else's life way easier, right? Finding those opportunities and sharing them because nobody asked for it because they assumed it would be hard. And in that case, it was not hard. In fact, it was very, very easy and they loved it.

[00:35:31] Dave Adsit: Yeah. Well, and things that you would never expect a PM to be aware of, like, "hey, we have a dependency on this library. They just released a new update. And in this new update, there's a visual component that can be used to build this kind of widget." And you say, "hey, we could use a widget like this in this thing." And they, the same thing. They would have never thought to ask you because they would have thought that it was months and months and months of work for you to build it. But it turns out you got it for free when you updated, when you did your monthly dependency management session and updated all your dependencies. And so, you know, giving the opportunity for capturing, like, significant value is fantastic.

[00:36:09] Allan Stewart: The product manager should also expect developers to deliver high quality work. If we want them to show up as a professional, we need to show up as professionals too. We need to be delivering high quality work that we're consistently keeping the code clean and refactored so that we can not get bogged down, but always maintain this flow of value delivery, right? If we say, "oh no, this is going to take a long time and we're going to disappear and you're not going to see us or hear from us for weeks," that doesn't work out. Right. Or if, or if we deliver something and we say, "Hey, this is done," but it's kind of slipshod work and it's really not done. It's not meeting the need. Well, that just makes their life harder. And so we need to be just as professional as we want to see out of them.

[00:37:02] Dave Adsit: Yeah, I agree with that. We've already talked about how the PM is the frontline for discussions with customers. And if we're releasing low quality code that has many defects and has bad user experience and whatever, they're going to hear about it. And we're going to make their job a lot harder. So they should expect us to deliver high quality work so that we can have good experiences interacting with customers, but also so that we can have a consistent flow of value over time and it doesn't degrade as the volume of features increases. And I think that one of the things that a PM should expect of developers is to engage with the product, care about the product you're building, understand the product you're building, understand the customers you're building. I think they should expect that of us, not necessarily at the same level of subject matter expertise. But I expect that engineers are going to want to be building the thing they're building and that that should be obvious and evident to the PMs who they are working with.

[00:38:08] Allan Stewart: Yeah. I mean, that's not, not every developer thinks or feels that way. And that's fine. Just like not every product manager wants to necessarily work the way that we've outlined just here. But I think that if we, you know, under our banner of crafting code, right, like we want to have really good code, that we're solving business problems, that this isn't, you know, some aesthetic thing that we're doing, but it's actually real. Demonstrable value, then we have to be doing that. And if we're not, then we don't really deserve an expectation of a product manager that's doing what we want either. That's right. So let's move on to another discipline, the UX designer. What does a UX designer do?

[00:38:57] Dave Adsit: So a UX designer is often a member of your team, often shared between multiple teams. This is someone who is responsible for holding the vision for how the user interacts with the product. This is someone who brings a design thinking into the software development process. You know, we've talked about, there've been many, many jokes about user interfaces designed by engineers being toxic and causing poisoning. Right? We all, we are like, "I drew four big boxes. One of them's a button. It's fine. Everything is perfect." Right. But when it comes to having elegant designs that meet the customer where they are and take them to where they're trying to go, a UX designer can be invaluable. They're going to do a lot of things very similar to a product manager. They're going to be doing a lot of customer research. They're going to be meeting with customers and showing them designs, hopefully alternative designs. "Here's design one, here's design two, here's design three. Which of these do you like the best? Which of these meet your needs?" There are a lot of practices and techniques for creating a design, generating a design on the fly with a customer as you are interviewing them about the problems that they face using your software product. I think having a UX designer designer on a team is a great sign that your company takes pride in and actually values the product that you are building, right? We want to build good products that people use and love. UX designers are an invaluable function in helping us get there.

[00:40:37] Allan Stewart: And I like how you kick that discussion off of what they do by talking about that user experience, right? That's what the UX stands for and not the drawing of pictures. Yeah. They might have design chops. Most of them do, right? Like they can draw things or at least create good interfaces. But it's not just about, hey, you're the person who in the old days used Photoshop to draw up something and then chop it up into pictures that we put on the web back in the bad old days, right? Like it's about that experience, right? It's more than just this is how many pixels gap there's going to be between all of the elements on the page or what colors we're going to use and how much border radius is going to be, like, yes, that has a place. And often they're the person who helps us with that. But I think it's more important to recognize that they're looking at the entire user experience. Like, how does the user interact with this? How are they going to feel about it? Is this going to actually meet their need and be effective? Not just does it look pretty?

[00:41:42] Dave Adsit: I think that UI design is a subset of UX design, much the way project management is a subset of product management. And your UX designer is probably going to be doing a lot of your UI design, but they're going to be doing so much more. And if you try to simplify their role to that, you're going to be missing an opportunity to collaborate once again with somebody who is raising the bar on your software. So what could we expect or what should we expect of our UX designers? I think one of the things that I expect is limited design inventory. We've talked about how design is one of the inventories that we keep track of in software. You know, we don't have physical inventory, but we can have many, many, many, many, many designs. And there are some problems with having too much design. It becomes, you'll never get around to implementing it all and it becomes waste. And long-term, one of the problems is that if we make a bad decision early and we built a hundred designs on top of it. Now we have to update 100 designs or throw them away. And so I expect a UX designer, much like a product manager, to be focused on what we're doing now with some forethought for what we're going to be doing next and soon. But not be so far out ahead of the team that they're not even on the same zip code anymore.

[00:43:13] Allan Stewart: Right. Yeah. Yeah, which is very easy to do because you can draw out mockups of things, especially if you're using a tool like I know a lot of designers like Figma. You can go very fast with Figma, much faster than the team can actually go and build it out. There's a lot of additional constraints that the engineering team has to deal with when they're actually going to make it work on the page and actually do the thing and save the data and so forth. And so if you get, I've, I've definitely worked in those environments where "here is the beautiful vision of what our website could be in the future." And I look at it as a, "wow, a long time to do to make what we have now look like that." We're talking about years of work and that can be demoralizing really for both, for the engineers who look at it and just say, "Oh shoot, like we just got handed our, you know, our marching orders for forever," but also for the designer themselves, that they're not going to be able to see their thing take shape because they projected too far out. And so they're not, their vision isn't getting achieved. The world keeps changing before we can ever arrive at their beautiful utopia.

[00:44:35] Dave Adsit: Well, and that goes back to one of the things that I expect from a UX designer, which is collaboration. Again, I want UX designers who are available to discuss designs as we are implementing them. You gave me a design. We talked about it during the project kickoff, the feature kickoff. Now we're working on it and we have questions about this and we have questions about how this interacts with that. And we have questions about what to do when this scenario that you didn't consider occurs in the code because it turns out it occurs multiple times every day. So I expect them to be available for collaboration and to answer questions and have discussions about the designs as we're actually building them.

[00:45:16] Allan Stewart: Agreed. And ideally, collaboration on the interfaces themselves, right? What kinds of interfaces will work? Do we have certain technical limitations? If the developers can get in early on the designs and say, hey, hey, we've already got a really good library for doing X. Can we do it that way? Instead of designing a new version of that and now we can't use the existing library. And there's various things like that that can happen and say, "oh, well, you know, I really love that you've made this special looking checkbox, but if we could just use the standard checkbox, we could get it done in an hour instead of two days."

[00:45:57] Dave Adsit: Well, and that's one of the things that I expect of a UX designer is some sort of design system. Modern tools are going to encourage that, right? If they're using Figma, Figma has the concept of here's the design components that you use and reuse over and over and over. I don't necessarily need them to be part of implementing a collection of React components that we're going to use over and over and over in the system. But if we have a collection of React components, I expect the UX designer to have had a hand in shaping them and also to leverage them in future designs until it's time to update them. So, yeah, a design system of sorts is how I think of it.

[00:46:38] Allan Stewart: It reminds me of one of the places we worked together. We had a speech-to-text component to the software that we were building. So users would record short voice recordings, which would get converted to text. And some of the initial UI designs weren't going to work because it takes time, especially then. We're constantly advancing. But at the time, there was some decent latency in getting a response back from, we took the recording and we saved it and we sent it for processing. And we got the results back from the processing. But our UX designer was really good at working with us and say, "okay, well, if we've got this limitation, how are we going to craft that user experience? Right. What are they going to see? What is it? How is it going to feel for them as they go through this process?" And by working together, we took something that's like, "oh, well, shoot, this isn't going to work. And it's no, not possible kind of, you know, idea" and turned it into something that worked great.

[00:47:39] Dave Adsit: Yeah. Yeah. It's that collaboration on the design and the technical limitations of implementing the design that is super valuable.

[00:47:47] Allan Stewart: I also like to see some sort of design system from a UX designer. Now that might be something that is, like, shared work across multiple teams. If you're in a, if you're in a larger company and I don't necessarily think that it has to be a huge, you know, Bible of a, of a document that, that covers everything, but at least some modicum of, "Hey, this is, this is what we do. This is how we achieve some consistency in our designs that makes it easier for us to build." And it makes it coherent and consistent for the customer who's using the product as well.

[00:48:27] Dave Adsit: Definitely. One of the things I expect from a a designer is that they, and this is related very much to a design system, is they avoid creating the kinds of changes that cascade across the entire application regularly. It's good to iterate, but if every release they're like, "by the way, we changed the shape of the button." So either we're going to have a new button or we're going to have to update the 500 existing buttons to the new one. And so every release, a significant portion of the development effort is spent on re-implementing existing functionality to bring it up to date with the modern designs. I want designs to be kind of stable over time. I do want to iterate and improve over time, but I want there to be some stability in the designs that are produced. For sure.

[00:49:18] Allan Stewart: Sure. One expectation I have for a UX designer is that they'll work on usability studies. There are various tools and various things that can be done to see how are people actually using our software, whether that's tracking that we're doing within the app, you know, collecting data, collecting screen recordings, heat maps of where people are looking and using. But also it can can happen beforehand too, right? Like do usability testing and say, "Hey, we're going to look for some of these details as people are using it to see where, where are they getting frustrated?" If we can find that out while we're still in like a wireframe or a Figma point and redesign it before we had to go and build it, then we can save a lot of time.

[00:50:05] Dave Adsit: Yeah. I think as an industry, we have moved to lower and lower cost ways of observing what customers are actually doing. We're using a a lot of tracking and tracing software in our websites and applications now. I haven't been part of participating in a usability lab for a long time. And I think that that mostly speaks to cost, not to value. But if we were to do a usability study, I would expect the user experience designer to lead that and to be the person who understands and interprets the results of that and turns them into improvements in our system. You know, I think that one of the things about a UX designer is that there's going to be a lot of overlap with the PM. And they're both going to be working to ensure that designs meet our customer needs and that they're communicating with developers early. And that we are investing in understanding whether this is likely to solve a customer problem before we go through the expense of building production level software. Yeah, absolutely. Absolutely. Also, like a PM, I expect a UX designer to be managing customer feedback. The feedback might be on different parts of the different aspects of the system, but I expect them to be good at managing and understanding customer feedback.

[00:51:25] Allan Stewart: So then developers, what can they expect from developers and how do we show up for working with a UX designer? I think the first thing is that developers should communicate clearly on design challenges. If they show a design of this is how we want it to interact and there's going to be a delay or a problem with that, let them know. Sometimes it's not that important, right? Like, "oh, for some reason we can't add that padding or that background color because of this other component that we're using on the page or something like that." Sometimes when you bring it up, the answer is, "oh, well, just don't worry about it. It's fine." And they go and change the design to something that's easier. Or other times it turns out it's like, "oh, well, this is more complicated. And so let's have the discussion." But communicating that early on lets them be aware. And then if there are alternatives or if there's some particular reason that it really needs to be a certain way, we can have that discussion early and it doesn't turn into frustration for either party down the road. Related, I think it also can be valuable to have some kind of a working agreement with your designer about how pixel perfect things need to be. There are some designers that I've worked with that care very much about, "it needs to be exactly this way." And other ones that I've worked with where they're like, "well, this was just kind of a suggestion of, you know, this is just communicating an idea," and they're not hung up on exactly, it had to be this many pixels or it had to be exactly the shade of blue or whatever. Ever. And so if you set that expectation early on, then you know how things are going to be. And you don't need to complain when they ask for changes because you understand, "Hey, these are the types of things that we're doing for this designer. They do care about the margins." And so let's not complain. Let's just learn what the system is and do it right. And so that we don't have to fight over it.

[00:53:29] Dave Adsit: Yeah, I definitely have had issues with those types of discussions. "Hey, I looked at this in Safari on the Mac and it doesn't look the same as IE on Windows," which tells you when I was having these conversations. But like, "well, why would you expect it to, first of all? But also, does that matter at all for our users and how they're interacting with the system?" And for some designers, it does. You know, we've had One of the organizations I worked on, we worked at, we had tweaky time with Bob. Bob would come and sit down with one of our front end developers and make sure that every single thing was pixel perfect before we were allowed to release the software. It's definitely more challenging and it depends on what you're building, whether or not that returns the value that you need. Yeah. So this is going to be an ongoing theme. It's an ongoing theme of every conversation I have about software development. Developers should be open to iteration on designs. As we see customers interact with our system, as we interact with our customers and get feedback from them, we need to be open to iterating on those designs. The user experience designer is doing the best they can with the knowledge they have. And as they gain new knowledge, they can potentially do better. And we need to work with them to realize that those possibilities.

[00:54:53] Allan Stewart: Yep. And developers should appreciate that specialty, right? Just like we talked about with product and we'll talk about with everybody else. "Hey, they've got a specialty that they're bringing to the table. Let's take advantage of it." I like to think that I can make okay-ish user interfaces, user experiences that don't make people become ill. But when compared with the simple little things that a good designer can do, that just makes it just a little bit more readable, just a little bit easier to understand, just a little bit nicer to use. Those are valuable. And let's make sure that we acknowledge it.

[00:55:30] Dave Adsit: And there's definitely something there that, you know, often developers, let's say developers early in their career are thinking in terms of the data that I'm capturing, the CRUD that I need to display on the screen, right? "I've got data. I want to show it to the users. The users knows what to do with it and they're going to do the right thing and then they're going to save it." So they create new data, read data, update data, delete data. Those are the basic functions of a software system. And a UX designer is going to take that to a new level of what is the goal that the user is trying to accomplish? What is their mindset when they get to this part of the the system and what can we do to enable them to accomplish that as quickly as possible? I mean, I'm thinking about the system that I work on right now. We have a settings page that has just so many settings. And the reality is that our typical customer needs to look at four of them. They need the ability to edit the dozens or hundreds of settings, but they only need four to get started and maybe ever. Maybe all of the defaults are good enough for everything else. And so if you're an engineer and you're like, "well, here's the hundred settings." Have you ever gone into your Gmail and looked at the settings tab for your Gmail? That's kind of what I'm talking about. That's what I'm talking about. And really, like, what are you trying to do? You're just trying to read email and every once in a while, create a filter. And so having a good UX designer can make a huge difference in whether the software is even viable. And so appreciating that specialty is critical. So one of the last things that I think that a UX designer should expect developers to do is provide visibility into how users are engaging with the production system. That means adding pixel trackers, adding reporting and analytics around server interactions and around customer flows through the app. Like a customer clicks this and then they go to this tab and then they make this edit and they click, you know, those types of things where understanding a customer journey through the app can allow for an even better user experience design. And it makes your user experience designer's job easier as well. Again, I think about one particular user experience that we have in our system right now. And we're missing something because every once in a while, one of our users will come in and they'll do like a command click, control click to open a whole bunch of tabs at once. And almost every time they get rate limited. And so providing that, hey, when users get to this page and they do this weird thing, they get rate limited is an opportunity for the UX designer to create a better flow that more closely meets the needs of the customers. Why are they doing that thing in that way? Why are they opening 15 tabs to do this thing? What can we do to help them? And so we need to provide visibility to that, to the UX designer so that they can create even better designs for our customers. So collaboration and cross-functional teams are something that are super important to Allan and I. And we ended up talking quite a long time about the various roles that we work with in different parts of our team. And because of that, we've chosen to divide this into two episodes. So we'll come back in the next episode with additional discussion of interacting with other specialized roles in your software developer teams.