Jun 6, 2023 · Episode 4

Hypergrowth, B2B vs B2C, and welcoming the rest of the world to AI with Heidi Williams from Grammarly

This time, Rebecca is joined by Heidi Williams who runs the engineering organization of Grammarly Business.

Show notes

Heidi is Director of Engineering at Grammarly, leading Grammarly Business, their B2B offering for teams and organizations.

In this episode, she shares stories of hypergrowth, the challenges of working on a product that has both business and consumer users, and transitioning a team from startup mode to long-term stability.

Timestamps

(00:00) Introduction
(00:32) Heidi’s journey at Grammarly so far
(01:45) Culture at Grammarly
(05:43) B2C vs B2B
(13:21) Heidi’s short stint in product
(14:33) Cross-functional work between engineering, product, and design
(16:22) Managing relationships with stakeholders
(19:02) The role of an engineering director at Grammarly
(20:36) Balancing technical debt with new development
(23:18) Centralized vs. decentralized architecture
(26:22) The role of platform teams
(28:52) Welcoming everyone else to the AI party

Links and mentions

Transcript

Rebecca: Hey, Heidi, how's it going?

Heidi: Hi Rebecca. How are you today?

Rebecca: Oh, so good. It's so good to get to talk to you again. It's been a long time, but I've had fun just chatting with you, prepping for this.

So maybe you can just tell me a little bit about who you are and what you do and how long you've been there and you know that that whole thing that you go through when you first meet somebody for work.

Heidi: Sure, happy to. I'm Heidi Williams and I'm a director of engineering here at Grammarly and I lead our Grammarly Business product. I've been working at Grammarly about two and a half years, so it's been an exciting ride trying to take a product that was a little pre-product market fit into building something that we are now super proud of and is out there in the world doing great.

Rebecca: Yeah, I've been telling people that I was gonna talk to you and like the brand goes far. It certainly is well known in the consumer and business world, and we'll talk about that in a little bit. But I'm sure, it's two and a half years, a lot has happened in the tech industry in the last two and a half years.

Tell me what sort of things have changed at Grammarly since you've grown or since you joined?

Heidi: Yeah, it's been an exciting ride. I think when I joined the company, we were under 300 people, and now we have almost tripled in size in the last two and a half years.

So it's the first time I've ever been at a company going through hypergrowth. I've been at other companies that have grown quickly, but I had no idea what hypergrowth meant until we were doing it here at Grammarly. So that's been really interesting. And I think one of the cool things actually is that our company culture has pretty much stayed the same, which I think is the hardest challenge for companies going through hypergrowth. And I'm really proud that we've managed to maintain that.

Rebecca: I'd love to hear more about that and what you've had to do to preserve that. It's not a thing that just happens. It requires intention and follow through with all those things.

So I'm curious, like what have you seen work to preserve that culture?

Heidi: Yeah, it's definitely been intentional, and fortunately intentional well before the hypergrowth period. So as a company, we've been around for 14 years, and from the very beginning, our founders and our CEO put together a set of values that are described as a set of behaviors.

What behaviors are on point with our values and what behaviors are not on point with our values. And I think from the very beginning, they've been intentional. We hire and fire by them. We celebrate people for their values. It's part of our performance reviews. It's so baked into how we operate that then when we went to hypergrowth, we just kept in place all of the things we've been doing all along and made really sure to keep that bar very high for making sure that people were culture adds, but also highly aligned with wanting to operate the way we operate.

And I will say one of my favorite things about that is that when you go in knowing how the company operates, you can sort of go down the list and say, “Oh, that’s how I work.”

So I can just show up and be myself and not have to figure out how to work with people. I can just do what I would normally do and it makes it much easier. So everyone goes through that same sort of hiring thing and onboarding and everybody comes here because the culture is amazing and it lives up to its expectations.

So we hold it dear and no one wants to let it dissolve at all. So it's definitely a group effort.

Rebecca: Yeah, you mentioned the performance process as a way to persist culture and to instill culture. How does that work at Grammarly?

