Making Organizational Level Changes to Achieve Product-Market Fit With Jenna Quindica

Changes and pivots are bound to happen, especially in the early days of a start-up. Jenna Quindica, Staff Software Engineer at Square, shares a story from early on in her career where a complete pivot was required to achieve product-market fit. Jenna also delves into what it takes to be an effective Staff SWE today.

What is SWIMM UPSTREAM?

The Swimm Upstream Podcast is a collection of conversations about knowledge sharing, code documentation, change management, scaling dev teams and more. Our guests come from all over the tech world, with some really interesting insights, stories, and… coffee hacks. Join Tom Ahi Dror, Co-Founder of Swimm (a Continuous Documentation platform that streamlines onboarding and knowledge sharing within software engineering teams), as he talks with some of the most inspiring engineering and dev team leaders in the industry.

Tom 0:00
They say that change is the only constant in life. On this season of Swimm Upstream, we're breaking down specific instances of change in software organizations when both technical and human aspects were involved.

Jenna is an experienced Software Engineer and has led a number of teams throughout her career and worked at companies both big and small. Jenna recently joined Square as their Staff Software Engineer. Welcome, Jenna

Let’s kick things off with some warm-up questions. What have you been listening to on Spotify?

Jenna 0:43
I'm laughing because the song that I've been listening to on repeat, it's not safe for work. But the reason I've been listening to it is because I've been following the journey of this song being created on TikTok. The song is called Light Switch. And the whole premise of the song is that centered around this accent beat, which is actually the recording of a light switch being flipped. So the soft light switch, and it's created with a literal - I watched this on TikTok guy holds a microphone up to a light switch, flips it on, and then mixes it into the song. And the beauty of this song is that it loops infinitely, so you can't tell when the song starts and ends if you have it on repeat. So it's the perfect thought to just have a going on in the background.

Tom 1:33
I'm gonna look for that. And also, I'm interested why it's not work-safe. So I'll check that out later on. Okay.

Tell us, like where you are right now? Where are we catching you in terms of your career at the moment?

Jenna 1:49
You know, it's really funny, the timing of you reaching out to me. I just started at Block formerly known as Square. And I also just got my first staff software engineering position, which is a role that I've been wanting desperately for the last two years. I had been working in organizations that didn't have a staff-to-staff position because we were so small. And I was writing my own promo packets, like collecting these experiences that I've been having at these smaller companies that would never give me a promotion into this role. And I was just spending those last two years working towards it. And I was really happy in my last role, like really, actually very happy.I love the team I was on; I thought that we were doing some really incredible things. But then the Square opportunity came knocking. And then also they decided to give me the staff position, which I never thought they would. I thought I was interviewing for like a senior software engineering position. But so anyway, you called me at this incredible time. I feel very validated in my career.

Tom 2:58
Correct me if I'm wrong, would you say that on top of, you know, just being a very significant engineering team, you're also expected to raise the level of engineering and software development in your team is that what it means to be a software engineer, staff software engineer?

Jenna 3:18
I think the big difference between senior software engineer and staff software engineer at Square - and by the way, I won't speak for Square. I'm not speaking on this podcast as a representative of Square. But my understanding is that the difference between senior and staff is that staff has effectiveness cross functionally, whereas a senior software engineer would be expected to be effective cross team. So in my last role, when I was one of six engineers, a big portion of my role was getting down in the weeds directly with our customer stakeholders, and the profile of our customer stakeholders ranged from IT to HR, to communications of internal comms, all the way up to senior leadership. And so I was getting down in the weeds working with all of these different kinds of profiles. And I think that's the exact experience that got me this staff software engineering role, but real experience of talking with people who do nothing like what you do, and being effective at it and driving driving outcomes. Mentorship is a huge part of being a senior engineers being and also being a staff software engineer. I'm lucky in that I had manager experience. And my last two roles, not significant manager experienced but enough to know how hard it is. And I think you really can't get to this level. If you don't have a good enough understanding to teach others how to do it. Like yes, you have to get there yourself. But you're not going to be consistent with your efficacy until you're able to teach others how to also be effective. And that was the big thing for me is being consistent.

Tom 5:02
And this season of the podcast where we want to be obsessed with change and how that happens with the way you know what challenges you need to face to make it happen. And it sounds like there are two. I'm connecting this with change what you just described - it sounds like there are two things here that are very much connected. One, rarely you can do significant change without being able to work it systematically, and be able to communicate with different stakeholders in the organization that you are in, right? So having that skill set, and having that system understanding is crucial a lot of times. Would you agree?

Jenna 5:46
Yes, definitely.

Tom 5:47
And the second thing is mentorship. I just think it's like, it's one of the best ways to bring change into the world. Because usually, you spend, like, really, it might be a few minutes, but those few minutes can sometimes affect someone significantly. And that change goes on. And you don't even have to make any effort because that person is going on with that thing that you taught them, right? So what a great way to make change, right?

