Getting everyone in the product development process on the same page requires radical transparency, empathy, and collaboration. In the Same Page event series, we’re getting practitioners and leaders together for open conversations on exploring what it takes to build those cross-functional team relationships and how to find alignment. 

In this show, Principal Engineer at Zipper Duretti Hirpa joins Abstract Engineering Manager Nathasha Loos to discuss collaboration in the design process from an engineering perspective. From developer handoff to scoping and building features together, they talk about how we can work better together as a team.

Transcript

Nathasha Loos: Hi. Hello everybody. Welcome to the Samepage event. My name is Nathasha Loos:. I'm an engineering manager at Abstract, and I'm very excited to be talking here with Duretti from Zipper.

Duretti Hirpa: Hello.

Nathasha Loos: Hi, Duretti. How are you?

Duretti Hirpa: Good, how are you?

Nathasha Loos: I'm good. Glad to be here. Let's just give everyone a few more minutes.

Duretti Hirpa: Sure. Yeah. I think there are some people from the UK. Hello.

Nathasha Loos: Hi. Cool. Before we get started, I'm just going to do a little intro. The goal of this event is to explore design-first approach for product development and today we're going to be talking about shipping. Cool. Cool. We're going to have some folks from San Francisco, North Carolina. Hi, everybody. Welcome. Boston. Hi. Hi. Canada. Wow. This is awesome.

Duretti Hirpa: Yeah. People from all over.

Nathasha Loos: Cool.

Duretti Hirpa: Got people from the UK. That's great.

Nathasha Loos: Cool, cool.

Duretti Hirpa: Awesome. Cool. Wow. This is cool. People from all over.

Nathasha Loos: Mm-hmm (affirmative). Florida. Hello everybody. Before we start, should we start a poll on... I would love to know where everybody's roles are, the product design managers, engineers, or let's see. See the results here. Cool, cool. While this poll is loading Duretti I have some questions if you want to just introduce yourself? Give me a little bit about your background and...

Duretti Hirpa: Yeah, let's see. I am a principal engineer at a small software startup called the Zipper. We are a pre-seed so still figuring it out. We're working on product development life cycle tool as we kind of try to help PMs with getting rid of a little bit of their daily drudgery. There's a lot of administration that goes into being a PM. So we're trying to figure out ways to help them with that. Before that, I was at Slack for four years and did a little bit of everything. I was an individual contributor there as well. Before that I worked at Fastly, which is a CDN also as an IC doing front-end work, and then before that, I worked at creative agencies and marketing agencies and I've been in tech for almost 15 years. It's a while. Yeah. I still like it so that's good.

Nathasha Loos: That's awesome. That's awesome. Cool. Let's see, you have a lot of product designers here. That's awesome.

Duretti Hirpa: Wow. product designers are in such high demand right now, to be honest. They're really cool.

Nathasha Loos: Cool. A little bit of background on myself. I've been a manager for a little less than a year. I was in IC. I was a front engineer for my goodness I think around 10 or 11 years. I had the opportunity to work with lots of talented designers and product managers and software engineers. So, shipping is something that we're really passionate about because that's an IC when you see something ship that's one of those really, aha moments like, hey, this thing is pride, alive, right?

Duretti Hirpa: Yeah. Yeah. This thing that we're working on is out, it's not critical anymore and it feels and I feel like again we kind of talked about dopamine loops a little bit before our earlier conversation, but the thing that sucks about being an IC, it's like, oh, you figure something out, you get a little bit of dopamine and I feel like you get such an adrenaline rush when things are actually out for people to see and use and interact with. That's a big part of why I really like still being an IC.

Nathasha Loos: Yeah, totally. So our first topic, this is something that I'm really excited to talk to you about is dev handoff and know there's a lot of... I feel like every company you work for the dev handoff process is very different. Sometimes it goes really good. Sometimes it goes really bad. Can you share some experience where we'll start with the bad? Can you just share some experience where a Dev handoff didn't go so well and what were the...