Just at the high level how do you take that, especially in hypergrowth where you're hiring not just new engineers, but plausibly new managers who also have to learn these these behaviors and how to apply them. How has that changed? How does it work?

Heidi: I think we've started being a little bit more structured about how we do performance management. And so when we started, we were doing performance reviews quarterly, and that was a lot, but it also was not as sort of intense as what a lot of companies think of as a performance review cycle.

And so we'd now switched to doing it twice a year. Where one is sort of the big performance review and the other one is more of a pure feedback and a career development check-in. And so we have always made it be really important that people gave feedback not only on what was the work that someone did and what impact they had, but also whether they were acting as culture champions or not.

And so you go through the same five values. They spell out the word EAGER, they stand for Ethical, Adaptable, Gritty, Empathetic, and Remarkable. And you can go through each of those and say, here are examples of where someone expressed one of those values. And then here's an example where I think they have a little more work to do.

So constant feedback about not just what impact we have, but how we work with each other.

Rebecca: Yes. EAGER. That's very good. You gotta have an acronym for everything, I suppose.

It's really good that quarterly review process. You know, I actually talked about this on another episode with Jack about, because we had a quarterly review process at Indeed for a while, and just how good it is at reinforcing culture. And it reinforces not just the culture and the behaviors the ICs are exhibiting, but it also like reinforces back to ICs that the business also will hold to that culture and hold to those values.

Heidi: Yeah, that's definitely true. And one thing that I forgot to add was that when you're going up for promotion, if you have values flags, there are some areas where you are sort of not being a good grammarlian, you cannot be promoted if you have values concerns, and so I think that is another way of reinforcing that.

You can't just do an amazing job and be a jerk. That's just not going to work.

Rebecca: It's not gonna work. So tell me, I know for me, every new job is full of new challenges and every job is full of new challenges if you stay there long enough. What's maybe one of the more unique challenges that you've had to face at Grammarly?

Heidi: Yeah, it's definitely been interesting. I think like you said, we have a super loyal fan base from our consumer product that's been around for a long time.

You know, we have a free and premium product, and so when I came in I was excited, first of all, about the opportunity, but of course that does come with interesting challenges to overcome about building a startup within a startup. So how can we build a brand new product for teams and organizations: Grammarly Business?

And how do you insert or somehow incorporate what it means to be enterprise-ready for a company that has deep consumer roots? And I will say at the same time, when I was hired actually, I was also leading Grammarly for developers, which was our platform offering. So we needed to both become platform-first and enterprise-ready. And still be an amazing consumer product without slowing down.

Rebecca: Of course.

Heidi: And so I think it's been interesting. It's not just a technical challenge, it's an organizational challenge. I mean, everything around your data and your metrics and what you optimize for, what problems you're solving, you know how these pieces relate to each other.

It's been super interesting to think about how to not be this little siloed group thinking about enterprise. How do we leverage the whole rest of Grammarly to help us be successful in the enterprise?

Rebecca: I can imagine based on past experience, that when there is a business, I don't know, like you are business and they are consumer, that there's tension there. What are some examples of the, the kind of things that you have to figure out when those two sides exist?

Heidi: Yeah, for sure. And not even just having a difference of opinion necessarily, but sort of then coming back to the business when you have one business that makes a lot of revenue and you have this new business that's an up-and-coming bet, right?

What are your priorities? You know, do you invest in the thing that could be huge or do you not mess up the cash cow that you have? And it's really, you know, of course Innovator’s Dilemma. You know, I think a lot of folks have read that book, but gosh, living it is hard. And it does come back to the day-to-day decisions.

Maybe just to give some examples whether in the growth funnel you have to decide which is better revenue? Is it a premium user or a Grammarly Business account being created? And how do we make sure to flow all of that back into the system so that we get proper credit for whatever choice we made and that we can tune it over time? Or maybe things like when you have a team that you wanna incubate and get started, that's great, but maybe nobody else knows what you're working on.