Jenna 6:15
It's really interesting that you're calling that out. Because it reminds me that you don't really know when someone is listening, and when it will analyze change, and a good or negative direction. And it's actually a great segue into a story I wanted to share today. Because I wasn't explicitly trying to make organizational level change. I think, what happened here, so just to sum up is - I felt pretty stubborn about this idea that I had in this direction. And I pretty much dug my heels in and made a bunch of compromises until it happened. That's how I would sum up this story. So here's what happened. I was employee number two at a startup. I had just moved to the San Francisco Bay Area for this startup. I think I was 21 years old, employee number two, and every other coworker of mine had been a long tenured Google software engineer. So I joined because I want to - I was so excited about the opportunity to work with these experienced people.

Jenna 7:26
To be honest, I don't know why they hired me, because it kind of makes no sense when you like, look back, and like, oh you were 21 and you were employee number two. Like what? And I had been there about maybe about nine months. And we were trying to find - we had realized that our first product that we had launched did not make product market fit. So our mission as a company was to pay attention to these long running forums on the internet, B bulletin, XenForo forums, that I guess now in 2022, might have been running for the last 30 years. So our idea was to pay attention to these forums, ingest their data, inspect it, analyze it, apply some machine learning, and try and surface or try and retrain our models regarding ranking content. We believed that because this content had been running on the internet for decades, decades longer than Twitter, you know, Facebook. We believed that the data on these forums had more expertise than anywhere else on the internet, or information that had been curated over the last several decades.

Tom 8:37
The most experienced people in the world at the time were writing stuff about things that they were very experienced about right?

Jenna 8:43
Right. These were Google engineers who had worked on search. They noticed that Google wasn't really spending time looking at these B bulletin, XenForo, PHP forums. At the time, we were talking, oh, my gosh, and at the time, you know, we were experiencing this Donald Trump election. And so ground truth data was extremely important to us, as a company. And I think just even in our in our social circles, it was really important to us.

Jenna 9:08
So we got the search products, we would ingest all the data on these PHP forms. So we had to write PHP to do this. And we had built the search engine and people liked it, but it wasn't hitting product market fit. And so if we were going to survive as a startup, you know, as a company, we needed to do something different. And it was always the idea that we would take the search data, basically, once we have the data, then we can do interesting things to that data, to transfer learn to rank content to curate content. So we were trying to figure out what would be our next product that would allow us to quickly iterate and test our machine learning models while still delivering value to the world. Because you know, we could have taken that data and then disappeared for 10 years and potentially done something cool. But you can't do that in a startup. You've got to deliver some kind of value to your customers and continue to get revenue.

Jenna 10:08
Okay, so this is about summertime. And we were working out of our investors office in Redwood City. There was, I think there were six of us at this time: two people who were remote, okay, yeah, so four or five people in the office. And we would just work and then eventually someone would say something, and then we'd all just - our whole workday would be derailed, and we'd be like, sucked into the big conversations in the middle of this giant, open space that we shared with our investors. And I wish I could remember, like exactly what happened. But so we're trying to figure out a way to test our ideas. And eventually, I don't know if I said at first or someone else, but we started talking about what if we just sent people an email, an email of the 10, top ranked, or curated, content that was created in the last week. And then we analyze their open and click through rates. And then we used that data and fed it back into our machine learning model. And then magically, we have some kind of train model.

Tom 11:06
So you'd be pushing instead of just pulling stuff, right? So...

Jenna 11:13
Exactly. So we spend probably two weeks throwing out all these kinds of ideas, because a lot of the team wanted to build an app, they wanted to build a social media app where you had infinite scroll, and you could like things and share things. And yeah, we wanted to build that. I think every[one] was pretty clear everyone wanted to build that. But we didn't have our Series A yet we were still running off our seed round. And that seed round, I think had been - we were going up on the two year mark of that seed round. We were really running out of money. And we just didn't have the revenue to keep going if we didn't raise another round. And so time was of the essence. And we were getting desperate.

Jenna 11:54
And so we spent about two weeks talking about this over and over and over. And I'm like, Look, why don't we just make an email, like a marketing email. And when you really think about it, these PHP forums, they weren't sending email. If you wanted to access content on these PHP forums, you had to remember the domain, you had to navigate to it, you had to remember to navigate to it. There were no hooks, there were no ways to pull you back in. And, and that's how you access that content. And so to me, I love email. I love that I can curate it, I can unsubscribe, I can mark that stuff as spam. Like I love, you know, you have so much control over the content that arrives in your inbox. And so I was like, Oh, this is pretty cool. We could do this - you know, this could be a great experiment. It's really quick - sending emails is so easy. Like, what do you mean it's gonna be hard? Like it's email. And kind of like what I was saying earlier, the thing that sticks with me to this day. It's been, I don't know, five years, or whatever. It's however long - it's been six years. And the thing that really sticks to me about this story, the reason I keep talking about this story is my CTO said in one of these big brainstorming sessions, that he never wanted to work on email. He thought email was the worst - he would never dedicate his life to email. It's not something he wants to spend his time on, he would quit if we worked on email. And he said all these things, and it was like, Oh, my gosh, like this is our CTO. Wait, if he doesn't agree, what are we going to do?