Duretti Hirpa: Yeah, I worked on a project where it was a... What was a hack day project? Someone was like, oh, it'd be really cool if we... It was when I was working at Slack, we wanted to be able to snooze notifications for longer than a day because sometimes you go on vacation or you're out on leave or something, it'd be really cool to not get notifications without having to go into the app every day and be like snooze again for 24 hours. So someone prototyped it very quickly on iOS during a hackathon kind of a hack week. Okay, good and from the hack week, one of the things Slack did when I was there was we'll take some of the ideas that really resonated with people and we'll actually put it on the product roadmap and we'll actually build it out.

Duretti Hirpa: If you're annoyed by it, probably other people are annoyed by it. So it came to my team. I was working on notifications as a background engineer at the time and we're like, "Oh cool. This will take no time." So we were like, okay, great. We spun up a little squad to work on it. We needed the mobile people. We needed a front-end engineer to do some of the preference point stuff and then me as a background engineer. My work was very easy. There was all I had to do was there was a timestamp in the backend that was the limit. So oh, as long as the timestamp is under such... Before it was hardcoded to whatever 24 hours was in seconds, 886,500 so I was just like times 365. Done.

Duretti Hirpa: That was my component because we were like, okay, you can snooze our notifications up to a year because maybe you're on parental leave. So then after that the PM that was running the team, we didn't really have because it was such a small project. We were like, oh we got this like, no problem. Then they're like, oh, are we going to... It got to the point where like, oh, are we going to ship it? We hadn't really had a meeting. Our PM had rolled off because he had actually moved to a different... He had transferred teams. We had a new PM and we were like, oh, we have to send this to QA. It wasn't done. I was like all over the place. We weren't even having regular standards because the feature we were like, oh, it's a small feature or whatever.

Duretti Hirpa: So that one was really rocky. We ended up having quite a retro after everything went out and feeling like, oh, we were all waiting for somebody else to step up and be a leader. We need to have stand up. We need to get this out the door and I'm used to at least at the time I was like, oh, that's the role of the PM. The PM is going to be the person running stand-up and being like, where's this thing? And because that didn't happen because this was a pretty small future for the PMOs coming in and the PMOs going out. They didn't have a good sync about it. It's out. You could snooze the pages in Slack now for up to a year. It's in the product. It was finished.

Duretti Hirpa: It definitely was really rocky because it was one of those things where it's like, oh, well, no one took that interest or personal responsibility and making sure. There wasn't even a mock really because it was like, yeah, we're going to use the existing interface. We'll just make this... Okay. We have to send it over to QA to test and all this stuff and it was just like... So that was when it was rocky, it was like the QA handoff. They were like, where's anything? Where is this spec? Where's like we don't have it.

Nathasha Loos: Oh my God.

Duretti Hirpa: So yeah. I think kind of the belief of, oh, it's just a small feature meant that we didn't run it as tight as we normally would have.

Nathasha Loos: Yeah. Was there any designing involved? Was there any virtual changes?

Duretti Hirpa: Eventually was a designer involved because as we needed to update a date picker for when did you want to snooze until, because before it was just sort of snooze for 24 hours and then we needed designs for, oh no, actually snooze on whatever date you want to pick. So we did need design help for, what should this look like? At the time the Slack app was being rewritten or reported to React. So the feeling was like, oh, look, if we're already doing date picker stuff. Let's just classic update the date pick revolver in here. So that happened and that was also part of it, having my designer come in and be like, "Hey, does this look the way you want? Because if so, we need to update our design system." So it kind of became a little bit of increased scope, but the feeling was like, we're going to have to do this any way we own this component. Why not? Right. But yeah, there was a designer, but it was again, it was seen as a very small project. So I think everyone took their eye off the ball. Myself included. Yeah.

