Grammarly has a simple but ambitious goal: turn all of its users into great writers.
Their product has become synonymous with quality and working professionals the world over depend on the digital writing assistant to improve their grammar, catch spelling mistakes and write engaging content.
Until recently, Grammarly was focused solely on consumers and individuals, but that all changed when they brought Heidi Williams on board. Hired as the new Head of Engineering for B2B and Platform, Heidi knew that in order to keep up with demand her engineering teams would have to enter a hypergrowth phase.
Then the pandemic changed everything. Suddenly, in the midst of gearing up for an explosion of hiring and onboarding, Grammarly found themselves gearing up for the transition to a remote organization instead.
Listen to Heidi as she details Grammarly's sprint to become a remote organization, what it's like to build a product for the world's one billion English speakers and why it's so important to search for engineering talent outside of Silicon Valley.
Episode Highlights Include:
- Why diverse teams make the best teams
- Hypergrowth best practices in a remote world
- How to preserve team culture when you're not in the office
- Looking for talent outside of Silicon Valley zip codes
- Building an AI and ML powered writing assistant
Check out a clip from our YouTube channel:
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Transcription:
---
Dan Lines: Host
Heidi Williams: Head of B2B and Platform Engineering at Grammarly
---
Heidi: [0:00] I joined Grammarly about a year ago. The whole company was about two hundred and seventy employees, we have since doubled.
[Music]
Sponsor: [0:06] This episode is sponsored by Linear B. Accelerate your development pipeline with data driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at LinearB.io and mention the dev interrupted podcast discount for one month free when you sign up for an annual pro membership.
[Music fades out]
Dan: [0:26] Hey everyone! Welcome to Dev Interrupted. I’m your host Dan Lines and today I’m joined by Heidi Williams, head of B2B and platform engineering at Grammarly. Heidi thanks so much for joining the pod today.
Heidi: [0:41] Thanks a lot Dan. I'm excited to be here. It's always fun to do these kinds of things.
Dan: [0:44] Yeah, absolutely. Awesome to have you on. Now you've been an engineering leader for several years now, I always like to get into this a little bit in the beginning, what made you decide to make the transition from being an individual contributor developer to take a leadership career path?
Heidi: [1:03] Yeah, it's a great question and I know it's what a lot of folks struggle with. They wonder if you if you go there, can you ever go back, and so it's definitely been an interesting journey. First of all, I've been in the industry twenty-five years so when I got into management, it was quite a long time ago, but I really haven't looked back. I've loved it. I think it started as an engineer, I started getting more and more curious, not just about what we build, and how we build it, but why we build it, and so I wanted to get into more opportunities of helping connect engineering and product management connecting to customers. That sort of naturally lead to a management, and eventually engineering leadership role, so that I can be more involved in why we do what we do, and not just the mechanics of how and what.
Dan: [1:42] Yeah, I was gonna ask if you remember, when you got your first opportunity, you're an individual developer, you're coding, you're doing all that fun stuff. Do you remember what it was when there was someone like, hey, we need someone to manage a team of people? Or was it more like you really know the product and the customer? Was there like a tipping point for you that you had to decide, should I do this or not?
Heidi: [2:06] You know, it was a little easier transition than that. I think I was probably annoying, how many questions I was asking you about, why are we doing this, why are we doing this, and we did have a construct of team leads. And so, I became a team lead not officially having people report to me, but just working with Dev and QA pairs and helping lead a theme of our product forward. I was back on Dreamweaver back in the day to totally date myself.
Dan: [2:26] Oh, I remember Dreamweaver, yeah!
Heidi: [2:29] So fun! So there were just a handful of features that were all similar to each other around a particular product theme. And so I helped those Dev and QA teams do their planning and collaboration and figure out how to stay on schedule. And eventually I did, having done that, got tapped to become a manager on a different team, a brand-new team that we were starting since I had shown interest in wanting to be on the management track.
Dan: [2:50] That's how it happens most often. I had an interesting situation for myself, it was at the last company that I was at it was called Cloudlock, I was the second employee hired there in a development position, like individual I was doing like front end development. And I started doing really well, I was understanding the customer, therefore creating really good UI. And then I was also it was a small company at that time, I was also doing our support, and like our customer success. I remember I had a sit-down conversation with the founders and they were like, Okay, you can either keep being an individual developer, or we would like you to be like an engineering team leader, because it seems like you work well with people, and of course you understand the customer, which we really appreciate your technical skills are good, or do you want to make a switch and move organizations and come join us in the sales organization and start doing customer success in sales or technical sales. I thought about it for a long time talked with my father about it, I decided to go the engineering leadership path I didn't want to completely go the sales in lose, like all of my technical skills, but I also decided, I'm not going to be like an individual developer or some, I forget what they call that… Distinguished Engineer. At some big… I wasn’t that path, so that's how I decided the leadership path is for me.
Heidi: [4:19] That’s awesome.
Dan: [4:21] Now, if you, I want to talk about your path, eventually getting to Grammarly. Let's look back at your past so I know you've been a CTO, and co-founder. You've been the VP of engineering previously. You've led teams, like really small teams, I think with a small headcount, you've also led teams I've seen here, with hundreds of engineers, and now you're in this like hyper-growth stage at Grammarly. We got to know all about this. Can you walk us through these different experiences through your career path? Really cool.
Heidi: [4:59] Yeah, it's definitely been an interesting journey, and I feel like I'm never going to be done exploring exactly what's the right place for me to be. But if you think about, I started at Macromedia in the early days as an engineer, three hundred and fifty employees, we were pretty small. Eventually, we got acquired by Adobe, now it's a twelve thousand person company, and being a manager or a director in that kind of environment is totally different. Then I went to a smaller company, Box, I think seven fifty when I started, twelve hundred by the time I left, and was leading a pretty large organization there. Then went super super small and decided to found my own company, and so there were two of us for a very long time, back to hands on coding again, for the first time in 15 years, which is quite a trip, I will tell you, but honestly, the story I love to tell people is that 15 years ago, we did not have Google Open Source or Stack Overflow. so it's actually easier now than fifteen years ago.
Dan: [5:44] Oh, you actually had to know how to program 15 years ago, like you couldn't just have Stack Overflow, I understand.
Heidi: [5:50] Like copy and paste, yeah. And so I think in that journey of, sort of, company sizes and seeing where do you get to wear multiple hats? And are you wearing too many hats or not enough hats? Is it too narrow? I think I really decided that Grammarly is a great size for me because not every problem is solved, but there's also still a lot that needs to be done. I guess realizing that innovation and entrepreneurial has been a theme in everything that I’ve done and I just like being able to bring the platform and B2B experiences that I've had in the past to Grammarly and kind of work on a 1.0 product within a larger a slightly larger organization but still not enormous.
Dan: [6:25] Awesome. Yeah, we're going to get to the grammar like everything going on with Grammarly. I want to ask you about your VP of Engineering at Box, right?
Heidi: [6:34] I was, yeah.
Dan: [6:35] That’s exciting! I think everybody knows Box. When you came in, how many people were on the team, like the development team, when you were there?
Heidi: [6:43] Gosh that's a good question. I was not the VP of all of engineering, we actually had a couple of VPs. When I started there, I was Director of Engineering for a team of seven. Then the whole engineering org was maybe a hundred and fifty or one hundred and seventy, when I started, something like that, and we grew to nearly four hundred by the time I left. My sort of VP of engineering responsibilities was similar to what I'm doing at Grammarly. We were building a platform, there was box, the application, but how could you take this set of API's and SDKs and let anybody use the box service as the foundation of some other products that they were building or for integrations or things like that. And so it was really cool to basically be creating a brand new product and business model and sales motion and new customers and whatnot. And so that was, that team I don’t even know how big it was, by the time I left maybe seventy folks or something like that.
Dan: [7:33] Yeah, that sounds amazing. So I gotta ask you like lessons learned from your VPE experience at Box. Like maybe, worst decision you ever made while you were there? Best decision you ever made? Lessons learned; can you share anything like that?
Heidi: [7:50] Totally, I think that sort of highlights and lowlights are flip sides of the same coin. And maybe there's another lowlight in there as well, somewhere.
Dan: [7:57] Okay, let's unpack it, yeah.
Heidi: [7:58] Yeah, I feel like one of the most challenging things, especially about building a new product, and especially within an existing company, is there's that sort of needing to understand the business and needing to work cross functionally, as an engineering lead was really critical. I have this distinct memory that the business team from platform had started a little bit and then I was added to the business team as the first kind of engineering counterpart and a little bit into it, I had to raise my hand and ask a really stupid question, which was, what's our strategy? Like, who exactly is our target developer? And how many of them we want to be $100 million business? Is that one hundred million developers that don't pay us much or is that a thousand developers. So even though that was a really, it felt like a dumb question, we got ten different answers around the table and really quickly realized that we were not on the same page about what we were trying to achieve. I guess I would say that the highlights and the lowlights is, if you're not aligned, and you don't take time to think about alignment, you can really go off track very fast. And so we did some fascinating exercises to go figure out, where are we selling successfully? What use cases are working for people? Let's actually then use those use cases to enable engineering and product and marketing and sales and just 100% be aligned around what our platform is good for, and when people should buy it, when will they be willing to pay and what products should we build to support that?
Dan: [9:20] Yeah, I think at any size organization, I wouldn't even call the dumb question, it just feels like an obvious question, and everybody should know it. But when you really get into the details of what is the persona that we are building this product for? Do we know that persona inside and out? And does everyone else in the organization agree this is the right persona, or we all agree on it. I have a small company and up and coming company and co-founder of LinearB and we talk about that all the time to make sure everyone's on the same page because it can change and you're bringing in new people, you're building new features. I think that's actually just a smart question to ask, not really a dumb question.
Heidi: [10:07] It can be an intimidating one, though, for sure if it feels like everyone knows this but you, it's intimidating to speak up and say, I don't feel like I'm hearing the same story from everyone. I guess maybe also a short story about on the engineering side as well, when you're building platforms, it's really easy to say they're developers, and I'm a developer, so I know what to build. But I have always wanted to make T shirts for my engineers that say, “I'm not the customer”. Just remind you that you need to get out there and actually understand that the role of an engineer in an enterprise company is super different than an engineer at a software company. You need to understand the constraints that they work in, and what their motivations are, in order to build them the right product.
Dan: [10:46] I want that T shirt. Yeah, really good point like it because you can rock yourself to sleep like I'm a developer, so I know what developers want. But there's actually all different types of personas within the developer ecosystem of like, what size company are you working at? Are you doing this kind of development or that type of development? Being really precise there make sense to me. Now also, I know about, you were a co-founder of a company, right? What was the name of that, equitable or something?
Heidi: [11:21] It’s tEQuitable actually. I feel like I like puns, which is probably also why I ended up at Grammarly. But tEQuitable was meant to be we're putting the equity back in tech, was part of it, and then within tech quotable, the EQ stands for emotional quotient and trying to… ultimately what we were trying to do, we were building a product to help improve workplace culture, with the idea that we wanted to address bias, discrimination and harassment in the workplace. With that focus that, you think about your culture, company culture, as your operating system, you need to make sure that is the right environment in order for things like equity and fairness to an inclusion to actually thrive.
Dan: [11:56] What a nice mission, still resonates. What year were you doing that?
Heidi: [12:01] It was fall of 2017 until January of 2020, and the company is still going.
Dan: [12:06] Oh, okay. Okay, so it’s recent. I was going to say, still very in tune of, I think, what’s going on in the world now. Definitely a good mission there. Were you one of the original founders there?
Heidi: [12:17] I was, yeah. So my co-founder and myself, we've met in college and reconnected, she had this amazing experience of actually working under President Obama and was working for the Department of Ed as the tech core that they had brought into to, anyway, bring industry best pack best practices to the government. Anyway, we reconnected when she left that and I had already left Box and was looking for a new opportunity. So we joined forces and I think in the first week, we actually, before I even decided to really join the company, we filmed our Y Combinator video.
Dan: [12:50] Oh you went Y Combinator?
Heidi: [12:51] We had a little bit of pre seed funding from K4 capital and then we also got into Y Combinator and did that in the first whatever winter of 2018 cohort.
Dan: [13:00] And so did you join as, like, the first technical person?
Heidi: [13:04] My co-founder was also technical so we did a sort of, not exactly a coin toss, she really did want to be the CEO, but we have very overlapping skills in terms of being business oriented engineering leaders with computer science degrees.
Dan: [13:17] What I’m digging at here, I think what our audience would want to hear is, you gave some examples of being at a pretty large company actually, in Box, now we're going to the other extreme, I was assuming maybe you start with zero engineers and if you are responsible for building out that team, what did you learn from going from zero to something in terms of an engineering organization? Any lessons learned there?
Heidi: [13:39] Yeah, so interestingly, so over the two and a half years that I was there, I was actually the only engineer. We didn't yet get to building a team, unfortunately. We talked about it a lot, but I think the nature of the product that we were building, the sort of initial technical offering was not super complicated. The thing that is harder is to figure out how to derive the data insights, how to partner with customers, like yourself, I was just as much doing sort of customer support and customer service and helping give these sort of workplace culture reports and advice to small companies as much as I was doing the engineering side as well.
Dan: [14:14] Okay, awesome. And now finally, you're at Grammarly, and so can you give us a little bit of context of what's your team size? Or when did you come in? Did you grow it at all? And of course, any challenges or major lessons that we could take away from this experience that you're doing now?
Heidi: [14:32] So many questions packed into one we may have to repeat if I missed some of them. I joined Grammarly about a year ago, the whole company was about two hundred and seventy employees, we have since doubled. And my team has also I guess, grown but then also just recently created more focus for myself as well. Essentially, for folks who don't know Grammarly, we are a digital writing assistance that is AI and ML powered and we have always sold to consumers and to individuals. So when I joined there were two initiatives that we really wanted to work on. One was Grammarly business, which was our first product offering for teams and organizations, so that requires a B2B motion, sales, marketing, customer support, setting up that whole B2B Motion to be able to sell to organizations and create a product for teams. And then we're also building Grammarly platform, which is a way for developers to embed the Grammarly experience on their own SaaS applications, and so between both of those, that is my background. That's why I wanted to join Grammarly and so they have both involved, essentially the Grammarly business team went from, say, we had one manager and maybe five engineers, and now we're at twenty-two and we're hoping to double again in the near future. The platform team went from zero for several months to I think now we have a team of four and we're hoping to triple that by the end of the year if we can. So a lot of hypergrowth going on both of those and assembling people who have B2B and Platform experience from outside who can come in and rapidly ramp up on Grammarly and understand what do we have today? And how can we transform that in these two different business models?
Dan: [16:08] Yeah, excellent. So with the pandemic, is Grammarly totally remote, or what are you doing for workstyle?
Heidi: [16:15] Historically, Grammarly has been a very in-office culture, we actually were founded in Kiev, Ukraine, and so we have a large engineering office there. Then our headquarters is in San Francisco and we have smaller offices in Vancouver and New York. When I joined last July, having never met anybody in person, everyone was saying, we're all going back in person, we're just going to wait till it's safe, and we kept creating a plan of is it going to be August is it going to be January. And then in June of this year, basically, we've all been remote, we've all been successful, we're learning a ton about what does it take to actually communicate effectively and collaborate effectively in a remote world. Then seeing where the workplace trends are going, we made the decision to flip 180 degrees and decide to be remote first hybrid. I'll unpack those a little bit, which essentially means that everyone will work from home, you are not required to come to the office but we are going to keep our offices as co-working spaces and collaboration hubs for people who do want to come in and or feel like they don't have a great workspace set up at home. Then we will encourage folks to get together a couple of weeks every quarter just for those specific things that we think are really good for in person collaboration, like brainstorming and innovation and maybe strategic planning and things like that.
Dan: [17:31] That’s really cool. We're actually doing a similar thing at Linear B with a hybrid. We're hiring remote, you can work remote, but we're thinking about hopefully, some positive things will happen with the pandemic. We’re having a little regression while we're doing this call right now. But as things maybe open up a little bit, go with that co-working offering as options, so I think that's a really good move. Did you say your team is in Ukraine or like where's everybody located?
Heidi: [17:56] Yeah, so about half of my team is in Kiev, Ukraine, and the other half is in North America spread out in different states.
Dan: [18:06] hearing a lot of people with teams in Ukraine. I love Ukraine. I think the developers there are awesome. I've been to Kiev, I used to have a team there, like really smart people working there. How have you dealt with the transition to the remote as an engineering team?
Heidi: [18:19] Yeah, it's definitely been interesting. I feel like the company has been super thoughtful. Actually, my husband worked at another company, I won't mention which one it was, but he was like “our company doesn't do that!”. And so we've done a lot of things to sort of make sure that people still feel that personal connection. Making sure that there are fun events, team events, care packages that arrive monthly for teams, really celebrating everybody's individuality, which is really cool. So maybe October I think it was October we celebrated Diwali by having an Indian cooking class so that we could all learn how to make saag paneer, all gone on Zoom together, our kids were there, chopping spinach and whatnot. We’ve tried to have events that encourage people to take a break from work and not just work twelve-hour days without stopping. Encourage people to take time out to have lunch with their kids if their kid is at home for school during the year. I think we've done a really good job of celebrating the fact that now work and home have so much overlap you need to force people to know that it's okay to take a break and to create space, whether you're a parent or whether you're a caregiver, or whether you're single and have 10 roommates or whatever it is how can we make it so that people do take a break? Have fun? We have these coffee chats called donut conversations where we send people gift cards to go buy a coffee and then get together on Zoom and get to know each other. It's been an interesting process. I've onboarded fully remotely I've only met four of my co-workers in person.
Dan: [19:41] Yeah, some great tips there. I think of different companies are taking advantage of some of the tips that you said there. I have heard like the coffee talk type thing. I like the gift card idea. I also heard hey, there's some delivery services that will deliver all around the same time so that arrives at the door bring your coffee or your cocktail. Usually, it's an alcohol service like your cocktail. Let's all try to meet each other and talk a little. So, you know, some good stuff on the people side there, on the technical side and working together and how you work, what tools or strategies are your team's using to either develop successfully remote or communicate remote? How are you getting work done?
Heidi: [20:24] Yeah, yeah, it's a great question. I think there's been a proliferation of new tools out there for people to try. We try to be async as much as we can, obviously don't want to be in zoom meetings all the time, there's a lot of that Zoom fatigue, but at the same time, we also want to be transparent about things. I think we do what a lot of folks are doing, which is recording your zoom meetings, and making sure to share those and open Slack channels so that information is discoverable or using typical tools like Confluence and JIRA, we're using Miro for brainstorming sessions and also for whiteboarding. We're using Figma. We're using Parabol for team retrospectives. So as much as possible, we're trying to find ways that we can not only digitally support the important things like team retrospectives, but also then have a recording of those so that we can refer to them later, and remember, the action items or the things that we wanted to try next. I think that's really been the key is, being transparent expectations and processes, trying to be really thoughtful about onboarding. I guess one thing I will say about onboarding is making sure that engineers feel like they have the time to get to know people and get to know the services before they feel the pressure to deliver. I think that has been a key first step in getting people to onboard.
Dan: [21:33] Totally makes sense. Are you using anything for workflow optimization, meaning everyone can have transparency into the work, workflow optimization being more like someone's waiting for a pull request or it's like the works on you or asynchronous pinging, that kind of thing?
Heidi: [21:50] Yeah, I think it varies team by team, I think different teams have figured out where they have pain points that like I said, we're at an interesting point in hypergrowth. We also, I think for example, we don't have productivity engineering, but we're probably on the cusp of saying maybe there's enough friction, like the tax on every team is a little too high, it's time to centralize some stuff like that. We're starting to explore what we can do there. I guess what I've seen is people automating things like writing a Slack bot that helps them process incoming on call questions and issues. Then they can look back at the data to say, oh, my gosh, do we need to have a project around this? Or maybe we need to improve our documentation around this so we don't get as many questions. That's the kind of thing that I'm seeing, I think otherwise, I feel like teams are just managing themselves to see if they're getting the productivity and outcomes that they want.
Dan: [22:35] We've created a feature for our customers at LinearB called WorkerB that's actually for each developer on an engineering team that pings them over Slack. Slack, Bother MS teams, it pings them, hey, someone's waiting for changes from your pull request, or this is ready now for you or, hey, your work just got released to production. Because what we're finding is some teams were already remote, but most weren't and so when you're all start working remote, and you have all this engineering work going on, it's hard to keep a single pane of glass or like transparency of what's going on, so we found that to be really useful.
Heidi: [23:14] Yeah, yeah for sure, and I can see that as well. I think teams have-have figured out how to create that visibility for themselves. But it's interesting, I guess I will say, working across North America and Ukraine, you have to be thoughtful about when to think people just because you finished working at midnight, the other person might be asleep and you don't want to wake them up as if it's a feature alert. No, you want to figure out okay, let's make sure that we schedule the thing to the first time, first part of their morning and their-of their day. And so it's interesting, new, different constraints [crosstalk][23:41]working with that perspective.
Dan: [23:41] Yeah it’s a good thing with like the chat, like Slack and stuff when their time zone is and you can get them the message and not pager duty them?
Heidi: [23:52] [Laughing] Exactly.
Dan: [23:53] Are you doing any, do you follow any metrics for your team? Do you look at any engineering metrics, and if so, what?
Heidi: [23:58] Yeah, yeah, I think we're actually very oriented around a couple different things. When we think about team health, there's a couple different pieces to that. There’s, how do the individuals and the team as a whole feel like they're collaborating? Are they productive? Is there conflict? Do they feel like they can rely on each other and get things done? There's the other piece, hypergrowth, we're always caring about hiring and not only hiring, but are you onboarding folks successfully? Can they push code in the first week? And that-that's a signal that your environment and documentation is set up in a way that people can be productive quickly and onboard and whatnot. And then the last piece is definitely the actual, you know, product metrics. So not just quality metrics, and uptime and issues and things like that, but also outcomes. What are the sort of service level metrics or the user metrics for Grammarly? Business, for example, is very much around, are people adopting our features? Are they engaged? Are they getting text checks on a regular basis and accepting the suggestions that we're sending? And so we really try to focus on the outcome and the value for the user as the key metrics for engineering.
Dan: [24:55] Yeah, awesome. Thanks for sharing that. Now You've been alluding to or they're talking to this a little bit but I know you're evolving from a 1.0 to a 2.0 product. You're introducing brand new business models. I'm sure it's a big challenge. You're doing all this interesting stuff at Grammarly. So, can you tell us about that 1.0, that 2.0 and how you're making it happen?
Heidi: [25:18] Yeah, platform and business are both on slightly different parts of their journey. I think of platform as being very zero to one and I think Grammarly business is one to ten and the rest of Grammarly is ten to a hundred. So we're doing it all at once, but yeah, it's interesting. I think the big thing really that's-that's a fun sort of transformational challenge is how to make sure we're all speaking the same language. If you use the word virality, or network effects, or even if you use the word go to market, but I think being able to translate from the business side to the engineering side is a really fascinating one, and vice versa honestly. I always think about, okay, if I have to write a post incident review for executives, like how do I explain cascading failures and thread pool exhaustion to the executive team to explain like what has happened or what not. So there's that translation and recognizing that not everybody is using the same lingo and is going to interpret it the same way, so I think that's been an interesting challenge. I guess it's also meant that we've introduced new kind of job functions that we didn't have at the company before. So introducing sales and demand generation, we had lifecycle marking for-marketing for individuals, but now we're talking about expansion, as opposed to just having one person renew that-renew their seat, so that's been interesting. And even on the front of user research, to get into the sort of technical side, as a consumer company, you can look at a billion data points and make decisions about that, and that is useful, but when you're doing enterprise, you have to be comfortable with getting 10 to 12 data points from having talked to customers, and they're more qualitative than quantitative. And you have to feel comfortable that those are representative because maybe your audience is more similar. And it's okay, twelve data points is actually as representative whereas otherwise, with consumers, it's so broad, you need a million data points in order to feel comfortable that you're making good decisions.
Dan: [27:01] Totally makes sense. You mentioned, I think you said in one area, you're going from zero to one, Is that on the platform side?
Heidi: [27:11] On platform side, yes.
Dan: [27:12] I want to-Okay, I want to know about that because going to zero to one jump is always, I think, tougher than like one to something else.
Heidi: [27:19] Yeah.
Dan: [27:20] So, this is the platform side of Grammarly, because when I think of Grammarly, I think I use it for like email, like individual consumer, edit my email. [Crosstalk][27:29] Yeah, something like that. And so the platform is a whole different thing and you're building it from scratch. Tell me about, what has been your worst decision so far? That-something bad that happened from the zero to one, and flip side, what was a decision that you're like, oh, this really helped me, like a great decision.
Heidi: [27:29] That’s right, yep. Yep.
Heidi: [27:50] Oh, my gosh, those are both really hard, because I think we're still early and we're not sure yet. Which ones were the bad ones and which ones were the good ones? [Laughing]
Dan: [27:56] You’re going to find out. [Chuckles]
Heidi: [27:58] About to find out. Yeah, I guess one I think that's interesting is, maybe this, I don't know, I'll be very self-critical for a little bit, which is, I think that we had the idea about platform before we were able to put all of our effort behind it, for a while. And that I think we could have been doing more user research early, customer research, partner research early, to understand what the need was and what people were asking for. And also thinking about, maybe we had started with thinking about the value to us, and we needed to think about what is the value to partners? What is it that they're going to get out of it? What do they need? So I probably would have done that a lot earlier, I would say we really started the platform efforts about six months into when I joined, and I think we should have started that a little bit earlier. And again, like going and doing that customer research, as opposed to looking at our own data points or something like that. I think that's something we should have done early. Because I think we're seeing so much interest and excitement, and it's really exciting early Product Market Fit signals that if we'd had them six months earlier, we would have moved faster to start develop.
Dan: [29:01] Sure, sure. And on the other side, is there a particular like move you made or a decision where you're like, yeah, that that worked well? And I would want to tell other people about it.
Heidi: [29:12] Definitely, definitely, I think once we put our minds to it, actually finding a couple of partners that all were coming or inbound organically to us and saying, but do you please have an API or an SDK or something that I can use, I really wanted to experience for the writers on my platform or something like that. So engaging with them early and saying, yeah, let's be nimble and quick and give them something just so they can poke at it. And I think putting a stake in the ground even though it's not going to solve everyone's problem but having something for partners and developers to poke at and give you feedback along the way. And I think that's been hugely instrumental with just a small handful of partners poking at this mostly incomplete thing to give us feedback about what value they get, what their users get in terms of value and whatnot. It's been really fascinating.
Dan: [29:57] So I'm gonna switch the topic a little bit here. You have been mentioning that at Grammarly, you're in this hypergrowth mode, you’re remote first, it's probably providing the opportunity to maybe acquire more talent or hopefully better-quality talent. How do you see offering work from anywhere differentiating hiring at Grammarly and moving forward?
Heidi: [30:21] Yeah definitely, I think a lot of companies are seeing this, that it's almost feels like it's a candidate's world right now. They have their choice of wherever they want to work, and there's such a wide range of companies offering remote first or hybrid or in person or whatnot. And so I just, I'm really excited that…I'm a big believer that, I'm gonna mess up the quote, but basically, that you don't have a higher percentage of genius in some particular zip code than another. So I'm really excited to look at all the zip codes across North America and across different geographies, to find that hidden talent that has quality of life somewhere else, that's not Silicon Valley. And so I think that leads to a lot of diversity. And that, whether it's racial, whether it's ethnic, whether its economic, whether you're an immigrant, you're a parent, whatever it is, I think there's diversity that can be found. And I've always been a huge believer in diverse teams for two reasons. One because, for sure, diverse teams solve problems better than homogenous teams, and it's been proven with studies, and so you come out with better outcomes, and you harness that creative conflict and those differences of opinions and those difference of perspectives, and you can really build better products. And that sort of related to the fact that as a writing assistant, a communication assistant for the world's 1 billion English speakers, we need to have a pretty diverse team to be able to understand and relate to the end users of our product, and especially in the world of AI and ML, and being ethical and thinking, being thoughtful about what you're building, you need to have a diverse team in order to build the right product for that broad of an audience.
Dan: [31:52] Yeah, absolutely. What does your hiring process, like the details of it, look like? What are the stages and how does it work?
Heidi: [32:01] Yeah, yeah, I guess at a high level, it probably looks like any company, but at the same time, I've been really happy with the kinds of tools that we put in the hands of recruiters. So we have a-there's a tool called SeekOut, which does a really great job of looking for diverse talent, it has AI and ML on top of LinkedIn search, as far as I can tell, that's what they've built. Yeah, we're also you know, partnering with-with job boards that are part of underrepresented communities. So there's ELFA for women in tech, Lesbians Who Tech has a great job board, we've participated in AfroTech and so I think we look for opportunities to look for underrepresented talent in other places, I think you have to double down on that, because organically, you will get over-represented talent coming to you by themselves. So you need to go “seek out” which I guess is why they call it that product, you need to go find the underrepresented talent the sort of underestimated talent in other geographies by giving your recruiting team different tools. But other than that, I think the rest of the process is we try to have a really thoughtful interview process, we get a lot of feedback that people appreciate that our interview process gives them a great sense of who we are as engineers, who we are as a company culture, and gives people a great-a great chance to just interact with their coworkers before they join and that's often the tipping point for why people end up joining Grammarly.
Dan: [33:17] Great. You've scaled engineering organizations, you've been in a hypergrowth mode from a people perspective, a lot of our podcast listeners are in the same situation where they're being asked to rapidly scale their team in a high-pressure situation. What lessons could have you learned when you were in that situation and needed to scale so rapidly?
Heidi: [33:40] Yeah, I guess there's all the pieces that you need to do to actually go find people. So a lot of our hiring managers are learning how to be good sourcers, how to send interesting messages and encourage people to come join their company. And I guess I would say the personal touch there is really important that you-that someone feels like they're making a personal connection with you and if you just rely on your recruiters, you might not get there. I think if you do your own outreach and your own initial calls with people, I think that makes a big difference. I guess the flip side, I would say, the hard part after you found these people is making sure that your current team is not falling apart, [crosstalk][34:12] because you don't want to neglect them while you're out doing ten hours of interviews and things like that.
Dan: [34:12] Right!
Heidi: [34:17] So really making sure that you're spending time on team health, that everyone is stable, that they feel like they're in a good place, that they feel like giving them as much autonomy as possible so that if you step out for a few hours, they're not going to fall apart. Like they'll feel more empowered anyway, so just making sure that they are set up for success if you need to spend time on sourcing. And then being really thoughtful about pulling the people together, the new people and the existing people doing things like having a buddy program and a mentorship program and setting expectations around, the team is going to have to reform a little bit and share our expectations and norms with these new folks and make sure that they integrate well and they’re well supported. And I think everyone gets this appreciation of yes, you're not going to be the star coder on day one and that’s okay. We want you to sort of get to know us people, build respect and trust and vulnerability with each other before we then start working on projects together. So I think that's really important, that integration piece.
Dan: [35:08] Do you have a defined the ramp-up or onboarding program that you created? Or how do you think about it?
Heidi: [35:15] It's evolved organically, actually. So when I started, the manager of Grammarly business, who started just a few months before I did, he created this great getting started guide and it really quickly caught fire across the organization. And it was just a really great one-page document with all the links, all the resources, all the expectations for day one, week on, month one, who are the key people to meet, context about their teams, encouragement that the first week is all about meeting people and getting your first line of code push and things like that. So I felt like that was a really great grounding document that now has spread company wide and translated to other organizations beyond engineering, but it's just a great like when you're losing your mind and your first week, what the heck am I supposed to be doing? I'm not productive and adding value yet! You can go back to that document. No, I agreed with my new manager, my first week is all about meeting people and pushing code. And then in the first month, it's a sort of expanding my knowledge and doing a small project and things like that. So we just helped people… I don't know, I felt when I started, I was very nervous about not adding value right away, and it was really nice to just be on the same page that that was not the point initially, it was just to get to know people and build relationships.
Dan: [36:25] Yeah having that, put it all on the table, this is what we expect, hey, you're supposed to go and build relationships. That's probably really nice to hear, and probably a good kind of a recruiting pro for coming to Grammarly. And you're trying to do your candidate sourcing in a diverse way. And then we talked a little bit about onboarding. I want to close it out around retention of employees, because you also want to keep the people that you have been spending so much time recruiting and getting ramped-up. Is there anything unique, you think, about the Grammarly culture for engineers that would make engineers want to stay for a long period of time?
Heidi: [37:08] Yeah, certainly, we care a lot about autonomy and empowering teams and just one thing that I'll note is, and I think a couple of companies do that do this, but in slightly different ways, so we do have internal titles, everyone knows what level they personally are at but titles are not public. So you're basically a software engineer, or a manager, And that's all that people really know about you. And so what's great is that good ideas can come from anywhere, opportunities to lead projects can come from anywhere and be given to anyone and there's no sort of deferring to the person with the highest title because they should know better, because they've got that title, it really gives the opportunity for people to just have an [stumbling] equal, even playing field with each other when they're having discussions, having debates, having conflict, and they can really just focus on solving the problem and not worry about who's the leader and who's the follower. So I think that's pretty special about it and I think it just creates a great environment when combined with autonomy and empowerment that people can have a good idea and advocate for it and we can find ways to help them work on that.
Dan: [38:08] That's what you want to do as an engineer you want the opportunity to create, and to innovate and get your work out there so it sounds like the culture is right on point at Grammarly. This has been a really great conversation. Heidi, thank you so much for taking us through your journey and engineering, diving into what you're working on at Grammarly and sharing all the strategies for being a successful engineering leader with us today.
Heidi: [38:33] Thank you Dan, it’s been a lot of fun.
Dan: [38:34] Now, as-as we've already talked about, you are hiring. So if I was interested in joining Grammarly, like where should I go? What should I check out?
Heidi: [38:44] Definitely check out our careers page on grammarly.com/careers and also our blog has a lot of interesting information. I think people don't realize how complex the things are that we're building, all the AI and ML that's underneath the amazing suggestions, not just error correction but things like reflecting your tone to you and whatnot. So check out our engineering blog as well has lots of info on how we've put all the magic into-into what we built.
[Music fades in]
Dan: [39:10] Absolutely. So everyone be sure to go check out the Grammarly career page. We'll include all of the information in the description below. Also a quick reminder for our listeners. If you haven't already reviewed the show please take 60 seconds, reviews are a crucial way that our show gets discovered. Also, be sure to join the Dev Interrupted Discord community. That's our community where we keep this type of combo going all week long and yeah, back to you, Heidi Happy Friday and again, thanks for joining us here.
[Music fades out]
Heidi: [39:43] Likewise, have a good weekend.