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 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 there might be a shared resource across the team. 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 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 they expect from me? And what should we do? 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 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. Right.

[00:02:29] Allan Stewart: 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. Right. So coming from a perspective of I am, 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. Is done ahead of time. And then everything else is just leftover for engineering. It's just like 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:45] 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. But 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 is 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 do? And how 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. Yeah.

[00:05:39] Allan Stewart: 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? Right. And one of the things that we have learned, one of the big issues with product development and external like 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, what can we build for this idea? What do we, what do we need to do to either validate or execute on this idea? And so I want small batches and I, and one of the things that I've learned is that if 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 in that 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 possible. Yeah. 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, before we get mockups, right? We can start searching for data or we can do some painted door tests. We can do some AB testing along the way. Those kinds of things that, that allow us to explore those options and see, Hey, is this even, is this even feasible? Is this going to work? And, and, and it just, it reminds me like if. 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, 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 I mean, 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 target audience. 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. Understanding the customer, looking at all the product requests and analyzing 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. I think that we've seen a lot of, 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. That's their priority work. Whereas my priority work as a developer is to write the code. Right? And so 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 doing. And we each take a specialty. 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 be. I can't do that specialty at all. But I want to trust that, hey, they've got their part down. 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 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. But in many cases, I think that the product manager should be somewhat of an expert in the area. And 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 tradeoffs. There are inevitably going to be tradeoffs 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 tradeoffs 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. So they own what it is we are going to build. They own that vision. And we share it together. We are building it together. But that is their core. Is to say, hey, what things should we build. To your point, there is always tons of good ideas. And there is never enough time to build everything. And so they help us focus on what we are building. And what the most valuable things should be. But then engineering owns how we build it. And that is an equally important aspect of building a product. Is actually building the product. And so, yeah, I expect that product management should not be bossing people around. And 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 have seen a lot of people try this. Where they have kind of the product manager as general manager or GM of this function. Type of a model. And they have the engineers and everybody else report to the product manager. And every time I have seen people try this, it has 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 skill set than you do. While also making it a challenge. And 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. Yeah. And also manage eight engineers who have a specialty you don't. And whose skills you are going to be have a hard time evaluating. And whose career development you are responsible for but don't understand. I feel like you are 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 is conflict, that is a problem. I expect there not to be conflict. I expect there to be collaboration instead.

[00:17:26] Allan Stewart: 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. You know, it is like we are 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 have seen plenty of cases where that gets out of balance. And if the engineers have too much say, then there is a lot of overengineering kinds of things that happen. And gold plating the product and building features that aren't necessary. If product has too much sway, 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 is my thinking with that healthy tension. 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 everybody. They are going to have the same kind of problem. They don't have the skill of product management in order to help them have their career development. And so there needs to be a different way of thinking about that. Where it is 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 nonfunctional 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 are 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 with all of the product people that I have worked with. That I have really, really liked working with them. What they had in common was this. Is that they had an appreciation for there are some hard technical problems. And we are going to need to spend some of our capacity on that. And that is just part and parcel with how we work. And we are going to do it continually. Right? So we are 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 will get you some time to do some technical things.

[00:20:20] Dave Adsit: Yeah.

[00:20:20] Allan Stewart: Which never comes. 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 are the project product management skills. And 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. We have talked, I think we have talked before about Amazon one pagers or PRDs or things like that. Right? 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 is the document. Let's go through it. Let's understand it together. Let's understand what is in scope and out of scope. Let's understand what things need to be done to accomplish this. How we are 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. 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 have made a bunch of changes to the system. What is the story we are 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? And I expect them to be responsible for that release management.

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

[00:22:24] Dave Adsit: And one more that immediately follows on from that is manage feedback from customers when we do a release. Go find out what they think. Again, do those surveys. Do those interviews. Find ways to measure engagement with the new things that we have done and whether they are creating value. 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 have measured the behavior after. The behavior after is more in line with what we want. we switch to another goal that is, you know, in alignment with our overall business mission or whatever.

[00:23:33] Allan Stewart: And then I think the final thing that I would hope from a product manager is kind of a recognition that coding work takes time. Like there's a lot of little details that go into it. There's, 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 days dreaming of what we're going to do in six months or, you know, 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, I want the PM to be readily available to answer questions about the work that's currently ongoing. 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 on next.