Nathasha Loos: Yeah. Well, I think everyone have that kind of stories. I really liked the idea of having hackathons and that's where a lot of those creative ideas start but then the execution if you try to skip steps and try to ship it really fast, like a lot of bad consequences going to happen. Yeah. Yeah. We do have a question here it said, have you ever been on a gig where you didn't have a PM, scrum master, or lead architect?

Duretti Hirpa: Well, I mean, I work at a really small place right now, so yes. I work in a five-person company and yes, there's not really a PM or lead architect. We're all kind of pitching in and doing a little bit at a time. When I worked at Fastly, we didn't break into feature teams. So we didn't work with a PM or a lead architect. When I was there as a front-end engineer and the front-end team owned both fastly.com and then the dashboard app. So we would do a lot of stuff for the marketing team because marketing teams have to need, oh, we're doing some new feature or rerelease a press release. Here's a blog post, whatever. So we would as a part of my regular work would be like, okay, what does marketing need this week?

Duretti Hirpa: We didn't have... Our EM was in meetings all day and wasn't really there to help us. There's two front ends on the team and then we had an EM, but he was just in meetings but not by any fault of his own. I think when you're an EM, you get pulled into a lot of different kinds of cross-functional conversations. So we did our best to run that on our own and so we had a weekly meeting with marketing being like, okay, what do you need this week and we'll try to flood it in alongside of the feature work and app maintenance we were doing. That wasn't like, okay. It wasn't my favorite way to work. It's always nice when there's someone whose role that is and when I was working at Fastly they didn't add a product management function until I was about to leave. They didn't add a product function. By that time, engineering was feral because we were just like we're doing what we want. Products coming in here.

Duretti Hirpa: Someone once told me, if you don't want to work on it, you should just say, ask product it will never come back to you because it was such a new function. So at the time, but I'm sure that was five years ago. So I'm sure it's different now. But at the time there was an EM that wasn't a PM, but yeah, I prefer to work in more structured environments if possible.

Nathasha Loos: Yeah. And I think... Yeah, I worked at, yeah, it was very small startup and then, once you're used to working in a place where there is some structure and process and when you go back to it, you feel, oh, I wish there was a PM to, take care of this. I think we have another question. You found a process structure to ensure you can limit scope creep or mopping up or do you think it's just part of the process?

Duretti Hirpa: The only thing I have found that has worked with any kind of regularity is the team constantly asking, is this in scope or being like, we'll do it in a fast follow, which is sort of like, we'll do a one, one and any other things we think are super important let's just capture it. But it's really hard. I've been fully guilty of being like, oh, I can sneak this in really quick, underestimating how much time something can take or hitting... If you hit some piece of technical dev where you're like, oh, I'll sneak something in, and then you're like, actually no, I've caused an outage or whatever. So it's tough. It's really tough to limit scope creep. My theory on why this happens is I think fundamentally engineers are optimistic people.

Duretti Hirpa: Yes, I can do that. I think a lot of people who are really good at saying no, but I do think fundamentally where we're like, oh yeah, sure. Why not? If we can fit it in, let's try to fit it in and people are trying to be accommodating and we're working in these environments. It's tough to be the bad guy and be like, no, we're not doing this. I've definitely worked with PMs who are much better at being like, it's not in scope. We're not doing it. We'll do it later or we need a question, we need a good reason to expand the scope. But especially if there's a date attached, that's really a good way to be like, oh, you can have this, but the date will move. But it's unless everyone is really aligned on what it is we're making and that's constantly being talked about. I haven't seen another way to prevent scope creep, unfortunately.

Nathasha Loos: I think like that in my experience, I want to say that if you have... especially if you have a PM and if you're the engineer, I think engineers tend to be more optimistic like you said. But it's I feel like once you start working on it, and if somebody comes with a PM or someone else's contents say, "Hey, we want to change this to something else." Doesn't matter what your role is it should have a say in and say, we want to change this. There's going to be either it's probably going to change the deadline or if you want to keep the deadline, there's always this thing where what is it? We have three things that you can only pick two. The quality, the time, and then what's the other one?