Jenna 13:24
And I genuinely did not see another option. And actually, I said, okay, okay, we're not going to do this forever. We're just gonna - it's just an experiment, you know. We just want to like, get some data - we want to test our ideas. And this is just an experiment just to test. We can craft this test to be time bound. So it doesn't have to, we don't have to dedicate a ton of engineering resources to it. It's not something that's going to live forever. We can write some Python scripts to send these emails, we can take CSV dumps of the database and just run the command on our computers like this is not. This does not have to be a productionized system. You know, we might just throw everything away in 10 weeks - like let's just find out if it works as a test.

Tom 14:14
Your taking this huge frog, right, that the CTO would not swallow ever. And you're making it into this small pill, right? It might have been obvious to someone like in his position, that's what you were doing, and he would need to swallow the frog at the end, right? If that worked out. So how did that work?

Jenna 14:37
I raised my hand and I said, “I'm gonna do all the manual work that I have to do to make this happen, and we're going to start sending emails.” I promised we would send emails by the next week. And we would pick one forum. And we would pick, I think we picked like users that had been active in the last 30 days. And I said, we're just gonna do it, and we're gonna get results. And that's what we want. The method doesn't matter here.

Tom 15:05
I'm sorry to just to stop you here again. So we took the frog put it made it into a pill. But the second thing here that made it work was that you said, “I'm going to do this, it's on me,” right? And I'm assuming it would have been harder to say, don't do it when you're saying I'm taking this on myself, right? So why worry about it? Is that true?

Jenna 15:29
I think so. I mean, let's be clear about what I was volunteering to do. I was volunteering to go into a production database, take some CSV dumps of emails, PII, stuff that you should really never do. And then I was creating a Python script that would, you know, query for the content. We were going to send into the set, put into the email, and then call on API to then pair of the emails with the content together. The thing that makes me upset to this day is we wanted those emails to be personalized. It was so important to us that each of those emails said hi, first name in the email. I don't know if it was in the first round or the second or the third. But throwing in the fact that I had to be personalized was like the hardest part about this whole manual process would have been way easier if we just copied and pasted the content into MailChimp, and just sent one email the same email to everybody.

Jenna 16:26
Anyway, yes, I signed myself up for 12 to 16 hour work days, for an entire summer. I think we started in July, maybe June or July. And so what I said, you know, maybe a month before we realize these issues, that email would be easy, I was wrong. We spent the 10 weeks running the experiment. Our emails were wildly successful, we were beating industry standard click through rates by I think 50%. It was just really incredible how how well these emails worked. We ended up signing an incredible deal with a huge aggregator of forum communities. So this company that had acquired a number of communities wanted to roll out our search engine, and they also wanted to use our newsletter product. So I think, you know, we raised our Series A, on this email product which no one ever believed we would. And, you know, I left the company, maybe about a year after we raised our Series A. And I do I do miss it, but I don't regret it because it was the right thing for me. But, you know, it's really funny, you reached out to me, maybe like a month or six weeks after this company that I'm talking about got acquired because of this email product.

Tom 18:10
What's missing for me is the process of swallowing that frog. I mean, I would assume and tell me if that's right, that you tried something and you saw enough good results at first, to justify keeping in this direction. Is that true?

Jenna 18:18
Yes, if I recall correctly, we were onboarding, we had forums lining up to be a part of our newsletter experiment. And we had to like gate the experiment, because we couldn't take on more forums. And so I think we started off with five or six. And I think we eventually rolled out to 12, within the first couple months. And I think just that excitement that we generated with these customers was enough to decide - oh, okay, wait: if we want to double the size of this experiment, now we're gonna have to invest in production eyes in this system. I think, honestly, it worked so well in that we did one thing. We got some good feedback we did, we did more of it, we got more good feedback. And eventually, we've created this wonderful like feedback loop, where the more we did, the better outcomes we experienced. And so that made it easy for everyone on the team to see that this was a worthwhile use of our time. And I think, if we hadn't crafted this experiment in a week by week thing where we were getting results, after the first week after the second week, I don't think it would have gotten this far. And so today, even now at Square, when I'm seeing these projects run multiple months, it's really important for us as engineers to figure out how we can validate our ideas as soon as we can. Because the worst thing you can do is spend five years on an email product and not see your company get acquired.

Tom 19:46
So basically, it's it's not only that you're making sure you're not going in the right direction. It's also that if you know that this, that there are steps in the process, and that you can exit at each one of those, it's easier to make the decision to go for something risky, right? Because you're not risking the next two years, you're only risking the next few weeks, right?

Jenna 20:12
Exactly, exactly. Yeah, I couldn't have said it any better.

Tom 20:18
I wish we could continue this. And Jenna, thank you so much for coming on and telling us your story. And I'm sure it's going to be an inspiration to people that want to make change in tough situations.

Jenna 20:34
Thank you for having me.

Tom 20:40
Thanks, everyone for tuning in. That's all the time we have for today. To read episode transcripts, check out our past season, suggest an episode or join our growing community of developers. Head to swimm.io that Swimm with two M's dot IO.