[00:25:19] Allan Stewart: Yeah. If that problem happens, I can assure you that there is some technical work that we can do. It 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. Yeah.

[00:25:37] Dave Adsit: So any team is going to have a collection of practices and meetings and rituals and things and different members of the team is going to, are going to participate in different, different parts of that overall process. I think there are several meetings that I expect. mandatory participant and possibly a couple as a, 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, 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. Um, 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 I, we pay for off of the. You know, the company card. Um, 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. Uh, 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: Honestly, I thought the problem was DNS. Well, the problem is always DNS.

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

[00:27:45] Allan Stewart: Okay. So we've talked a lot about our expectations and desires. We've talked 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, that they're actually doing their job to, to define the important problems. We're working together to solve those. And we're, we're going to focus on that. The, the, 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, the 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. Yeah. Yeah. product better and, and if at all possible related to the thing that we're actually doing right now, right? The, the important thing that the product manager selected.

[00:29:03] Dave Adsit: Yeah. I think that the product manager should also be able to expect transparency from the developers. I think that as developers, it is, we should feel an obligation to keep them in the loop on what's going on and what we're learning. Often we will, I want us to keep, I like to, I don't, I don't 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 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 their PM an estimate in terms of hours, days, weeks, or months, and not a quantity of each of those, just one of those

[00:30:09] Allan Stewart: four words. 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 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. It's like, oh no, we can't possibly do this because this won't work. This won't work. We need to get into that. So it's a good way to say, 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? And 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

[00:31:33] Dave Adsit: is a very important skill. That's one of the concepts that I took from Don Norman in principles of product development flow 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,

[00:32:22] Dave Adsit: can we, and you're already saying no. Right. 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 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 be, they should expect developers to give them

[00:33:51] Allan Stewart: bad news, updates of issues, ASAP. I think on the flip side of the coin, the PM should expect developers to share ideas and opportunities as they arise, right? Because it'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, we're going to have to make this change to code? 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, you know, it's aligned with the kinds of work that we're doing. They don't know that they might have, they might've 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 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, sharing them because that, you know, 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, 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 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. Yeah. The product manager should

[00:36:11] Allan Stewart: 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 to what we need to be. foul foul foul foul foul foul foul foul foul ! foul 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

[00:37:02] Dave Adsit: see out of them. 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 manager 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, not every developer thinks or feels that way and that's fine. Just like not every product manager. 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. Yeah. 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 things that are 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, 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

[00:40:34] Allan Stewart: invaluable function in helping us get there. 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'd 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 between all of the elements. 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 UI, 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. 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've built a designs on top of it. Now we have to update a hundred designs or throw them away. And so I, 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. And which, which is very easy to do because you can draw a mock-up, 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, 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, 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, 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

[00:44:32] Dave Adsit: ever arrive at their beautiful utopia. 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 as we are actually building them. 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. Agreed. And, and ideally,

[00:45:23] Allan Stewart: What kinds of interfaces will work? Do we have certain tech technical limitations? If we can, if the, if the developers can get in early on the designs and say, 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, you know, there's, there's various things like that, that can happen and say, Oh, well, you know, I really love the, the, the, the, the, the, the, the,

[00:46:13] Dave Adsit: 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

[00:46:37] Allan Stewart: of it. 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 the UI. 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? What are they going to see? 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 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 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 designer is that they, and this is related very much to a design system is they avoid creating the kinds of changes that cascade. Yeah. 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, every release, a significant portion of the development effort is spent on re implementing existing functionality to, and 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: One expectation I have for a UX designer is that they'll work on a 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. Yeah. You know, collecting data, collecting screen recordings, heat maps of where people are looking and using. But also it 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 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 expensive. Yeah, 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:26] 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, 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. Let's 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. 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. Discuss. Discussions. 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 this 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. Uh, 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 he said, we're going to have to have a lot of conversations with our developers and make sure that every single thing was pixel perfect before we were allowed to release the software. Uh, 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 it. 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 Yeah. 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 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. Yeah. 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. 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 designers job easier as well. Again, I think about one particular user experience that we have in our system right now. And we are, we're missing something because every once in a while, one of our users will come in and they'll do like a. 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.