Duretti Hirpa: Is it good, fast, cheap is the one I've heard?

Nathasha Loos: Yeah. Yeah. Yeah, yeah. So, if this scope changes, yeah. I can fix this, but it's probably going to take longer or I could fix it. I could hack this. Right. But it's probably going to be a very bad quality and then it ads detect that. Yeah, exactly.

Duretti Hirpa: It looks like someone in the chat who said it's price, quality, delivery. Yeah. Yeah. Oh, for the what you can pick two of. Sorry.

Nathasha Loos: Oh, okay.

Duretti Hirpa: Yeah. Yeah. Yeah. It's tough. Yeah. So there's a trade-off. I recently did some work on my house and they were like, if you want to change anything, there's a whole change order process and it would cost you money. I don't know how you would do this in software, but we should be because I was like, oh, I'm just not going to make any changes then. Let's decide upfront and then we'll just stick to the plan. Sometimes, obviously, and then it was my bathroom and they found... I thought we found this thing in the bathroom when we were opening up the walls or whatever. I'm like, oh, classic. I'm familiar with that. So, kind of when you open up the innards of a tech product you find something you weren't expecting. So I was like, yeah, I'll fix that. But they were like that won't be a change order because we weren't expecting to find this when we opened it but maybe we need a concept of change order.

Nathasha Loos: Yeah. I want to say my experience with a lot of the... Not a lot, but I want to say it's a feature that's very technically complex sometimes I've seen where you get the mock, you get the final mock and then the engineer starts working on it and they seen some technical issue that like, oh, you know what? You can't really, we could, but this is going to take longer, blah, blah blah. Because as a designer, they may not know what the technically possible and whatnot, and then one of the things that really worked in an abstract that we're trying right now, it's having the design reviews, like adding engineers to reviewers as reviewers so they get to... Just one engineer. Usually let's say we have a project and it's a feature and we have a designer and then we'll set some kind of tech lead like a project lead would actually review their design.

Nathasha Loos: Then before it gets to actual dev handoff they'll get a chance to review it and then they can feel like they basically work together. So product design and the tech lead work together in an early on stage and then, by the time it's actually ready a lot of those edge cases I want to say through.

Duretti Hirpa: Have been thought through a bit.

Nathasha Loos: Thought through and it actually really helped us to especially with the timelines. Timelines is a very complex thing. I don't know if there's a hundred percent solution for everything, but at least this really helped us with the scope creep a lot because, by the time everything's ready in Abstract, we use our notebooks, we review everything. Once by the time we approved the design and there's lot of if you change it again, then that will consider a scope creep and we could say, well, we approved it and this is what it is. If you're going to change it, this is look probably going to have to change the timeline or something. So it's actually really worked well for us because that's you're signing the contract. Right?

Duretti Hirpa: Mm-hmm (affirmative). Yeah. And then they really help. Yeah. I feel like I still want there to be more maybe money. You know what mean? Maybe they'll feel like you got skin in the game because it's really easy to ask for changes before all the deadlines kick in-

Nathasha Loos: Money. It's going to cost you.

Duretti Hirpa: It's going to cost you. If you want this it's going to cost you. I don't know how that would work at all at work, but yeah, I think that's a really good way of just sort of just to echo what you said in terms of we all decided this is approved, this is the line.

Nathasha Loos: We had some questions. Let's start from the top. The triangle metaphor, but what happens when leaders are famous for scope creep just adding to the project-

Duretti Hirpa: Yo. That's a great question.

Nathasha Loos: That's a really good question.