And so we did have an example of a feature that Grammarly Business already had, and then we built another feature for the free and premium product that we didn't really think about ahead of time, it had implications and might end up having a weird user experience for Grammarly Business customers because they're both in this same topic, and so we had a sort of last-minute “Oh no, what are we gonna do? We have to think about how to integrate these features.”

And it never occurred to the team building the free and premium version that there might be a conflict. So part of it is honestly just a lack of awareness and a lack of an understanding. It's hard to keep everything in your head and really get visibility into what this new incubating product is doing.

You know, you want it to be incubated, but at the same time, everybody kind of needs to pay attention to what's happening. So you don't sort of two steps forward, one step back on things.

Rebecca: Great. Oh my gosh. So many questions about everything that you just said. It sounds like right now you’re organizationally optimized for focusing on the business goals of business or the business goals of consumer.

And you want to keep those, like the organization set up to keep those, those distinct. Do you think they'll stay that way? Or is there a time when this like, incubator startup within a startup goes away and becomes like grown up? Because I can imagine that there's a point where this is extremely valuable because as a startup you can move super fast.

But I can also imagine that, yeah, you start to have issues where the flagship product or the core product or whatever is making changes without you. And like now Grammarly business is down or something seems bad. So yeah. Do you think that that the organization will stay like that? And how long has it been like that?

Heidi: Yeah, I think we're still transitioning and sort of coming out of that siloed way of working. I think early on we were super siloed and realized that was a problem. And so I think we've tried to do just find better opportunities.

Maybe just one example of things that we've done to try to bring people closer together and have shared empathy for what we're all trying to do — either what our business constraints and concerns are, or what our goals are — is to bring our eng, product, and design leadership together on a regular basis to problem solve and put our, be able to put on our Grammarly hat because we know everything that's going on at Grammarly.

You know, it's very easy to have your B2B hat on if all you ever learn about is B2B, right? So how do you get the company hat? You have to go out and learn about what else is going on? So that's been an exciting new thing that we have been trying to really work as a leadership team and cross-functionally and product design, user research, data science, the, you know, human insights, all of that, right?

Because we really do need to have a shared understanding of the priorities and the challenges and how to help each other and how to help our teams make good decisions on the ground when someone asks them to come and do something. They need to know why. They need to know the relative priority of that other thing to the work they're doing.

So that's definitely one way that we're trying to approach and break down those silos.

Rebecca: Whether it's B2B versus consumer or SMB versus enterprise or, you know, or developer versus platform. Yeah. Definitely a real pattern.

Were you there for the decision for the org to look like this?

Heidi: No. So I joined when Grammarly Business was seven people. So there was one manager and six or seven engineers at the time. But I have had a hand in shifting and shaping, you know, how we are organized and, and sort of any other questions about how should we be organized going forward.

And maybe just one thing that I'll share, it wasn't necessarily on the engineering side, but early on we had a sort of, Grammarly business exec team, and it was as if we were, you know, CEO, CTO, CRO of our own little startup. And that actually caused more siloing.

And so we broke it up and then recently we fixed a bunch of the communication challenges, and now we have reconstituted a GB operating team — sorry, GB being Grammarly Business —, our own operating team, but we understand how our operating team relates to the company operating team and that there's a similar operating team for the consumer business, et cetera. So I think we sort of had to break it up in order to define a pattern that worked consistently across the company and then could restart it again.

Rebecca: Yeah. I'm curious, like this is fascinating stuff to figure out and work on. Is this the kind of stuff that you like to figure out and work on? Is this the stuff that lights you up or are there other aspects of your job that like, “Eh, I just do that so that I can do this?“

Heidi: Yeah, I do love the strategy and the entrepreneurial and business thinking and thinking about systems and all of that.

So I really do enjoy these early parts of figuring out how to get started and then how to help people. You know, find out what the roadblocks are and kind of remove those so that you can move forward. But definitely the entrepreneurial side is super fun. So I do love the organizational stuff. I do love the strategy and the business thinking of, you know, what is the market and who are the customers and what problem are we solving?

