Adi from Spoke.ai has seen how features they’ve worked on end up getting delayed because of covering an edge case that could have been covered after.
We had a super interesting discussion around why not all acceptance criteria are created equal. I hope you learn something!
✅ Embrace Transparency: Transparent communication is crucial in a fast-paced startup environment, especially when dealing with shifting priorities and new challenges.
✅ Proactive Issue Discussion: Early and open discussions about potential issues or complexities in development can prevent unnecessary delays and improve collaboration between teams.
✅ Adaptive Acceptance Criteria: It's important to regularly review and prioritize acceptance criteria, being open to adjust them based on practicality and time constraints.
✅ Collaborative Design and Development: Building a collaborative relationship between designers and developers can lead to more feasible and efficient implementations, encouraging mutual understanding and creative problem-solving.
✅ Clear Incident Communication: Recognizing and addressing the need for clear and immediate communication during incidents can help manage expectations and expedite resolutions.
Adi (00:00)
Hi, my name is Adi. I am currently a frontend developer at Spoke. And before that, I worked at N26 and Gorillas in various fields, like in agile coaching. But then I switched to frontend development.
Jack (00:31)
Cool. So you've obviously got lots of experience in, you know, fast moving teams and working with different PMs and different engineers on the backend side, data scientists, designers, et cetera, et cetera. And we're talking a lot about product communication, right? So that all of the communication that happens around building products. And my question is very, basically very simple. Tell me about an experience you've had where the communication between product and you in the front end or product and engineering in general wasn't so perfect. And we can dig into that a little bit.
Adi (01:10)
Um, I guess it's worth mentioning that Spoke is like a very young startup, right? So like everything is shifting all the time. Like the priorities are shifting, the product is changing, the designs are changing, like we've thrown out our codes.
We're throwing it out like basically on a daily basis, right? So there's a lot of stuff going on and that's why there's also like a lot of communication, right? And also a lot of the stuff that we do, like I am doing stuff on a daily basis that I've never done before. So there's a lot of communication going on and also that's why there's a lot of communication that can go very wrong.
Actually, quite recently, we started building that one feature. And as I was like ready to hand it over to QA, I just double checked the acceptance criteria and I realized we missed like this teeny tiny copy for the empty state. But backend moved on and I moved on, but kind of we didn't really implement it. But then instead of like reaching out to product and saying like, okay, this is a hard thing to do and actually we've all moved on, can we like kind of skip it and afterwards, we actually delayed the future by quite a bit and yeah I think the communication there could have gone massively better.
Jack (02:27)
So if I understand it was missing something, kind of missing the real edge case in the ACs, then you've built the thing, then you kind of realize that you've already moved on to other stuff to do.
Adi (02:38)
Yeah, totally. Also, like, it's a bit bitter because 90% of the future was basically built in a couple of days. And then this one edge case was like taking three days of investigation from everyone's side and nobody really communicated well and got unnecessarily delayed.
Jack (02:55)
Yeah, so how do you think in that case, what were some of the causes for the issue there?
Adi (03:04)
Um, yeah, I think most of the time, as I said, we don't really know what we're doing, right? So sometimes something might look like a small thing, but then as you dig in, it turns out to be quite big. And I think in those cases, it's really necessary to kind of openly communicate to product and say, like, Hey, you know, this is an edge case and it's going to take forever, instead of just silently writing code in your corner and not communicating because you don't want to let anyone down, because it's not letting anyone down, right? It's just being open.
And also like in a startup situation where you need to weigh your time against also the value of the thing that you're producing so I think yeah, that's what happened.
Jack (03:46)
And how did you resolve it in this case in particular?
Adi (03:49)
So after like the backend developer and I, we digged into like it for quite a bit. And then we both realized like, okay, this is really annoying and it's going to take a long time. We're like, okay, let's, let's just take it to product and tech and, um, sorry, product and design. And like, we raised it in a channel and then we talked about it, like also in the following daily and basically then.
Logically, Jack was like, well, it's not worth it. Let's just ship the feature as is and then like, you know, make a small fix off to it.
Jack (04:22)
Makes sense. And if you were to approach that whole situation again, kind of start to finish, what would you do differently?
Adi (04:29)
I think that's just something that I am actually doing right now actively in the daily as I ask myself like okay is there anything that is causing me unnecessary trouble and like can I suggest alternatives? So for instance, I can say oh this acceptance criteria like can we take it out of the ticket and like shift it afterwards but like have the rest of the feature for instance on production much earlier right? So that's one thing and also like I think it's um something that I can actively ask about um the backend counterpart was working on the feature right? I'm like okay this is taking quite a bit, like this is definitely something that I started doing, but also like reading the acceptance criteria more actively. I guess it's never a bad idea before you start developing something.
Jack (05:23)
Yeah, I'm glad I'm not an engineer for that. I think I would get stung for reading badly or misreading or whatever. Um, but yeah, I think it's so interesting. This thing of just asking people how important stuff is because, you know, there might be five acceptance criteria. Two of them might be essential and three of them might be a nice to have. Right. And it's like, you know, I think product or design when they're writing tickets often is trying to cover every case, every case.
But not all of those cases are created equal. So it's definitely a valuable thing to just push back on that and work out how things could be sliced down or released later or whatever.
Adi (06:02)
I think also with those startups scenario, right? Like, I mean, we both kind of come from bigger companies and there's like every acceptance criteria in the ticket is kind of like, it has to be done. But in a startup, especially like when you have limited time and limited resources, right? You want to like really weigh all the decisions and like see where you're wasting lots of time and stuff. So that's definitely a learning for me.
Jack (06:26)
Totally. Yeah. Everything is optional here, I guess that is the learning. That's obviously a situation and experience that you've had at Spoke is that if you think back to Gorilla's or N26, where it was like a more established engineering team, more established product team, the products were more mature. Are there any situations there where the communication between product and engineering could have been improved?
Adi (06:54)
I mean honestly, hundreds and hundreds of stories, right? Communication is so hard. It's really hard to pinpoint. I mean, it basically boils down to just people not being able to talk to each other properly somehow. And I think my biggest learning from that is just always be transparent, sort of.
You know, for instance, what happened to me in the past is like, I am someone who really doesn't let people down. So I would be like, okay, maybe I like spend one more hour on, on this, on this feature or whatever, right? Instead of just like saying, okay, I'm going to stop now and then I'm going to communicate properly with, um, with product or maybe something else about communication as well as like when stuff is on fire, you need to communicate fast and clear. And that's definitely not something that I've always done right, let's say. Like, if there is a bug, then the first reaction might be, OK, can I quickly fix this by myself and make it so that nobody notices and it just works, right?
But then the first probably reaction right now from me would be like, OK, I'm going to tell everyone, OK, there is a bug. You know, it's breaking right now. We are aware we're going to fix it and stuff like that, right? And that's definitely something about communication that I've done very wrong in the past, for sure.
Jack (08:17)
Yeah, it's so useful that thing of being like, just, I'm on it, you know, I'm aware as the first kind of flag of indication that actually, you know, something's being looked at, at least. And it's a bit like those incident reporting things, right? It's like you have to acknowledge that you've at least seen the incident and that you're looking at something so that everyone's like, okay, you know, we can calm down. It's not fixed, but it's known about. I think that unknown is pretty scary.
Adi (08:45)
Totally. And also like there's so much noise. Sometimes there might be an incident and maybe the relevant backend developer is not aware, right? So like just going on a public channel and being like, okay, there's this incident tagging everyone and then like getting the, you know, getting it done is much more effective than like pinging someone in DM and then the product manager doesn't know. And maybe like the QA ledges know. So, you know, so.
Jack (09:08)
Totally. And then final question. So obviously we've talked about kind of product and engineering, but there's also the interaction between design and engineering as well. Do you have a story from that where the interaction could have been better?
Adi (09:25)
Again, hundreds, I mean, front-end developers and designers were probably, yeah, it's the closest people you work with at a company, right? Because basically, you're turning into life what the designers came up with. And I think a lot of the times where interactions go wrong is basically designers coming up with Figma stuff that looks really beautiful and static, and then you try to turn it into reality and it's really hard And I feel like what front-end developers, what I did wrong in the past is basically I would try to do like this pixel perfect design right instead of just being, hey, look, can we do it another way? It's going to save me a lot of time. And it's not going to be 100% how the design is, but it's not going to be worse. And it's going to be actually code-wise better, and going to work better on different screens, and so on. And I feel like this is where the communication between design and front end is.
That's where the key is, being able to say, okay maybe I might not be able to implement the design just like this but then offering alternatives as well so that's like and now I'm trying to bring the designers that spoke also closer to the front-end code so that they know how it works and then also maybe while they are making the Figma designs they can actually like maybe think ahead and be like oh this is going to be a problem or whatever
Jack (10:52)
Yeah, I think that reminds me of two things. Like number one is, is designers or product people not asking engineers, is it possible? But like, which of these versions would make most sense, right? Because often there's like three ways to do something and one of them might be one day and one of them might be two weeks. And I think that conversation happens way too rarely. It's just like, Oh, I've asked engineering and it is possible. And the thing is that we're not building rocket ships, right? Most of the things that we do, I mean, I say this as a, you know, product person, not as an engineer, you are building rocket ships, but you know, most of the things that are happening are possible. They are feasible.
And the second thing was when you joined the Spoke Team, one of the first things that you said was like, please no models because you found those super difficult to implement or you hated implementing them and they caused a lot of issues. And what was interesting about that was before we were always like adding lots of things in mobile models and having issues with them. And it was like, it was a very helpful clear cut when you just said basically to design, please stop doing them. Can we find another way?
So it was again moving the conversation from is it possible to you know, how can we achieve this end state in the best way?
Adi (12:23)
I guess that's sort of the problem when it comes to implementing certain designs. Just because we can doesn't mean we should, right? Turning everything into a model, yeah sure we can do that, but maybe that's also not the right way to do things, right? So again, I have nothing against models. I think when they are appropriate, they are delightful and they save some space and everything, but not everywhere.
Jack (12:49)
You just think they're never appropriate. So that's the issue.
Adi (12:52)
Oh no, that's not true. No, I think there are like one or two modals that I wish like, okay, that makes sense. That makes sense.
Jack (12:58)
Fair enough, fair enough. Cool, Adi, thanks so much for your time. Super interesting to chat to you and I definitely learned some stuff.
.webp)