Duretti Hirpa: A great question. I think it depends a little bit on human factors. Is it a CEO? Is it a very classic swoop and poop where they come in and they're like do it this way and I'm a CEO and you're kind of like your hands are tied there? Also, is there a power differential? Is this leader a director or VP? Can you push back or not? Otherwise, I found that there is some power in everybody on the team being like, we're not doing that. You cannot make me actually do that with my hands. It's more but it's really tough because okay.

Duretti Hirpa: Yes, there is a trade-off between time and quality, and is the expectation to do it at the same you have more to do but you have to do it in the same amount of time and still do it well. That's just not going to happen. So I just... It's weird to not accept that because that's just reality. So I don't know and maybe that... What's that thing that Steve Jobs had? Like a reality distortion field where he just was sort of like, well, the way I think about it is what will happen. That's amazing. I would love to live in that world, but it's really tough because if there's a power differential I found that there's not much that I can do, but if it's someone that's an IC where there's more people on this squad that are like, no, we can't actually do this, I found that to be successful but that's really tough.

Nathasha Loos: Yeah and I think that's a really good question. I think that's a lot of times in SNIC may not really have the voice and to say no. I think that's a really good response, like a responsibility of the EM or the PM, who are the leaders to say, if you want this change, just talk about communicate the trade-off. Yeah. Yeah. If you want it, we can add this feature, but this is the timeline it's going to take longer and then I've heard there's some places where their leaders or the managers, they're not really talking, talking behalf of them. So it ends up people just working late hours because... It happened to me before in previous jobs too, like, hey, we have to get this done and things keep adding. But really my boss or anybody they're not taking our side and not listening to us and that's where if it happens definitely as a leader, you should be able to talk behalf of your team.

Duretti Hirpa: Mm-hmm (affirmative). Yeah. Because that just adds to trust degradation between the team and the leader. Especially if you're in crunch time trying to get something out the door. I've definitely worked long hours trying to get something out the door, but that's not how I prefer to work day in and day out.

Nathasha Loos: Yeah. Exactly.

Duretti Hirpa: I think it's because there's too much time on crunch leads to burnout. I don't know that there's a... if you look at it holistically, it doesn't seem like a great solution, but I mean, it happens. We absolutely... yeah. I mean, that's one way to look to expand if someone... It just leads to late hours, I think you're right.

Nathasha Loos: Sometimes even if you put more people in the way it doesn't really help because not... There are certain things that you can't really do with multiple people. So sometimes, okay, I'll throw more engineers so they can do it. I'm just like, no, but sometimes it doesn't work.

Duretti Hirpa: Yeah. Yeah. Because you often will have to get somebody up to speed. If you're adding someone in new in the last minute to say, okay, here let me do a tour of what we were working on and here's a ticket for you, but you're not familiar with what we've been doing. It may take more time before that person's up to speed. So yeah, it's a really tough situation to be in. A lot of compassion for that.

Nathasha Loos: Cool. Should we take one more question? We'll start with the next one for Carlos. What would your starting point be if you arrived in a company with no real design dev process, but a huge web presence in a lot of tech debt? It's a good question.

Duretti Hirpa: Yeah. I guess my starting point would be to make friends with people on the team. I've definitely worked at places where I've been kind of there for a long time and people immediately join and have a lot of energy to make things better. That's a hundred percent of the energy that we always need when a new person joins. But I have found that there's defensiveness, that can happen when someone comes in and is like, we're going to change everything. I mean, my zero-step would just be like, let me establish some relationships with key people, both on my team and around, and get a sense of why this happened. Because sometimes it's just growing pains and it's not anyone person's fault and sometimes there's super extenuating circumstances and you can't get anything done.

Duretti Hirpa: I worked at a place that had just... I'll admit the name to protect the innocent, but I worked in a place that I was like, oh, I'm ready to like change things. I would come in and want to fix these things. I joined to be the tech lead of a product that had been underloved and I was like, okay. They wanted to pay down all the tech debt and then hopefully increase the price of the product to kind of increase the business. So I was like, okay, great. So I joined and the first day, I was like, okay, there's not a read me on our repository and this has been around for five years, what's going on here? And I was like, huh, okay. This is a signal and later a coworker of mine was like, yeah, I wanted to warn you that all of your good energy was not going to go anywhere because there was a reason that all that stuff had happened.