There's definitely other things that are less fun for me, but I still put my hat on and do that occasionally or when it's needed. So you know, I get to do everything, I guess

Rebecca: If I remember right, you did at least a stint on the product side of things. Is that… are you wearing both hats now?

Do you have a product partner and, yeah. I'm just curious how that has influenced your, your journey.

Heidi: Yeah, it was a short stint and I I will say it was interesting because, in a lot of ways, that product role was a non-traditional product role, and I think it made me appreciate what a good product partner is.

Fortunately, I do have a great product partner and a great design partner as well. And so we are a little triad for Grammarly Business, and we always talk about EPD and product and design as a triad. So it's been great to have that. But it also, having had that moment as a product manager helped me understand the dynamics of a business and really early on, I think, understanding you can't just build the best technology or the best product. You actually have to have it fit into the market and be something you can sell and that you can reach your audience. And so I love that business thinking and I love being able to ask product questions, but not be the person that has to go figure out all the answers. So… a good, not annoying partner to product. I don't know.

Rebecca: I know that when I have had that triad — and I hate when I don't, my last job I didn't have that triad, and it was a very different experience than the job before that.

I know when I do have that situation, like, yes, we all have our titles and yes, we all have our, like, official scopes, but it gets really blurry in a meeting room in a really good way. And I'm just curious, was I just lucky or do you see that kind of cross-functional conversation and even execution?

Heidi: Yeah, for sure. I think we are clear who's ultimately responsible, but at the end of the day, we like the blurriness as well, and we try to show it all the way through the organization. I'm so anti-waterfall and I really want it to be that product managers aren't the only people that come up with great ideas of what we should build.

I want eng and design in the room at the time, and let's all be clear on, “What problem is interesting to solve?” What are all the ways we could solve it? And let's be like, put our creative juices together to come up with the best possible answer. It just doesn't work for me if that happens, you know, that product and design, get to do the fun stuff and engineering just implements it.

So yeah, we try to model it from the top and then have clear partnership of that EPD triad at every level in the organization. And encourage everyone to sort of operate that way and get involved early. Give each other hard feedback, ask hard questions. You know, even question, in our engineering rubric and engineering manager rubric, you are asked to drive impact.

And so that means you need to be able to stand up and say to your product person, I don't think that's impactful. We're not working on that. Let's find something else. And so, yeah, I love the fuzziness. I think that the fuzziness is where all the, the goodness, the creative, all the tension comes into really, really good play.

Rebecca: Yes. It's so much more fun when it's just the three of you in a room hashing something out, and then you have to come out and put your hats back on.

So as you are navigating all of this, I imagine your stakeholders are your bosses and also the teams that you're working with.

I usually ask this as like, “How are you evaluated as an engineering leader?” But I want to flip that around a little bit and just ask like, How are you… at a certain level of leadership, you have to start to make a point of how you show up.

It is not simply you know, information that you receive and you do what you're told. You have to make a choice about how you show up. I'm curious how you are choosing to show up and represent your organization to your bosses, but really to your stakeholders, whoever they are across the organization. How do you talk about the work that you're doing and what's hard about it, and maybe why it's not done yet? And those sorts of things.

Heidi: It's a great question, and I think, you know, we sort of have our formal ways of doing it, through our QBRs and things like that. But I really want to make sure that I am, like you mentioned, celebrating everything from the things we've done well and our successes and where we have had impact on the business, but also where the challenges have been and maybe where there's organizational friction into, or technical friction in trying to build what we're trying to build. And so I do want to be an advocate for my teams and make sure they have what they need to be successful or that we, you know, change how we operate as a whole engineering organization.

And things like that. So there's sort of several examples where I've sort of pioneered or championed things that I've heard from people on my team and said, “OK, I'm going to come be an advocate for that and try to help us do better or do differently. So that things are a little bit more scalable.”

So we do have things like there's a monthly eng digest that each engineering leader sends monthly and we rotate. So there's one that comes out every week. And so that's a great opportunity for me to have the eng managers help me tell the story of what did we ship and who did the work, and let's recognize them and what was the business impact and what's coming next, and who do you talk to if you have questions about that.

So I love that we have a regular cadence of sharing out with the org the things that we're working on and all of that.

Rebecca: That's really cool too, that it is that it is a company-wide practice. That this isn't something that you're leaving up to each group to figure out how do we cascade or propagate information to the rest of the business.

So that is powerful when you can get to the point that you say, and therefore every month I have one and every week there is one. Makes it so much more valuable I think to the receivers of that communication too, to know that like they can, they can expect this and they can rely on it.

What are the things that you are held kind of accountable for in your, in your role? What does the business expect that the head of engineering for business is doing?

Heidi: Yeah, it is definitely, there's a lot around driving impact, so having good judgment, knowing what impact means, like knowing about the business and helping align all of our teams and efforts to drive that impact.

So and make sure that we deliver and whatnot. So, all the things that come with that. So you have to know and understand the business. You have to have good judgment about your priorities and deciding when do we work on this feature? When do we work on something big or small? When do we work on tech debt and all of that.

So really helping all of my engineering managers and engineers have also that same ability to prioritize and make calls and work with them to make sure they have that, that context so that they can, they can do that. So that's sort of one aspect is delivering impact. Another one is sort of driving alignment and making sure that not just within my organization and within engineering, but also across different functions you know, how can I help everybody?

You know, sort of give us the boost that we need to be successful or how can I, you know, help fix roadblocks and, and remove roadblocks and, and sort of fix friction and, and stuff like that. So, you know, so ultimately my goal at the end of the day is I want my org to be able to operate without me if I'm gone for a week or two weeks or whatever on a vacation or something.

And just make sure that everybody feels like an empowered decision maker with the right information to be able to be confident in their decisions.

Rebecca: You mentioned tech debt, somewhere in there. And I wanted to just zero in on that a little bit because everybody, every 14 year old business has it, right?

And it seems like Grammarly at the same time is still in a period of growth and like product exploration and product expansion. So how do you think about that balance of tech debt slash KTLO or whatever you wanna call it, versus that new development?

Heidi: Yeah. It's a, it's a great question and I guess, oh my gosh, there's so many different pieces to that because I do think our tech debt maybe looks different than other companies’ tech debts.

And part of that is I think many, many companies start with a monolith and then eventually have to break it into microservices. And I think we started very much the other way. With building microservices, with the idea that every team is empowered to choose their own tech stack and do whatever they needed to do to move fast.

So it was a very intentional, don't create dependencies, be able to operate independently, own your own destiny. And that was great. And so the kinds of tech debt that we have now is that if any one engineer needs to work in multiple different services. It's almost like knowledge debt? I don't know what to call it, but it's sort of context debt.

I don't know what word to put on that, but it does make it slower because you have to ramp up on someone's tech stack, their style guides, their code review and merge processes. You know, and it can be super different. So yeah. So that part I think is actually really interesting. On the other hand, I guess I will say, and I always have to knock on wood when I say this, when I joined, I was stunned that one of the top level company OKRs is not how many nines.

You know what's our uptime? Right?

And it's because it's actually so good. We haven't had to measure it rigorously, so knock on wood. Knock, knock, knock, knock. So that autonomy has given us this amazing boost that people feel it very deeply and directly. If something goes down, they know exactly whose service it is and who is on call and who's gonna fix it.

And so it really is amazing that that empowerment led to this autonomy and ownership, deep sense of ownership. And coming back to the culture, this sort of value and mission led and customer obsession. Every engineer is always advocating for how do we do best by our customers.

And so all of that kind of comes together in this amazing way that not to say we don't have other kinds of tech debt, but we at at least don't have issues with tech debt causing our services to go down all the time, which is great. But yeah.