Duretti Hirpa: There wasn't a ton of inertia in engineering team and there wasn't... Because the company was doing really well financially there wasn't a lot of incentive. There was no urgency to get things out the door. So it's really tough to walk into places and be like, I have a lot of energy to change things without maybe understanding how they got there. So my first step would be let me make some friends, let me get the tea. Let me find out what's happening here because if it's happening on purpose and don't touch it. But if it's not happening on purpose, then I think you can influence what's happening and kind of help people, hey, well maybe it'd be better if we had a real process here to pave the cow path a little bit, but it could be a hot stove that you shouldn't touch.

Nathasha Loos: That's very good point. I think the process changes when you're coming in as a new employee. It's very you don't want to be that person come in and changing everything and everyone's unhappy, right? Yeah. I think for me, it's my experience. I feel like at least as an IC, I was really lucky to at least have the design team and the engineering team has always been very close because usually they work together. There was some process improvements, but like you said, the best thing that do is just talk to them. Talk to them individually and talk to them about pain point and what is it that you want trying to do? What we're trying to do and then slowly you can change things, but if you try to change everything at once and you're going to be the back person.

Duretti Hirpa: Yeah. Even though you're trying to do a net positive, like a net good. And maybe it's something depending on the size of the company, it becomes maybe a committee or not committees are tough because they're long run. You want something that's our purview is just to get ourselves a design process, like a depth design process and maybe include more than just one person because it sounds like a process that would be throughout engineering, at least stemming from this question.

Nathasha Loos: Yeah. Sometimes you don't even need to say the word process that could scare people. You can just say like, hey, we're going to work together and sometimes that really works. It just definitely depends on the person and how open the other person is. I think that's the other thing too. Especially if you're new, you have to talk to these people with an open mind. You can't be judging and I think that would really help me, especially my personal experience is that you just need to figure out where these people are coming from and what their problems are.

Duretti Hirpa: Mm-hmm (affirmative). Yeah. Can you do it on a smaller scale? If you're on a team, we'd be like, okay, we're going to do it this way and then if they see how effective that is, like, if your team is working better, people will want to copy that. If it's successful and you managed to do it on a smaller scale, then you can kind of start to evangelize that process. Like, oh, here's what we did and it worked really well and we're shipping much faster than we were before people love that.

Nathasha Loos: Mm-hmm (affirmative). Yeah, exactly. Let's see. I think we could open a poll here. We'll talk about the dev still in the dev handoff topic. We'd love to know. Oops, hold on. I just clicked. Yeah. There you go. To know when you bring in engineering on the hand-off process. PDE and for those I'm not familiar with what it means like PDE is that a product design and engineering? Some may not even have a PDE team per se, but it's just when you will include an engineer, it could be a tech lead or it could be a product lead or we'll see. Let's see the results here. When we are ready to build another moment before.

Duretti Hirpa: Vibe. Vibe.

Nathasha Loos: I feel like that's where a lot of my experience, I feel like as an IC I remember, I'll get the mock at the end and yeah, just go build this. A lot of... Oh, this is perfect. Look at this it's a team meet from the start. That's really good.

Duretti Hirpa: Yeah. It is. It is what you want to see is some engineering representation in those rooms.

Nathasha Loos: Yeah. Cool. Let me just... I think we can move on to the next question. In terms of involving engineering you talk a little bit about what involving, or having a P that either lead or somebody represent in engineering representation, how early do you think sometimes it could be too early and then wasting engineering time? Can you talk a little bit about the experience where it worked really well? And when was it too early, too late, sometimes not just-