Rebecca: Yeah. So, yeah, so I'm guessing it's more like, it's more debt around well, just delivery, like it takes longer to do things that used to take less time because there's more surface area to understand in order to do it.

Heidi: Yeah. Yeah. And maybe also several services that do the same or very similar things. But they're not quite accessible by each other, and so there's probably some of that that's going around like different, whatever it is, Kafka implementations or different services that handle settings of different kinds and whatnot.

So there's some of that as well. But I think we are committed to realizing that if we wanna improve developer productivity now that we've scaled, we probably need to invest more in unifying some of those and making it easy for people to do the similar thing than to do something different.

Rebecca: How do you see that kind of working out in the context of the culture? Because that can feel like a really big change to engineers. I used to be able to do whatever I want and like, this was my little playground that I knew no one would mess with. And now you're gonna make it easier for people to mess with it.

And you're gonna make me write like, you know, I don't know. I don't know what the, the. Negative language is right now, and I don't know what Grammarly is written in, but yeah. So it definitely can can feel like it's encroaching on autonomy even though it's absolutely best for the business, because those inefficiencies have like logarithmically increasing costs as the codebase and the team expands.

So yeah, I'm curious how you, how you think about navigating that cultural aspect of that.

Heidi: Yeah, there's probably a couple pieces to it for sure. Going from a bottom up thing to something top down feels icky just to even say it out loud. And so I think one philosophy that we have is instead of being prescriptive, why don't we instead set guardrails and say, well, you can choose the technologies within this limited set, or you can choose these building blocks, or if you are going to build something that's the same as someone else, we are going to invest in expanding that something else for your use case as opposed to building a brand new version of that.

And so we introduced an architectural design review committee. And the idea there is actually just to spot patterns and to share knowledge and to see what's going on and try to catch some of these before we proliferate into three versions of the same service and things like that.

And then probably the last approach, which I find the most effective, regardless of whether you have a top-down mandate for this or not, is: Build something useful and then shop it around and see if you can get other people to use it because they need it and it makes their lives easier. And so interestingly, you know, that's a cool place for Grammarly Business to be because we are the first product that's not exactly the same as everything else.

And so now all of a sudden we are the second pattern maybe of something. And so we say, wait a minute. Let's build this a little more platform-y. And so, just as an example, we built one of the first API gateways in the company.

And even though we ended up with separate versions of API gateways, we at least saw people come to us and say, “Ooh, that's a cool pattern. I wanna do something just like that.” Let me actually replicate that. And so even though we have three, they're similar enough that we actually could unify them at some point. That sort of bottom up building useful things and if they get traction, then great, you just keep investing in them and expand their use cases.

Rebecca: Yeah, one of my favorite posts is product for platform teams by Camille Fournier, and one of the things that she talks about in that post is that yes, like steal stuff from other teams. If you're a platform team, steal stuff from other teams and learn from what they've done and don't go reinvent it. Just, you know, land and expand in that thing that already exists.

One of the other things that I think about with the model that you just talked about is like, when you do combine those three things, who does it? And who carries the pager for it. So I'm curious how you think about that stuff.

Heidi: Yeah. And we actually do have an eng platform team. And really what they're responsible for in a super simplified way is all of our AWS building blocks. And so they have a couple of additional things, like they did institute a new sort of metrics service and they successfully got everybody to migrate to that and use it, which has been fantastic.

And they're always thinking about, you know, how do they sort of manage and curate these AWS building blocks. They're responsible for giving people access to different services, setting up permissions. And I think that is a team that we will continue to expand to be going further and further up the stack into developer experience, developer productivity services and tooling. And then, like I said, sort of organically a bunch of teams like within the NLP organization. We have a team that does ML infra and they're also building productivity tools and services for the rest of the ML org to use.

So we even at one point thought about repurposing one of our GB teams to be a foundations team for the whole company. The timing wasn't quite right, but I feel like that instinct there of like, I will give people to it because this will be such a boost for the whole company. You know so there's lots of ways to do it.

Rebecca: Alright, I'm gonna add a hash mark for for “foundations.” I'm always listening to what do people call these things? You've got some infra, you've got some core, you've got some foundations, we had capabilities back in the day.

Heidi: We had too many things called platforms, so we had to find another name. But fortunately, we're a good company at finding synonyms for things, and so we manage.

Rebecca: You got there. Excellent.

And just to wrap up here I always do have to ask people just like how tech has changed a whole lot very suddenly in the last few months. Whether that's the layoffs or just the new fear that we all feel. And then throw in AI just for funsies to make you question absolutely everything.

You know, I'm curious how these last six months or so — I don't know exactly where we put the starting point, but I put it at the beginning of November — how these last six months have kind of affected you and affected Grammarly and affected how you approach work.

Heidi: Yeah. Yeah, it's a great question.

It's been such a whirlwind and so much uncertainty everywhere about all of it, and so many things happening at once. Like you said, I think even in November, it didn't necessarily feel like even the pandemic was over. So everything's happening at once. You know, why not throw one more thing in the pot.

I think our approach has really been, first of all to just recognize that people individually might be really concerned about the macroeconomic climate. And so I think we've been thoughtful about being proactive and addressing what concerns might people have, letting them know that we're okay, there's no worry, we're not worried about needing to do layoffs, and just at the end of the day saying there is uncertainty, but the one thing that we can control is what we work on, what impact we have.

And so, If you're in charge of your own destiny, let's get to work and let's actually build things that are valuable and, you know, get creative about how to iterate and deliver quickly and ultimately, keep our revenue going strong, and all of that. And I think that really felt empowering to folks.

And I will say that even though I think AI threw everyone for a loop in November and December, we were sort of like, “Oh, thank goodness. Finally, welcome everyone to the conversation. We've been here for 14 years. Glad you decided to join us.” So it’s been really amazing that at that moment of macroeconomic uncertainty, there's like this fastest growing usage of an individual product ever.

And now all of a sudden this market that we used to have to convince people that AI was okay for your writing, all of a sudden the market is created. And we're just like, “Oh yeah, we've been here for a while, you know? Yeah, welcome everyone. Here's what we're gonna do for you.” So that has been a huge opportunity, super exciting for us in the last six months to be able to work on our own product leveraging generative AI and LLMs. Yeah. So it's been super exciting.

Rebecca: Is it causing you to like take risks or maybe things that used to seem risky, don't seem as risky now? I'm just curious, like, is it affecting like the product strategy to go from June where it's like, “Yeah, yeah, nobody can write like me” to today. Yeah. Just curious about that.

Heidi: Yeah, there's certainly a lot of power in LLMs that make things very quick to at least get a prototype out there and something compelling. And so I think at LLMs, certainly as a technology have helped us speed up our discovery process and learning what are the things that we can build here and how can we do it well?

And so, yeah, I think no doubt we've always been keeping an eye on every technology and what's coming. And of course, we've known about LLMs for a long time and been involved in various efforts in that area. And so yeah, it is exciting and it does feel like it speeds up your pace of learning and that has been really, really cool.

So, you know, we did launch Grammarly Go not so long ago. And that's been exciting to have our first generative AI user experience in the product. And I think we're gonna continue learning and seeing what we can do there. But, yeah, I think that's the main thing is it just feels like it speeds up a lot of cycles that before were a lot more manual.

Rebecca: Yeah. And I think I am definitely myself starting to just question, because I am a good writer and I have my own style and whatever, but that first draft I don't need to write it. I'll just write the second draft. And so yeah, it's really interesting to see how that's gonna change so many things.

Well, Heidi, thank you so much. This has been a delight, just like last time I talked to you a very long time ago. I hope maybe we can do it sooner than that again, and yeah, just really enjoyed our conversation today, so thanks so much.

Heidi: Likewise. Thank you so much, Rebecca. It's been a lot of fun.

Brought to you by
Helping you create better software development organizations, one episode at a time.
© 2023 Swarmia