Duretti Hirpa: Yeah. It's very, what's that children's story? The three bears, like just right. Yeah, yeah. Yeah. So I think I've seen projects go off the rails when engineering gets involved too late, because design has done a lot of efforts to get something looking a particular way and maybe there's some technical limitation that means, oh, we actually can't build any of that and that's sad because someone's spent a lot of time trying to get from point a to point B. I've seen it work best when there's some engineering representation in those early conversations, but not the whole team because that spares the team from losing cycles to new feature work. Usually I find that an EM is sufficient, but a lot of times a tech lead will be in those rooms. Being like, yes, we can do this, no we can't do this.

Duretti Hirpa: So that kind of helps guide the design. So by the time the designs are done and the full team is in some of those questions that have been asked, but it's tough because it's like, okay, when do you write the tech spec? You write the tech specs after you've gotten the designs or before you've gotten the designs to inform what you're doing. So it could be challenging to get that right but I find that the earlier involvement is better. I think it depends on it is a little bit of it's not the most fun to be in these meetings having been in them, but it is necessary to have some engineering representation, but in a place where the squad, the cross-functional teams are closely aligned. A lot of times the kickoff is a formality because you'll be asking, hey, I came up with this corner case with a design, can you come up with something new?

Duretti Hirpa: It's not like once the kickoff is done and the design is sent over that's over. A lot of times it's like, I found this weird thing I need this button state, this error state, whatever we didn't kind of anticipate, can you come with a design for that? Then a lot of times I've worked at places where design will be pulled into some of the QA testing. Hey, someone's staging will you click through and make sure this is what you wanted it to look like. Because a lot of times designers will have opinions about that. Which is good they should have opinions that they've made designs. But yeah, the earlier the better, I think.

Nathasha Loos: Yeah. I liked the idea that we do sometimes in our PRs we'll tag designers and they can actually look within the PR, but it will deploy to a staging environment and they can design or we can actually look at it and see how it looks. It's easier for UI stuff, but for backend work, it's a little you can't really test anything until the UI is right.

Duretti Hirpa: Yeah. That's true.

Nathasha Loos: Cool. Let's see. I think we'll start this one question here. How important is the final review, final QA to you? It's about using the final product in UAT as close to prod as possible and checking that feeling full experience of design actually has the desired effect.

Duretti Hirpa: Yeah. I mean, to me, it's super important because you don't get a second chance to make a first impression. You can also obviously spend a ton of time in UAT and QA and everything and it's very easy to noodle on that last little chunk of work. But I think it's super important also because as an engineer working on the future, I kind of become... I lose awareness in a certain way of how it feels because I've been doing that flow so many times in a row to as I build it and so fresh eyes on it, it's always super helpful.

Duretti Hirpa: I've worked at places where we've had full QA teams or we've had product managers go through flows or we've had customer support go through flows to get, hey, is this solving the right problem? How does this feel? But also one of the last places I worked at was Slack, which was super intense about product quality. So if you didn't hit user acceptance testing or the QA and you didn't finish everything, then it wouldn't go out. So wanting that polish and I think we are seeing a lot of people are now coming to expect that polish as well. As these new features come, new software comes out users don't have a lot of tolerance for a non-polish experience too. So I think it's super important, but I also am a quality nerd. I just really... I like using things that feel nice and I think that's a competitive advantage too, for your business. Something is easy to use. It's hard to do, but I think it's really important.

Nathasha Loos: Yeah. I think another thing is we try to... At one of the things that reviewing with the engineer, sometimes it helps with trying to be able to reuse components. Sometimes they'll be really helpful. Sometimes they need a new designer and they weren't aware of, oh, this is something very similar, like this it fit somewhere else. Then trying to have the same look and feel and I think I'm one of those people that just work with the designer and figure it out. Then I think that really helped with the quality and the final product really helps with that and just trying to reuse components as much as possible. Yeah, I think reusing a component or reusing colors and all that stuff all of that keep everything polish and anything you change. Maybe if we change it here we're probably going to change all these other places. Right. All of that. Yeah. Cool.

Nathasha Loos: I think we only have... We're getting close to the end. All right. Let's see. We only have five minutes left. Before we close I want to talk a little bit about our last segment is process pages project. We talked a lot about process here, like building process, but a lot of times, before a process turn it into an actual thing you usually starts with the head and you start writing things down on a paper, or it would be a digital thing. So at abstract we really want to... We really like to celebrate that first idea, sketching the idea, and we're actually going to give away 75 process pages and you can actually see these examples, really beautiful examples of people submitted their process pages. Some are very visual and Duretti I'm curious are you more of a visual process person or a text process person?

Duretti Hirpa: I'm more of a text person. Yeah. I have a writing background. So I think for me just writing everything out is really good. I'm also a visual learner. So if I can see a comp or a sketch, that's great too. I know there's people who are more audio folks out there, but yeah. Writing, sketching something out, drawing something out. Maybe getting in a room with people becoming more an option than some places in the world, whiteboarding, things like that. Although there are some cool products out there that you can whiteboard online. Yeah. I think Figma just came out with this thing FigJam and it's been really nice to use for whiteboarding online.

Nathasha Loos: Whiteboarding online. That sounds really cool. Yeah. For me, I just write, like, I usually jot it down real quick in my notebook and I actually have... I just use a different colors here. I don't know if you can see it's all text, but it's just a different color. I like to make it fun, but yeah, just if you have the audience. Kelsey will share the link in the chat, so you can actually... we're giving away 75 process journals, if you'd like to claim one Kelsey will put in the chat where you can claim and if you claim one, please share your process pages with us. We'll be putting together digital zine and show off your process pages. Yeah. There'll be a lot of cool stuff and you'll get more information in the email after the event. We can actually go check out a Twitter page and you can get some inspiration as well. Cool. Let's see. Let's see. I think we only have two minutes left. Let's see maybe take a last question. Any questions?How do you deal with those who are loudest feature scope? Ooh.

Duretti Hirpa: Like against it or the people who are that's not a creep? I don't... I need a little more clarification I think.

Nathasha Loos: I think they're talking about... Let's see in the chat maybe.

Duretti Hirpa: Because if there's people who are regularly being like, we should not post a feature creep, I'm like, yeah, you're right. I'm on board. But if it's people who-

Nathasha Loos: We really want this.

Duretti Hirpa: They want this thing and are really insistent on it that's tough. That's really interpersonal stuff. Usually, if you can be put it in a ticket and we'll do it in a fast follow, usually does work because it's sort of like, we have to get this thing out the door as is and that can work. I don't know what the... it's really tough because you have to maintain relationships with people as you work. If there's someone really dying on every hill that's tough to take. It's almost like crying wolf a little bit. It's like, oh, every time we're on a project day, you're always the one that's explaining the scope. It's like, well, it's tough to want to work with that person because they're not actually getting things out of the door. Some of the joy of being an engineer is getting stuff out on the product people and into people's hands and using it. It's really satisfying to me as an engineer.

Nathasha Loos: Cool. Yeah. I'm thinking it's like, yeah, without just saying no, we can start a plan. I think that usually works. Either we'll like trade-off. We'll trade this with that or just like, hey, why don't we do a fast follow next week or something. Cool. I think we're out of time and thank you so much for-

Duretti Hirpa: Yeah this was fun.

Nathasha Loos: ...This was really fun and thank you everybody for joining us-

Duretti Hirpa: Yeah. From all over that's great.

Nathasha Loos: From all over. I hope you guys all enjoyed the conversation and yeah. Thank you so much. We'll have our next episode in July 22nd and that will be our last Samepage. Yeah.

Duretti Hirpa: Cool.

Nathasha Loos: Cool. All right. Thank you, everybody.

Duretti Hirpa: Bye.

Nathasha Loos: Bye.

‍